ATi Support on infinityOS

[darkphoenix22]

OK, it wasn't meant to question your methods, your decision how you build your distri. What I do is more a hobby than some serious work (my work PC is running on OpenSUSE and I don't have admin-rights). I like to play around with such stuff and admin my system (in German you would call it "frickeln", don't know if there is a proper translation).

But I guess if I developed some software and had to build packages, I would choose the OpenSUSE Build Service. This way you can "easily" build packages for the "main" distributions.

Ya, I love the idea of the Launchpad and OpenSUSE build services.

The translation in English for "frickeln" btw would be "fucking around".

As an aside, the root account on infinityOS is effectively disabled. Hell, I can disabled the su command for non-admin users, so a service running in an unpriviledged user can be hacked to get root acess (that is if you manage to get terminal access).

[darkphoenix22]

gah "can't be hacked to gain root access"

[darkphoenix22]

I was just lurking through the forums and saw that ATi Radeon KMS power management is coming in Linux kernel 2.6.34.

I want to personally thank the devs for the hard work. It seems like you guys are laying the ground work for a completely open source driver, even if it is coming along a little slower than most people would like.

The only thing I must ask is to make the development a bit more transparent. Of cousre, I'm going to suggest Launchpad as I am a clear fanboy, but there are other sites with very similar feature sets. It seems like the main frustrations with the Radeon drivers are not the drivers themselves but how hard it is to install them (and I completely understand that you have to lay the groundwork in the kernel as well as in the libraries) and the effort it currently requires to keep track of their development. Git and mailing lists are not good solutions for end users.

You guys should also make it better known all the work you are doing, as it sadly seems to be virtually unknown. Perhaps a few interviews with some of the big blogs (like Ars Technica, Wired and Engadget) and a few announcements will do the trick. People have to know about it in order for you to get credit for it.

I can't wait to try out all these new features once they make it to Ubuntu, and include them in my distro.

Keep up the good work,
Ryan

[bridgman]

My understanding is that when the new functionality is ready for general use it gets included in releases of the kernel and/or userspace drivers which are then picked up by distros and *are* made broadly available. Prior to that, the code is really intended for use by developers and by users who are willing to test the work-in-progress code and provide valuable feedback to the devs.

[darkphoenix22]

I realize that that this is the reality in the short term as there is much work to be done in the kernel, in terms of KMS and DRM support, in order for the open source code base to even be able to support what you guys want to do with the Radeon drivers. However, after the next Radeon driver release and kernel release, perhaps you guys should at packaging the Radeon drivers and distributing them in a simliar manner to the Nvidia and ATi binary drivers.

This may require quite a few changes in the way video APIs are handled the kernel and X.org, but I believe it will be much better for end users in the end. It's a huge pain having to update the kernel, X.org and Mesa in order to take advantage of the latest features in the Radeon drivers.

One of my core beliefs is that development is greatly assisted (and speed up) when the end users and the developers can collabrate directly, instead through a middleman distribution. The current video/graphics system in Linux seems to be a pretty big impediment to establishing this kind of relationship in the use and developement of the Radeon drivers. Look to ALSA for an ideal of how the video/graphics system on Linux should work and a guideline on how to implement it.

Ryan

[bridgman]

Hmmm. I think the trend, if anything, is to go the other way and focus on delivering a great experience with a specific combination of xorg, kernel, and driver stack, and focus less on supporting arbitrary "mix and match" combinations of xorg, kernel, and individual driver components.

Some parts of what you are asking for are actually happening, in the sense that all of the components (Xorg, X drivers, kernel, kernel drivers, Mesa, mesa drivers) are moving onto a common quarterly development cycle so that the three main driver components can generally be released as a set, in the same way as binary drivers. A number of distro packagers provide frequent builds off the git tree in order to let users stay current with the work-in-process driver code (understanding that it is not stable released code) while still staying within their native packaging system and not having to touch git or make.

Since most distros tend to release fairly frequently as well (6 months being about the norm) they will tend to pick up matched sets of xorg, kernel and drivers each time so everything will work together. The driver stack has been going through massive changes over the last year or so, to the extent that a few months makes a huge difference, but I think you'll see that settling down now that the major architectural work is largely done. As a result, you'll probably see most users happy to wait until the next distro release to pick up the new drivers as well.

The part that is not determined yet (AFAIK) is how new hardware enablement will happen between distro releases. The conceptually simple answer is to backport the new hardware support to previous driver versions, but since different distros will take different versions the obvious question is "who's gonna do all that backporting ?". The other conceptually simple answer (and the previous way of doing things) was to write the driver code so that it would recognize and work with a wide range of framework versions, but the problem there was "who's gonna test all the combinations before release ?" and the answer generally turned out to be "nobody", or at least not enough people to make a dent in the (exponentially growing) number of combinations.

Looking to sound drivers as an example for video may not be a good analogy, since the audio hardware changes incredibly slowly while new GPUs come out quite frequently and operate in a highly competitive market where keeping new product details secret until launch is often a hard business requirement.

The transition to KMS (and the resulting need for kernel driver updates in order to provide even the most basic functionality) is going to result in some changes in the way drivers are managed going forward. One option is what you suggested - where the kernel driver is disconnected from the kernel tree and delivered independently in a kernel-version-independent manner - but since the kernel driver just finished being moved *into* the kernel tree and synced up with other kernel development activities that seems pretty unlikely to me.

The other obvious option is for more distros to move onto a rolling-release model, where distro packagers make it easier for users to update xorg, kernel and the associated drivers on a regular basis in sync with each new release from development.

I suspect the latter option is more likely than the former. In the meantime I guess the choice is between backporting new hardware support to slightly older versions of the drivers, or making the latest driver work on slightly older versions of the framework. I'm not sure what the conclusion will be but I expect those discussions to continue over the next few months.

[darkphoenix22]

It's really interesting hearing this stuff first hand from a dev. It takes a lot of dedication to come out answer your users' questions in depth like this. Seeing it has seriously raised my impressions of ATi and I'm sure it has done the same to many others. The next graphics card I buy will be ATi, just because I need to reward this kind of dedication.

Just remember even though you may get alot of flack from the Linux community for one reason or another, you guys are still doing a bang up job. Infinitely better than Nvidia, who has done their best to curtail the development of open source drivers for their hardware. I am now confident that ATi is completely dedicated to open source on a level completely above that of Nvidia and most other companies. All you guys need now is a bit of recognition.

Thanks again for listening to my suggestions and my (at times, baseless) criticism,
Ryan

[bridgman]

In the interests of full disclosure I'm probably better described as an ex-dev, at least as long as the other parts of my job stay as busy as they are.

But thanks

[monraaf]

In the interests of full disclosure I'm probably better described as an ex-dev,

In the interest of full disclosure are you by any chance responsible for or had anything to with the disaster called fglrx? Note that anything you say can and will be used against you

[monraaf]

no bridgman do not wana be the 'fglr-dev'(no one wana)... find another one to hit...

Yeah. I can imagine why. His job as an ATI spokesperson in the Linux community is hard enough already, especially at the end of each month when a new Catalyst release comes out