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.gitHmm, 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/

[bridgman]

I think we'll see distro schedules and kernel schedules gradually align themselves so that non-enterprise distros will automatically pick up the most recent kernel release while it's still fresh. Right now kernel packagers need to plan around both X and kernel release schedules in order to pick up new hardware, but as hardware-specific code moves out of the X drivers and into either the kernel or Gallium3D this should become a lot easier for everyone to manage.

I'm not sure if the Gallium3D code is built as a separate library or is linked into the state tracker, but there's a good argument for having it independent of the state trackers so that only the Gallium3D library needs to be updated. This is all "next year" stuff of course; there aren't enough drivers using Gallium3D yet for this to be a practical solution for distros today.

[Kano]

The drm git would be also usefull when it would only work with the current kernel, because it is not really a good idea to compile the whole kernel over and over again after a small change when only drm would be needed.

[suokko]

The drm git would be also usefull when it would only work with the current kernel, because it is not really a good idea to compile the whole kernel over and over again after a small change when only drm would be needed.

make modules SUBDIRS=drivers/gpu/
sudo make modules_install SUBDIRS=drivers/gpu/

[Kano]

Well ok, but why do i need to checkout the whole kernel tree when i only need drm?

[nanonyme]

Well ok, but why do i need to checkout the whole kernel tree when i only need drm?Because that's the way Linux works? :) It's not like you could build DRM anyway without something to build it against.

[chithanh]

Hmm, that's the DRM with security issues? Does anyone use Mach64 anymore anyway?
It had security issues, but these were fixed some time ago:
http://dri.freedesktop.org/wiki/ATIMach64
http://lists.freedesktop.org/archives/xorg/2006-October/019137.html

[Kano]

Sure, but the checkout was MUCH smaller.

[nanonyme]

It had security issues, but these were fixed some time ago:
http://dri.freedesktop.org/wiki/ATIMach64
http://lists.freedesktop.org/archives/xorg/2006-October/019137.htmlJust my opinion but I think if it's been made secure, it should just be cleaned up and merged into the kernel. No use having it hanging loose and eventually dying out. :3

[RealNC]

AFAIK, the Mach64 X driver doesn't actually need DRM to provide acceleration. I suppose that's the reason the DRM driver isn't getting merged.

[nanonyme]

AFAIK, the Mach64 X driver doesn't actually need DRM to provide acceleration. I suppose that's the reason the DRM driver isn't getting merged.Well, it's not like you would need DRM for any card (until KMS). ;)

[mdias]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?

Before people start flaming me or just saying "you're free to do so yourself", well, I don't have the time to do so, and maybe not the skills either.

~end of probably uneducated rant

[Ant P.]

Educate yourself then. (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/stable_api_nonsense.txt;h=847b342b7b20bd73758c603d 833811c5ac738930;hb=HEAD)

[RealNC]

Educate yourself then. (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/stable_api_nonsense.txt;h=847b342b7b20bd73758c603d 833811c5ac738930;hb=HEAD)

Thanks. We now know why. We still think it sucks though. It kind of ignores reality and the real world.

[pvtcupcakes]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?

Before people start flaming me or just saying "you're free to do so yourself", well, I don't have the time to do so, and maybe not the skills either.

~end of probably uneducated rant

If Windows updated it's kernel as often as Linux, they'd have the same problem too. Only it'd be worse because you'd be relying on Vendors to update their drivers.

[bridgman]

The enterprise and LTS distros are really the counterpart to Windows, not the fast moving ones.

It probably helps if you think about the fast moving distros as a view into the enterprise distros coming a year or two from now, which *will* have a stable driver interface.

[agd5f]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?


The interface to userspace is stable, it's just the internal kernel APIs that change. It makes it much easier to undo stupid designs or move to more efficient algorithms as things progress. Since the drivers are mostly all in the tree they get updated when the interface changes. If internal interfaces had to stay around forever, the kernel would fill with bloat as new stuff kept got added onto the old t avoid breaking old out of tree drivers that use old interfaces and never get changed.

[rvdboom]

Thanks. We now know why. We still think it sucks though. It kind of ignores reality and the real world.
That's a bit exagerated. I usually compile my own kernel with every new release, copying my .config file from one tree to the other and checking if there's nothing new or changed. It's not really that big a hassle now with the fast processors and it's been at least two years I've not seen any real regression doing this, which shows quality control has greatly improved in the kernel development.
I believe having separate drivers is just something one misses when one wants desperately to get a Windows way of managing its system, but I find it hardly necessary.
In fact, not having to check around several vendors to get driver updates is actually nice.

[RealNC]

OK, I'm certainly no expert on the matter, but AFAIK, Solaris has such a driver interface, and mostly positive things came out of it. For Linux that would mean more manufacturers, who are not able/willing to open source their code, offering Linux drivers.

