Have the drm.git kernel modules been abandoned?

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

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.