[Xorg] The big multiconsole nasty

[Thomas Winischhofer]

Egbert Eich wrote:
> 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.

Well, in reality they don't have to. Looking at each others code has 
been done, is being done and will be done anyway. A bit more of 
cooperation between fbdev and X driver developers (if not identical) 
would minimize this "agony" (if any). And finally: fbdev drivers are 
really dumb pieces of software compared to a modern X driver. The only 
thing they share is mode setup in general (internals differ, of course).

But before we talk about transferring video stuff - what level ever - 
into the kernel (which I personally am not especially keen about) I 
suggest we first agree on

- what hardware architectures and
- what OS platforms

we intend to support. (Couldn't find any official statement regarding 
these qeustions anywhere on x.org at first glimpse.)

After these lists are complete, the next step would be to evaluate what 
it takes to get stuff into the kernel on all these archs/platforms, how 
long release cycles usually take, what the respective kernel maintainers 
think about it (ie whether or not the would accept any of this) and so on.

 From my experience, getting gfx stuff into the linux kernel sometimes 
means smuggling it in behind Linus' back. An agony of its own kind if 
one knows Linus' attitude to fbdev drivers and graphics stuff in the 
kernel in general. No idea how other kernel maintainers like this idea, 
not at least when it comes to non-OSS, commercial kernels.

My very humble $.02 as one who's been in X driver development and user 
support for a mere 4 years: Forcing people to change and reconfigure 
their kernel just to run the "current gui" is something I really can't 
imagine being a much appreciated idea. And the "gui" shouldn't really be 
able to take down the entire machine in case of a bug. Welcome to the 
world of Windows (and debugging hell, besides).

I can well agree on moving resource allocation stuff into the kernel if 
not there already; mode setup etc, however, I tend to think is userland 
stuff. Not even speaking of 2D, video, HW cursor, color management, etc 
(ie stuff that requires register access in the same way as mode setup).

Hell, I guess I am one of the "10 to 15 percent".

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
twini AT xfree86 DOT org