"Get your driver in the kernel" is an extremely naive suggestion; do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.) Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response. Or no one is actually willing to include the driver; Marvell opened up their ethernet driver at some point (GPL), but no one ever has put it in the kernel; to this day, the "sky2" kernel driver is still used even though it has bugs. They expect Marvell to do it.

So companies not only have to get all the legalese and paperwork solved to open their drivers, they also have to work extra to actually adapt it for kernel inclusion. Yeah sure, "open up the specs so we can write drivers." They open the specs, no one writes drivers. Then, "open up the source code for your drivers." Er, OK, we gave you the specs, you didn't write any drivers, so fine, here's the freaking source code, take it. Oh noes, no one includes it in the kernel... "Rewrite your driver and beg on LKML for acks". There's only one response really: "Screw you. I'm out. I'm not prepared to waste ten times more resources for a market ten times smaller."

I don't blame them the least for not doing all the above. It's not worth the effort. And Linux isn't helping them even though according to simple logic, it should (they don't need Linux; Linux needs *them*).

This situation is the main reason I think that a major part of "The Linux Kernel Driver Interface" document is bollocks and Greg Kroah-Hartman not really thinking before writing. The technical reasons seem logical though.

[nhaehnle]

"Get your driver in the kernel" is an extremely naive suggestion;
It's working pretty well in reality, don't you agree?

do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.)
Please. Yes, there is a lot of work going into those graphics drivers, so I can understand where they're coming from. But the general rule is that drivers aren't that big a deal, the graphics market is the rare exception here.


Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response.

If the code really is crap, then why would you want to run it as a binary blob?

[Vash63]

OK, I'm certainly no expert on the matter, but AFAIK, Solaris has such a driver interface, and mostly positive things came out of it. For Linux that would mean more manufacturers, who are not able/willing to open source their code, offering Linux drivers.

"Get your driver in the kernel" is an extremely naive suggestion; do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.) Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response. Or no one is actually willing to include the driver; Marvell opened up their ethernet driver at some point (GPL), but no one ever has put it in the kernel; to this day, the "sky2" kernel driver is still used even though it has bugs. They expect Marvell to do it.

So companies not only have to get all the legalese and paperwork solved to open their drivers, they also have to work extra to actually adapt it for kernel inclusion. Yeah sure, "open up the specs so we can write drivers." They open the specs, no one writes drivers. Then, "open up the source code for your drivers." Er, OK, we gave you the specs, you didn't write any drivers, so fine, here's the freaking source code, take it. Oh noes, no one includes it in the kernel... "Rewrite your driver and beg on LKML for acks". There's only one response really: "Screw you. I'm out. I'm not prepared to waste ten times more resources for a market ten times smaller."

I don't blame them the least for not doing all the above. It's not worth the effort. And Linux isn't helping them even though according to simple logic, it should (they don't need Linux; Linux needs *them*).

This situation is the main reason I think that a major part of "The Linux Kernel Driver Interface" document is bollocks and Greg Kroah-Hartman not really thinking before writing. The technical reasons seem logical though.

Um, exactly what drivers are you talking about Linux needing? I can't really think of any major products that aren't supported. Marvell chips work fine with sky2, the specs being open means the driver was done in the main tree... just because their "official" driver isn't there doesn't mean the hw is unsupported. If their driver is GPL'd yet still not included while there is already sky2, I'm sure there's a good technical reason for that.

[mdias]

If Windows updated it's kernel as often as Linux, they'd have the same problem too. Only it'd be worse because you'd be relying on Vendors to update their drivers.

Well, cool thing that they don't change their kernel that often then... Plus, I've had success installing XP drivers on Vista, so, there must be something working there, and as far as I can tell they've got a preety stable and secure kernel by now.

I just read the article "Ant P." told me to, and I honestly didn't find anything new in there... So, we should just ship trillions of drivers with the kernel (or it's source) in order to solve compiler problems now?

