OSDev.org

Hi,

when people on this forum ask how to get beautiful graphics for their OS the answer is often: "Use VBE (or the boot loader) to mode set and never change the mode after that. Writing a driver for modern graphics cards is too hard!" I would argue that this is no longer true for Intel and AMD graphics cards with publicly available documentation.

In the last few days I have written a mode setting driver for Intel's G45 graphics chip. I documented this process in a wiki page.

This is an RFC about said wiki page:

• Is the page comprehensible? Does it define all terms that it uses? Is there anything that is ambiguous or not clearly stated?
• What topics should I elaborate on?
• Is it detailed enough so that you can write your own G45 driver by reading the wiki page + the documentation of specific registers from Intel? If not: What is missing?
• Should we add it to the front page when it is tidied up? The page is arguably in a better shape than many other pages that are linked on the front page.

That being said there are still a few things to do:

• The EDID page that I linked to is horrible. This really needs to be cleaned up and supplemented with useful information.
• We need a short page about I²C and DDC. I can write them but my knowledge of DDC mostly comes from reading the Linux kernel source. Does someone have a copy of the E-DDC standard available?

I hope that this work inspires people to write their own native mode setting drivers (and hopefully extend the wiki page ) . I only have the G45 available in hardware but would love to have a driver for the later generations of Intel chips. I do not think that writing a mode setting driver for those cards is much more complicated than writing a mode setting driver for the G45. And it is really not that complicated: My G45 driver is just 600 SLoC. That's shorter than my UHCI driver and UHCI is the least complicated of the USB HCDs.

Thanks,
Alexander

Korona wrote:Hi,

when people on this forum ask how to get beautiful graphics for their OS the answer is often: "Use VBE (or the boot loader) to mode set and never change the mode after that. Writing a driver for modern graphics cards is too hard!" I would argue that this is no longer true for Intel and AMD graphics cards with publicly available documentation.

In the last few days I have written a mode setting driver for Intel's G45 graphics chip. I documented this process in a wiki page.

This is an RFC about said wiki page:

• Is the page comprehensible? Does it define all terms that it uses? Is there anything that is ambiguous or not clearly stated?
• What topics should I elaborate on?
• Is it detailed enough so that you can write your own G45 driver by reading the wiki page + the documentation of specific registers from Intel? If not: What is missing?
• Should we add it to the front page when it is tidied up? The page is arguably in a better shape than many other pages that are linked on the front page.

That being said there are still a few things to do:

• The EDID page that I linked to is horrible. This really needs to be cleaned up and supplemented with useful information.
• We need a short page about I²C and DDC. I can write them but my knowledge of DDC mostly comes from reading the Linux kernel source. Does someone have a copy of the E-DDC standard available?

I hope that this work inspires people to write their own native mode setting drivers (and hopefully extend the wiki page ) . I only have the G45 available in hardware but would love to have a driver for the later generations of Intel chips. I do not think that writing a mode setting driver for those cards is much more complicated than writing a mode setting driver for the G45. And it is really not that complicated: My G45 driver is just 600 SLoC. That's shorter than my UHCI driver and UHCI is the least complicated of the USB HCDs.

Thanks,
Alexander

Hi Alexander. First of all I would like to say congrats! You are the first person on this entire forum to do something like this and document it. This will for sure help some better aka more experienced users who have enough knowledge and time to do something as "tough". I don't think that an average user will be able to make use of it just by reading it. That person will have to know the background of all these terms (clocks, timings, refresh rates, I2C, DDC). 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.) The only downside (personally) is that you used C++. I don't know if it is translatable to C. I would like somebody to translate it to C. (For users (most of them) that use C (or even Assembly).) This is a true inspiration, I would like to see users doing their drivers based on this. Also you should put this at the front page. You said AMD, but which ones? Old or new graphics cards? I think you should also cover 2D acceleration and mouse hardware layer. FreeBSD has an I2C library that you could provide a link to.

Hi,


Please do note that hgoel already is writing a page about Intel HD graphics, which can be found here: http://wiki.osdev.org/Intel_HD_Graphics.

I suggest you contact him in order to have a better coordinated effort to write a single wiki page that describes Intel graphics. However, he hasn't be on this forum since 10th and he hasn't been on IRC for at least two days either. So, you will need some patience here.


Regards,
glauxosdever

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.

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. If I dump the registers to the screen, and they match the expected default values, I know that I'm on the right track. I love working with virtual machines because I can code and test on the same machine, but I've run into many, many situations where the hardware registers just do not behave as they should, and I end up trying to fix the problem in my code when there is no problem.

For open ended values, like timing and multipliers, some example values that are known to work in specific scenarios is pretty helpful, as well.

With that said, your work is very thorough and detailed, so no complaints there. I just need actual numbers that I can use in my code. I think I have an old laptop with HD graphics that I can use for testing if I can get my network bootloader working again.

Hi,

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.

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. However, newer generations have moved a lot of the system over to DisplayPort, there we don't get GMBUS and have to work with the DisplayPort AUX channel. This needs documentation, not only because it is a bit more complex, but also because the newer DisplayPort standards are behind a pay wall. It is however possible to access older versions of the standards that do describe the AUX channel interface.

DisplayPort standards: https://www.vesa.org/vesa-standards/free-standards/
Also, for the EDID, the Wikipedia article as well as the official VESA specification are pretty good sources.

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.

Good luck!

glauxosdever wrote:Hi,


Please do note that hgoel already is writing a page about Intel HD graphics, which can be found here: http://wiki.osdev.org/Intel_HD_Graphics.

I suggest you contact him in order to have a better coordinated effort to write a single wiki page that describes Intel graphics. However, he hasn't be on this forum since 10th and he hasn't been on IRC for at least two days either. So, you will need some patience here.


Regards,
glauxosdever

I try to always remain connected to IRC, didn't notice I had gotten disconnected, thanks for stepping in for me though!

Hi,

octacone wrote: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 .

octacone wrote: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.

SpyderTL wrote: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.

SpyderTL wrote: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.

hgoel wrote:Hi,

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.

hgoel wrote: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.

hgoel wrote: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.