OSDev.org

Hi,

I am looking (again) at the way my OS handles drivers. Because I am now VESA enabled, I was starting off by writing a video driver - but I have a conceptual difficulty....why?

My OS will eventually have a GUI, but for the moment I am just working on creating a console mode. A Virtual Console Manager will supply console services to apps (display memory and keyboard input) and will display the currently actice console on the screen by writing to display memory.

Because I have chosen a flat display memory model, VESA space starts from 0xE0000000 upwards, with direct writes to this area giving visual output as expected. But surely my Virtual Console Manager could just be writing directly to this area? Why even bother with a display driver (other than finding a way to change modes)?

When I eventually create a GUI, it will be the Window Manager which writes to this display area directly. Again, why even bother with a display driver? Just ensure that it is only the Window Manager that can write to that area of memory and all apps go through the window manager.

Am I looking at this in the wrong way?

Cheers,
Adam

Your system is based upon the assumption that all video devices are just dumb framebuffer devices. For starters it will do, but if you want any support for hardware accelleration then framebuffer accesses may no longer be possible without certain constraints.

Oh yes - sorry - I was assuming a driver based on a linearly buffered VESA device. I can see the advantage of having a video driver if you want a common interface for hardware-accellerated graphics.

I did just have a thought after posting. Perhaps if my driver took a pointer to the buffered desired display of the 'Virtual Console' to copy in to video RAM, it could then ensure that the copy-in happened as fast as possible for the type of CPU (using mmx / sse etc...) regardless of how the user-space software was written.

Cheers,
Adam