Idk what to do about the "new interface" -> "old interface" compatibility problems, but I guess that's why linux is so unsupported. If linux is all about freedom why aren't companies given the freedom to release binary blobs? (and I mean ones that would work for more than a single kernel version's lifespan)... The end user doesn't really care if things are opensource or not...

[lbcoder]

do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel?
Uh, YES. In fact I *DO* see AMD able, willing, and ACTIVELY DOING so... Did you read the front page news today? http://www.phoronix.com/scan.php?page=news_item&px=NzU0Nw

Somebody else is working on the nvidia stuff since nvidia still has a stick shoved up their a$$, but if AMD can do so, then SO CAN nvidia (no more excuses here), all they need is to be willing.

[lbcoder]

The end user doesn't really care if things are opensource or not...
...no, but the GPL does...

[agd5f]

Idk what to do about the "new interface" -> "old interface" compatibility problems, but I guess that's why linux is so unsupported. If linux is all about freedom why aren't companies given the freedom to release binary blobs? (and I mean ones that would work for more than a single kernel version's lifespan)... The end user doesn't really care if things are opensource or not...

But that's the _point_ of Linux; that the source is available. If the end user doesn't care about the source than they are free to pick another OS.

And I certainly wouldn't say "Linux is so unsupported." I'd argue that it supports about as much hardware as a given version of windows in most cases.

It's not the lack of a stable internal kernel interface that's preventing more widespread support in certain markets, it's lack of marketshare. For example, Linux has great hardware support in the server and embedded spaces (where it has significant market share), but not as much in things like home-user desktop. Companies will support whatever interface they need to support if the potential revenue warrants it.

It's generally more of a mindset problem. Most companies are used to dealing with windows. It takes time to adapt to another way of doing things.

[rohcQaH]

And I certainly wouldn't say "Linux is so unsupported." I'd argue that it supports about as much hardware as a given version of windows in most cases.
for mainstream consumer hardware, it's often the other way around.

Using Linux, every piece of hardware I own is supported out of the box. I just need to manually install the binary GPU drivers for 3D support - but hopefully, that'll change.

Using Windows, I also need to manually install the binary GPU drivers.
- On XP, I also need to manually install drivers for my NIC, the SATA controller (much joy unless you still use an IDE HD) and the sound card.
- On Vista, NIC and SATA work fine, but there is no way to use my sound card. Neither Microsoft nor Creative care to provide drivers (of course the old ones don't work, windows doesn't have a stable kernel interface either).

There are similar results for my laptop, and windows on the GPU-less server doesn't even work.


For me, Linux has better hardware support on 3 out of 3 computers, even though every part I bought was "designed for Windows".

[nanonyme]

For me, Linux has better hardware support on 3 out of 3 computers, even though every part I bought was "designed for Windows".Well, that claim mostly only means "the vendor can only be held responsible if this doesn't work with Windows", nothing more. ;)

[mdias]

...no, but the GPL does...
I never said I'd want to GPL my code if I were to release my device's driver...

But that's the _point_ of Linux; that the source is available. If the end user doesn't care about the source than they are free to pick another OS.

So because a user would like to develop an app/game without giving up the source he shouldn't target linux?


And I certainly wouldn't say "Linux is so unsupported." I'd argue that it supports about as much hardware as a given version of windows in most cases.

You're right, I made a poor choice of words, I meant developers don't target linux so much.


It's not the lack of a stable internal kernel interface that's preventing more widespread support in certain markets, it's lack of marketshare. For example, Linux has great hardware support in the server and embedded spaces (where it has significant market share), but not as much in things like home-user desktop. Companies will support whatever interface they need to support if the potential revenue warrants it.

It's generally more of a mindset problem. Most companies are used to dealing with windows. It takes time to adapt to another way of doing things.

Linux webservers certainly don't need bleeding edge technology, it doesn't need constantly updated drivers and kernerls to support those tasks.

Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.

It's true that companies will do whatever it takes to get money, however they'll also choose the easiest way to do so, and unfortunately, currently that's on Windows. I'm hoping Gallium 3D will improve gaming on linux dramatically, however I wouldn't bet on that.

[edit] on another note; who would be held responsible if my open source gfx driver wiped out the BIOS of the card? I'd love to use a stable, fast driver if it was closed source. At least I know I'd get support from that company even if I ever needed (they have their name to defend, unlike OSS devs). Sure, fglrx sucks for the normal user and as such I currently use the open source drivers that are going strong :)

Please don't get me wrong, I'm not saying the oss devs don't support the users; I'm saying that they don't HAVE to.

[pingufunkybeat]

Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.
They are not meant to, distributions will do that for them.

Bleeding edge drivers that haven't been fully written yet are a separate category, and not something for the less tech-savvy home-user desktops.

[mdias]

They are not meant to, distributions will do that for them.

Bleeding edge drivers that haven't been fully written yet are a separate category, and not something for the less tech-savvy home-user desktops.

It still looks they'll have to install a new kernel everytime an updated driver is out for their hardware, and has been said before, that kernel could have regressions in other areas.

[nanonyme]

on another note; who would be held responsible if my open source gfx driver wiped out the BIOS of the card?You're right. ;) You. Then again, BIOS isn't afaik too trivial to accidentally wipe...

[agd5f]

So because a user would like to develop an app/game without giving up the source he shouldn't target linux?

I'm talking specifically about drivers. The kernel is open source and driver developers should target upstream inclusion if they want their driver to work well on Linux.


Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.


They are not supposed to. They use whatever the oem puts on the system. In most cases this is windows. For those users wanting to try Linux, the distro packages everything for you. Until Linux gains more desktop market-share, there will tend to be a delay between desktop hardware availability and driver availability. If you want to use the bleeding edge now, you need to use development trees.

[Kjella]

Uh, YES. In fact I *DO* see AMD able, willing, and ACTIVELY DOING so... Did you read the front page news today? http://www.phoronix.com/scan.php?page=news_item&px=NzU0Nw

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

