[Xorg] Kernel Summit and console design

[Egbert Eich]

Jon Smirl writes:
 > 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.

Right. It doesn't have to.
As long as the kernel knows the framebuffer parameters 
(depth, bpp, location, size, stride, current start address)
it can dump anything to it.
The only obstacle may be an active 2D or 3D engine:
- Some chipsets don't like it if you dump things into the fb when 
  an accelerator is active.
- The kernel could interrogate the 3D driver to find out about the state
  of the HW.
- The entire 2D code could be put into the kernel so it could be dealt with
  the same way - not my favorite solution and not feasable for the range
  of HW that is in use.
- A small piece of HW dependent code could be in the kernel to probe the
  HW state.
- The kernel could just wait for a while and hope that the engine is
  idle.

 > 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.

Why? 
The framebuffer is just a range in the memory address space of the
kernel. So it can write to it whatever it wants. 
The only problem I see is the status of the 2D and 3D engines.


 > 
 > 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?

We may need both.

 > 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?

Generally there is no need to change the video mode.
You just paint into the framebuffer - without worrying what else is
in there.

 > 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

I'd prefer a single device driver. 
However before we have all drivers ported to the new model (with all
features and capabilities) one needs to be prepared that people use 
'other' drivers for certain HW.

 > 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?

I would prefer if as little as possible lives in kernel space.

 > 9) what should the driver IOCTL interface look like? fbdev, DRI,
 > something new?

I think can be decided best after one knows what needs to live within
the kernel.

 > 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.

With library you probably refer to something not living in the address
space of the application itself.

 > 11) what is the future of VGA mode? how will it be controlled with
 > multiple cards are present?

There is a wide range of hardware around that still requires some
VGA support. Depriving user of this HW of a feature that they have
been using for a long time would make them very unhappy.
In an multi card, multi seat environment it is necessary to have a 
central agent to control this. 
There are two parts to it:
1. Keep track of which device currently has VGA access.
2. Control VGA access (bus routing etc).
We probably want to do 1. in user space while 2. could be handled
in kernel space.
Please note: 
a. I the X server we presently don't restrict resource
   sharing to VGA registers - VGA matters only as far as bus routing
   is concerned - we support it for arbitrary registers. This can 
   matter on HW that still requires 8514 (or other legacy standard)
   registers.
b. When two devices share the same address space for some registers
   one device is taken off the bus (we can disable PIO and MMIO separately).
   That means: anything that needs to draw to this address space
   has to either go thru the agent that controls the access or 
   has to enable access itself (which would be the case when the
   kernel needs to dump oopses).

 > 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.

I personally favor a model where mode setting can be kept outside of
the kernel. If a user mode app does mode setting and notifes the kernel
about the mode parameters (framebuffer location) it should be sufficient.

Display hot plugging requires a lot more.

 > 13) How do secondary cards get reset in a multicard system?

You always keep it in some mode. Sometimes it may be desireable to
be able to repost a card (if something went awfully wrong).

 > 14) How are we going to get all the groups working together and
 > building a coordinated system?
 > 

That's definitely a good question!

Cheers,
	Egbert.