Have the drm.git kernel modules been abandoned?

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

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

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

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

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

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

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

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

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 )

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