Funding Radeon driver development

Russell Shaw rjshaw at
Sun Apr 15 23:20:45 PDT 2007

Alex Deucher wrote:
> On 4/15/07, Russell Shaw <rjshaw at> wrote:
>> Daniel Kasak wrote:
>> > Firstly, I thought I'd start a new thread instead of replying the the
>> > original one, as I'd like to get maximum exposure and not just people
>> > interested in tv-out ...
>> >
>> > Hanno Böck wrote:
>> >
>> >> Hi,
>> >>
>> >> One of the most missing features for me in linux is my non-working
>> >> tv-out. (well, it can work with the proprietary ati-driver, but that's
>> >> not really what I want)
>> >>
>> >> Now, I heared that some people were working on that, but never saw a
>> >> patch that made it work for me. As this would make things much easier
>> >> for me, I thought that I might donate a small amount of money if
>> >> someone is willing to pick that issue up. I also think that I could
>> >> gain some more donaters via a public announcement in my blog.
>> >>
>> >> My question: Would such an initiative be welcome by the xorg-devs?
>> >> Anyone probably already interested in getting such a bounty?
>> >
>> >
>> > I've been meaning to suggest something similar, but I've been snowed
>> > under in work and stuff. I think the bounty idea is a great way of
>> > motivating both users and developers...
>> Geez, i've had *months* of free time to write drivers for *free* and have
>> tried just that for the ATI 9200 card i have.
>> The failure of xorg is to document anything about writing a card driver,
>> how existing ones work, and how DRI works.
> There is a fair amount of documentation, what aspect were you having
> trouble with?  Also, I've said this before, and I'll say it again, if
> you need help understanding something, please ask!  Email the list or
> me directly if you want.  I'm happy to explain anything I have
> knowledge of:  crtcs, outputs, drawing engines, how a mode gets
> programmed on a radeon, etc.
>> Even though i've worked out a lot of it by looking at source code over
>> years, there's too much undocumented stuff such as the dozens of card-
>> specific non-vga registers and configuration code that makes it
>> impossible to understand the hardware well enough to write and debug
>> X driver code.
>> The first thing that could be done is to document what driver code
>> is based on proprietory NDA data, and what was reverse engineered.
>> Money spent on X driver documentation or howtos is far less wasteful
>> than X conferences (of which i'll never go to anyway).
> Well, what sort of documentation do you want or think you need.
> Seriously.  Perhaps we can start putting something together.  I feel a
> lot of people say we need documentation, but no one can clarify beyond
> it's too hard for me to understand and then a bunch of hand waving.
> What aspect of the driver did you want to work on?

I wanted to know enough so that i could use the drivers stand-alone in my
own windowing system. For compatability, X apps would run in their own X
environment in their own top-level window of my windowing system. The goal
is to make a better (in many ways) windowing infrastructure than X. I can
do it on my own embedded system with my own video hardware, but not on a
normal pc.

>> If i had've had enough information to hack my radeon card, the ati driver
>> could've been by now *bug free*.
> Unfortunately pretty much everyone is in the same boat here.
> Databooks are not some magical panacea of knowledge.  They are pretty
> much what you see in the driver reg.h files: register offsets and bit
> fields, often without descriptions.  You really just have to dive in
> and start playing with the driver and asking questions.  Working
> source code is *invaluable*.

There's such a large number of register bits in radeon_reg.h that just
playing with crash-and-burn methods will take forever to conceptualize
everything. Then the same understanding would be needed if other chips
were to be used.

What i really wanted is an openGL graphics driver infrastructure for all
cards that is external to X. I haven't figured out how to separate DRI
from X yet.

More information about the xorg mailing list