[Xorg] The big multiconsole nasty

[Egbert Eich]

Hi Thomas,

Thomas Winischhofer writes:
 > 
 > 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 

There still is a little obstacle that is tied to the license of the 
drivers. Kernel drivers are GPL. To use them as a sample to derive
code for an MIT Licensed driver one would have to go thru a 'clean
room' step.

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

That may be true for the SiS driver. It is not necessarily true for
other drivers - especially ones that have been orphaned in X for a
while. 
>From what I hear the MCA fbdev driver in the kernel has better support
for DVI than the X driver has.
Furthermore there are the little pesky problems I'm thinking about:
someone may find a fix and add it to one driver. The maintainer of the
other driver may not even realize the fix.

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

Presently we support OSes for which there is no representative on
this list, yet. It will be a job we have to takle in near future to get
all these people together.
I'm sure at the moment we don't even know for sure on which OSes/platforms
the code still builds.

However this is not my only concern: I'm also concerned about portability.
Portability to future OSes/platforms.

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

That's an even bigger problem: if commercial OSes don't provide a way
to build custom modules and demand loading them there is now way we 
can go thru the kernel.
There are not that many commercial OSes around any more we support today
and most of them don't play a signifficant role any more. 
Solaris/x86 may be the most importand one. There are not too many OS/2
users left, I haven't heared from LynxOS for quite a while and SCO has
a bad press anyway these days....

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

True!

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

Right. Also debugging a driver in user land is much simpler.
After you've gone thru hundreds of modify-build-test cycles to
get one combination of register settings right you know what
I mean :-/

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

Well, as a debian/i386 user you are very mainstream. Your opinion
may not be mainstream, however ;-)

Cheers,
	Egbert.