[Xorg] The big multiconsole nasty

[Jon Smirl]

--- Keith Packard <keithp at keithp.com> wrote:
> One thing I'd like to see is a general reduction of code that runs in
> the same address space as the 'scary' bits.  Starting with the device
> initialization and mode selection logic makes good sense as none of
> that is particularily performance sensitive.  This should give us
> significant freedom of choice in implementation.

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. 

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.

=====
Jon Smirl
jonsmirl at yahoo.com


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail