For example try typing DDC in Google. Personally I've never heard of DDC. (Which means I will have to learn about it in order to use it.)
Well that problem can be fixed with a DDC page in the wiki
You said AMD, but which ones? Old or new graphics cards? I think you should also cover 2D acceleration and mouse hardware layer.
(Relatively) new generations are likely easier to support than old ones because they are better documented.
2D acceleration (i.e. BLTing) is almost the same as 3D acceleration. The greatest difference between 2D and 3D acceleration is in the userspace OpenGL/Vulkan/DirectX driver. But yes, I will try to document the hardware cursor handling.
Personally, the most important information that I need to write a driver are all of the IDs, constants, register offsets, flag values and enumerations that apply to the hardware. If the descriptions are detailed enough, I can almost get by with nothing else.
These can be in table form, or in asm or C style code blocks. I usually use these values to create XML files, because they can easily be transformed to virtually any other format. Having to look them up in a 300 page PDF file is probably the worst approach.
I will add the constants that are not easily accessible from the manuals to the page. However I don't think that copying the register numbers and bits from the manual would help that much. People who want to implement a driver will likely have to read the manual anyways and copying the values would be tiresome. One would have to copy/prepare at least 20 pages from the PDF. We should invest our time in complementing the official documentation and not in replacing it.
As a compromise I could add the respective section numbers when discussing each register so that it is easier to find in the official docs? I will also make sure that I mention every bit that has to be set in a register.
The next important thing I need is a run down on the default/initial values, and a sequence showing in which order registers need to be changed.
The sequence in which registers need to be programmed is more or less documented in the wiki page. I will try to make that sequence more clear. I will also add a few default / example values and calculations.
Nice to see someone else also working on Intel graphics!
As glauxosdever mentioned, I've written a (mostly incomplete) page on Intel integrated graphics already at http://wiki.osdev.org/Intel_HD_Graphics
Now we have 3 pages on the same topic (including http://wiki.osdev.org/User:Greasemonkey/Intel_GenX
), it might be good to merge them, please let me know if you are interested. I am generally always available on the Freenode IRC at #osdev or #Cardinal-OS though depending on your time zone, I may be asleep.
Yeah, nice to see that you're also working on a driver
I did not know of the other pages otherwise I would have tried to integrate my work into them
. Yes, it would be great to merge everything into a single Intel graphics page. I will review the two other pages and comment on that later.
DDC and I2C aren't too complicated and it's mostly enough to just set the appropriate timings in the GMBUS configuration registers, and I2C is fairly well documented as it's a popular protocol in embedded systems, so I'm not sure if it needs a page of its own.
Yeah it looks like DDC is nothing more than "write 1 byte segment to I²C address 0x30, write 1 byte into to I²C address 0x50 and then read 128 bytes from the same address" and I got that working and can set the modes from EDID. However the exact standard is also behind a paywall and maybe it would be nice to confirm that there is really nothing else to consider.
I will take a look at the DP standard.
I've been intending to write full 3d accelerated drivers for Intel graphics, but it's all currently on hold as I take a break from my OS to work on a few other things as practice.
I plan to port libdrm + Mesa to my OS so that I can run a Wayland userspace. Mode setting is basically sufficient for that but executing command buffers (i.e. 2D/3D acceleration) would of course be nice too.