To join in development you must first understand the DRI and X11 architecture. Start by reading the developer documents in the documentation section of this website.
Check out the DRI git tree. Poke around the driver source code to find out more about the inner workings of the DRI. There also are some text documents within the X11 source tree that contain useful information. The Building page tells you how to check out, build and install into your local installation of X.
Once you feel that you have sufficient understanding of the DRI to begin coding you can start by submitting a patch. You have to submit at least one patch to get write access to our git. Have a look in Bugzilla for open issues. That is a good place to find an issue that you can fix by submitting a patch.
After you have submitted your patch you can start working on a more concrete project. Have a look at the Status page or read the newsgroups for projects that need to be worked on.
Of course you don't have to submit a patch before you can work on a project. But since you wont be able to check in your work until you submit a patch it is very desirable to submit a patch first. You do want people to test your work, right?
Also, don't be shy about asking questions on the dri-devel newsgroup. The main purpose of the newsgroup is the discussion of development issues. So, feel free to ask questions.
Submit a patch by posting it to the dri-devel mailing list as an attachment to a message. Make sure you explain clearly what your patch is for.
Once you become a regular contributor we'll give you git access.
The References page has a list of suggested reading material. This section will give you a guide to how you should approach the reading of these resources.
There is a wide range of concepts involved in making a DRI driver. As a beginner you don't really need to fully understand them -- just a basic understanding which enables you to get the global picture. You should skim through all the documents referred below, giving more attention to the parts that your curiosity and/or ignorance point you to.
The first document you should read is this FAQ. Not because it's more important than the rest, but because is full of references and simple explanations that provide basic knowledge you need to guide yourself.
There are several topics you must address:
- 3D cards workings: Since a 3D driver and the OpenGL API are basically abstractions to 3D graphics cards abilities, knowing how a 3D card works will help you better understand the drivers. Barron01 and Savator01 give an excellent overview.
- OpenGL API: DRI drivers typcially aim to be as conformant as possible to the OpenGL API. The best reading is indeed the OpenGL Specification. As BrianPaul once said: "The RedBook is for OpenGL users. The spec is more for the implementors."
- Low-level programming: Since you'll be dealing with the guts of the hardware and the OS you should read LDD which addresses all the details of writing a device driver, covering issues such as I/O, DMA, and memory organization from the Linux kernel perspective. TLK and LKMPG are also good references.
- background on ioremap, cacheing, cache coherency on x86
- DRI and X11 architecture: This FAQ will give you a good overview of the DRI architecture. It does not contain all the information of the DRI documentation, but you should give a quick look through it since you may need it for later reference. The X11 architecture is also important.
Beyond reading the above documents more thoroughly, the source code can be the best reference available, especially when the documentation is out of date or non-existent.
Master the tools to quickly find information in a large source tree like DRI's. Use find and locate to quickly get to the files you search. Use grep for searching a for a particular variable or piece of text. You can also use specific tools for code navigation such as cscope and Source Navigator.
Another source of information is the source of the drivers other than the one you are interested in. Since the DRI drivers are largely in tune with each other you can learn much by comparing the sources. Use diff or xxdiff for that.
After you read enough about what to do and how to do so without damaging your hardware, you could look: