[Xorg] The big multiconsole nasty

[Egbert Eich]

Jon Smirl writes:
 > --- Keith Packard <keithp at keithp.com> wrote:
 > > My position here is to avoid taking a position -- migrate the
 > > existing mode selection logic behind a new API and get the X server 
 > 
 > There is a lot more to this. Some of the areas include:
 > 
 > Device detection
 > Reset, with real mode helper, getting the ROM contents
 > Active VGA device control, making sure there is only one
 > Locating device resources, where are registers/RAM, etc
 > Mode setting - for all heads
 > Who owns the hardware - root or user
 > Hotplug add/remove of video cards
 > Hotplug add/remove of input devices
 > Multiuser - what video/keyboard/mouse form a group, how do things get
 > assigned.
 > How can the kernel put up error messages on the display -- OOPS, printk
 > Coordination of VRAM memory management
 > 
 > This list is pretty large and I've probably forgotten a few things.
 > 
 > All of this matters equally to fbdev and X.
 > 

If you consider fbdev as something that lives solely in the kernel
the only solution would be to place most - if not all - of the
functionality mentioned above into the kernel.
If we can agree on that all the kernel needs is a framebuffer
with certain properties (like location, size, depth ...)
most things listed above could also live in a userland daemon.

I acknowledge that there are still problems: 
for the boot console the graphics chipset needs to be initialized 
at boot time by the bootloader or kernel.
I'm still trying to figure out what systems require such initialization.
Certainly some embedded systems do - but there this may require some
custom solution anyway.
VRAM coordination for printk's is also tricky: on some chipsets you 
need to know if the chipset is idle. If the kernel can still communicate
with the daemon process it can let this handle the output.

Egbert.