Certainly, it's very nice that they do give away that much and that they reveal the hardware interface at all, But I don't think that AMD is giving away any tricks that'll make them come out 2 FPS behind instead of 2 FPS ahead in the next GPU shootout. Those kinds of optimizations are in the blob and staying in the blob for the foreseeable future.

I think Linux would do better pushing for universal standards, like for example how all USB sticks conform to a USB mass storage device spec - no need for separate drivers. Same with webcams and USB video spec. Create a few more like those and there is little reason to have a million drivers in the first place.

[agd5f]

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

It's not so much an information thing as an effort thing. Squeezing out every last drop of performance is a major amount of engineering. There's enough information out there to write a driver that comes close to the performance of the closed driver, but there are not enough developers to actually realize that. To use your analogy, the instructions and engine upgrades are there to go 200 mph, but there aren't enough mechanics to install it all. The cost of lots of extra mechanics is not justified if only 2 people are actually going to watch the race.

[bridgman]

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

Certainly, it's very nice that they do give away that much and that they reveal the hardware interface at all, But I don't think that AMD is giving away any tricks that'll make them come out 2 FPS behind instead of 2 FPS ahead in the next GPU shootout. Those kinds of optimizations are in the blob and staying in the blob for the foreseeable future.

Just to be clear, the plan has always been that we provide documentation, sample/initial code and developer support, then the open source community writes and maintains the drivers. In the case of 6xx/7xx 3D, the community developers were mostly focused on other areas like KMS and GEM/TTM, so we offered to do most of the initial coding, and that is mostly completed. What happens next in terms of performance and features is up to you.

We are going to keep helping in what we see as key areas (which may include performance), and we are going to keep adding support for new hardware, but you should *not* be expecting us to write the drivers ourselves or complaining if we don't dump enough proprietary code into the open source stack. We have a proprietary driver for that.

I don't think anyone is trying to match the performance and features of the Catalyst driver BTW; the goal is to provide a driver set which meets the needs of most desktop users, which can stay current with (and be used for the development of) the evolving X/DRI framework, and which can be directly supported by Linux distribution developers.

[nanonyme]

Just to be clear, the plan has always been that we provide documentation, sample/initial code and developer support, then the open source community writes and maintains the drivers. Our job was to make sure there is enough information out there for the development community to program the hardware, *not* to write the drivers ourselves. I would rather have our team working on Evergreen or trying to open up UVD.I at least appreciate the effort that's led into imo amazingly fast progress. You guys definitely got to my personal Wall of Beer. (members eligible for a round if they pop by ;) )

[mdias]

I'm talking specifically about drivers. The kernel is open source and driver developers should target upstream inclusion if they want their driver to work well on Linux.
While I agree that drivers might be better on the kernel and open, we should allow for binary blobs to still exist and be compatible for as long as possible.

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).

They are not supposed to. They use whatever the oem puts on the system. In most cases this is windows. For those users wanting to try Linux, the distro packages everything for you. Until Linux gains more desktop market-share, there will tend to be a delay between desktop hardware availability and driver availability. If you want to use the bleeding edge now, you need to use development trees.
True.

[nanonyme]

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).This is exactly why the drivers should be included in the kernel tree and adapt to changes change by change instead of eg every kernel version.

[agd5f]

While I agree that drivers might be better on the kernel and open, we should allow for binary blobs to still exist and be compatible for as long as possible.

Why other than that's what windows does?

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).

I don't really see that happening. Often times the changes can be made with simple search and replace. I think the argument is more relevant to keeping old internal interfaces around for backwards compat, eventually you have so may old interfaces the code gets unreadable and unmaintainable.

[lbcoder]

I never said I'd want to GPL my code if I were to release my device's driver...
If you don't want to GPL your code, then don't write kernel drivers. Fact is that the GPL *DEMANDS* that your code be compliant with the GPL, and writing non-GPL drivers is a violation of the GPL since that is what the kernel itself is under. And yes, the kernel interfaces written by AMD and NVIDIA for their blob drivers are GPL compatible (though it is debatable whether the blob part is compatible, which is part of the reason for migrating to open source drivers).


So because a user would like to develop an app/game without giving up the source he shouldn't target linux?
<<flush>> this has nothing to do with the discussion, which is about DRIVERS, not applications, which BTW need NOT be GPL.


You're right, I made a poor choice of words, I meant developers don't target linux so much.
??? I see no meaning or relevance to this statement.



Linux webservers certainly don't need bleeding edge technology, it doesn't need constantly updated drivers and kernerls to support those tasks.
RIGHT!!! so don't bother wasting your time on bleeding edge kernels if you don't need them! Nobody is holding a gun to your head telling you that you *must* run the latest of everything.

Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.
No, they'll install whatever distro they like, which (depending on the maintainers) will include updates applicable based on the policies of that particular distro. If you don't like regressions, use a more stable distro. If you use the latest and bloodiest distro, chances are that you'll have the latest and bloodiest drivers. Case in point: Fedora Rawhide (what is to become Fedora 12) has Radeon R600/700 3D/KMS in it *right now*.

