Have the drm.git kernel modules been abandoned?

[nanonyme]

It's a slippery slope.

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

[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.

[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.

[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]

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.

[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.

[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.

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.

[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?

[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?

[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?