Have the drm.git kernel modules been abandoned?

[RealNC]

As title says, will users be forced to use in-kernel DRM drivers? I saw a message in Gentoo's repo that those kernel modules will be removed from it due to upstream not supporting them anymore.

If yes, that's pretty sad; driver updates will be tied to kernel upgrades ("upgrade everything or nothing, sucker.")

[bridgman]

Practically speaking, yes. As the rate of kernel change increased the effort required to keep out-of-kernel trees working with a variety of kernel versions increased as well, to the point where it became impractical with the available manpower. Support for new hardware is still sometimes backported to older kernel trees, but in general people seem to be picking up new kernels more aggressively for other reasons, typically to enable support for some *other* new hardware.

On the other hand, most of the driver functionality is still in the user mode driver components. You need to pick up new kernel versions frequently while the graphics stack is going through these big changes, but once things settle down I think you'll find things aren't much different from before.

[nanonyme]

Dunno how big a part it played with all of this but having a separate DRM tree that has to be kept compatible with all future and past kernel versions very fast ends up as a Bloody Mess. Also sooner or later you start having failures at forward-ports to new kernels only being partially complete so users who are using DRM modules from repo experience completely unexpected and unexperienced bugs by devs who are using stuff that's ending in and exists in kernel. The code gets much clearer and better maintainable and expandable if it stays without compatibility hacks. The old approach gave an illusion of a static API/ABI (which never existed except throughout compatibility hacks), now things show all the way to end-users more like how they really are.

[RealNC]

It's nothing tragic, just a deep personal hatred about the way drivers work in Linux :P They come as a "big, fat bunch", all inside the kernel. Reminds me of those "super duper 846-codecs pack" on Windows; I hated those too. Drivers should be separate entities. But I guess since Linux totally lacks a driver interface, we have to live with it.

[lbcoder]

It's nothing tragic, just a deep personal hatred about the way drivers work in Linux :P They come as a "big, fat bunch", all inside the kernel. Reminds me of those "super duper 846-codecs pack" on Windows; I hated those too. Drivers should be separate entities. But I guess since Linux totally lacks a driver interface, we have to live with it.

You don't know about loadable driver modules? Drivers do NOT need to necessarily be "built in" to the kernel. They can be built outside the kernel and loaded in on an as-needed basis, the same as that *other* (junk) OS. Sure they have to be built against relevant kernel source, but same thing goes again with that *other* OS -- when was the last time that you saw a driver that truly worked for more than one version of microshod? Now where the loaded kernel modules really shine is in enterprise linux, i.e. RHEL, which maintains a single kernel version across all updates to a major version and thus modules remain compatible. RHEL6 will have a new kernel version from RHEL5 and therefore will require all new drivers.

Now one of the big reasons for keeping the driver source with the kernel is this; it means that when you install the latest kernel, you get all the drivers for everything. WHY would you want to have to go on a driver hunt? Aren't we beyond that? Leave that driver hunting nonsense to microsheep.

[RealNC]

You don't know about loadable driver modules? Drivers do NOT need to necessarily be "built in" to the kernel.

How can I *not* know about them. You totally missed my point.

Now one of the big reasons for keeping the driver source with the kernel is this; it means that when you install the latest kernel, you get all the drivers for everything. WHY would you want to have to go on a driver hunt? Aren't we beyond that? Leave that driver hunting nonsense to microsheep.

You really don't get it. I don't want driver hunting. I want drivers without having to either wait for the next kernel release (why the hell should I wait for the *whole kernel* to be updated if I only want a single driver?) or needing to update to the next kernel release.

Instead of driver hunting, in Linux we have kernel hell. Something in the new kernel doesn't work for you? Some nasty regression? Too bad, sucker. You need to downgrade to an older kernel and by doing so downgrading *every* freaking driver too. It's all or nothing. That is what I call brain damage.

[nanonyme]

Instead of driver hunting, in Linux we have kernel hell. Something in the new kernel doesn't work for you? Some nasty regression? Too bad, sucker. You need to downgrade to an older kernel and by doing so downgrading *every* freaking driver too. It's all or nothing. That is what I call brain damage.

One option is to use a distro which has capable and patient developers who backport features to older kernels but still avoid breaking anything. (a lot of the time requires they actually understand how the drivers work themselves)

[chithanh]

I guess that distros will start taking code from the kernel and drm-next and backport into their distro kernels, as Fedora already does. So for ordinary users not much will change.

Users with mach64 chipsets will be sol though, as their drm is only in drm.git

[nanonyme]

I guess that distros will start taking code from the kernel and drm-next and backport into their distro kernels, as Fedora already does. So for ordinary users not much will change.

Users with mach64 chipsets will be sol though, as their drm is only in drm.git

Hmm, that's the DRM with security issues? Does anyone use Mach64 anymore anyway?

[DanL]

You really don't get it. I don't want driver hunting. I want drivers without having to either wait for the next kernel release (why the hell should I wait for the *whole kernel* to be updated if I only want a single driver?) or needing to update to the next kernel release.

I'm sure the Haiku project would welcome your contribution http://www.haiku-os.org/