OSDev.org

Hey,

I recently did a bit of research on OS graphics. My kernel isn't in that stage yet by a long shot, so I didn't understand everything I found (which is also why I put this in the ramblings section...). I guess I got a grasp at most things, please correct me if I say something terribly wrong.

I basically have an old computer and a new full-HD monitor. I initially had windows XP on it, which (if I remember correctly) needed drivers before my monitor would work on full resolution. The way I understand it now, is that windows XP was probably using SVGA until there was a specialized driver available, because SVGA works on most (all?) graphics cards.

I did a little more research about graphics cards, and it seems that drivers are usually only made for windows and linux. I understand that it is possible to reverse engineer a graphics card (or should I say chipset? I'm not 100% sure about the correspondance between these two things, but I suspect the chipset defines the hardware interface), and implement a driver, but it is practically near to impossible (especially when you do it alone). Then there are some graphics cards which have their interface documentation online. I think AMD started to do this a long time ago (and now I'm looking up the osdev wiki article: intel and 3dfx have some documentation online), but I never heard anything from it since. It seems that the documentation online is just for some old cards, and to be honest, I don't understand too much of what I've seen so far.

Are there people who have succesfully implemented hardware drivers? What would be my best shot? I'd love to use my 1920x1080 monitor for my OS, but I have no idea how feasible this is (And I fear it's not at all).

kutkloon7 wrote:The way I understand it now, is that windows XP was probably using SVGA until there was a specialized driver available, because SVGA works on most (all?) graphics cards.

SVGA is a display standard. Since, in the past, each SVGA card vendor designed their hardware differently, VESA defined an interface called VBE/Core, for systems that use a BIOS firmware. As long as the SVGA hardware supports it, a driver can be written against this interface. Alas, VBE/Core doesn't do anything fancy so it should only be used as a last resort, when a native driver is missing. Systems that use EFI or UEFI firmware provide an alternative: UGA or GOP, respectively. As do systems which employ OpenFirmware firmware (heh), but you won't see any such machines these days.

kutkloon7 wrote:I understand that it is possible to reverse engineer a graphics card, and implement a driver, but it is practically near to impossible (especially when you do it alone).

Reverse engineering a modern GPU and/or GPU driver by yourself is not an impossible task but it may be a tedious one, depending on the hardware.

kutkloon7 wrote:Then there are some graphics cards which have their interface documentation online. I think AMD started to do this a long time ago (and now I'm looking up the osdev wiki article: intel and 3dfx have some documentation online), but I never heard anything from it since. It seems that the documentation online is just for some old cards, and to be honest, I don't understand too much of what I've seen so far.

The major graphics hardware vendors for the PC platform are Nvidia, Intel, and AMD. The former doesn't enough programming documentation in order to write a industry-grade driver (but there are ongoing reverse engineering efforts), while the latter two do. If this is important to you, you should factor this in the next time you buy graphics hardware.

kutkloon7 wrote:(or should I say chipset? I'm not 100% sure about the correspondance between these two things, but I suspect the chipset defines the hardware interface)

A chipset is a motherboard component which manages the interaction between the CPU's and the various onboard controllers (for both memory and peripherals).

kutkloon7 wrote:Are there people who have succesfully implemented hardware drivers?

Yes, plenty.

kutkloon7 wrote:I'd love to use my 1920x1080 monitor for my OS, but I have no idea how feasible this is (And I fear it's not at all).

It's very feasible. All you need to do is to write the appropriate drivers.

Thanks for your answer

I don't know about EFI and UEFI: are they commonly used? Do they provide a better alternative for VESA (I often use SVGA when I mean VESA, sorry for the confusion). Also, I could not find very much driver documentation online (for AMD and Intel cards). I don't really have time now to check it (in the afternoon I probably will), but last time I checked I was under the impression that the documentation posted online was mainly for older cards.

kutkloon7 wrote:Do they provide a better alternative for VESA (I often use SVGA when I mean VESA, sorry for the confusion).

And you're still doing it wrong: it's VBE (VESA BIOS Extensions). VESA is the organisation, SVGA means better than VGA.

In EFI, VBE is gone and replaced by GOP because VBE isn't maintainable in that environment.

Also, I could not find very much driver documentation online (for AMD and Intel cards).

http://www.x.org/docs/AMD/

kutkloon7 wrote:I don't know about EFI and UEFI: are they commonly used?

Nowadays, Macs use EFI and PC's use UEFI, while BIOS is on its way out. It's sometimes still supported for backwards compatbility but many machines shipped in the last few years don't even bother with it anymore.

Combuster wrote:In EFI, VBE is gone and replaced by GOP because VBE isn't maintainable in that environment.

Just to avoid confusion, I'll mention again that EFI defines UGA, while UEFI defines GOP (as a replacement for UGA).

I guess this is just too complex for me at this point. I have no idea about some important concepts (UEFI, GOP, I'm not too sure about VBE either), and I have no idea were to start. MAybe the best plan is just to keep focussing on my kernel and deal with graphics stuff when the rest is steady and stable. Hopefully I'll have a bit more knowledge, so I'll have some starting points.

Thanks for the posts though, I appreciate!