It's true that companies will do whatever it takes to get money, however they'll also choose the easiest way to do so, and unfortunately, currently that's on Windows. I'm hoping Gallium 3D will improve gaming on linux dramatically, however I wouldn't bet on that.
This is absolutely related to MARKET SHARE and has nothing to do with anything else.

on another note; who would be held responsible if my open source gfx driver wiped out the BIOS of the card?
Unless the author was a braindead monkey on drugs, the chances of this happening are *EXTREMELY* remote, and FYI: the chances are *equal* regardless of whether the drivers are open or closed source. No, scratch that, the chances are *GREATER* if the drivers are closed source since there are fewer eyes on the code to make sure that nothing stupid happens.

I'd love to use a stable, fast driver if it was closed source. At least I know I'd get support from that company even if I ever needed (they have their name to defend, unlike OSS devs).
You seem to have things backwards. You typically get BETTER support for open source drivers, faster updates, greater compatibility, less waiting before the driver is updated to support your favorite new bleeding edge distro, the possibility of FIXING IT YOURSELF if something is wrong, the security of knowing that if the manufacturer goes out of business that the whole code is still there to work with, the security of knowing that when the hardware goes "legacy" a year or two after it is manufactured, that it will continue to be supported (until it is so obsolete that you would have to be NUTS to try to use it), ...

Sure, fglrx sucks for the normal user and as such I currently use the open source drivers that are going strong :)
Always worked fine for me, but whatever...

Please don't get me wrong, I'm not saying the oss devs don't support the users; I'm saying that they don't HAVE to.
*OF COURSE THEY DO* -- the open source devs *work for someone* who's reputation *IS* on the line. In fact, sometimes MORE peoples'/organizations' reputations are on the line with the open source drivers than with the closed since open drivers may be developed by *MORE THAN ONE* organization, again case in point: Radeon R600/700 new stuff: AMD + Red Hat (+other?) vs. fglrx: AMD only (sure there may be IP from other groups in fglrx, but it is still just AMD on the front cover).

[nanonyme]

From radeon kernel drivers:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:" followed by the "you must include this permission note and copyright clause with software" and "no warranty" conditions. Sounds plenty fair to me.

[mdias]

This is exactly why the drivers should be included in the kernel tree and adapt to changes change by change instead of eg every kernel version.

Sorry, you misunderstood my question.
agd5f did get to the point I was after. No offense intended :)


@lbcoder: you're mostly out of context on your replies. I talked about the BIOS issue as just an example of something that can go wrong for example.

I'm not gonna turn this thread into a fglrx discussion as it's a matter of needs and personal preference.

I AM going to say that OSS devs DON'T have to support me though. I could anonimously contribute with code and I'd have nothing to lose from ignoring users' questions.

Why other than that's what windows does?

Ease of installation of just that module. And to give people who don't want to release the code the freedom to do so.

[pvtcupcakes]

Ease of installation of just that module. And to give people who don't want to release the code the freedom to do so.

AFAIK vendors can submit a small part of their driver to the kernel, and then have their binary blob hook into that.
I think VIA (OpenChrome?) tried it recently, but got rejected. Might have just been poor code quality; I don't remember.

[nhaehnle]

AFAIK vendors can submit a small part of their driver to the kernel, and then have their binary blob hook into that.
I think VIA (OpenChrome?) tried it recently, but got rejected. Might have just been poor code quality; I don't remember.
No, they can't.

The kernel has a rather strict policy about keeping the userspace interfaces stable. If the only client of a userspace interface is a binary blob, then you have an extremely weak case for inclusion into the kernel.

On a sidenote, I occasionally wished that not just kernel drivers, but actually the userspace components of 3D drivers were part of the same repository. After all, 3D driver design is really an exokernel design, and it is kind of annoying to have pretend that the userspace interface is a userspace interface, when in fact it is really just a tightly coupled communication link between kernel module and userspace driver. At least that's my story.

[RealNC]

No, they can't.

The kernel has a rather strict policy about keeping the userspace interfaces stable. If the only client of a userspace interface is a binary blob, then you have an extremely weak case for inclusion into the kernel.

VMWare's "VMI" interface anyone? It got welcomed with open arms...

Oh, and two days ago, they announced that their VMWare products will stop using VMI anyway and announced that they will remove VMI from the kernel because of that.

It seems some "binary blobs" get preferential treatment.

[amphigory]

I love such lively debate regarding imponderable conundrums. ;-) Next thing you know the microkernel / monolithic argument will raise its ugly head again.

Myself... I'm just enjoying the beauty of a stable unified video driver and don't worry too much about design philosophy. Oh yes... and wondering what to do with the NVIDIA card I replaced with AMD.

[krazy]

