[Xorg] The big multiconsole nasty

[Egbert Eich]

Jon Smirl writes:
 > --- Egbert Eich <eich at pdx.freedesktop.org> wrote:
 > > We could probalby stick a large amount of this into the kernel and
 > > make 85 to 90 percent of the users happy. 
 > > The reason why I don't advocate this but instead suggest to try to do
 > > as
 > > much as possible from user land is that I don't want to make the
 > > other
 > > 10 to 15 percent unhappy by giving them the finger.
 > > Furthermore it seems to be much harder to port things between kernels
 > > of different OSes than to port a userland application to the
 > > interfaces
 > > of a new kernel.
 > 
 > But now we end up building everything twice on Linux since fbdev needs
 > all of these things too. Then we have to spend time making the X and
 > fbdev versions play nice together. Plus, X's PCI bus manipulations are
 > in direct conflict with the Linux kernel.
 > 
 > Why not build an external library that adds these features to the OS's
 > that don't have them and uses the OS routines when available. This
 > library would be small on Linux and big on BSD. The library interface X
 > uses would be the same on both OS's. Mesa-solo needs this same library.

I would like to arrive at a single driver source for all OSes.
video chipsets probably have more registers than any other hardware
- many of them serve obscure purposes and are poorly documented.
driver development - unlike a lot of other code - is not cheap.
No use that two groups have to go thru the same agony.

Most other things are not quite that critical. We can duplicate
the PCI and address space mapping stuff easily as this is doesn't
have to be redone for each chipset but is more platform and OS 
depent.

 > Another example of this is sorting out where hotplug input devices go
 > in a multiuser system. Linux is going to have to do this at the
 > kernel/library level in order to support framebuffer console. This code
 > can easily sort these things out for X too. But if X builds a system
 > for this too then we have to make everything coordinate and use the
 > same config files, etc.

We have already discussed a daemon solution. Which parts would have to
live on the kernel level?

Egbert.