Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[James S. <jsi...@tr...>]

> You are speaking about the merging as something that will happen inevitably,
> and quite soon also. 

No. It will be awhile. 

> How is it really, do the DRI people know you intent to
> merge the drm and fbdev ? What do they think about it ? I suppose it is quite
> political stuff, isn't it ?

I have spoken to them before about this. They know it has to be done but
don't really care abouot fixing the problem. 

> What about if an app wants to take over let's say the top 4/3 orsomething such
> of the screen (in order to open a 16/9 or whatever video playback window or
> something such) and keep fbcon active in the lower part, in order for the app
> to do it's I/O ?

In graphics mode it should draw the fonts itself. Does X use the console
to draw its fonts? No, of course not. Userland drawing fonts has a few
advantages as well. One with mmap mmio regions you avoid going threw many
layers of the console to draw fonts. Second you have much more control
over the fonts including writing asian fonts which can't be done very well
in the current console system.

> > XFree86 is wrong in this department. The console system should handle it.
> 
> Ah, sure, but Xfree86 is the main app out there, and it is they who really own
> the linux desktop. And they also have the most visibility right now.

So M$ windows owns the PC market. Does this make the way they do software
the right way? In time XFrre86 WILL discover this as linux works across
more and more types of hardware. 

> But again, X actually thinks that they are responsible for handling the card,
> and the DRI follows their lead. It is the X driver who handles the switch
> between the 2D and various 3D contexts. How will using hardware access on the
> console handle this ?

Console will be shutdown in "graphics" mode. This is the way IRIX has
handled it for more than 10 some odd years. It has been proven to work.