VMWare's "VMI" interface anyone? It got welcomed with open arms...
No it didn't. It got rejected, and made to "plug-in" to paravirt_ops, precisely because kernel hackers didn't want to be responsible for a stable ABI. paravirt_ops is also used by Xen and Lguest.

[lbcoder]

@lbcoder: you're mostly out of context on your replies.
No, I'm afraid not.
Your problem is your lack of understanding and/or your clarity of statement.

If my responses appear to be out of context, then that is due to your statements being worded differently than your intended meaning.

Fact is this;
Linux is NOT INTENDED to allow you to make closed source drivers. It is in fact quite the reverse -- it is intended to FORCE you to make OPEN SOURCE drivers for many reasons, some of which I have outlined. That isn't going to change. If you don't like that, then this isn't the appropriate platform for you and you should therefore concentrate on something else. This platform is there for those who agree with or NEED this policy...

I talked about the BIOS issue as just an example of something that can go wrong for example.
The same statements I have made are applicable regardless of what particular issue you invent to be representative of worst-case-scenario.

I AM going to say that OSS devs DON'T have to support me though. I could anonimously contribute with code and I'd have nothing to lose from ignoring users' questions.
Bad spelling aside, at what point in the process do you observe anonymous contributions being blindly accepted into mainline? All of the major components have some responsible overseer and testing process to verify quality of code.

[mdias]

No, I'm afraid not.
Your problem is your lack of understanding and/or your clarity of statement.

If my responses appear to be out of context, then that is due to your statements being worded differently than your intended meaning.
Well, I'm sorry english is not my native language. Others appeared to understand my point as I meant it to be understood.

Fact is this;
Linux is NOT INTENDED to allow you to make closed source drivers. It is in fact quite the reverse -- it is intended to FORCE you to make OPEN SOURCE drivers for many reasons, some of which I have outlined. That isn't going to change. If you don't like that, then this isn't the appropriate platform for you and you should therefore concentrate on something else. This platform is there for those who agree with or NEED this policy...
If that's the case then so much for freedom I guess...
I don't see linux to be what you say it is, and not liking one feature of an OS can be not enough to make me change my opinion about it, specially since I'm an application developer and not a kernel driver dev.

The same statements I have made are applicable regardless of what particular issue you invent to be representative of worst-case-scenario.
You missed my point again. AMD must not damage my hardware, be it wiping the BIOS or whatever. The open source driver devs do not have to guarantee you anything.


Bad spelling aside, at what point in the process do you observe anonymous contributions being blindly accepted into mainline? All of the major components have some responsible overseer and testing process to verify quality of code.
Again, english isn't my native language, but I'm sure I can communicate in an understandable manner. I can't see how that kind of observation helps this discussion.

I never mentioned the code being blindly accepted. The fact is that bugs can slip through everyone's eyes.

[pingufunkybeat]

If that's the case then so much for freedom I guess...
Freedom of kernel hackers to develop the kernel the way they think is best?

Or which freedom?

[mdias]

Freedom of kernel hackers to develop the kernel the way they think is best?

Or which freedom?

Freedom as in being able to support binary drivers in a stable and legal way.
Meaning that open source devs as well as closed source devs should be able to do it without major problems.


