[Xorg] Kernel Summit and console design

[Jon Smirl]

I see that keithp is running the KS session about video drivers. It
might be useful to hash this out with the X developers since a lot of
people at Kernel Summit don't work with graphics cards. Many of these
things have been discussed on this an other lists before.

First is a basic assumption, there are two kinds of display output from
the system:
1) kernel stuff - printk, kernel boot, kdbg, OOPS. Kernel stuff can
have a high display priority and optionally override other displays,
for example a kernel OOPS while you are running X. Since the system
just crashed getting that OOPS on the screen is the most important
thing in the system. Kernel display can not use userspace code since
user space may be dead.
2) everything else

Now working from this assumption, the video driver must have a kernel
entry point for drawing to the screen. This entry point has to be
optionally able to force itself onto the screen.

Next there are a bunch of discussion points about how to build
everything else...
1) SAK - how to achive a guaranteed secure login that can't be trojaned
2) multiuser support - supporting multiple cards and different users
logged into each head, both at the console level and X level
3) after looking at multiuser you will want to move the VT system to
user space, how can this be done?
4) should there be a standard IOCTL interface to video drivers, or
should the IOCTL interface to drivers be private and the published API
be a library API?
5) If an OOPS needs to interrupt X, how can it draw? Should the OOPS
attempt to change the display mode, or should the OOPS code be general
enough to clear and draw the display without changing the mode?
6) What about an OOPS during an uninterruptable graphics operation?
should the kernel drivers force the complete atomic operation to be
submitted to the kernel before starting the operation in order to
guarantee that it can be finished if user space is dead?
7) should there be a single device driver for each card or should the
kernel implement a robust system for multitasking different drivers
onto the hardware
8) kernel drawing does not need acceleration. If the VT system and user
consoles are running from user space could they use a user space
library for acceleration instead of the existing fbdev model?
9) what should the driver IOCTL interface look like? fbdev, DRI,
something new?
10) Should user space hardware access from things like X be blocked?
Instead a 2D XAA driver would be moved to an external library and X
would call this library. The library would be granted hardware access.
The point of the external library is to allow coordinated access to it
from non-X apps like user console and user space VT implementations.
Hardware access would be blocked from all apps, not just X. Everyone
would have to use the library.
11) what is the future of VGA mode? how will it be controlled with
multiple cards are present?
12) How is mode setting handled? Is everything done in the kernel?
Everything in user space? How about computing the register values
needed for achieving the valid modes in user space and the storing the
values in the driver. If you use a KVM switch you need to recompute.
13) How do secondary cards get reset in a multicard system?
14) How are we going to get all the groups working together and
building a coordinated system?


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


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail