Imagine there's a company A that releases a new graphics adapter. Who manages the process that results in this new graphics adapter being supported by the Linux kernel in the future? How does that proceed? I'm curious how kernel support for any new hardware is handled; on Windows companies develop drivers on their own, but how does Linux get specific hardware support?
Linux – How is new hardware support added to the linux kernel
driverskernellinux
Related Solutions
Open source drivers are getting pretty good these days. I haven't had any problem with Intel or AMD hardware.
Intel
I hear the old ones are pretty bad, but my G4500HD does everything I need well. Video acceleration could be better though. There isn't a proprietary driver for Intel either, your only choice is open source. The composited 3D desktop in KDE works great on my laptop which has an Intel chip.
AMD/ATi
Right now the older cards are better supported than the new ones. If you could somehow get an x1800 or something from the same generation that would probably be the best. The r300g
driver is getting more development work than r600g
. That's not to say r600g
is bad, in fact it's great! It's just somewhat behind the driver for the older hardware. AMD has a proprietary driver for the new hardware, but in my experience you want to avoid it; it's pretty bad. The hardware covered by r300g
isn't supported by that driver, so the open driver is your only option there. And like the Intel chip I have, my Radeon 4850 runs the composited desktop in KDE well.
At the moment, I wouldn't recommend an HD6000 series. The 6900s have no support at all in the open driver, and the others have basic support. Go for an HD5000 or an HD4000.
Nvidia
They have a really good proprietary driver, but the open driver is struggling along. It's getting better all the time, but Nvidia is doing nothing to help the developers. At least AMD helps out a little bit for their hardware.
The advantage to having an open driver is that it will work out of the box in any distro. If you install Fedora, everything will work including dual screen and 3D. The proprietary ones are painful to setup. Neither of them properly set up my dual screens. It was easier to setup with Nvidia which isn't saying much because the AMD blob was just awful at this. Also, anytime you update the kernel, you have to reinstall the driver. Most distros take care of this if you install the in-repo version, but if you don't it's annoying to boot up one morning and realize you updated the kernel and now X.org doesn't work.
If you aren't planning on playing 3D games, either the Intel or AMD drivers are the best. The AMD driver is more modern than the Intel one, it uses the Gallium3D architecture within Mesa (that's what the g
stands for in r600g
), but they both get the job done.
The short answer is no.
The driver support for the same kernel version is configurable at compile time and also allows for module loading. The actual devices supported in a distro therefore depend on the included compiled in device drivers, compiled loadable modules for devices and actual installed modules.
There are also devices not included in the kernel per se that a distro might ship. I have not run into problems lately, but when I started with Linux at home I went with SuSE, although they had the same, or similar, kernel versions as RedHat, SuSE included ISDN drivers and packages "out of the box" (that was back 1998).
Best Answer
Driver support works the same way as with all of open source: someone decides to scratch their own itch.
Sometimes the driver is supplied by the company providing the hardware, just as on Windows. Intel does this for their network chips, 3ware does this for their RAID controllers, etc. These companies have decided that it is in their best interest to provide the driver: their "itch" is to sell product to Linux users, and that means ensuring that there is a driver.
In the best case, the company works hard to get their driver into the appropriate source base that ships with Linux distros. For most drivers, that means the Linux kernel. For graphics drivers, it means X.org. There's also CUPS for printer drivers, NUT for UPS drivers, SANE for scanner drivers, etc. The obvious benefit of doing this is that Linux distros made after the driver gets accepted will have support for the hardware out of the box. The biggest downside is that it's more work for the company to coordinate with the open source project to get their driver in, for the same basic reasons it's difficult for two separate groups to coordinate anything.
Then there are those companies that choose to offer their driver source code directly, only. You typically have to download the driver source code from their web site, build it on your system, and install it by hand. Such companies are usually smaller or specialty manufacturers without enough employees that they can spare the effort to coordinate with the appropriate open source project to get their driver into that project's source base.
A rare few companies provide binary-only drivers instead of source code. An example are the more advanced 3D drivers from companies like NVIDIA. Typically the reason for this is that the company doesn't want to give away information they feel proprietary about. Such drivers often don't work with as many Linux distros as with the previous cases, because the company providing the hardware doesn't bother to rebuild their driver to track API and ABI changes. It's possible for the end user or the Linux distro provider to tweak a driver provided as source code to track such changes, so in the previous two cases, the driver can usually be made to work with more systems than a binary driver will.
When the company doesn't provide Linux drivers, someone in the community simply decides to do it. There are some large classes of hardware where this is common, like with UPSes and printers. It takes a rare user who a) has the hardware; b) has the time; c) has the skill; and d) has the inclination to spend the time to develop the driver. For popular hardware, this usually isn't a problem because with millions of Linux users, these few people do exist. You get into trouble with uncommon hardware.