[Xorg] The big multiconsole nasty

Egbert Eich eich at pdx.freedesktop.org
Wed Jul 7 05:45:19 PDT 2004

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.


More information about the xorg mailing list