[edit] uhh, what a coincidence (http://news.cnet.com/8301-13505_3-10358024-16.html).
I'm aware that having those binary interfaces would add up to the problem, but it seems that embedding drivers on the kernel is also starting to be a problem...

[pingufunkybeat]

Freedom as in being able to support binary drivers in a stable and legal way.
Is somebody preventing this?

I don't think so. It's unfair to expect kernel hackers to spend extra time making sure third-party binary drivers are working. It's the job of the writers of the said drivers.

They are free to support them, nobody is taking this away.

[mdias]

Is somebody preventing this?

I don't think so. It's unfair to expect kernel hackers to spend extra time making sure third-party binary drivers are working. It's the job of the writers of the said drivers.

They are free to support them, nobody is taking this away.

You are correct. But the problem is that apparently no one will accept a nice interface to be included in the kernel for the sole purpose of supporting binary blobs, just because it's binary, no matter who developed it.

[nhaehnle]

You are correct. But the problem is that apparently no one will accept a nice interface to be included in the kernel for the sole purpose of supporting binary blobs, just because it's binary, no matter who developed it.
Have there even been serious attempts at such in-kernel interfaces? Somehow, I doubt it - because all the people who scream for binary interfaces are usually just screamers, and not doers.

On the other hand, FUSE and now CUSE are perfectly fine binary driver interfaces that have been accepted into the kernel without too much fuss. I think it's a very good solution to the problem: If you insist on writing binary blob drivers, you can go to userspace and play microkernel.

[Ex-Cyber]

You are correct. But the problem is that apparently no one will accept a nice interface to be included in the kernel for the sole purpose of supporting binary blobs, just because it's binary, no matter who developed it.No one will accept such an interface precisely because it is not a "nice" interface from a maintenance perspective. How are kernel devs supposed to debug the interface when the only code using it is closed (i.e. how do you distinguish a bug in the kernel side from a bug in the blob side)? How are they supposed to know what changes will or won't break assumptions made inside the blob?

[mdias]

No one will accept such an interface precisely because it is not a "nice" interface from a maintenance perspective. How are kernel devs supposed to debug the interface when the only code using it is closed (i.e. how do you distinguish a bug in the kernel side from a bug in the blob side)? How are they supposed to know what changes will or won't break assumptions made inside the blob?

In a perfect world this interface would be so "nice" that even open source devs would want to build using that. That would make code availabe to debug.
They're supposed to know what will break the binary drivers by previously defining specifications and what can and cannot be made an assumption.

I'm sure I'm no genious that just found the solution to everything, but I'm telling you my "ideas" to be able to read the reasons why they're not feasable if that's the case.

I mean, PCI devices will always be PCI devices, and not much can change on how you communicate with them, right? Same happens with every other kind of buses, why do we need a constantly changing interface?

In my mind the kernel should have interfaces to communicate with ISA, PCI, PCI-E and whatever, and then the drivers would communicate with the physical device using the desired interfaces on the kernel that wouldn't change over time. This would mean that a device driver would never stop to work and would never need any maintenance just to work with the latest kernel because it'd have the interfaces expected by the driver.

So I guess my question here is; what exacly can change in an interface and why?

[pingufunkybeat]

To get back to the topic -- what is the kernel one needs to be using in order to switch to the in-kernel DRM and abandon the external module? I'm talking r600+ goodies here.

Gentoo has hard-masked the ebuild for the x11-drm with the reasoning that it's being abandoned, so it is time to move, but which version? I know it should be a very recent post-31 kernel, but I don't feel like pulling the kernel from git.

Any gentoo users? Is git-sources-2.6.31-r10 recent enough?

[Ant P.]

To get back to the topic -- what is the kernel one needs to be using in order to switch to the in-kernel DRM and abandon the external module? I'm talking r600+ goodies here.

Gentoo has hard-masked the ebuild for the x11-drm with the reasoning that it's being abandoned, so it is time to move, but which version? I know it should be a very recent post-31 kernel, but I don't feel like pulling the kernel from git.

Any gentoo users? Is git-sources-2.6.31-r10 recent enough?

See here (http://wiki.x.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3).

I haven't had much luck with KMS so far. If you're going to try it, remember to select "Build in-kernel firmware into the binary" or it seems to die on boot.

[agd5f]

To get back to the topic -- what is the kernel one needs to be using in order to switch to the in-kernel DRM and abandon the external module? I'm talking r600+ goodies here.

Gentoo has hard-masked the ebuild for the x11-drm with the reasoning that it's being abandoned, so it is time to move, but which version? I know it should be a very recent post-31 kernel, but I don't feel like pulling the kernel from git.

Any gentoo users? Is git-sources-2.6.31-r10 recent enough?

Dave's drm-next branch is your best bet:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next
Linus pulled the drm-next into 2.6.32, so that would work too.

[crumja]

Freedom as in being able to support binary drivers in a stable and legal way.
Meaning that open source devs as well as closed source devs should be able to do it without major problems.

You're looking at the wrong platform then. There is nothing in the GPL or the Linux community that stipulates that binary drivers must be supported. Heck, even syscall doesn't have to be stable, but it is because the developers decided that it was worthwhile. Furthermore, we don't want to encourage binary drivers because they are so buggy and that no one can ever fix them. Look at the "bloody mess" with the Poulsbo driver for instance. Fglrx and nvidia used to crash back when I used them. The open-source ATI driver never does. Which situation would you rather have?

Obviously, you're not content with the current state of development. You can join the development team and make suggestions. If not, the easy fix is to just make your own private tree based on a kernel snapshot and maintain a stable interface for binary drivers. Then, maybe package your own distro to use that kernel and convince companies to support it. Oh wait, we already have that. It's called RHEL, SLED, Ubuntu LTS. As for keeping that binary stability between versions, even Windows doesn't go that far.

Since you're an application developer, I'm wondering why you would need stable kernel driver interfaces.

[mdias]

You're looking at the wrong platform then. There is nothing in the GPL or the Linux community that stipulates that binary drivers must be supported. Heck, even syscall doesn't have to be stable, but it is because the developers decided that it was worthwhile. You can join the development team and make suggestions.

Obviously, you're not content with the current state of development. The easy fix is to just make your own private tree based on a kernel snapshot and maintain a stable interface for binary drivers. Then, maybe package your own distro to use that kernel and convince companies to support it. Oh wait, we already have that. It's called RHEL, SLED, Ubuntu LTS. As for keeping that binary stability between versions, even Windows doesn't go that far.

Since you're an application developer, I'm wondering why you would need stable kernel driver interfaces.

We shouldn't focus on other OS's, instead please give me a reason why it's not feasable.
I never said that binary drivers must be supported... I'm just against the "mustn't" attitude.

I don't actually need stable kernel interfaces myself, we're just discussing the benefits of things being the way they are and why it's not the other way. And one of the benefits of the "other way" IMO are ease of installation/upgrade of individual drivers, and also free the kernel of the burden of constantly changing every driver to meet the requirements of the new interface.

[crumja]

We shouldn't focus on other OS's, instead please give me a reason why it's not feasable.
I never said that binary drivers must be supported... I'm just against the "mustn't" attitude.

I don't actually need stable kernel interfaces myself, we're just discussing the benefits of things being the way they are and why it's not the other way. And one of the benefits of the "other way" IMO are ease of installation/upgrade of individual drivers, and also free the kernel of the burden of constantly changing every driver to meet the requirements of the new interface.

[edit] Sorry everyone for helping this thread go out of topic.

It *is* feasible. It's just not desirable. I've already stated why I (and most devs) are against binary drivers. One more reason is that it prevents reworking of too much kernel code that might be needed to be changed for performance, functionality, or security reasons. If you use them or code them, I've already listed enterprise distros that do offer that stability.

Installation of drivers wouldn't be simpler; it wouldn't be any different from how it's done now. If you're open-source, you release the source and ppl compile it for release as modules for their distro (or do it individually). If you want to distribute binaries, you'll do so for every single version of every distro you support regardless of the kernel because of gcc, library, and platform differences.

[Ant P.]

Everyone here shouting for support of a stable driver API is in effect saying they're happy with hardware vendors putting out binary trash like the X-Fi and GMA500 drivers, never updating them because they don't have to, and not bothering to get an open/maintained driver into the kernel because they don't have to do that either. Look no further than Windows Vista for what happens when you give people a stable driver API then try to fix flaws in it later.

It's a slippery slope. (http://lwn.net/Articles/162686/)

[nanonyme]

It's a slippery slope. (http://lwn.net/Articles/162686/)/me raises populism flag
I prefer real arguments. The link to the post by Greg earlier in this thread had those. That link is just propaganda.

[RealNC]

Fglrx and nvidia used to crash back when I used them. The open-source ATI driver never does.

That is a very naive assumption ("it works for me = it works everywhere"). The open source driver does crash here far more often (by orders of magnitude) than fglrx.

[mdias]

What the hell? Are you serious? What kind of article is that?

I'm off this discussion. I feel it was somewhat enlighting to me and probably someone else until fanboys came in.

Bye.

[nanonyme]

I'm off this discussion. I feel it was somewhat enlighting to me and probably someone else until fanboys came in.If you mean my comment, it was imo perfectly justified. The post behind the link was a worst-case scenario. Quoting that page is like quoting the articles that say LHC is gonna create a black hole every time when talking of particle accelerators. Some people like playing with feelings more than reason. There are good reasons for not having a stable ABI but I consider the lwn.net link more of a flame-bait than intellectual conversation.

[Ant P.]

Yeah, I guess I should apologise, that wasn't very helpful.

Here's (http://www.opensolaris.com/get/index.jsp) a better link for those complaining about Linux's development model. Let us know how it goes.

[nanonyme]

I've been meaning to take a look when I have enough spare time, haven't yet had.

[energyman]

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.

sucks to be you :P

And I hate to hunt around for drivers and love the fact that everything is in one nice tarball.

[highlandsun]

re: binary drivers - Linux is not just an x86 OS, you know. There are other processor architectures out there, important ones, and they also run Linux and use a lot of the same types of devices. Advocating binary-only drivers is extremely short-sighted.

It's not even x86 vs ARM / Sparc / PowerPC whatever that causes this problem. Even now I don't have a stable driver for the modem in my laptop, because the vendor's driver depends on an x86 blob therefore it won't run in my x86-64 kernel. This is a ridiculous state of affairs and I've been disassembling / decompiling that particular blob just so I can recompile it for x86-64. If you insist on locking me out of hardware that I own after paying in good faith for everything contained within, then I am going to continue to break the locks that you've placed on my property.

[yoshi314]

btw. what are *BSD developers going to do now? i mean, linux is slowly getting KMS and drm is adapting to it accordingly. how is bsd going to maintain their own drivers now?

[bridgman]

The 6xx/7xx 3D has been ported across and is running on *BSD already; not sure of the KMS status but I think rnoland is working on it.

[nanonyme]

re: binary drivers - Linux is not just an x86 OS, you know. There are other processor architectures out there, important ones, and they also run Linux and use a lot of the same types of devices. Advocating binary-only drivers is extremely short-sighted.The original point of talking of a static ABI in this thread was not related to binary drivers. It was just that it also harms sensible development of out-of-tree opensource kernel driver development. (kernel developers don't think you're supposed to be doing that anyway but rather have your drivers integrated to the kernel tree and then everyone has to download whole kernel tree to get the drivers) Dunno who sidetracked the conversation yet again to proprietary code, that was quite offtopic. :)