OT: For all the Window haters

I am talking about drivers for devices like multiport serial/parallel cards. When you find a serial card on a far-east webshop, that advertises "with Linux driver", you will normally find a .tar.gz file on the small CD in the box that you are supposed to unpack and compile as a module with your current system.

I can tell you from experience: there is ZERO chance that this is going to work. The Linux developers make changes in the driver architecture willy-nilly, and the compile will fail with missing include files, missing defines, differently named structure members, and the like. It worked on the system of the developer as little as 1 year ago (often 3-4 years), but it is not going to work today.

The hardware manufacturers do not update their drivers every 6 months, and so your device is not going to work.

On the other hand, a number of such drivers exist in the kernel source tree, and they do work. So, chances are that your device will just work when you plug it in (whereas it would not work under Windows until you install the driver, as Windows does not include any such specialist drivers like Linux does).

When it does not work and cannot be made to work by just patching some PCI ID table, just toss it in the bin! It will be a never-ending battle to get an uptodate driver that works with the current kernel and will still be working after a kernel update.

Some commercial vendors of video cards and other such more common hardware go to great lengths to keep their driver compatible with those kernel changes without getting it integrated in the source tree. That is a lot of work, and it is actively counter-acted by the kernel developers. That is unfortunate.

In Windows, there is more compatability in the driver interface and sloppy manufacturers can keep distributing a working driver for longer than is possible with Linux.

In the old days, manufacturers avoided this problem by sticking to a de-facto standard chip/functionality for a certain device. Like all the serial cards acted like a 16450 or a number of those. That is no longer true, so you always need a matching driver. It has happened to me that I ordered a 4-port serial card in China (for like 25 euro, so no great loss) that is advertised with a certain chip for which I first checked there is a driver in Linux, then I get the card shipped and it contains the next revision of the chip for no working driver exists. So it is kind of hard to deal with.

There's some serious pain you have there.

The driver APIs don't change willy-nilly but do change. It's all discussed on the kernel mailing lists but if you don't follow them then it can come as a surprise.

Assuming the driver was complete and did compile at one time then making it compile for a new kernel is just bit-rot fixing. If you are trying to move from a 2.6.9 kernel to 3.17.0 you'll be in for some serious fun and games. Most of the time it's tedious stuff but not impossible. But as I do it as part of my job, I suppose I'm used to doing it.

You are telling me that when I want to buy hardware that requires a driver, and that says "driver for Linux included", I need to track the kernel developers to be alerted that they again are breaking things?

If the driver is old, kick the people who wrote it, not the kernel devs. Its part of the driver maintainers job to track kernel changes and update their driver as needed. Thats no different from doing their other jobs, i.e. fixing bugs and updating their drivers as the chips in their hardware change, e.g. everybody whose display hardware used 8250 UARTs probably had to upgrade to 16550s at some point.

Of course it is not surprising that people stop supporting Linux drivers when it works that way... they see writing a driver as part of the development of a new piece of hardware, finished when it is released. Not as a lifetime commitment to track whatever the Linux kernel folks are up to this week.

But if it's open source then whoever cares about it working can keep it updated, or pay somebody else to.

In this case you're talking about hardware where the advertising says says on the box 'driver for Linux included', so its *highly* unlikely that the developers are unconnected with the hardware maker. Since the drivers are part of a product, you're fully entitled to expect that they will be covered by the guarantee.

If the kernel changes during that period, you're entitled to expect that a revised driver will be made available for download: that's SOP for reputable firms.

Still wouldn't have actually produced a usable display, since those are in fact Serial port UARTS.

My ADM5A is currently driven by a 16550 UART under Linux and can display asciipr0n !

Mosatly making a driver work with a new kernel is as simple as recompiling it with the new headers etc.

Its not that hard.

And the distro people normally do that as a matter of course *if* they have the source.

Where it breaks down is when te hardware manufacturer wont release source or even linkable modules so the driver is as it is and whether it works is pot luck.

Yes, of course I know that. Picked as an example of a hardware enhancement that most people would recognise and that almost certainly forced a driver modification when it was introduced.

Switching non-graphical displays away from MC6845 CRTC chips (which were widely used with non-Motorola chipsets too) to more complex, functionally integrated chips would be another example.

I challenge you to get the WCH Multi-I/O Board Device Driver, which supports many kernel versions up to 3.6, compiled for a recent kernel. It is not that hard, you claim. So prove it.

No, where it breaks down is when the kernel developers change the driver interface all the time and existing drivers, with full source, fail to compile.

Also the kernel developers do not provide the change documents that specify how existing driver sources have to be modified for the new driver interface. So every driver developer will have to find out themselves what has changed. In the above case, the whole method of linking data structures to device instances has been overhauled, and getting the driver to support that is not a simple matter of recompiling with new headers.

Well if you want to be obtuse, go ahead. Saying "driver for Linux included" is as meaningless as saying "driver for Windows included".

Ain't life a bitch.

Some of us just get on and find the changes and fix the driver. As I have said many times, that's part of what I get paid to do so I don't find it too challenging.

If you are talking about a device made by a no name Chinese firm which is a copy of a copy of a copy, you have to treat it as disposable and chuck it when anything changes on your machine.

You need pay a bit more than rock bottom and buy from someone who is likely to develop new drivers for new versions of the OS, of whatever flavour, and just as importantly produce security updates for the life of the device.

---druck

On Sun, 9 Aug 2015 16:55:44 +0000 (UTC), Martin Gregorie declaimed the following:

Based on the description (wikipedia) a driver modification would only have been needed to properly make use of the FIFO buffer controls (and, apparently, a bug in the original chips made the FIFO unusable, anyway). Otherwise an 8250 driver should have seen no significant difference.

Now... working with the late 70s era AY-5-1013 UART in my parts pile would be another miracle (along with the 8 21L02 static memory, related UV EPROM, 8228/8080A chips -- my college digital electronics course never did get to the point of assembling those chip evaluation kits into something S-100 compatible).

The driver is actually written by the maker of the chip, not by the firms that make the boards. All makers of such boards ship the same driver CD with it.

Nice to hear your opinion, but I want to point out that those concerns apparently do not apply to Windows users. They get the driver, written at the same time (in 2012) as the Linux driver, and it just works.

Why? Because Microsoft do not change the driver interface every few months, so the developers do not have to play catch-up.

Anyway, I think the discussion is irrelevant.

My point is:

- Linux provides more included driver support than Windows

- Linux normally works fine after install, for Windows you need to hunt for drivers.

- When for Windows you need a driver not included, you are likely to find it.

- When a driver is not included in Linux, you are in trouble. A driver you download separately is unlikely to work and even less likely to remain working over the device lifetime.

That still holds after all those remarks about how driver developers are to check the kernel mailing list every morning at breakfast and how buyers of hardware are responsible of making sure those developers actually do that now and in the future.

Logitech, you would think, fall into this category but I have keyboards with unusable extra multi-meeja buttons and no longer have webcams which have become driverless and have been thrown out.

Logitech has become over-priced crap with built-in obsolescence and are off my shopping list.

Those (webcams) will mostly work with linux.

Multimedia buttons cane be easily remapped as well.

Biggest problem with my logitech web cam is that its fine with Linux, but the BIOS spends two minutes on boot deciding it doesn't understand it.