[Xorg] The big multiconsole nasty

[Egbert Eich]

Jon Smirl writes:
 > Mode setting code is large. If you add up everything for the radeon it
 > is about 100K. Parts of this need to be in the kernel. For example the
 > Linux kernel has a well defined framework for I2C (used to retrieve
 > DDC). The IOCTL that actually sets the mode bits into the registers
 > should be in the kernel to remove the need for X to be root. But those
 > two things add up to about 5K of code. The rest of this code is open to
 > debate where it goes. There are definitely two groups on whether the
 > rest of this code goes into the kernel or into a library. 

The Linux kernel does. What about the other OSes? 

Today many drivers run the BIOS to retreive DDC data.
All that takes place in userland.

 > 
 > Mode setting on dual head cards means you also have to deal with memory
 > management. Changing the mode can cause the buffers to resize. Setting
 > a mode is useless without a buffer to display from so you have to deal
 > with this problem. fbdev has avoided this issue by only supporting a
 > single head.
 > 
 > But now introduce OpenGL. OpenGL supports double buffering with page
 > flipping on each display. It needs depth buffers, aux buffers, texture
 > memory etc. If you go full screen on a video you may want to switch to
 > a different framebuffer. OpenGl can discard and move these buffers too.
 > 
 > These are just some of the things that need to be considered when
 > designing the mode setting code. I haven't even touched on the boot
 > display and kernel printk. From what I know, mode setting is going to
 > be the hardest API to design.
 > 

Basic mode setting code does not have to deal with these issues.
They need to be implemented on top of it.

Egbert.