replacing X Window System !

replacing X Window System !

[linux cbon]

hi,

I know it may not be the best place, sorry for that.

X Window System is old, not optimized, slow, not
secure (uses root much), accesses the video hardware
directly (thats the kernel's job !), it cannot do VNC,
etc.

The question is : what are your ideas to make a system
remplacing X Window System ?

I think that linux kernel should contain a very basic
and universal Window System module (which could also
work on Unixes and BSDs) to replace X, X.org etc.

What do you think about this ?

Thanks









	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Michal Piotrowski]

Hi,

On 16/05/06, linux cbon <linuxcbon@yahoo.fr> wrote:
> hi,
>
> I know it may not be the best place, sorry for that.
>
> X Window System is old, not optimized, slow, not
> secure (uses root much), accesses the video hardware
> directly (thats the kernel's job !), it cannot do VNC,
> etc.
>
> The question is : what are your ideas to make a system
> remplacing X Window System ?
>
> I think that linux kernel should contain a very basic
> and universal Window System module (which could also
> work on Unixes and BSDs) to replace X, X.org etc.
>
> What do you think about this ?
>
> Thanks

It's a bit off topic here.
Please try on Linux Visionaries Mailing List
http://blackwhale.net/cgi-bin/mailman/listinfo/lvml

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: replacing X Window System !

[Måns Rullgård]

linux cbon <linuxcbon@yahoo.fr> writes:

> hi,
>
> I know it may not be the best place, sorry for that.
>
> X Window System is old,

Still being around might suggest that it has some merit, no?

> not optimized,

Wrong.

> slow,

Wrong.

> not secure (uses root much),

Would you prefer to give any random user direct access to the hardware?

> accesses the video hardware directly (thats the kernel's job !),

Debatable.

> it cannot do VNC, etc.

Most programs can't do VNC.

> The question is : what are your ideas to make a system
> remplacing X Window System ?

Pointless.

-- 
Måns Rullgård
mru@inprovide.com

Re: replacing X Window System !

[Alistair John Strachan]

On Tuesday 16 May 2006 22:57, Måns Rullgård wrote:
> linux cbon <linuxcbon@yahoo.fr> writes:
[snip]
>
> > it cannot do VNC, etc.
>
> Most programs can't do VNC.

I must also note that this is wrong. Many VNC implementations come with the 
Xvnc server (a drop-in replacement for X, headless) and there's the xf4vnc 
project which provides a few pseudo-devices for a regular X session and hooks 
into the video updates (which are then sent via VNC as well as directly to 
your video hardware).

-- 
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: replacing X Window System !

[alan]

On Tue, 16 May 2006, linux cbon wrote:

> hi,
>
> I know it may not be the best place, sorry for that.
>
> X Window System is old, not optimized, slow, not
> secure (uses root much), accesses the video hardware
> directly (thats the kernel's job !), it cannot do VNC,
> etc.
>
> The question is : what are your ideas to make a system
> remplacing X Window System ?
>
> I think that linux kernel should contain a very basic
> and universal Window System module (which could also
> work on Unixes and BSDs) to replace X, X.org etc.
>
> What do you think about this ?

This is a topic that comes up every year or so.  Every year the result is 
the same.  It is not going to happen.

First of all, your assumptions are incorrect.  Modern versions of X are 
not old, unoptimised, will do remote sessions, etc.

There are a couple of very hard problems here.

First you have to come up with a design that is better than X.  That is 
pretty hard.  Next you have to convince all the programmers to port their 
code over to use your new spiffy API.  That is even harder.

Until you have a working model, or at least a design, you can blue-sky all 
you want.  It won't get anywhere and just waste other people's electrons.

-- 
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, 16 May 2006 15:19:16 PDT, alan said:

> First of all, your assumptions are incorrect.  Modern versions of X are 
> not old, unoptimised, will do remote sessions, etc.

Remote sessions have been there as long as the DISPLAY environment variable - I
think even X10.4, 2 decades and more ago, could do that.  I know that it worked
just fine 18 years ago with X11R1 (aah... building that from source on a 25mz
Sun3 took a little while). (Anybody know when the first instance of
pointing 'xmelt' at another user's machine for amusement was? :)

It's interesting that almost every attempt to devise something "better than X"
always seems to get as far as an Xterm-alike, an XClock-alike, a primitive
window manager, and 2 or 3 toy demo programs.  Then, unless you're Microsoft
or Apple, you discover that doing a complete window system is *hard*.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[alan]

On Tue, 16 May 2006, Valdis.Kletnieks@vt.edu wrote:

> On Tue, 16 May 2006 15:19:16 PDT, alan said:
>
>> First of all, your assumptions are incorrect.  Modern versions of X are
>> not old, unoptimised, will do remote sessions, etc.
>
> Remote sessions have been there as long as the DISPLAY environment variable - I
> think even X10.4, 2 decades and more ago, could do that.  I know that it worked
> just fine 18 years ago with X11R1 (aah... building that from source on a 25mz
> Sun3 took a little while). (Anybody know when the first instance of
> pointing 'xmelt' at another user's machine for amusement was? :)

Yep. I know. Most people don't seem to know that X was designed to do 
remote connections very early on.

> It's interesting that almost every attempt to devise something "better than X"
> always seems to get as far as an Xterm-alike, an XClock-alike, a primitive
> window manager, and 2 or 3 toy demo programs.  Then, unless you're Microsoft
> or Apple, you discover that doing a complete window system is *hard*.....

"Those who do not learn the lessons of X are doomed to reimpliment them 
badly."

-- 
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis

Re: replacing X Window System !

[linux cbon]

hi,

X Window System has many problems affecting directly
the kernel.

http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
-Many current implementations of X manipulate the
video hardware directly.
-X deliberately contains no specification as to user
interface or most inter-application communication.
-The X protocol provides no facilities for handling
sound,
-Until recently, X did not include a good solution to
print screen-displays. 
-One cannot currently detach an X client or session
from one server and reattach it to another.

I would add :
-X needs to be root so it opens many security holes.
-X has more code than the kernel and it is almost an
OS in itself.
-if a "closed-source" graphical card driver has
security holes, what do you do ?
etc.

Some people are working on replacement like Y windows
:
http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf
http://www.y-windows.org/

There are some questions like :
- should the next generation window versions Y,Z etc.
remain backward compatible with X ?
I think they should start something better and simpler
from scratch and not backward compatible.
- should the kernel remain pure "shell" or include
some basic universal graphical universal window system
?
I think second answer.


Regards.












	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:

> - should the next generation window versions Y,Z etc.
> remain backward compatible with X ?

If it isn't backward compatible, people won't use it.  X may suck,
but it doesn't suck hard enough that people will abandon all their
currently mostly-working software.

> I think they should start something better and simpler
> from scratch and not backward compatible.

Feel free to write it.  Keep in mind that X doesn't even try to do
widgets - those are done in userspace libraries.  Let us know when you
have enough functionality to make converting worth thinking about.

> - should the kernel remain pure "shell" or include
> some basic universal graphical universal window system

> I think second answer.

Actually, you've proved the opposite.  Consider if the kernel had *already*
included some universal window system (we'll call it W). At that point, you
can't easily write an X, Y, or Z if you don't like W.  If anything, the
*current* W (which happens to be called X11) is *too* friendly with the kernel
already - witness all the headaches dealing with DRM and 'enable' attributes
and other hoops things have to jump through.

If anything, there should be even *less* kernel support for graphics.
That way, writing a Y or Z (or improving X) is easier to do without
destabilizing the kernel.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[linux cbon]

 --- Valdis.Kletnieks@vt.edu a écrit : 
> On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:
> 
> If it isn't backward compatible, people won't use
> it.  X may suck,
> but it doesn't suck hard enough that people will
> abandon all their
> currently mostly-working software.

If we have a new window system, shall all applications
be rewritten ?


> Actually, you've proved the opposite.  Consider if
> the kernel had *already*
> included some universal window system (we'll call it
> W). At that point, you
> can't easily write an X, Y, or Z if you don't like
> W.  If anything, the
> *current* W (which happens to be called X11) is
> *too* friendly with the kernel
> already - witness all the headaches dealing with DRM
> and 'enable' attributes
> and other hoops things have to jump through.
> 
> If anything, there should be even *less* kernel
> support for graphics.
> That way, writing a Y or Z (or improving X) is
> easier to do without
> destabilizing the kernel.

My idea is that the kernel should include universal
graphical support.
And then we would NOT need ANY window system AT ALL.
We wouldnt have 2 os (kernel and X) at the same time
like now.
It would be faster, simpler, easier to manage etc.






	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]

On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:

> If we have a new window system, shall all applications
> be rewritten ?

No.  /bin/cat and /bin/ls will survive unscathed.  However, if you
have a graphical application, it will need reworking.  That's a LOT
of code.

> My idea is that the kernel should include universal
> graphical support.

And if we discover the API is wrong, or there's a bug, what then?

Or if you just want to try a different window manager?

> And then we would NOT need ANY window system AT ALL.

And if Gnome is in the kernel, what do all the KDE and Enlightenment
users supposed to do?

> It would be faster, simpler, easier to manage etc.

It wouldn't be faster, and it wouldn't be simpler, and it wouldn't be
easier to manage.

Come back when you've examined all the code in libX11 (that's just *one*
of the libraries), and identified *all* the locking issues, put in
schedule() calls at all the right places to allow pre-emption, and converted
it to use only 16K of stack space (that's *generous* - if it were in the
kernel, it would have a lot less than 16K available).

And consider that currently, you can update your kernel and usually not
need to make much change to your Xorg source tree, and vice versa.  A bug
in Xorg doesn't force a kernel upgrade.  Now imagine that you hit a bug
in Xorg that's fixed in the 2.6.28 kernel - but releases after 2.6.26 don't
boot on your hardware because of a bug with the SATA disk controller you
have.

And if my X server dies on me, I don't usually need to wait for the
entire system to reboot.  If it was in the kernel, it just became a
panic/reboot rather than "init respawns gdm and life goes on".

I'm idly wondering how many years of actual system kernel hacking and
sysadmin experience you have - I know for a fact that I've been doing it
for a living since well before many frequent posters to this list were
even born (Hi, Kyle! :)  And the single most important point I've learned
in almost 30 years of making a living at it is:

There is *nothing* that ruins a sysadmin's entire week as badly as a
lengthy pre-req chain.  "We need to upgrade A, but that requires a new
release of B, which means we need to upgrade C as well, but the next
release of C won't work with hardware J of ours...".   People who
complain about Red Hat systems having "pre-req hell" with RPMs are
wimps - I've *never* seen a pre-req chain since Red Hat 7.0 that was more
than 5 or 7 RPM's deep.  IBM's AIX 3 often had pre-req chains over
100 deep - I once had a *single* bugfix against one /etc script replace
*literally* over 3/4 of /usr....)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[Panagiotis Issaris]

Valdis.Kletnieks@vt.edu wrote:

>On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
>
>  
>
>>If we have a new window system, shall all applications
>>be rewritten ?
>>    
>>
>
>No.  /bin/cat and /bin/ls will survive unscathed.  However, if you
>have a graphical application, it will need reworking.  That's a LOT
>of code.
>  
>
Wouldn't porting GTK+ and Qt be enough for the majority
of the graphical applications?

With friendly regards,
Takis

Re: replacing X Window System !

[Ondrej Zary]

Panagiotis Issaris wrote:
> Valdis.Kletnieks@vt.edu wrote:
> 
>> On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
>>
>>  
>>
>>> If we have a new window system, shall all applications
>>> be rewritten ?
>>>   
>>
>> No.  /bin/cat and /bin/ls will survive unscathed.  However, if you
>> have a graphical application, it will need reworking.  That's a LOT
>> of code.
>>  
>>
> Wouldn't porting GTK+ and Qt be enough for the majority
> of the graphical applications?

And maybe some compatibility layer for the other?

-- 
Ondrej Zary

Re: replacing X Window System !

[Olivier Galibert]

On Wed, May 17, 2006 at 04:10:38PM +0200, Panagiotis Issaris wrote:
> Valdis.Kletnieks@vt.edu wrote:
> 
> >On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
> >
> > 
> >
> >>If we have a new window system, shall all applications
> >>be rewritten ?
> >>   
> >>
> >
> >No.  /bin/cat and /bin/ls will survive unscathed.  However, if you
> >have a graphical application, it will need reworking.  That's a LOT
> >of code.
> > 
> >
> Wouldn't porting GTK+ and Qt be enough for the majority
> of the graphical applications?

You'll need OpenGL/GLX and SDL too to stand a chance.

And in any case, porting gtk+ includes porting gdk, and gdk isn't much
more than a very thin layer over libX11 with some added functionality.
So in practice it is a better idea to have a libX11-compatible API
(and if possible ABI), which will give you gdk/gtk/Qt/Motif for "free"
(not GL/SDL though), and then change gtk/Qt where appropriate to use
your own features.

  OG.

Re: replacing X Window System !

[Bob Copeland]

On 5/17/06, Olivier Galibert <galibert@pobox.com> wrote:
> So in practice it is a better idea to have a libX11-compatible API
> (and if possible ABI), which will give you gdk/gtk/Qt/Motif for "free"
> (not GL/SDL though), and then change gtk/Qt where appropriate to use
> your own features.

If only there was a way to get all of that for free without doing any
work at all :)

Bob

Re: replacing X Window System !

[Lennart Sorensen]

On Wed, May 17, 2006 at 02:39:37PM +0200, linux cbon wrote:
> If we have a new window system, shall all applications
> be rewritten ?

Unless you make your new system compatible with X, then all X
applications must be rewritten.

> My idea is that the kernel should include universal
> graphical support.
> And then we would NOT need ANY window system AT ALL.
> We wouldnt have 2 os (kernel and X) at the same time
> like now.
> It would be faster, simpler, easier to manage etc.

So if I get a new video card I have to get a new kernel?  Why can't I
just get an updated display system if my kernel works just fine.  RIght
now I can boot any VGA compatible card (and many others) to text mode
and work on my system, while I figure out how to get X going on my new
card.  If it was all in the kernel I am screwed if the kernel doesn't
yet support doing graphics on my new card.  I know that problem from
using Windows, although at least it eventually got better at falling
back to VGA only mode if it couldn't work with a new card.

Len Sorensen

Re: replacing X Window System !

[Bob Copeland]

On 5/17/06, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
> On Wed, May 17, 2006 at 02:39:37PM +0200, linux cbon wrote:
> > If we have a new window system, shall all applications
> > be rewritten ?
>
> Unless you make your new system compatible with X, then all X
> applications must be rewritten.

True for things written directly with Xlib, but hardly anything new is
written without a toolkit these days.  E.g. someone could port GDK to
the new windowing system of the week and all GTK+ applications would
work.  Though I won't disagree that the idea is pointless.

Bob

Re: replacing X Window System !

[Michal Piotrowski]

Hi,
On 17/05/06, Bob Copeland <me@bobcopeland.com> wrote:
[snip]
>  Though I won't disagree that the idea is pointless.

IMHO putting window system to monolithic kernel is mischievous idea.

> Bob

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: replacing X Window System !

[Jesper Juhl]

On 17/05/06, linux cbon <linuxcbon@yahoo.fr> wrote:
>  --- Valdis.Kletnieks@vt.edu a écrit :
> > On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:
> >
> > If it isn't backward compatible, people won't use
> > it.  X may suck,
> > but it doesn't suck hard enough that people will
> > abandon all their
> > currently mostly-working software.
>
> If we have a new window system, shall all applications
> be rewritten ?
>
Unless the new windowing system is 100% backwards compatible with X11, then yes.


>
> > Actually, you've proved the opposite.  Consider if
> > the kernel had *already*
> > included some universal window system (we'll call it
> > W). At that point, you
> > can't easily write an X, Y, or Z if you don't like
> > W.  If anything, the
> > *current* W (which happens to be called X11) is
> > *too* friendly with the kernel
> > already - witness all the headaches dealing with DRM
> > and 'enable' attributes
> > and other hoops things have to jump through.
> >
> > If anything, there should be even *less* kernel
> > support for graphics.
> > That way, writing a Y or Z (or improving X) is
> > easier to do without
> > destabilizing the kernel.
>
> My idea is that the kernel should include universal
> graphical support.
> And then we would NOT need ANY window system AT ALL.
> We wouldnt have 2 os (kernel and X) at the same time
> like now.
> It would be faster, simpler, easier to manage etc.
>
And when the windowing system crashes it'll take the kernel down with it - ouch.

And if I want to run a headless server without a graphical display I
can't simply stop the windowing system I'd have to rebuild a kernel
without the windowing system in it - yuck.

What we have now is a nicely decoupled system - it would be even
better if X was even more decoupled from the kernel, but lets not put
the windowing system in kernel space.

X is not perfect, but it has been around long enough that it has a
huge base of software using it. Throwing that out the window would be
silly.
X also has had networking support since the beginning, and all X apps
can run with remote displays without having to do much (if anything)
themselves to support that - that's a really nice feature.
Modern X can be quite fast with a properly supported graphics card,
and stuff like Xgl has just improved things even more recently.
X has good multihead support - another nice feature.
Graphics drivers for X run (usually/mostly) in userspace - nice, then
they don't destabilize the kernel.
And there's lots of other features as well.

Do you really want to put all that complexity into the kernel?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: replacing X Window System !

[linux cbon]

 --- Jesper Juhl <jesper.juhl@gmail.com> a écrit : 
> And when the windowing system crashes it'll take the
> kernel down with it - ouch.

It is already happening today with X, because :
X runs as root - ouch.
X can write into kernel memory - ouch.
X can mess with clocks - ouch.
X can mess with PCI bus - ouch.
etc.  - ouch.


> And if I want to run a headless server without a
> graphical display I
> can't simply stop the windowing system I'd have to
> rebuild a kernel
> without the windowing system in it - yuck.

Is it so difficult to disable a module ? - yuck.


> What we have now is a nicely decoupled system - it
> would be even
> better if X was even more decoupled from the kernel,
> but lets not put
> the windowing system in kernel space.

We dont need 2 kernels like today.
All "dangerous code" should be in kernel.


> Do you really want to put all that complexity into
> the kernel?

Kernel is already complex, that wouldnt affect it.
But that would greatly simplify the whole system.







	
	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 €/minute ! 
Téléchargez sur http://fr.messenger.yahoo.com

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3556 bytes --]

On Wed, 17 May 2006 16:53:35 +0200, linux cbon said:

> It is already happening today with X, because :
> X runs as root - ouch.
> X can write into kernel memory - ouch.
> X can mess with clocks - ouch.
> X can mess with PCI bus - ouch.

You're confusing "X" with "One misdesigned implementation of X".  If
you actually checked the list archives, you'll see that there are steps
underway to drastically reduce the amount of stuff that X does...

> We dont need 2 kernels like today.
> All "dangerous code" should be in kernel.

Erm. No.  Dangerous code should remain out in userspace where it can't
cause as much damage.

> > Do you really want to put all that complexity into
> > the kernel?
> 
> Kernel is already complex, that wouldnt affect it.

% size /usr/src/linux-2.6.17-rc4-mm1/vmlinux /lib/modules/2.6.17-rc4-mm1/kernel/drivers/video/nvidia.ko
   text    data     bss     dec     hex filename
3681149  893719  316992 4891860  4aa4d4 /usr/src/linux-2.6.17-rc4-mm1/vmlinux
2910736 1299276   10388 4220400  4065f0 /lib/modules/2.6.17-rc4-mm1/kernel/drivers/video/nvidia.ko

Wow, that one module is 75% of the size of my kernel...

OK.. Maybe I run a lot of modules?

% lsmod | grep -v nvidia | wc
     43     143    1793
% lsmod | grep -v nvidia | awk '{sum +=$2} END {print sum}'
627006

Nope, only another 600K or so. Puts us up to 4.2M or so kernel, plus 3M of nvidia..

But wait, there's more.  Let's look at the X server and all its shared libs.

# size `lsof -p 2087 | egrep 'mem.*REG' | awk '{print $9}'`
   text    data     bss     dec     hex filename
  32711     448     480   33639    8367 /lib/libnss_files-2.4.90.so
  28347     668       8   29023    715f /usr/lib/xorg/modules/libramdac.so
 242306    2396      44  244746   3bc0a /usr/lib/xorg/modules/libfb.so
 130662    1848     332  132842   206ea /usr/lib/xorg/modules/extensions/libextmod.so
   1087     160      32    1279     4ff /usr/lib/tls/libnvidia-tls.so.1.0.8756
7983042  127036   17376 8127454  7c03de /usr/lib/libGLcore.so.1.0.8756
   9457    1524      60   11041    2b21 /usr/lib/xorg/modules/input/kbd_drv.so
  38096    3352      16   41464    a1f8 /usr/lib/xorg/modules/input/mouse_drv.so
 578630   73544    3968  656142   a030e /usr/lib/xorg/modules/extensions/libglx.so.1.0.8756
 219189   89192       4  308385   4b4a1 /usr/lib/xorg/modules/libpcidata.so
 434782   11352       4  446138   6ceba /usr/lib/libfreetype.so.6.3.8
1230342   10368   11312 1252022  131ab6 /lib/libc-2.4.90.so
  43260     420     292   43972    abc4 /lib/libgcc_s-4.1.0-20060512.so.1
 141605     336      64  142005   22ab5 /lib/libm-2.4.90.so
  71955     704       4   72663   11bd7 /usr/lib/libz.so.1.2.3
  17096     368       4   17468    443c /usr/lib/libXdmcp.so.6.0.0
  16794    3776    1248   21818    553a /usr/lib/libfontenc.so.1.0.0
   6550     368      12    6930    1b12 /usr/lib/libXau.so.6.0.0
 439854   25036   47916  512806   7d326 /usr/lib/libXfont.so.1.4.1
   6814     400      48    7262    1c5e /lib/libdl-2.4.90.so
 154483    2376    1088  157947   268fb /usr/lib/liblbxutil.so.1.0.0
  27966     608    1064   29638    73c6 /usr/lib/xorg/modules/linux/libdrm.so
  28409     908      36   29353    72a9 /usr/lib/xorg/modules/extensions/libdri.so
   1541     396       4    1941     795 /usr/lib/xorg/modules/fonts/libbitmap.so
  99149    2392     192  101733   18d65 /lib/ld-2.4.90.so

Totalling it up: 
11984127 359976   85608 12429711

Yowza.  124 *meg*.

> But that would greatly simplify the whole system.

Yeah, adding 124 meg to a 4.2M kernel will simplify it...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

On Wed, 17 May 2006 11:09:38 EDT, Valdis.Kletnieks@vt.edu said:

> Totalling it up: 
> 11984127 359976   85608 12429711
> 
> Yowza.  124 *meg*.

12.4 (slipped a decimal pint). But still.

> > But that would greatly simplify the whole system.

> Yeah, adding 124 meg to a 4.2M kernel will simplify it...

Still quadruples the size and even worse on complexity...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[linux-os (Dick Johnson)]

On Wed, 17 May 2006 Valdis.Kletnieks@vt.edu wrote:

> On Wed, 17 May 2006 11:09:38 EDT, Valdis.Kletnieks@vt.edu said:
>
>> Totalling it up:
>> 11984127 359976   85608 12429711
>>
>> Yowza.  124 *meg*.
>
> 12.4 (slipped a decimal pint). But still.
>
>>> But that would greatly simplify the whole system.
>
>> Yeah, adding 124 meg to a 4.2M kernel will simplify it...
>
> Still quadruples the size and even worse on complexity...
>


The X window system was an excellent design
that just isn't used properly if you really
need a high security environment. All you
need is a "display machine" that runs X.
The high-security machine doesn't run X,
it just runs the X-Window programs after
setting the proper DISPLAY environment string.
The I/O for these programs will run over
the network to your display machine. The
network can be a dedicated wire from dedicated
controllers if you are all freaked out about
security.

The combination of a display machine with
nothing important on it, plus the connected
high-security machine makes for a no-compromise
situation, but certainly more expensive than
running a single machine.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.AbominableFirebug.com/ http://www.LymanSchool.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On Wed, 17 May 2006 11:30:46 EDT, "linux-os (Dick Johnson)" said:

> The X window system was an excellent design
> that just isn't used properly if you really
> need a high security environment. All you
> need is a "display machine" that runs X.

But now your "display machine" is inside the security perimeter,
and as such, has to be treated as high security as well.

Otherwise, you're basically doing the equivalent of granting
insufficiently authenticated VPN access into the high security
part of the net.

A more deployable answer is for the X server to compartmentalize the clients,
be aware of their security classifications, and mediate interactions (for
instance, if a "cut" is done in a high-security window, only allow it to
be "paste" into other high-security windows).  The X Security Extension
was one effort to start doing this, and more recently, there have been
patches to allow SELinux mediation of the interactions.

Of course, there will still be those applications where the user ends
up with 2 computers, monitors, keyboards, and mice on their desk,
each connected to a different level network.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[linux cbon]

 --- Valdis.Kletnieks@vt.edu a écrit : 
> On Wed, 17 May 2006 11:09:38 EDT,
> Valdis.Kletnieks@vt.edu said:
> 
> > > But that would greatly simplify the whole
> system.
> 
> > Yeah, adding 124 meg to a 4.2M kernel will
> simplify it...
> 
> Still quadruples the size and even worse on
> complexity...


Are all those 124 meg *really* usefull ?
Thats why it should be rewritten from scratch or
better, redesigned...







	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Randy.Dunlap]

On Wed, 17 May 2006 17:53:25 +0200 (CEST) linux cbon wrote:

>  --- Valdis.Kletnieks@vt.edu a écrit : 
> > On Wed, 17 May 2006 11:09:38 EDT,
> > Valdis.Kletnieks@vt.edu said:
> > 
> > > > But that would greatly simplify the whole
> > system.
> > 
> > > Yeah, adding 124 meg to a 4.2M kernel will
> > simplify it...
> > 
> > Still quadruples the size and even worse on
> > complexity...
> 
> 
> Are all those 124 meg *really* usefull ?
> Thats why it should be rewritten from scratch or
> better, redesigned...

so you should get started soon.

---
~Randy

Re: replacing X Window System !

[Stas Myasnikov]

Hi,

>>>> But that would greatly simplify the whole
>> system.
>>
>>> Yeah, adding 124 meg to a 4.2M kernel will
>> simplify it...
>>
>> Still quadruples the size and even worse on
>> complexity...
> 
> 
> Are all those 124 meg *really* usefull ?
> Thats why it should be rewritten from scratch or
> better, redesigned...

So, do it :-)

Stas

Re: replacing X Window System !

[Alan Cox]

On Mer, 2006-05-17 at 16:53 +0200, linux cbon wrote:
> We dont need 2 kernels like today.
> All "dangerous code" should be in kernel.

The kernel is even more privileged than the X server so putting
dangerous code there is counterproductive. Security comes about through
intelligent design decisions, compartmentalisation, isolation of
security critical code segments and the like. If you merely put shit in
a different bucket you still have a bad smell.

Alan

Re: replacing X Window System !

[linux cbon]

 --- Alan Cox <alan@lxorguk.ukuu.org.uk> a écrit : 
> On Mer, 2006-05-17 at 16:53 +0200, linux cbon wrote:
> > We dont need 2 kernels like today.
> > All "dangerous code" should be in kernel.
> 
> The kernel is even more privileged than the X server
> so putting
> dangerous code there is counterproductive. Security
> comes about through
> intelligent design decisions, compartmentalisation,
> isolation of
> security critical code segments and the like. If you
> merely put shit in
> a different bucket you still have a bad smell.


With "dangerous code" I meant : code which *could be
potentially dangerous* like accessing directly the
hardware etc.
That code should be only in the kernel.











	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Stas Myasnikov]

Hi,

>>> We dont need 2 kernels like today.
>>> All "dangerous code" should be in kernel.
>> The kernel is even more privileged than the X server
>> so putting
>> dangerous code there is counterproductive. Security
>> comes about through
>> intelligent design decisions, compartmentalisation,
>> isolation of
>> security critical code segments and the like. If you
>> merely put shit in
>> a different bucket you still have a bad smell.
> With "dangerous code" I meant : code which *could be
> potentially dangerous* like accessing directly the
> hardware etc.
> That code should be only in the kernel.

It's your opinion only.

Stas

Re: replacing X Window System !

[Gábor Lénárt]

On Wed, May 17, 2006 at 04:53:35PM +0200, linux cbon wrote:
>  --- Jesper Juhl <jesper.juhl@gmail.com> a écrit : 
> > And when the windowing system crashes it'll take the
> > kernel down with it - ouch.
> 
> It is already happening today with X, because :
> X runs as root - ouch.
> X can write into kernel memory - ouch.
> X can mess with clocks - ouch.
> X can mess with PCI bus - ouch.

What? Check out Xnest or Xephyr, they won't mess up anything :) Sure you
will note here that they require another X server running on, but my point
is that you SHOULD NOT confuse X in whole with an x _implementation_ like
Xorg of XFree86 and even the OS counts they runs on. Sure, you can write an
X server (or port/modify eg Xorg) which does not require root privs, and
others. So you don't want to create a new windowing system if the only
problem you have is about the implementation done by Xorg and/or Linux
kernel, etc etc ...

-- 
- Gábor

Re: replacing X Window System !

[Felipe Alfaro Solana]

> > My idea is that the kernel should include universal
> > graphical support.
> > And then we would NOT need ANY window system AT ALL.
> > We wouldnt have 2 os (kernel and X) at the same time
> > like now.
> > It would be faster, simpler, easier to manage etc.
> >
> And when the windowing system crashes it'll take the kernel down with it - ouch.
>
> And if I want to run a headless server without a graphical display I
> can't simply stop the windowing system I'd have to rebuild a kernel
> without the windowing system in it - yuck.

Ey! That's very familiar to me and it's called Windows.

Re: replacing X Window System !

[grundig]

El Wed, 17 May 2006 19:17:12 +0200,
"Felipe Alfaro Solana" <felipe.alfaro@gmail.com> escribió:

> > And when the windowing system crashes it'll take the kernel down with it - ouch.
> >
> > And if I want to run a headless server without a graphical display I
> > can't simply stop the windowing system I'd have to rebuild a kernel
> > without the windowing system in it - yuck.
> 
> Ey! That's very familiar to me and it's called Windows.

Windows XP and 2003 support headless mode. I don't think it's particulary
difficult to do it, just implement a /dev/null graphics driver.


Oh BTW, Windows is getting their graphics subsystem out of the kernel
(except the drivers of course) in Vista. The perfect time for people
to start useless rants on whether Linux should include a graphic subsystem
in the kernel. 

Re: replacing X Window System !

[Lennart Sorensen]

On Wed, May 17, 2006 at 07:33:57PM +0200, grundig wrote:
> Windows XP and 2003 support headless mode. I don't think it's particulary
> difficult to do it, just implement a /dev/null graphics driver.
> 
> Oh BTW, Windows is getting their graphics subsystem out of the kernel
> (except the drivers of course) in Vista. The perfect time for people
> to start useless rants on whether Linux should include a graphic subsystem
> in the kernel. 

Wasn't it back in NT4 they moved it into kernel space to speed things
up? :)

Len Sorensen

Re: replacing X Window System !

[grundig]

El Thu, 18 May 2006 11:42:15 -0400,
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) escribió:

> Wasn't it back in NT4 they moved it into kernel space to speed things
> up? :)

I suspect that moving everything back to userspace is not something that
they do because it's "The Right Thing", but because they need it. The
graphic subsystems that are people is starting to finish and that will
be used in the next years need to allow a huge amount of "personalization"
done by toolkits. XP already has some problems - you can only use "signed"
themes, themes probably have to be uploaded in the kernel and it's a
requeriment.


I wouldn't say that putting the graphic subsystem to speed things up was
an error - it had good sides. It _really_ speed up things, and it wasn't
that unstable - look at how high uptimes you can get with win2k/xp. In
Linux we also have a TCP/IP stack, filesystem, VT100 emulation...

It's certainly an error to do that today, but at that time it wasn't the
end of the world.

Re: replacing X Window System !

[Helge Hafting]

linux cbon wrote:

> --- Valdis.Kletnieks@vt.edu a écrit : 
>  
>
>>On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:
>>
>>If it isn't backward compatible, people won't use
>>it.  X may suck,
>>but it doesn't suck hard enough that people will
>>abandon all their
>>currently mostly-working software.
>>    
>>
>
>If we have a new window system, shall all applications
>be rewritten ?
>  
>
All graphical applications - sure.

>My idea is that the kernel should include universal
>graphical support.
>  
>
You contradict yourself here.  You complained that
X runs too many things as root, and is therefore unsafe.

Now you want to move graphichs into the kernel???

Don't you know that the kernel is even more privileged than
root, so anything running in the kernel is way more
dangerous than a program running as the root user?


Also note that windows runs its graphics in the kernel,
and have exactly this problem. An error in the windows
graphichs system can therefore crash the machine.

X has a harder time crashing the machine because it
is not in the kernel, but of course the root privilege
is still somewhat dangerous as you mentioned.

The real security fix would be to run X as a non-root
user, except for a hw acceleration library that
should be in a kernel driver.  This can be done without
changing the apps too - wether it is doable without
performance loss is another issue.

>And then we would NOT need ANY window system AT ALL.
>We wouldnt have 2 os (kernel and X) at the same time
>like now.
>It would be faster, simpler, easier to manage etc.
>
Your solution does not mean "no window system at all"
You still got one, except now it is in the kernel and
therefore more dangerous.  We do not have 2 os now,
because X is _not_ an os.  Please look up what an os _is_,
and you'll see that. 

Also, please tell why this would be faster, simpler, or
easier to manage.  Stuff in the kernel is generally
harder to manage than userspace stuff, and definitely
not simpler.  Kernel code lives with all sorts of requirements
and limitations that an application programmer would hate
to have to worry about. 

Helge Hafting

Re: replacing X Window System !

[linux cbon]

 --- Helge Hafting <helge.hafting@aitel.hist.no> a
écrit : 

> All graphical applications - sure.

As already discussed here, not all graphical
applications should be rewritten, but only some
layers.
And none, if we can emulate X.


> Now you want to move graphichs into the kernel???

Unix was NOT designed for graphics.
Linux is supposed to be *modern*.

The kernel already drives the files system, the
network, the cdrom, the cpu, etc. Why not the graphics
?

Why dont we have "good" 3D support in X ?


> Your solution does not mean "no window system at
> all"
> You still got one, except now it is in the kernel
> and
> therefore more dangerous.  We do not have 2 os now,
> because X is _not_ an os.  Please look up what an os
> _is_,
> and you'll see that. 

I trust the linux kernel to command my hardware
correctly, so why not the graphical too ?


> Also, please tell why this would be faster, simpler,
> or
> easier to manage.  Stuff in the kernel is generally
> harder to manage than userspace stuff, and
> definitely
> not simpler.  Kernel code lives with all sorts of
> requirements
> and limitations that an application programmer would
> hate
> to have to worry about. 

Put X in the kernel, so we dont have 7924 bad written
incompatible implementations of it.
Even much better : put a replacement for X (and an X
emulation for old softwares), so we can have
simplicity, speed, 3D etc.

In my opinion, graphics do belong to the OS, like
sound, network and file system.


X implementations problems :
http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
http://www.std.org/~msm/common/protocol.pdf
http://archives.neohapsis.com/archives/openbsd/2006-03/0987.html
http://cbbrowne.com/info/xbloat.html


How to improve/replace X :
http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/
http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf


What is your opinion ? 


Thanks











	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

On Thu, 18 May 2006 19:28:27 +0200, linux cbon said:

> Why dont we have "good" 3D support in X ?

Because people are too busy actually using total crap like OpenGL
to put any time into "good" 3D support.

Either that, or maybe there *is* already good 3D support, but you're
just so unfamiliar with X that you don't know what you're talking about.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[Thierry Vignaud]

linux cbon <linuxcbon@yahoo.fr> writes:

> Why dont we have "good" 3D support in X ?

no documentation how to program nvidia 3d chips?
or for the very latest ati chips?
or from the XYZ vendor?
....

> > Also, please tell why this would be faster, simpler, or easier to
> > manage.  Stuff in the kernel is generally harder to manage than
> > userspace stuff, and definitely not simpler.  Kernel code lives
> > with all sorts of requirements and limitations that an application
> > programmer would hate to have to worry about.
> 
> Put X in the kernel, so we dont have 7924 bad written
> incompatible implementations of it.

no, we now have 7924 kernels that have to implement each of these
drivers (linux, *bsd, other unices, macos x, ...)
ow! how do we do with macos x? or on windows?
no more X? (though i don't really care but...)

> In my opinion, graphics do belong to the OS, like
> sound, network and file system.

"belong to the OS" != "belong in the kernel"
and where do you put the boundary of the OS? most people don't say
that the OS is only the kernel...

> 
> How to improve/replace X :
> http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/
> http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf

like if xorg wasn't trying to improve x11 status (slowly trying to
isolate priviliged stuff, introducing xcb, ...)

> What is your opinion ? 

stop troll^h^h^h^h^h thread?

Re: replacing X Window System !

[linux cbon]

 --- Thierry Vignaud <tvignaud@mandriva.com> a écrit :

> linux cbon <linuxcbon@yahoo.fr> writes:
> 
> > Why dont we have "good" 3D support in X ?
> 
> no documentation how to program nvidia 3d chips?
> or for the very latest ati chips?
> or from the XYZ vendor?
> ....


What do you think about this :

http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893&w=2

But let me be clear -- the X developers are a bunch of
shameless vendor-loving lapdogs who sure are taking
their time at solving this > 10 year old problem! 
They spend way more time chasing the latest vendor
binary loaded device driver, than they do solving this
obvious
problem.  (Translation: They don't want to change how
X works, because it would break the vendor binary
drivers from ATI and NVIDIA.  That is part of what
happens when X developers get jobs at vendors).

They've had 10 years, and yet every year they get more
entrenched in the entirely insecure model of "gigantic
process running as root, which accesses registers like
mad".

This problem is ENTIRELY the X group's fault!  They
have failed us. Ten years ago they were laughing at
Microsoft for moving their video subsystem into their
kernel, but now the joke is on the X developers,
because what Microsoft did solved all these driver
security problems!

This is 100% an X server bug.  It is not a hardware
bug, and it is not an operating system bug.


and this

http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317926101&w=2

Some of our architectures use a tricky and horrid
thing to allow X to run.  This is due to modern PC
video card architecture containing a large quantity of
PURE EVIL.  To get around this evil the X developers
have done some rather expedient things, such as
directly accessing the cards via IO registers,
directly from userland.  It is hard to see how they
could have done other -- that is how much evil the
cards contain.


> "belong to the OS" != "belong in the kernel"
> and where do you put the boundary of the OS? most
> people don't say
> that the OS is only the kernel...

Dont play with words. You know I meant graphics do
belong to the kernel. I didnt mean graphics belong to
gnu tools.


> like if xorg wasn't trying to improve x11 status
> (slowly trying to
> isolate priviliged stuff, introducing xcb, ...)

See above.


> > What is your opinion ? 
> 
> stop troll^h^h^h^h^h thread?

If I am a troll, then who are Theo or Linus ?




Thanks


	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[David Lang]

On Thu, 18 May 2006, linux cbon wrote:

when you don't even recognise that there is no ONE 'X group' it makes it 
impossible to take the rest of you accusations about what that group does 
seriously.

Nowdays there are two free implementations of X, the xfree group and the 
xorg group. In addition there are (or were as recently as a couple years 
ago) multiple commercial companies who write and sell X server software.

if you are leveling accusations about what a group does or doesn't care 
about you need to at lease devine who you are accusing, anything less _is_ 
just a troll

David Lang


-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: replacing X Window System !

[Gerhard Mack]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4202 bytes --]


You have also just made it easy for the rest of us to tell that you don't 
actually follow linux GUI stuff very much at all.  If you had you would 
have known that the X folks finally went too far and forced a long needed 
fork of the X code so the real work is being done on X.org 
now and these days most of the good linux distros have changed over.  

This is *not* a recent event.

Welcome to my killfile, please find a less annoying hobby for yourself.

	Gerhard




On Thu, 18 May 2006, linux cbon wrote:

> Date: Thu, 18 May 2006 21:31:08 +0200 (CEST)
> From: linux cbon <linuxcbon@yahoo.fr>
> To: Thierry Vignaud <tvignaud@mandriva.com>
> Cc: helge.hafting@aitel.hist.no, Valdis.Kletnieks@vt.edu,
>     linux-kernel@vger.kernel.org
> Subject: Re: replacing X Window System !
> 
>  --- Thierry Vignaud <tvignaud@mandriva.com> a écrit :
> 
> > linux cbon <linuxcbon@yahoo.fr> writes:
> > 
> > > Why dont we have "good" 3D support in X ?
> > 
> > no documentation how to program nvidia 3d chips?
> > or for the very latest ati chips?
> > or from the XYZ vendor?
> > ....
> 
> 
> What do you think about this :
> 
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893&w=2
> 
> But let me be clear -- the X developers are a bunch of
> shameless vendor-loving lapdogs who sure are taking
> their time at solving this > 10 year old problem! 
> They spend way more time chasing the latest vendor
> binary loaded device driver, than they do solving this
> obvious
> problem.  (Translation: They don't want to change how
> X works, because it would break the vendor binary
> drivers from ATI and NVIDIA.  That is part of what
> happens when X developers get jobs at vendors).
> 
> They've had 10 years, and yet every year they get more
> entrenched in the entirely insecure model of "gigantic
> process running as root, which accesses registers like
> mad".
> 
> This problem is ENTIRELY the X group's fault!  They
> have failed us. Ten years ago they were laughing at
> Microsoft for moving their video subsystem into their
> kernel, but now the joke is on the X developers,
> because what Microsoft did solved all these driver
> security problems!
> 
> This is 100% an X server bug.  It is not a hardware
> bug, and it is not an operating system bug.
> 
> 
> and this
> 
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317926101&w=2
> 
> Some of our architectures use a tricky and horrid
> thing to allow X to run.  This is due to modern PC
> video card architecture containing a large quantity of
> PURE EVIL.  To get around this evil the X developers
> have done some rather expedient things, such as
> directly accessing the cards via IO registers,
> directly from userland.  It is hard to see how they
> could have done other -- that is how much evil the
> cards contain.
> 
> 
> > "belong to the OS" != "belong in the kernel"
> > and where do you put the boundary of the OS? most
> > people don't say
> > that the OS is only the kernel...
> 
> Dont play with words. You know I meant graphics do
> belong to the kernel. I didnt mean graphics belong to
> gnu tools.
> 
> 
> > like if xorg wasn't trying to improve x11 status
> > (slowly trying to
> > isolate priviliged stuff, introducing xcb, ...)
> 
> See above.
> 
> 
> > > What is your opinion ? 
> > 
> > stop troll^h^h^h^h^h thread?
> 
> If I am a troll, then who are Theo or Linus ?
> 
> 
> 
> 
> Thanks
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
> Rendez-vous sur http://fr.yahoo.com/set
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: replacing X Window System !

[linux cbon]

 --- Gerhard Mack <gmack@innerfire.net> a écrit : 
> 
> You have also just made it easy for the rest of us
> to tell that you don't 
> actually follow linux GUI stuff very much at all. 
> If you had you would 
> have known that the X folks finally went too far and
> forced a long needed 
> fork of the X code so the real work is being done on
> X.org 
> now and these days most of the good linux distros
> have changed over.  
> 
> This is *not* a recent event.
> 
> Welcome to my killfile, please find a less annoying
> hobby for yourself.
> 
> 	Gerhard


Yes X.org has replaced Xfree86 because of licence and
internal disputes.

But in the links I sent, Theo's comments dates back to
Mars and May 2006. That's recent.

When he criticizes X, he criticizes especially Xfree86
or X.org implementations.












	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Martin Mares]

Hello!

> But in the links I sent, Theo's comments dates back to
> Mars and May 2006. That's recent.
> 
> When he criticizes X, he criticizes especially Xfree86
> or X.org implementations.

Then the kernel tree is a wrong tree to bark at, isn't it?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Only dead fish swim with the stream.

Re: replacing X Window System !

[Adrian Bunk]

On Thu, May 18, 2006 at 09:31:08PM +0200, linux cbon wrote:
> 
> What do you think about this :
> 
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893&w=2
>...
> and this
> 
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317926101&w=2
>...

If you want to hear negative things about X11 or Linux, you might find 
quotes from Theo.

If you want to hear negative things about BSD, you might find quotes 
from Linus.

> If I am a troll, then who are Theo or Linus ?

Theo and Linus are people who sometimes have controversal views, but who 
also have significantely contributed to open source software.

That's the difference between them and you.

It seems you are a troll.
If you want to prove me wrong, simply send an implementation of your 
ideas and there will be a basis for a technical discussion.

> Thanks

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Thu, 18 May 2006 21:31:08 +0200, linux cbon said:
> What do you think about this :

> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893&w=2
> and this
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317926101&w=2

I think it adequately demonstrates that you're unable to distinguish
between problems that *a specific implementation of X* has, and problems
that *the X system as a design* has.  If one particular X server has
a misfeature, the correct fix is to fix the server software.

And in particular, it's *not* even an X problem, as you'd know if you bothered
actually *reading* what you quoted:

"It is hard to see how they could have done other -- that is how much evil the
cards contain."

So if you want to fix the *problem*, go learn enough about graphics to
actually help design an open, non-evil chipset.  That's the *real* problem,
not whatever fantasized shortcomings of X itself you're trolling about.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[linux cbon]

 --- Valdis.Kletnieks@vt.edu a écrit : 
> I think it adequately demonstrates that you're
> unable to distinguish
> between problems that *a specific implementation of
> X* has, and problems
> that *the X system as a design* has.  If one
> particular X server has
> a misfeature, the correct fix is to fix the server
> software.

Didnt I already write about all this before ?
We should fix X.org (root, hardware access) problems.
But fixing only X.org is not enough.

X implementations problems :
http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
http://www.std.org/~msm/common/protocol.pdf
http://archives.neohapsis.com/archives/openbsd/2006-03/0987.html
http://cbbrowne.com/info/xbloat.html


> So if you want to fix the *problem*, go learn enough
> about graphics to
> actually help design an open, non-evil chipset. 
> That's the *real* problem,
> not whatever fantasized shortcomings of X itself
> you're trolling about.

One example : Tech Source company is trying to do an
open-source graphic cards.
http://lists.duskglow.com/mailman/listinfo/open-graphics

I would be happy that Nvidia or ATI open their
drivers.


Regards






	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Al Viro]

> Didnt I already write about all this before ?
> We should fix X.org (root, hardware access) problems.
> But fixing only X.org is not enough.
> 
> X implementations problems :
> http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
> http://www.std.org/~msm/common/protocol.pdf
> http://archives.neohapsis.com/archives/openbsd/2006-03/0987.html
> http://cbbrowne.com/info/xbloat.html

<yawn>

	You do realize that this is not splashsnot, don't you?  Since you
appear to be so fond of references, go and google for Kipling+Tomlinson...

Re: replacing X Window System !

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

Hi.

> because what Microsoft did solved all these driver
> security problems!

Then why are MS moving it out of the kernel with Vista?

>>stop troll^h^h^h^h^h thread?
> 
> 
> If I am a troll, then who are Theo or Linus ?

They're the guys that put their code where their
mouth is instead of discussing stuff they have no
clue about.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: replacing X Window System !

[Helge Hafting]

linux cbon wrote:

> --- Helge Hafting <helge.hafting@aitel.hist.no> a
>écrit : 
>
>  
>
>>All graphical applications - sure.
>>    
>>
>
>As already discussed here, not all graphical
>applications should be rewritten, but only some
>layers.
>And none, if we can emulate X.
>  
>
Well, sure.  You have some work to do though, all that rewriting of yours.

>
>  
>
>>Now you want to move graphichs into the kernel???
>>    
>>
>
>Unix was NOT designed for graphics.
>Linux is supposed to be *modern*.
>  
>
There is nothing "modern" about graphichs in the kernel.

You did not answer my question - because you couldn't.  You
are trapped in a logic flaw of your own.  A sane person would
admit it - you answer with meaningless talk about "being modern".

1. You dislike X for running stuff as root - that's dangerous.
    The obvious solution then, is to run X (or that rewritten X)
    in a less dangerous fashion - the only choice then is
    to run as a non-root user.

2. You want to run the graphichs in the kernel. But that is stupid,
    because it is even more dangerous than running as root.
    So you're trying to "solve" a problem by making it WORSE.
    Pretty dumb, actually.


>The kernel already drives the files system, the
>network, the cdrom, the cpu, etc. Why not the graphics
>?
>  
>
See above!  I also explained that in the previous email.
But since you are slow at getting things,
here it is again:

Kernel graphichs are more dangerous than root graphichs, so
you only make the security flaws worse by moving it into the kernel.

Don't bother arguing for "kernel graphichs" on the grounds that
it is "modern".  First, it isn't modern.  Vendors who use in-kernel
graphichs are moving away from it. The modern (and safe) approach
is graphichs separated from the kernel.  This is one of the many
things that unix got right from the very start.

Second - who cares what is "modern" or "fashionable"???
Nobody, except people buying clothes.  For computer
software, we care about stability and performance.

>Why dont we have "good" 3D support in X ?
>  
>
Wrong question - we have excellent 3D support in X.  It is called opengl,
and is really good!  Sure, it is only available for a handful of cards, 
there
are lots of good 3D cards without linux 3D support.

This problem is trivially solvable by writing drivers for the cards in
question.  A rewrite of X now, will make that process much slower,
as people will be tied up rewriting X instead of writing 3D drivers.

The problem with writing those 3D drivers is not complexity
or "historic baggage" in the X codebase.  It is the fact that
only the vendors know how the cards work, and most of them
won't tell us.

To which the solution is:  buy the cards that work, and screw the rest.
Or raise enough money to purchase specs without NDA.  A rewrite of X,
or stupidly moving graphichs into the kernel won't help with this
_at all_, the specs will still be in the dark. So you'll do all that work,
perhaps improving X a little, perhaps making it more unsafe,
and you still won't have 3D drivers for more than a handful of cards.

>>Your solution does not mean "no window system at
>>all"
>>You still got one, except now it is in the kernel
>>and
>>therefore more dangerous.  We do not have 2 os now,
>>because X is _not_ an os.  Please look up what an os
>>_is_,
>>and you'll see that. 
>>    
>>
>
>I trust the linux kernel to command my hardware
>correctly, so why not the graphical too ?
>  
>
Code does not magically become "correct"  once it gets into
the kernel.  Shifting an X graphichs driver into the kernel
won't improve code quality at all, so nothing to gain there.
If you think a rewrite will get you better code - well maybe,
but then there is no reason to stick it in the kernel.

Stuff doesn't go into the kernel because it is a nifty place to stick it.
Stuff ends up in the kernel when it absolutely have to, and this is
not the case for graphichs.  Well, perhaps a very small part,
such as the direct manipulation of hardware registers could
go in the kernel.  All the rest, i.e. higher level stuff like handling
"images", "windows", "fonts", "3D surfaces" definitely belongs
in userspace where the _inevitable_ bugs in any large piece of
software won't kill the box.

>>Also, please tell why this would be faster, simpler,
>>or
>>easier to manage.  Stuff in the kernel is generally
>>harder to manage than userspace stuff, and
>>definitely
>>not simpler.  Kernel code lives with all sorts of
>>requirements
>>and limitations that an application programmer would
>>hate
>>to have to worry about. 
>>    
>>
>
>Put X in the kernel, so we dont have 7924 bad written
>incompatible implementations of it.
>  
>
We don't have a bunch of incompatible implementations of X.
We have a single version, the newest version of x.org.
Of course there exist many older
versions (including xfree86).  Surely you can't complain
that older versions exist - that is the case for any software, including
the linux kernel.

There aren't many other X implementations for linux, certainly
none of importance.  You're mistaken here.

>Even much better : put a replacement for X (and an X
>emulation for old softwares), so we can have
>simplicity, speed, 3D etc.
>  
>
I repeat - putting software in the kernel does not magically
make it faster, simpler, or easier to manage.  It won't even
stamp out any "incompatible implementations".
There is, for example, an userspace nfs server even though
we have had kernel nfs for a long time now.

>In my opinion, graphics do belong to the OS, like
>sound, network and file system.
>  
>
That's your opinion.  As for graphichs, it is your opinion _alone_,
because it is not founded on reason.  You have failed to
provide even one example of why it'd be useful,
all your arguments either comes down to meaningless
busswords like "modern" or "your own opinion."
That won't _ever_ work here, and if you can't do better, quit!

Or show us all that you are right by rewriting a kernel X yourself.

Too much work or not interested? Neither are we!  You see, anyone
cabable of undertaking this sort of work is also capable of
visionary planning, so we _don't need you_ to provide _ideas_.

Helge Hafting

Re: replacing X Window System !

[Panagiotis Issaris]

Hi,

Helge Hafting wrote:

> [...]
> The problem with writing those 3D drivers is not complexity
> or "historic baggage" in the X codebase.  It is the fact that
> only the vendors know how the cards work, and most of them
> won't tell us.
>
> To which the solution is:  buy the cards that work, and screw the rest. 

Just out of curiosity: Do you know any currently sold cards that support
XVideo, OpenGL and for which open source drivers are available?

With friendly regards,
Takis

Re: replacing X Window System !

[Helge Hafting]

Panagiotis Issaris wrote:

> Hi,
>
> Helge Hafting wrote:
>
>> [...]
>> The problem with writing those 3D drivers is not complexity
>> or "historic baggage" in the X codebase.  It is the fact that
>> only the vendors know how the cards work, and most of them
>> won't tell us.
>>
>> To which the solution is:  buy the cards that work, and screw the rest. 
>
>
> Just out of curiosity: Do you know any currently sold cards that support
> XVideo, OpenGL and for which open source drivers are available?

I don't know much about XVideo.
For DRI support, look at:
http://dri.freedesktop.org/wiki/Status?action=highlight&value=CategoryHardware

Many of the cards listed there are a few years old, but several of them
are still available as cheap alternatives in shops.  I had no problem buying
a radeon 9200 and a matrox G550 for example.

Also, the VIA graphichs chips found on current mini-itx motherboards
have both opengl and mpeg2-acceleration.  A mini-itx thing is hardly what
you use as a power desktop machine, but the small size and fanless operation
means they're popular for homemade media player/entertainment boxes.

I got one in my car; mostly for playing CDs and gps navigation. But
it will also play DVDs, play tuxracer using opengl, as well as
the usual web surfing and word processing.

Helge Hafting

Re: replacing X Window System !

[David Greaves]

Panagiotis Issaris wrote:
> Hi,
>
> Helge Hafting wrote:
>
>> [...]
>> The problem with writing those 3D drivers is not complexity
>> or "historic baggage" in the X codebase.  It is the fact that
>> only the vendors know how the cards work, and most of them
>> won't tell us.
>>
>> To which the solution is:  buy the cards that work, and screw the rest. 
>
> Just out of curiosity: Do you know any currently sold cards that support
> XVideo, OpenGL and for which open source drivers are available?
>
> With friendly regards,
> Takis
Almost all ATI cards :)

What you mean is 'that use hardware acceleration to achieve useful
results' (like playing NeverWinter Nights or watching MythTV).

I think the ATI Radeon 9250 is the best graphics card still available
that has an open source driver (X.org radeon r250/r280 driver). This
works nicely with the 2.6.16 kernels. The 9250 isn't actually mentioned
in Google results very much and it seems to be more widely available
than the slightly older 9200.

I recently bought 2 for exactly this reason.

Then one failed and the supplier kindly sent me an upgraded version, a
9600 IIRC - but the r300 driver isn't out yet - in X.org 7 maybe - and
it seems incomplete anyway - so I had to send it back and ask for a
'downgrade' which confused them.

HTH

David

PS My wife removed her shiny new (expensive) ATI 9800 card and replaced
it with a 9250 and although the performance dropped she found that
having a driver that let her machine run accelerated graphics for over 5
minutes at a time was a serious benefit. The open source driver was
simply *much* more stable.
Anyone want a spare ATI 9800 :)
(just kidding - I'll test the r300 driver as soon as I get the chance!)

-- 

Re: replacing X Window System !

[Xavier Bestel]

On Fri, 2006-05-19 at 16:34, David Greaves wrote:
> Panagiotis Issaris wrote:
> > Hi,
> >
> > Helge Hafting wrote:
> >
> >> [...]
> >> The problem with writing those 3D drivers is not complexity
> >> or "historic baggage" in the X codebase.  It is the fact that
> >> only the vendors know how the cards work, and most of them
> >> won't tell us.
> >>
> >> To which the solution is:  buy the cards that work, and screw the rest. 
> >
> > Just out of curiosity: Do you know any currently sold cards that support
> > XVideo, OpenGL and for which open source drivers are available?
> >
> > With friendly regards,
> > Takis
> Almost all ATI cards :)

BEWARE !! None of the "Avivo" series (ATI X1000 and later) will work.
Only the readon (Radeon 7xxx, Radeon 8xxx, Radeon 9xxx, X600, X700,
X800) have drivers.

See DRI homepage for more information.

	Xav

Re: replacing X Window System !

[linux cbon]

 --- Xavier Bestel <xavier.bestel@free.fr> a écrit : 
> BEWARE !! None of the "Avivo" series (ATI X1000 and
> later) will work.
> Only the readon (Radeon 7xxx, Radeon 8xxx, Radeon
> 9xxx, X600, X700,
> X800) have drivers.
> 
> See DRI homepage for more information.
> 
> 	Xav


Hi,

does DRI access hardware *directly* ?
How does DRI compare with other drivers ?

Thanks







	
	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 €/minute !
Téléchargez sur http://fr.messenger.yahoo.com

Re: replacing X Window System !

[Xavier Bestel]

On Fri, 2006-05-19 at 17:13, linux cbon wrote:
>  --- Xavier Bestel <xavier.bestel@free.fr> a écrit : 
> > BEWARE !! None of the "Avivo" series (ATI X1000 and
> > later) will work.
> > Only the readon (Radeon 7xxx, Radeon 8xxx, Radeon
> > 9xxx, X600, X700,
> > X800) have drivers.
> > 
> > See DRI homepage for more information.
> > 
> > 	Xav
> 
> 
> Hi,
> 
> does DRI access hardware *directly* ?

Yes it does.

> How does DRI compare with other drivers ?

DRI is not finished for r300 cards (radeon 9600 => X700 IIRC), but it
kind of works. The only other driver I know for r300 is Xorg's radeon,
and it's dead slow.

	Xav

Re: replacing X Window System !

[linux cbon]

 --- Xavier Bestel <xavier.bestel@free.fr> a écrit : 
> On Fri, 2006-05-19 at 17:13, linux cbon wrote:
> > Hi,
> > 
> > does DRI access hardware *directly* ?
> 
> Yes it does.
> 
> > How does DRI compare with other drivers ?
> 
> DRI is not finished for r300 cards (radeon 9600 =>
> X700 IIRC), but it
> kind of works. The only other driver I know for r300
> is Xorg's radeon,
> and it's dead slow.
> 
> 	Xav


Are "DRIs" the best available open-source drivers for
old ATI cards ? Done by reverse engineering ?
And not all functions are usable :-(.
What about newer ATI or Nvidia cards ? A hope for
something better ?

What do you think of using binary drivers (blobs)
instead ?
I think thats sad to use them, in an open-source
kernel like Linux.

By the way : did you know of this project about an
"open source graphic card" ?
Hardware specs are open, so no need of DNA and
open-source drivers coding easier :
http://opengraphics.gitk.com/open_graphics_spec.pdf
http://lists.duskglow.com/mailman/listinfo/open-graphics
(still a project).


Regards







	
	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 €/minute !
Téléchargez sur http://fr.messenger.yahoo.com

Re: replacing X Window System !

[Peter Gordon]

On 5/19/06, linux cbon <linuxcbon@yahoo.fr> wrote:
> Are "DRIs" the best available open-source drivers for
> old ATI cards ?
Yes.

> Done by reverse engineering ?
Nope. As I understand it, the R200 drivers and earlier are written
from actual specs submitted to the X.org/Mesa/DRI hackers by ATi
(under some NDAs).
The R300/R400 stuff is being reverse-engineered.

> And not all functions are usable :-(.
Most of it is there: hardware video scaling (XVideo), OpenGL hardware
acceleration where available, DDC/I2C support, MergedFB/Xinerama
(multi-head setups), Render acceleration (yay for EXA!) etc. The only
major thing that isn't to my knowledge is the S3TC texture compression
(due to patents?).

> What about newer ATI or Nvidia cards ? A hope for
> something better ?
Intel's published specs and open source drivers for their integrated
video chips (which can do cool things like XvMC, etc.). From speaking
with a couple of X.org hackers, the GMA 900/950 stuff is supposed to
have nearly equivalent performance to a Radeon 9500 or so. (Thanks,
Intel!)

> By the way : did you know of this project about an
> "open source graphic card" ?
> Hardware specs are open, so no need of [NDA] and
> open-source drivers coding easier :
> http://opengraphics.gitk.com/open_graphics_spec.pdf
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> (still a project).
I'm hoping to be able to buy one Real Soon Now(TM). :)

--Peter

Re: replacing X Window System !

[Xavier Bestel]

Le samedi 20 mai 2006 à 00:09 +0200, linux cbon a écrit :
> What about newer ATI or Nvidia cards ? A hope for
> something better ?

No.

> What do you think of using binary drivers (blobs)
> instead ?

Not on my system.

	Xav

Re: replacing X Window System !

[Jeff Carr]

On 05/19/06 08:18, Xavier Bestel wrote:

>>> See DRI homepage for more information.

That page should be wiki'fied as it doesn't seem to be keeping pace with
the improvements in X.

>> How does DRI compare with other drivers ?
> 
> DRI is not finished for r300 cards (radeon 9600 => X700 IIRC), but it
> kind of works.

3D acceleration is working well on my portable's ATI Technologies Inc
RV350 [Mobility Radeon 9600 M10]. ppracer runs well. Lots of
improvements have been made with xorg; a trend I'm sure everyone would
like to see continue.

X Window System Version 7.0.0
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 7.0
Build Operating System:Linux 2.6.12-1-686 i686
Current Operating System: Linux jcarr 2.6.17-rc2-g6b426e78 #3 SMP Mon
Apr 24 15:46:38 PDT 2006 i686
Build Date: 16 March 2006

Re: replacing X Window System !

[Sander]

David Greaves wrote (ao):
> Panagiotis Issaris wrote:
> > Helge Hafting wrote:
> >> To which the solution is:  buy the cards that work, and screw the rest. 
> >
> > Just out of curiosity: Do you know any currently sold cards that support
> > XVideo, OpenGL and for which open source drivers are available?
>
> Almost all ATI cards :)

A few years ago you could say that, but ATI is not OSS friendly anymore.

These days NVidia supports the OSS community much more than ATI does,
while NVidia used to be the dark side. There is still a lot of space for
improvement though :-)

	With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: replacing X Window System !

[Jan Engelhardt]

>
>These days NVidia supports the OSS community much more than ATI does,
>while NVidia used to be the dark side. There is still a lot of space for
>improvement though :-)
>

	RFC 1925
	Good, Fast, Cheap: Pick any two; you can't have all three.

Something similar (opensource, speed, support for newest hardware) goes for 
today's graphics cards.



Jan Engelhardt
-- 

Re: replacing X Window System !

[David Lang]

On Sat, 20 May 2006, Jan Engelhardt wrote:

>> These days NVidia supports the OSS community much more than ATI does,
>> while NVidia used to be the dark side. There is still a lot of space for
>> improvement though :-)
>>
>
> 	RFC 1925
> 	Good, Fast, Cheap: Pick any two; you can't have all three.
>
> Something similar (opensource, speed, support for newest hardware) goes for
> today's graphics cards.

true for nVidia and ATI, not true for many other hardware vendors (most of 
which do not make graphics cards), so this isn't a general trueism like 
RFC 1925, just the current broken state among the current graphics 
leaders.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: replacing X Window System !

[Jan Engelhardt]

>> The kernel already drives the files system, the
>> network, the cdrom, the cpu, etc. Why not the graphics
>> ?
>> 
> See above!  I also explained that in the previous email.
> But since you are slow at getting things,
> here it is again:
>
> Kernel graphichs are more dangerous than root graphichs, so
> you only make the security flaws worse by moving it into the kernel.

What about framebuffer, dri and agpgart? Does that belong to 
"graphics"? Because it's "in" the kernel... (or am I just missing 
something?)


Jan Engelhardt
-- 

Re: replacing X Window System !

[linux cbon]

 --- Helge Hafting <helge.hafting@aitel.hist.no> a
écrit : 

>There is nothing "modern" about graphichs in the
kernel.

It depends on the meaning of graphics :
If it is direct card access, then kernel job.
If it is higher level like window system etc, then it
can be discussed...


>The modern (and safe) approach
>is graphichs separated from the kernel.  This is one
of the many
>things that unix got right from the very start.

Unix was not designed for graphics.


>Second - who cares what is "modern" or
"fashionable"???
>Nobody, except people buying clothes.  For computer
>software, we care about stability and performance.

Is X so stable and performant ?
For instance, X is not precise enough to make
compatible implementations.
X.free and X.org are not compatible.
Some graphic drivers work only with special versions
of X.org.
Gnome and KDE are not compatible.
etc.
Other example : can X follow new graphic progress ?


>but then there is no reason to stick it in the
kernel.

Usual reasons : Reusability, portability, ease of
maintenance, speed, etc.

What do you think of solutions using framebuffers like
directfb or fbui ?
It is in the kernel, the hardw access is direct, it is
fast and stable.

Why X.Org puts so many layers between the hardware and
the screen ? It adds complexity and slowness to the
project.

I think the discussion should move to X.Org ?


Regards












	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Adrian Bunk]

On Sat, May 20, 2006 at 12:40:56AM +0200, linux cbon wrote:
>...
> I think the discussion should move to X.Org ?

The whole discussion is pointless anywhere as long as you are not 
writing the code to implement your proposal.

If you think you could send an idea and other people would implement it 
you are misunderstanding how open source software works.

You have your idea.

It is YOUR job to write the code implementing your proposal.

Then there's a basis for a technical discussion of the advantages and 
disadvantages of your ideas.

Otherwise, you are only wasting your (and our) time since there's 
exactly a 0% probability that someone else will implement your ideas.

> Regards

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: replacing X Window System !

[Willy Tarreau]

Hi Adrian,

On Sat, May 20, 2006 at 03:02:20AM +0200, Adrian Bunk wrote:
> On Sat, May 20, 2006 at 12:40:56AM +0200, linux cbon wrote:
> >...
> > I think the discussion should move to X.Org ?
> 
> The whole discussion is pointless anywhere as long as you are not 
> writing the code to implement your proposal.
> 
> If you think you could send an idea and other people would implement it 
> you are misunderstanding how open source software works.
> 
> You have your idea.
> 
> It is YOUR job to write the code implementing your proposal.
> 
> Then there's a basis for a technical discussion of the advantages and 
> disadvantages of your ideas.
> 
> Otherwise, you are only wasting your (and our) time since there's 
> exactly a 0% probability that someone else will implement your ideas.

I 100% agree with you. However, given the posts I've read from the same
person on some french forums, I can assure you that we'll never see one
line of code, not even any useful advice ! Since he's only wasting our
time, we should stop feeding this troll.


         +-------------------+             .:\:\:/:/:.            
         |                   |            :.:\:\:/:/:.:           
         |   PLEASE DO NOT   |           :=.' -   - '.=:          
         |                   |           '=(\ 9   9 /)='          
         |  FEED THE TROLLS  |              (  (_)  )             
         |                   |              /`-vvv-'\             
         +-------------------+             /         \            
                 |  |        @@@          / /|,,,,,|\ \           
                 |  |        @@@         /_//  /^\  \\_\          
   @x@@x@        |  |         |/         WW(  (   )  )WW          
   \||||/        |  |        \|           __\,,\ /,,/__           
    \||/         |  |         |          (______Y______)          
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==================================================================

> > Regards
> 
> cu
> Adrian

Regards,
Willy

Re: replacing X Window System !

[jerome lacoste]

> >The modern (and safe) approach
> >is graphichs separated from the kernel.  This is one
> of the many
> >things that unix got right from the very start.
>
> Unix was not designed for graphics.

What is this supposed to mean?

http://en.wikipedia.org/wiki/Silicon_Graphics

Jerome

Re: replacing X Window System !

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Sat, 20 May 2006 00:40:56 +0200, linux cbon said:

> Unix was not designed for graphics.

Rather amusing, given that Dennis Ritchie has a different memory of it:

http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

He seems to think that one of the original motivating forces for Unix
was to provide a development environment for a PDP-7, so that they
could support the graphics terminal for a game called 'Space Travel'.

So if anything, Unix was designed specifically *for* graphics.

Now who should I believe here, dmr or an apparent troll?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: replacing X Window System !

[linux cbon]

 --- Valdis.Kletnieks@vt.edu a écrit : 
> On Sat, 20 May 2006 00:40:56 +0200, linux cbon said:
> 
> > Unix was not designed for graphics.
> 
> Rather amusing, given that Dennis Ritchie has a
> different memory of it:
> 
> http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
> 
> He seems to think that one of the original
> motivating forces for Unix
> was to provide a development environment for a
> PDP-7, so that they
> could support the graphics terminal for a game
> called 'Space Travel'.
> 
> So if anything, Unix was designed specifically *for*
> graphics.
> 
> Now who should I believe here, dmr or an apparent
> troll?


hi,

unix only provided the tools to write the game in
assembly.
No graphic system or environment.
Guis were invented in Xerox PARC and not in Unix.

Who wrote "The X server has to be the biggest program
I've ever seen that doesn't do anything for you."

Regards









	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

Re: replacing X Window System !

[Manu Abraham]

linux cbon wrote:
> Usual reasons : Reusability, portability, ease of
> maintenance, speed, etc.
>
> What do you think of solutions using framebuffers like
> directfb or fbui ?
>   



DirectFB is indeed a nice solution, the last i heard of it, many vendors 
were looking at it in a very positive manner, for commercial products. 
As usual, every project can use more hands. :-)



Manu

OpenGL-based framebuffer concepts

[Kyle Moffett]

Tentatively going with the assumption put forth by Jon Smirl in his  
future-of-linux-graphics document and the open-graphics-project group  
that 3d rendering is an absolutely essential part of any next- 
generation graphics system, I'd be interested in ideas on a new or  
modified /dev/fbX device that offers native OpenGL rendering  
support.  Someone once mentioned OpenGL ES as a possibility as it  
provides extensions for multiple-process windowing environments.   
Other requirements would obviously be the ability to allow client  
programs to allocate and share out chunks of graphics memory to other  
clients (later used as textures for compositing), support for  
multiple graphics cards with different hardware renderers over  
different busses, using DMA to transfer data between cards as  
necessary (and user-configurable policy about how to divide use of  
the cards), support for single or multiple framebuffers per GPU, as  
well as an arbitrary number of hardware and software viewports per  
framebuffer.  There would also need to be a way for userspace to trap  
and emulate or ignore unsupported OpenGL commands.  The kernel would  
need some rudimentary understanding of OpenGL to be able to handle  
buggy GPUs and prevent them from hanging the PCI bus (some GPUs can  
do that if sent invalid commands), but you obviously wouldn't want a  
full software renderer in the kernel.  The system should also support  
transmitting OpenGL textures, commands, and other data asynchronously  
over a TCP socket, though doing it locally via mmap would be far more  
efficient.  I'm probably missing other necessary generics, but that  
should provide a good discussion starter.

The necessary kernel support would include a graphics-memory  
allocator, resource management, GPU-time allocation, etc, as well as  
support for an overlaid kernel console.  Ideally an improved graphics  
driver like that would be able to dump panics directly to the screen  
composited on top of whatever graphics are being displayed, so you'd  
get panics even while running X.  If that kind of support was  
available in-kernel, fixing X to not need root would be far simpler,  
plus you could also write replacement X-like tools without half the  
effort.  Given that sort of support, a rootless xserver would be a  
fairly trivial wrapper over whatever underlying implementation there  
was.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 23 May 2006 05:08, Kyle Moffett wrote:
> Tentatively going with the assumption put forth by Jon Smirl in his
> future-of-linux-graphics document and the open-graphics-project group
> that 3d rendering is an absolutely essential part of any next-
> generation graphics system, I'd be interested in ideas on a new or
> modified /dev/fbX device that offers native OpenGL rendering
> support.  Someone once mentioned OpenGL ES as a possibility as it
> provides extensions for multiple-process windowing environments.
> Other requirements would obviously be the ability to allow client
> programs to allocate and share out chunks of graphics memory to other
> clients (later used as textures for compositing), support for
> multiple graphics cards with different hardware renderers over
> different busses, using DMA to transfer data between cards as
> necessary (and user-configurable policy about how to divide use of
> the cards), support for single or multiple framebuffers per GPU, as
> well as an arbitrary number of hardware and software viewports per
> framebuffer.  There would also need to be a way for userspace to trap
> and emulate or ignore unsupported OpenGL commands.  The kernel would
> need some rudimentary understanding of OpenGL to be able to handle
> buggy GPUs and prevent them from hanging the PCI bus (some GPUs can
> do that if sent invalid commands), but you obviously wouldn't want a
> full software renderer in the kernel.  The system should also support
> transmitting OpenGL textures, commands, and other data asynchronously
> over a TCP socket, though doing it locally via mmap would be far more
> efficient.  I'm probably missing other necessary generics, but that
> should provide a good discussion starter.

Not that I can see, but the network connectivity bit should probably not be 
targeted in the first set of patches. IMHO, the best way to handle this would 
be to start merging the DRI drivers into the Framebuffer drivers.  This would 
then provide some of the infrastructure needed to bring an accelerated 
graphics framework into the realm of possibility just in userspace.

In other words - like with everything, the kernel only needs to provide a very 
basic set of tools. Provide the kernel with the capacity to handle the 
accelerated aspects of video cards seemlessly with the framebuffer driver and 
the "Mesa Solo" project would be more than half complete.

By implementing a framework where userspace doesn't have to know - or care - 
about the hardware, which, IMNSHO, is the way things should be, then 
userspace applications can take advantage of such a system and be even more 
stable.

> The necessary kernel support would include a graphics-memory
> allocator, resource management, GPU-time allocation, etc, as well as
> support for an overlaid kernel console.  Ideally an improved graphics
> driver like that would be able to dump panics directly to the screen
> composited on top of whatever graphics are being displayed, so you'd
> get panics even while running X.  If that kind of support was
> available in-kernel, fixing X to not need root would be far simpler,
> plus you could also write replacement X-like tools without half the
> effort.  Given that sort of support, a rootless xserver would be a
> fairly trivial wrapper over whatever underlying implementation there
> was.

Here you outline what is needed, and strangely I find myself thinking that a 
lot of this code has already been written. The DRI/DRM system provides a 
method for userspace to directly access the acceleration features of graphics 
cards. Would it not be possible, then, to take the DRI system, merge it with 
the framebuffer system in some manner, and provide a single interface to 
userspace?

Even now I know that most applications that directly access the framebuffer 
and make use of it have special drivers for the various cards that have 
framebuffer drivers in Linux. These might be because of the various 
colorspace conventions - like the BGRA (IIRC) of the Radeons - but even that 
could be better handled either via a sysfs file or by an ioctl in the 
drivers.

But if the Framebuffer system got a makeover, perhaps implementing the 
information side as sysfs files and the actual control side as ioctls...

One thing that I've been thinking about is that there is some need for DMA to 
and from the card. This would probably best be done by the current S/G DMA 
system, as it's a well known and very stable part of the kernel that is 
(IIRC) exposed to userspace.

As for allowing direct access to the GPU, about all I can think of is 
providing an IOCTL that gives you a pointer to a buffer that you can write 
the information to, although a better solution would be to provide a single 
IOCTL that takes a userspace buffer and transfers it directly to the GPU.

Neither option seems good to me, since both would require userspace to know 
which card it's talking to. So, my only real suggestion is to add another 
library to the kernel - one that can translate a user request into the proper 
GPU commands and hide all the machinery from the end-user.

DRH
(Note: I do not like any of the GPU access options I mentioned. The first two 
because they require userspace knowing which hardware it's talking to when I, 
personally, feel that userspace should have no need to know that sort of 
information. The last one because it requires adding a complex interpreter to 
the kernel, and that screams to me of "bloat".)

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/22/06, D. Hazelton <dhazelton@enter.net> wrote:
> Not that I can see, but the network connectivity bit should probably not be
> targeted in the first set of patches. IMHO, the best way to handle this would
> be to start merging the DRI drivers into the Framebuffer drivers.  This would
> then provide some of the infrastructure needed to bring an accelerated
> graphics framework into the realm of possibility just in userspace.

Merging fbdev and DRM is the obvious place to start. Fully
implementing a merge requires solving a number of issues. Here are a
few to get you going...

1) Running the video ROM at boot to reset cards, emu86
2) Sorting out VGA when multiple cards are present
3) Determining where mode setting code is going to live
4) Providing a default driver for video cards that have none
5) Actually merging DRM/fbdev
6) Some way for multiple users to control their video card without being root

None of this is rocket science, patches have been already attempted
for everything on the list. The real challenge is political, not
technical.

> By implementing a framework where userspace doesn't have to know - or care -
> about the hardware, which, IMNSHO, is the way things should be, then
> userspace applications can take advantage of such a system and be even more
> stable.

A true monolithic design doesn't really work for video hardware. In
the monolithic model all devices in a class present a uniform API. The
better design for GPUs is the exo-kernel model. DRM already uses the
exo-kernel model. With exokernels each driver presents a unique API
and userspace libraries are used to provide a uniform API.

The exo-kernel model works well with software fallbacks. mesa provides
a complete software OpenGL implementation. The device specific user
space library then overlays functions that its hardware can
accelerate.

The current microkernel'ish design of the 2D Xserver causes a great
deal of conflict with existing Linux subsystems. Given that 3D is
already in the exo-kernel model, I don't see much benefit is pursuing
a microkernel 2D solution.

> > The necessary kernel support would include a graphics-memory
> > allocator, resource management, GPU-time allocation, etc, as well as
> > support for an overlaid kernel console.  Ideally an improved graphics
> > driver like that would be able to dump panics directly to the screen
> > composited on top of whatever graphics are being displayed, so you'd
> > get panics even while running X.  If that kind of support was
> > available in-kernel, fixing X to not need root would be far simpler,

There is no technical reason requiring X to run as root, it is a
matter of choice and convenience. I have had versions of X with 3D
support running without root on my local machine but the patches were
not merged.

> > plus you could also write replacement X-like tools without half the
> > effort.  Given that sort of support, a rootless xserver would be a
> > fairly trivial wrapper over whatever underlying implementation there
> > was.
>
> Here you outline what is needed, and strangely I find myself thinking that a
> lot of this code has already been written. The DRI/DRM system provides a
> method for userspace to directly access the acceleration features of graphics
> cards. Would it not be possible, then, to take the DRI system, merge it with
> the framebuffer system in some manner, and provide a single interface to
> userspace?

The strategy of adding acceleration feature to the framebuffer drivers
causes conflict with X and DRM drivers. The better solution is to
collect all acceleration support into a single driver. The DRM
acceleration code is much more advanced than the fbdev code.

> One thing that I've been thinking about is that there is some need for DMA to
> and from the card. This would probably best be done by the current S/G DMA
> system, as it's a well known and very stable part of the kernel that is
> (IIRC) exposed to userspace.

DRM already supports DMA to/from the GPU and does security checks on
the parameters. It also security checks the commands being fed to the
GPU to keep Direct Rendering applications from causing mischief.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Matthew Garrett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> 1) Running the video ROM at boot to reset cards, emu86

Jon, how many times am I going to have to tell you that this won't work? 
The video ROM is not always present on laptop hardware, and even when it 
is it may jump into sections of ROM that have vanished since boot. 
In the long run, graphics drivers need to know how to program cards from 
scratch rather than depending on 80x25 text mod being there for them.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/23/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > 1) Running the video ROM at boot to reset cards, emu86
>
> Jon, how many times am I going to have to tell you that this won't work?
> The video ROM is not always present on laptop hardware, and even when it
> is it may jump into sections of ROM that have vanished since boot.
> In the long run, graphics drivers need to know how to program cards from
> scratch rather than depending on 80x25 text mod being there for them.

1) I didn't put a lot of detail into the line item but you only need
to use the ROM to reset secondary cards on x86 architectures. Primary
cards are always initialized by the system BIOS so you don't need to
run their ROM on boot. I think the only way to get a secondary card
into a laptop is through a PCMCIA slot and I've only seen one PCMCIA
video card.

2) The ROM support in the kernel knows about the shadow RAM copy at
C000::0. When you request the ROM from a laptop video system it
returns a map to the shadow RAM copy, not to a physical ROM. You need
access to the shadow RAM copy to get to things the BIOS left there
when it ran.

So to add more detail,
Run the ROM on primary adapters if the arch is non-x86 and the ROM
contains x86 code.
Run the ROM on primary adapters on embedded systems if the system BIOS
doesn't do it.
Otherwise don't run a primary ROM. The kernel ROM API tracks primary
versus secondary for you.
Always run the ROM on secondary adapters. Secondary adapters don't
have the compressed laptop ROM problem.

When running the ROMs you will need to add code to manage the active
VGA device since both adapters will try and turn it on when their ROMs
are run.

You will also need to provide a mechanism to call out to userspace.
The userspace program will use vm86 or emu86 to run the ROM image.

The contents of the ROM image should be put back into the kernel using
the ROM copy APIs but no one has gotten that far yet. Video ROMs
assume they are running out of shadow RAM so they alter things and
leave pointers to what they found.

I can provide more detail on how to set all of this up if needed.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 23 May 2006 23:38, Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> > > 1) Running the video ROM at boot to reset cards, emu86
> >
> > Jon, how many times am I going to have to tell you that this won't work?
> > The video ROM is not always present on laptop hardware, and even when it
> > is it may jump into sections of ROM that have vanished since boot.
> > In the long run, graphics drivers need to know how to program cards from
> > scratch rather than depending on 80x25 text mod being there for them.
>
> 1) I didn't put a lot of detail into the line item but you only need
> to use the ROM to reset secondary cards on x86 architectures. Primary
> cards are always initialized by the system BIOS so you don't need to
> run their ROM on boot. I think the only way to get a secondary card
> into a laptop is through a PCMCIA slot and I've only seen one PCMCIA
> video card.

Agreed. I'll see about doing this using a method similar to the X int10 model. 
I don't have access to the specs on anything other than x86, so if someone 
could provide some information to help with the non-x86 side of the code I'd 
be grateful.

> 2) The ROM support in the kernel knows about the shadow RAM copy at
> C000::0. When you request the ROM from a laptop video system it
> returns a map to the shadow RAM copy, not to a physical ROM. You need
> access to the shadow RAM copy to get to things the BIOS left there
> when it ran.

Of course. But then there are people who do stupid things like telling the 
BIOS not to provide a shadow copy of the ROM. However that isn't a big 
problem and those people should have their hardware properly configured in 
the first place...

> So to add more detail,
> Run the ROM on primary adapters if the arch is non-x86 and the ROM
> contains x86 code.
> Run the ROM on primary adapters on embedded systems if the system BIOS
> doesn't do it.
> Otherwise don't run a primary ROM. The kernel ROM API tracks primary
> versus secondary for you.
> Always run the ROM on secondary adapters. Secondary adapters don't
> have the compressed laptop ROM problem.

Okay. This is good - exactly what I was thinking would be done anyway.  What 
about cards like the Radeon's with two CRTC's that can run multi-headed off a 
single card?

Apparently the card is booted properly by the BIOS, but the second head 
(either the VGA port, the Composite/TV Out or the DVI) isn't setup properly 
by the BIOS because, apparently, the ROM can't detect the properties of the 
second head in some situations.

However, for situations like that it might be best to have the API open so 
that userspace tools can be used to set those secondary outputs.

> When running the ROMs you will need to add code to manage the active
> VGA device since both adapters will try and turn it on when their ROMs
> are run.

Okay. This has me beat - any suggestions on how to manage it?

> You will also need to provide a mechanism to call out to userspace.
> The userspace program will use vm86 or emu86 to run the ROM image.

Yes - problem is that I have not been able to find any decent information on 
vm86/emu86 in order to capitalize on the system call. Might be better to have 
some people specifically working on the userspace stuff while others focuse 
on the in-kernel stuff.

> The contents of the ROM image should be put back into the kernel using
> the ROM copy APIs but no one has gotten that far yet. Video ROMs
> assume they are running out of shadow RAM so they alter things and
> leave pointers to what they found.
>
> I can provide more detail on how to set all of this up if needed.

Yes, please. I made the post I did - dumping my immediate thoughts on the 
subject into it - because I was interested in working on this and making some 
contribution to the kernel. I have a feeling I can get the DRM stuff working 
as the backend for the framebuffer drivers and export that API, or something 
slightly different, to userspace for the userspace tools to take advantage 
of.

In this case, I was thinking that the exo-kernel model used in ALSA would be 
the best solution. For that matter, it wouldn't be trivial, but your 
suggestion about modifying Mesa to be the main userspace interface to the 
kernel graphics system has a lot of merit.

One problem is that Mesa is strictly OpenGL, so this would mean there would 
have to be a second library for the 2D stuff. Potential contenders for this 
are abundant, including one windowing system that actually, IIRC, is 
distributed as a kernel patch/module. I would love to leave the 2D stuff 
completely up to userspace, but all modern video cards contain acceleration 
for 2D drawing, so it would probably be best to include that in any userspace 
side of the system.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/23/06, D. Hazelton <dhazelton@enter.net> wrote:
> > 2) The ROM support in the kernel knows about the shadow RAM copy at
> > C000::0. When you request the ROM from a laptop video system it
> > returns a map to the shadow RAM copy, not to a physical ROM. You need
> > access to the shadow RAM copy to get to things the BIOS left there
> > when it ran.
>
> Of course. But then there are people who do stupid things like telling the
> BIOS not to provide a shadow copy of the ROM. However that isn't a big
> problem and those people should have their hardware properly configured in
> the first place...

Every recent system I've turned the shadow copy off on won't boot any more.

> Okay. This is good - exactly what I was thinking would be done anyway.  What
> about cards like the Radeon's with two CRTC's that can run multi-headed off a
> single card?
>
> Apparently the card is booted properly by the BIOS, but the second head
> (either the VGA port, the Composite/TV Out or the DVI) isn't setup properly
> by the BIOS because, apparently, the ROM can't detect the properties of the
> second head in some situations.

That is a card specific problem that needs to be addressed in the
driver for the card. As long as the ROM is run the hardware will
correctly respond to commands asking it about the secondary heads.

> However, for situations like that it might be best to have the API open so
> that userspace tools can be used to set those secondary outputs.
>
> > When running the ROMs you will need to add code to manage the active
> > VGA device since both adapters will try and turn it on when their ROMs
> > are run.
>
> Okay. This has me beat - any suggestions on how to manage it?

Don't worry about multiple cards in a single system yet.

>
> > You will also need to provide a mechanism to call out to userspace.
> > The userspace program will use vm86 or emu86 to run the ROM image.
>
> Yes - problem is that I have not been able to find any decent information on
> vm86/emu86 in order to capitalize on the system call. Might be better to have
> some people specifically working on the userspace stuff while others focuse
> on the in-kernel stuff.

BenH has source for a working emu86. I would wait on that project
until klibc has been merged.

> One problem is that Mesa is strictly OpenGL, so this would mean there would
> have to be a second library for the 2D stuff. Potential contenders for this
> are abundant, including one windowing system that actually, IIRC, is
> distributed as a kernel patch/module. I would love to leave the 2D stuff
> completely up to userspace, but all modern video cards contain acceleration
> for 2D drawing, so it would probably be best to include that in any userspace
> side of the system.

OpenGL is perfectly capable of doing 2D drawing as well as 3D. Check
out the profile option of OpenGL/ES. It has been proposed before to
chop mesa down into a smaller OpenGL/ES profile for system where space
is at a premium. There is a commercial minimum profile OpenGL/ES
implementation that fits in 100K.

I would leave accelerated 2D alone to begin with and I would remove
the fbdev 2D acceleration from any fbdev drivers that you merge. The
fbdev acceleration code conflicts with the DRM code. If you ask me,
there should be no in kernel access to acceleration of any kind.
Anything wanting acceleration would need to ask for it from user
space. More details on consoles and acceleration are in:
http://jonsmirl.googlepages.com/graphics.html

Merging and fixing the kernel graphics subsystem is a gigantic
project. My strategy would be to split it up into small steps and get
one step accepted at a time. Don't start writing code for the next
step until the first one is accepted. The number of changes you will
get on the first step will invalidate anything you do on the second
step.

A good first project would be to start building a set of user space
apps for doing the mode setting on each card. All of the code for
doing this exists in the X server but it is a pain to extract. X has
1000s of internal APIs and typedefs. You would end up with a set of
apps that would be able to list the valid modes on each head and then
set them. The code for achieving this is all over the map, sometimes
we know everything needed like for the Radeon, sometimes you need to
make a VM86 call to the BIOS to get the info (Intel). Load an fbdev
driver and check out the current support for this in sysfs.

When you get done with a command it should be a tiny app statically
linked to klibc and have no external dependencies. These apps should
be 30K or less in size. You probably will end up with about ten apps
since a lot of the uncommon cards only have a standard VBE BIOS and
will all use the same command.

You will also need to make a licensing decision. X and DRM are MIT
licensed and fbdev is GPL licensed. If you use any code from fbdev you
have to pick GPL for your license. This won't bother Linux but it will
bother BSD. I'm a Linux user and I've never booted BSD so I don't
care, but other people do.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 04:21, Jon Smirl wrote:
> On 5/23/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > 2) The ROM support in the kernel knows about the shadow RAM copy at
> > > C000::0. When you request the ROM from a laptop video system it
> > > returns a map to the shadow RAM copy, not to a physical ROM. You need
> > > access to the shadow RAM copy to get to things the BIOS left there
> > > when it ran.
> >
> > Of course. But then there are people who do stupid things like telling
> > the BIOS not to provide a shadow copy of the ROM. However that isn't a
> > big problem and those people should have their hardware properly
> > configured in the first place...
>
> Every recent system I've turned the shadow copy off on won't boot any more.
>
> > Okay. This is good - exactly what I was thinking would be done anyway. 
> > What about cards like the Radeon's with two CRTC's that can run
> > multi-headed off a single card?
> >
> > Apparently the card is booted properly by the BIOS, but the second head
> > (either the VGA port, the Composite/TV Out or the DVI) isn't setup
> > properly by the BIOS because, apparently, the ROM can't detect the
> > properties of the second head in some situations.
>
> That is a card specific problem that needs to be addressed in the
> driver for the card. As long as the ROM is run the hardware will
> correctly respond to commands asking it about the secondary heads.

Okay, I'll shelve this for a second or third step in the devel then - as some 
of the heads - notably the composite and s-video out - can't provide EDID or 
DDC information.

> > However, for situations like that it might be best to have the API open
> > so that userspace tools can be used to set those secondary outputs.
> >
> > > When running the ROMs you will need to add code to manage the active
> > > VGA device since both adapters will try and turn it on when their ROMs
> > > are run.
> >
> > Okay. This has me beat - any suggestions on how to manage it?
>
> Don't worry about multiple cards in a single system yet.
>
> > > You will also need to provide a mechanism to call out to userspace.
> > > The userspace program will use vm86 or emu86 to run the ROM image.
> >
> > Yes - problem is that I have not been able to find any decent information
> > on vm86/emu86 in order to capitalize on the system call. Might be better
> > to have some people specifically working on the userspace stuff while
> > others focuse on the in-kernel stuff.
>
> BenH has source for a working emu86. I would wait on that project
> until klibc has been merged.

Okay.

However, I'd assume that the person writing emu86 (BenH) would provide some 
support and documentation for it.

vm86 is a whole different beast. I've been through every document on it that I 
can find and still don't understand how to use it properly.

> > One problem is that Mesa is strictly OpenGL, so this would mean there
> > would have to be a second library for the 2D stuff. Potential contenders
> > for this are abundant, including one windowing system that actually,
> > IIRC, is distributed as a kernel patch/module. I would love to leave the
> > 2D stuff completely up to userspace, but all modern video cards contain
> > acceleration for 2D drawing, so it would probably be best to include that
> > in any userspace side of the system.
>
> OpenGL is perfectly capable of doing 2D drawing as well as 3D. Check
> out the profile option of OpenGL/ES. It has been proposed before to
> chop mesa down into a smaller OpenGL/ES profile for system where space
> is at a premium. There is a commercial minimum profile OpenGL/ES
> implementation that fits in 100K.

Okay. What I was thinking is that by providing a 2D and 3D API the cards that 
people might have that lack 3D acceleration capabilities could still do 
accelerated graphics in the 2D sense. This would be best done, IMHO, through 
a dedicated 2D acceleration API.

However, I also have taken to heart the admonition that the kernel should 
provide a minimal API and the rest should be in userspace. So, technically, 
the 2D drawing API could use OpenGL itself and the hardware would see the 
proper commands as filtered through it's userspace side driver.

> I would leave accelerated 2D alone to begin with and I would remove
> the fbdev 2D acceleration from any fbdev drivers that you merge. The
> fbdev acceleration code conflicts with the DRM code. If you ask me,
> there should be no in kernel access to acceleration of any kind.
> Anything wanting acceleration would need to ask for it from user
> space. More details on consoles and acceleration are in:
> http://jonsmirl.googlepages.com/graphics.html

Thank you!

> Merging and fixing the kernel graphics subsystem is a gigantic
> project. My strategy would be to split it up into small steps and get
> one step accepted at a time. Don't start writing code for the next
> step until the first one is accepted. The number of changes you will
> get on the first step will invalidate anything you do on the second
> step.

This is how I work anyway.

> A good first project would be to start building a set of user space
> apps for doing the mode setting on each card. All of the code for
> doing this exists in the X server but it is a pain to extract. X has
> 1000s of internal APIs and typedefs. You would end up with a set of
> apps that would be able to list the valid modes on each head and then
> set them. The code for achieving this is all over the map, sometimes
> we know everything needed like for the Radeon, sometimes you need to
> make a VM86 call to the BIOS to get the info (Intel). Load an fbdev
> driver and check out the current support for this in sysfs.

Actually I had planned to do something much larger. I had planned to implement 
a framebuffer driver for my current video card using the latest stable kernel 
release and the latest DRM sources.  This way I'll have a basis for porting 
the other existing framebuffer drivers over, which will save me a lot of 
time.

I had planned on actually exporting the full, probed capabilities of the 
devices to userspace via sysfs, though I don't know if there is a good way to 
export full DDC or EDID information. Perhaps that should go somewhere 
in /proc?  (I know, the kernel is moving away from information in /proc but 
the sysfs "single setting per file" would mean a lot of files to contain all 
the potential information)

And as you note, licensing is an issue. However, as the kernel is GPL I might 
use DRM as an information source and write that code over again to sidestep 
any licensing issues. (I really don't want to piss off the MIT or BSD people)

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/23/06, D. Hazelton <dhazelton@enter.net> wrote:
> I had planned on actually exporting the full, probed capabilities of the
> devices to userspace via sysfs, though I don't know if there is a good way to
> export full DDC or EDID information. Perhaps that should go somewhere
> in /proc?  (I know, the kernel is moving away from information in /proc but
> the sysfs "single setting per file" would mean a lot of files to contain all
> the potential information)

Load an fbdev driver and look in sysfs. fbdev already has the ability
to list the valid modes via the 'modes' parameter. Copy one of those
strings into 'mode' and your more will be set.

> And as you note, licensing is an issue. However, as the kernel is GPL I might
> use DRM as an information source and write that code over again to sidestep
> any licensing issues. (I really don't want to piss off the MIT or BSD people)

But it is very hard to merge DRM and fbdev without touching the fbdev
code and getting things mixed up.  Plus there is no guarantee that BSD
will even use your code if you keep the license clean. Other OS's
don't necessarily like the Linux fbdev model.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 04:57, Jon Smirl wrote:
> On 5/23/06, D. Hazelton <dhazelton@enter.net> wrote:
> > I had planned on actually exporting the full, probed capabilities of the
> > devices to userspace via sysfs, though I don't know if there is a good
> > way to export full DDC or EDID information. Perhaps that should go
> > somewhere in /proc?  (I know, the kernel is moving away from information
> > in /proc but the sysfs "single setting per file" would mean a lot of
> > files to contain all the potential information)
>
> Load an fbdev driver and look in sysfs. fbdev already has the ability
> to list the valid modes via the 'modes' parameter. Copy one of those
> strings into 'mode' and your more will be set.

Okay. I was under the impression that it wasn't good to have more than one bit 
of information per file in sysfs.

> > And as you note, licensing is an issue. However, as the kernel is GPL I
> > might use DRM as an information source and write that code over again to
> > sidestep any licensing issues. (I really don't want to piss off the MIT
> > or BSD people)
>
> But it is very hard to merge DRM and fbdev without touching the fbdev
> code and getting things mixed up.  Plus there is no guarantee that BSD
> will even use your code if you keep the license clean. Other OS's
> don't necessarily like the Linux fbdev model.

Pardon me for saying this, but... I don't actually care about them. It's the 
fact that MIT is a *huge* college and likely has money to pursue license 
issues and similar, and the BSD license, IIRC, states that the code is 
"Property of the Board of Regents" of, IIRC, UC Berkeley. UC Berkeley is 
again, a rather huge college, and has the resources to pursue license issues.

For that reason alone I am going to try to keep any code I produce clean. I 
could care less if BSD or an MIT OS project use the code - I'm writing it for 
Linux.

DRH

Re: OpenGL-based framebuffer concepts

[Chase Venters]

On Wed, 24 May 2006, D. Hazelton wrote:

> And as you note, licensing is an issue. However, as the kernel is GPL I might
> use DRM as an information source and write that code over again to sidestep
> any licensing issues. (I really don't want to piss off the MIT or BSD people)

While licensing is obviously entirely up to you (as the author), I 
wouldn't worry too much about using the GPL / copyleft for your software 
in this case. I know there are a lot of BSD developers that would be happy 
to replace every line of GPL-licensed code with BSD-licensed code, but 
given that the BSD license has around 5% penetration versus 
some-number-around-80% for the GPL, I think GPL code in a BSD system is 
kind of a reality at this point. It might be more of a concern to me (in my work) if I 
thought that the GPL was restrictive.

Remember that the GPL doesn't even apply to the end-user until they want 
to make a copy of your original or their derivitive work. Also remember 
that GNOME and KDE are both under (L)GPL licensing.

> DRH

Cheers,
Chase

Re: OpenGL-based framebuffer concepts

[Paulo Marques]

Jon Smirl wrote:
> [...]
> BenH has source for a working emu86. I would wait on that project
> until klibc has been merged.

A while ago I worked on cleaning up the emulator that was first written 
by SciTech, and then used by X and LinuxBIOS people.

The .text size of the emulator went from 59478 to 38225 bytes, but I bet 
I could shrink it even further. The emulator was a bit optimized for 
speed, but IMHO we want it optimized for size.

If I can get the emulator to use, say, 20kB, wouldn't it be better to 
have it in the kernel instead of as user-space helper?

This would allow the graphics driver to call BIOS functions as if they 
were regular functions, i.e., you could call on a BIOS function to set 
the graphics mode and continue execution when the BIOS function completes.

A user mode helper will always be more cumbersome from a programming 
POV. Not to mention that it would be a lot easier for distro maintainers...

-- 
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
            Dilbert: Sanity? Reality? The laws of physics?

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
>> Jon Smirl <jonsmirl@gmail.com> wrote:
>>
>> > 1) Running the video ROM at boot to reset cards, emu86
>>
>> Jon, how many times am I going to have to tell you that this won't work?
>> The video ROM is not always present on laptop hardware, and even when it
>> is it may jump into sections of ROM that have vanished since boot.
>> In the long run, graphics drivers need to know how to program cards from
>> scratch rather than depending on 80x25 text mod being there for them.
>
> 1) I didn't put a lot of detail into the line item but you only need
> to use the ROM to reset secondary cards on x86 architectures. Primary
> cards are always initialized by the system BIOS so you don't need to
> run their ROM on boot. I think the only way to get a secondary card
> into a laptop is through a PCMCIA slot and I've only seen one PCMCIA
> video card.
I wonder, could this secondary initialization be done by the bootloader?
A standard pc bios don't initialize extra graphichs cards, and making
a custom bios isn't easy.  But the boot loader (lilo/grub) runs in a mode
where calling into a bios should be easy. 

Or will there be a lot of trickery in mapping the secondary (and
tertiary...) card bioses somewhere in order to run them?

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Stefan Seyfried]

On Tue, May 23, 2006 at 07:38:40PM -0400, Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:

> 1) I didn't put a lot of detail into the line item but you only need
> to use the ROM to reset secondary cards on x86 architectures. Primary
> cards are always initialized by the system BIOS so you don't need to
> run their ROM on boot. I think the only way to get a secondary card
> into a laptop is through a

Docking station.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen

Re: OpenGL-based framebuffer concepts

[Matthew Garrett]

On Tue, May 23, 2006 at 07:38:40PM -0400, Jon Smirl wrote:

> 2) The ROM support in the kernel knows about the shadow RAM copy at
> C000::0. When you request the ROM from a laptop video system it
> returns a map to the shadow RAM copy, not to a physical ROM. You need
> access to the shadow RAM copy to get to things the BIOS left there
> when it ran.

My experience is that, on some laptops, the code at c000:0003 may jump 
into some other address block that isn't necessarily shadowed. There's 
no reason to assume that POSTing an ancilliary ROM will work after the 
system has left the BIOS. Further, my laptop doesn't appear to have a 
rom entry in sysfs, which makes getting at stuff that way rather more 
awkward...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 22:08, Matthew Garrett wrote:
> On Tue, May 23, 2006 at 07:38:40PM -0400, Jon Smirl wrote:
> > 2) The ROM support in the kernel knows about the shadow RAM copy at
> > C000::0. When you request the ROM from a laptop video system it
> > returns a map to the shadow RAM copy, not to a physical ROM. You need
> > access to the shadow RAM copy to get to things the BIOS left there
> > when it ran.
>
> My experience is that, on some laptops, the code at c000:0003 may jump
> into some other address block that isn't necessarily shadowed. There's
> no reason to assume that POSTing an ancilliary ROM will work after the
> system has left the BIOS. Further, my laptop doesn't appear to have a
> rom entry in sysfs, which makes getting at stuff that way rather more
> awkward...

As has been previously stated, the kernel should have already setup the 
primary video card by that point. EDID information can be used to get 
information about valid modes. I don't know of a single laptop that has 
multiple video cards in it. If you do, please enlighten me.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/24/06, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, May 23, 2006 at 07:38:40PM -0400, Jon Smirl wrote:
>
> > 2) The ROM support in the kernel knows about the shadow RAM copy at
> > C000::0. When you request the ROM from a laptop video system it
> > returns a map to the shadow RAM copy, not to a physical ROM. You need
> > access to the shadow RAM copy to get to things the BIOS left there
> > when it ran.
>
> My experience is that, on some laptops, the code at c000:0003 may jump
> into some other address block that isn't necessarily shadowed. There's
> no reason to assume that POSTing an ancilliary ROM will work after the
> system has left the BIOS. Further, my laptop doesn't appear to have a
> rom entry in sysfs, which makes getting at stuff that way rather more
> awkward...

As outlined in the previous mail, you don't repost a primary adapter
that has already been posted. Adapters should only get posted once.
Laptop adapters are always primary. However, you may need access to
the shadow ROM copy to get info out of it and to run non-post
functions.

A missing sysfs ROM entry is probably a bug. There is a quirk in
arch/i386 that detects shadow video ROMs and tracks the primary video
adapter. It probably needs some special case code added for your
chipset. You're the first report of it being missing. Since I don't
have your laptop you'll need to debug this yourself. It shouldn't be
hard, it is a tiny piece of code.

The ROM attribute feature is not well tested on all platforms since
not much of the user space code that should be using it hasn't been
changed yet.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Matthew Garrett wrote:
> In the long run, graphics drivers need to know how to program cards from 
> scratch rather than depending on 80x25 text mod being there for them.

True in theory, but that's a task of immense proportions.  The Video 
BIOS is often the only place where RAM timings and other board-specific 
data lives.

	Jeff

Re: OpenGL-based framebuffer concepts

[Matthew Garrett]

On Tue, May 23, 2006 at 09:50:38PM -0400, Jeff Garzik wrote:
> Matthew Garrett wrote:
> >In the long run, graphics drivers need to know how to program cards from 
> >scratch rather than depending on 80x25 text mod being there for them.
> 
> True in theory, but that's a task of immense proportions.  The Video 
> BIOS is often the only place where RAM timings and other board-specific 
> data lives.

We lose at ACPI support unless we can do this, unfortunately - the "run 
chunks of video BIOS" fallbacks aren't going to work forever.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On May 23, 2006, at 13:17:18, Jon Smirl wrote:
>> By implementing a framework where userspace doesn't have to know -  
>> or care - about the hardware, which, IMNSHO, is the way things  
>> should be, then userspace applications can take advantage of such  
>> a system and be even more stable.
>
> A true monolithic design doesn't really work for video hardware. In  
> the monolithic model all devices in a class present a uniform API.  
> The better design for GPUs is the exo-kernel model. DRM already  
> uses the exo-kernel model. With exokernels each driver presents a  
> unique API and userspace libraries are used to provide a uniform API.

The one really significant potential problem with the exo-kernel  
model for graphics is that the kernel *must* have a stable way to  
display kernel panics regardless of current video mode, framebuffer  
settings, 3D rendering, etc.  The kernel driver should be able to  
provide some fundamental operations for compositing text on top of  
the framebuffer at the primary viewport regardless of whatever  
changes userspace makes to the GPU configuration.  We don't have this  
now, but I see it as an absolute requirement for any replacement  
graphics system.  This means that the kernel driver should be able to  
understand and modify the entire GPU state to the extent necessary  
for such a text console.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 00:10, Kyle Moffett wrote:
> On May 23, 2006, at 13:17:18, Jon Smirl wrote:
> >> By implementing a framework where userspace doesn't have to know -
> >> or care - about the hardware, which, IMNSHO, is the way things
> >> should be, then userspace applications can take advantage of such
> >> a system and be even more stable.
> >
> > A true monolithic design doesn't really work for video hardware. In
> > the monolithic model all devices in a class present a uniform API.
> > The better design for GPUs is the exo-kernel model. DRM already
> > uses the exo-kernel model. With exokernels each driver presents a
> > unique API and userspace libraries are used to provide a uniform API.
>
> The one really significant potential problem with the exo-kernel
> model for graphics is that the kernel *must* have a stable way to
> display kernel panics regardless of current video mode, framebuffer
> settings, 3D rendering, etc.  The kernel driver should be able to
> provide some fundamental operations for compositing text on top of
> the framebuffer at the primary viewport regardless of whatever
> changes userspace makes to the GPU configuration.  We don't have this
> now, but I see it as an absolute requirement for any replacement
> graphics system.  This means that the kernel driver should be able to
> understand and modify the entire GPU state to the extent necessary
> for such a text console.

For this it's not trivial, but seems to be, on the surface, rather easy to 
accomplish.

Since the driver is controlling all aspects of the system - memory and the 
like - and doing DMA to/from that memory for userspace accesses why not use 
one of the built-in framebuffer fonts and draw the panic directly to the 
video memory of the current screen?

Of course there are some times when this might not be possible - most notably 
during a display mode switch.  In that case I have no solutions, because when 
a Panic happens you have no guarantees about the state of the system.

Perhaps have the video-hardware re-initialized on a kexec after the panic and 
provide some way for the new kernel to display the panic information?

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/23/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On May 23, 2006, at 13:17:18, Jon Smirl wrote:
> >> By implementing a framework where userspace doesn't have to know -
> >> or care - about the hardware, which, IMNSHO, is the way things
> >> should be, then userspace applications can take advantage of such
> >> a system and be even more stable.
> >
> > A true monolithic design doesn't really work for video hardware. In
> > the monolithic model all devices in a class present a uniform API.
> > The better design for GPUs is the exo-kernel model. DRM already
> > uses the exo-kernel model. With exokernels each driver presents a
> > unique API and userspace libraries are used to provide a uniform API.
>
> The one really significant potential problem with the exo-kernel
> model for graphics is that the kernel *must* have a stable way to
> display kernel panics regardless of current video mode, framebuffer
> settings, 3D rendering, etc.  The kernel driver should be able to
> provide some fundamental operations for compositing text on top of
> the framebuffer at the primary viewport regardless of whatever
> changes userspace makes to the GPU configuration.  We don't have this
> now, but I see it as an absolute requirement for any replacement
> graphics system.  This means that the kernel driver should be able to
> understand and modify the entire GPU state to the extent necessary
> for such a text console.

It's not as bad as it seems. I haven't tried implementing this; I
believe the Novell kernel debugger is the system that has done so.
Here's what I think needs to be done, but I may be missing something.

1) Track where the scanout buffer is.
2) Track the x/y size of the buffer and it's pixel format
3) Know how to stop the GPU (usually a poke into an IO port)
4) Have a minimal font in the driver - fbdev already has this.

On a panic, stop the GPU and then use the font and buffer info to
paint into the display. fbdev already contains code that can draw
using the fbdev fonts into an arbitrary resolution/pixel format
buffer. The code that implements this is small and is probably already
in the kernel that you are using.

This model doesn't work with the current X server since it never tells
the kernel the location and size of the scan out buffer.

Of course they are windows when this won't work, for example a panic
in the middle of a mode change, but it is a lot better than what we
have today.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Kyle Moffett wrote:
>
> The one really significant potential problem with the exo-kernel model 
> for graphics is that the kernel *must* have a stable way to display 
> kernel panics regardless of current video mode, framebuffer settings, 
> 3D rendering, etc.  The kernel driver should be able to provide some 
> fundamental operations for compositing text on top of the framebuffer 
> at the primary viewport regardless of whatever changes userspace makes 
> to the GPU configuration.  We don't have this now, but I see it as an 
> absolute requirement for any replacement graphics system.  This means 
> that the kernel driver should be able to understand and modify the 
> entire GPU state to the extent necessary for such a text console.
I am not so sure I want this at all.
In the early 90's, I used unix machines wich did exactly this - spamming the
framebuffer console with occational messages while X was running.
Yuck yuck yuck yuck yuck .  .  .

Now, a panic/oops message is sure better than a silent hang, but that's 
it, really.
Anything less than that should just go in a logfile where the admin can look
it up later.  The very ability to write on the console will alway be abused
by some application programmer or kernel driver module vendor. 

Blindly writing on the console won't be very useful either, the user might
be running a game or video which overwrites the message within 1/30s anyway.
Well, perhaps it can be done better than that, with some thought. I.e. :

* block all further access to /dev/fb0, processes will wait.
* Mark graphichs memory "not present" for any process that have it mapped,
   so as to pagefault anyone using it directly.  (read-only is not enough,
  processes should see the graphichs memory they expect, not
  the kernel message)
* Try to allocate memory for saving the screen image (assuming the
   machine won't hang completely, it will often keep running after an oops)
* Annoy the user by showing the message
* Provide some way of letting the user decide when to proceed, such
   as pressing a key
* Restore the saved screen memory (if that allocation was successful)
* Mark framebuffer memory present, releasing pagefaulted processes
* Unblock /dev/fb0

So, kernel messages can be done.  But if the plan just is to blindly
write messages to the framebuffer, then please drop it.  I really hate
stupid messages on top of my windows, especially when the X display
is _scrolled_ without invalidating the windows. :-(

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Alexander E. Patrakov]

Helge Hafting wrote:
> Now, a panic/oops message is sure better than a silent hang, but that's 
> it, really.
> Anything less than that should just go in a logfile where the admin can 
> look
> it up later.  The very ability to write on the console will alway be abused
> by some application programmer or kernel driver module vendor.
> Blindly writing on the console won't be very useful either, the user might
> be running a game or video which overwrites the message within 1/30s 
> anyway.
> Well, perhaps it can be done better than that, with some thought. I.e. :
> 
> * block all further access to /dev/fb0, processes will wait.
> * Mark graphichs memory "not present" for any process that have it mapped,
>   so as to pagefault anyone using it directly.  (read-only is not enough,
>  processes should see the graphichs memory they expect, not
>  the kernel message)
> * Try to allocate memory for saving the screen image (assuming the
>   machine won't hang completely, it will often keep running after an oops)
> * Annoy the user by showing the message
> * Provide some way of letting the user decide when to proceed, such
>   as pressing a key
> * Restore the saved screen memory (if that allocation was successful)
> * Mark framebuffer memory present, releasing pagefaulted processes
> * Unblock /dev/fb0

Still too complex. Can't this be simplified to:

  * Don't use the kernel text output facility for anything except panics, where 
there is no point in allowing userspace applications to continue
  * Rely on userspace to display oopses and less important messages, because 
doing this from the kernel leads either to the complex procedure outlined above 
(where the policy is in the kernel, e.g., on which of the two keyboards should 
one wait for a keypress?) or to unreliable displaying of messages
  * Have a method in the framebuffer driver for clearing the screen and setting 
a known good mode, for the Linux equivalent of a "blue screen of death"

-- 
Alexander E. Patrakov

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>   * Have a method in the framebuffer driver for clearing the screen and setting
> a known good mode, for the Linux equivalent of a "blue screen of death"

You can't change the mode, instead you have to track it and use the
one that is already set. Changing the mode on a lot of cards that we
don't have docs for requires making BIOS calls using VM86. VM86 only
runs from user space and user space may be dead when you want to
print. WIndows can take a different approach since they have access to
the video hardware docs.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Alexander E. Patrakov]

Jon Smirl wrote:
> You can't change the mode, instead you have to track it and use the
> one that is already set.

OK, this doesn't change my other point: use in-kernel text output facility for 
panics only.

-- 
Alexander E. Patrakov

Re: OpenGL-based framebuffer concepts

[Matheus Izvekov]

On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
> Jon Smirl wrote:
> > You can't change the mode, instead you have to track it and use the
> > one that is already set.
>
> OK, this doesn't change my other point: use in-kernel text output facility for
> panics only.
>

It would be a good idea to allow oopses to be shown too. For example,
your main disk controller driver may oops, and then you have no way to
tell what happened, because if you try to run dmesg it may deadlock,
and obviously the oops message wont be logged either.
So a BSOD which allows you to hit enter to continue after an oops is
not a bad idea.

Re: OpenGL-based framebuffer concepts

[Alexander E. Patrakov]

Matheus Izvekov wrote:
> On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>> Jon Smirl wrote:
>> > You can't change the mode, instead you have to track it and use the
>> > one that is already set.
>>
>> OK, this doesn't change my other point: use in-kernel text output 
>> facility for
>> panics only.
>>
> 
> It would be a good idea to allow oopses to be shown too. For example,
> your main disk controller driver may oops, and then you have no way to
> tell what happened, because if you try to run dmesg it may deadlock,
> and obviously the oops message wont be logged either.
> So a BSOD which allows you to hit enter to continue after an oops is
> not a bad idea.

Now suppose this.

The kernel has to save the video memory contents somewhereto restore it after 
pressing Enter. This may swap something out. Whoops, swap is on that failed disk.

Or: lock the memory in advance, to avoid the use of swap. But this is not better 
than doing the same thing from a userspace application that shows a pop-up 
ballon with the contents of this oops. And it won't be affected by a disk 
failure, because it has everything already in memory.

-- 
Alexander E. Patrakov

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
> The kernel has to save the video memory contents somewhereto restore it after
> pressing Enter. This may swap something out. Whoops, swap is on that failed disk.
>
> Or: lock the memory in advance, to avoid the use of swap. But this is not better
> than doing the same thing from a userspace application that shows a pop-up
> ballon with the contents of this oops. And it won't be affected by a disk
> failure, because it has everything already in memory.

Most video hardware (99%) has enough memory to support double
buffering. You save it to the other buffer, display the error, and
copy it back on enter.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Alexander E. Patrakov]

Jon Smirl wrote:
> Most video hardware (99%) has enough memory to support double
> buffering. You save it to the other buffer, display the error, and
> copy it back on enter.

This is possible only if the video memory management is in the kernel. Reason: 
userspace may also want to use double buffering, and we definitely want to 
allocate the "other (maybe third) buffer" somewhere in the free video memory. 
And allocating a lot of system RAM on oops seems to be a very bad idea (cascade 
of oopses may follow).

Also, did anyone measure the video RAM usage during a typical Xgl session (i.e.: 
is there really enough free video RAM, not occupied by various caches)?

Although, a Microsoft-ish "lost context, please redraw" solution has been 
already proposed.

-- 
Alexander E. Patrakov

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 26 May 2006 04:57, Alexander E. Patrakov wrote:
> Jon Smirl wrote:
> > Most video hardware (99%) has enough memory to support double
> > buffering. You save it to the other buffer, display the error, and
> > copy it back on enter.
>
> This is possible only if the video memory management is in the kernel.
> Reason: userspace may also want to use double buffering, and we definitely
> want to allocate the "other (maybe third) buffer" somewhere in the free
> video memory. And allocating a lot of system RAM on oops seems to be a very
> bad idea (cascade of oopses may follow).
>
> Also, did anyone measure the video RAM usage during a typical Xgl session
> (i.e.: is there really enough free video RAM, not occupied by various
> caches)?
>
> Although, a Microsoft-ish "lost context, please redraw" solution has been
> already proposed.

In the case of an oops or a panic the system might not be stable enough to 
continue operation.  In fact, I have never had a system experience either and 
still be able to run - even at the console.

In such a case, I think it'd be preferable to overwrite any graphics mode 
currently in use to display the data.  However, there must be some control on 
this, to prevent people from arbitrarily killing the video mode to display 
data.  In any event, seeing the huge ideological split and the inability of 
the people involved with this discussion to agree on a single, clear path for 
the graphics system to take...

Let me put it this way: I may write code for free, but I don't write code 
unless theres a design to it. I joined this conversation to toss a few ideas 
off the top of my head out there and see if any were useful. This has become 
something of a very genial flame war... 

Over the next couple of days I'll work on a few design ideas for a replacement 
to the current, somewhat poorly done graphics core in Linux and post them for 
comments. These will hopefully cover all sides of the currently seen 
ideological split as well as one or two that hopefully span the split.

All of them will be open for comment and revision, and if one of them is 
ultimately agreed on, I'll start work on it. If not, then I'll go back to 
just watching the traffic and hoping someone will finally start fixing the 
problems in the graphics systems.

DRH

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Jon Smirl wrote:
>>
>> Or: lock the memory in advance, to avoid the use of swap. But this is 
>> not better
>> than doing the same thing from a userspace application that shows a 
>> pop-up
>> ballon with the contents of this oops. And it won't be affected by a 
>> disk
>> failure, because it has everything already in memory.
>
> Most video hardware (99%) has enough memory to support double
> buffering. You save it to the other buffer, display the error, and
> copy it back on enter.
Graphichs memory and double buffering is nice, which is why it might
already be in use when the panic happens.  Overwriting
someone elses double buffers or fonts or textures is even worse
than overwriting the display. The latter is usually sort of fixable
with a few alt+tabs. . .

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Matheus Izvekov]

On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
> Now suppose this.
>
> The kernel has to save the video memory contents somewhereto restore it after
> pressing Enter. This may swap something out. Whoops, swap is on that failed disk.
>
> Or: lock the memory in advance, to avoid the use of swap. But this is not better
> than doing the same thing from a userspace application that shows a pop-up
> ballon with the contents of this oops. And it won't be affected by a disk
> failure, because it has everything already in memory.

If you have enough video memory, you may use that to save the contents
of the screen.
If you dont, then save it in main memory. if you dont have space
there, then i guess not saving the contents is acceptable.

Re: OpenGL-based framebuffer concepts

[Xavier Bestel]

Le mercredi 24 mai 2006 à 22:26 +0600, Alexander E. Patrakov a écrit :
> Now suppose this.
> 
> The kernel has to save the video memory contents somewhereto restore it after 
> pressing Enter. This may swap something out. Whoops, swap is on that failed disk.
> 
> Or: lock the memory in advance, to avoid the use of swap. But this is not better 
> than doing the same thing from a userspace application that shows a pop-up 
> ballon with the contents of this oops. And it won't be affected by a disk 
> failure, because it has everything already in memory.

Don't save the framebuffer. Just send a message to the client
application saying "fb is corrupted, please redraw". X11 can do it,
console can do it.

	Xav

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Xavier Bestel wrote:
> Don't save the framebuffer. Just send a message to the client
> application saying "fb is corrupted, please redraw". X11 can do it,
> console can do it.
>   
Sure, X has no problem doing an expose event on the entire screen.
But then the kernel would need a way to tell X that the display
was invalidated outside its control.  Is there even an
API for that today?

The problem isn't trivial, for the machine may be running
quite a few xservers.  Or some other sort of software
that uses the framebuffer.  (libsvga, y, berlin, ...)

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Xavier Bestel]

On Fri, 2006-05-26 at 09:05, Helge Hafting wrote:
> Xavier Bestel wrote:
> > Don't save the framebuffer. Just send a message to the client
> > application saying "fb is corrupted, please redraw". X11 can do it,
> > console can do it.
> >   
> Sure, X has no problem doing an expose event on the entire screen.
> But then the kernel would need a way to tell X that the display
> was invalidated outside its control.  Is there even an
> API for that today?
> 
> The problem isn't trivial, for the machine may be running
> quite a few xservers.  Or some other sort of software
> that uses the framebuffer.  (libsvga, y, berlin, ...)

I'd say send something simple (SIGWINCH?) to all apps opening fbdev, and
for legacy apps (e.g. current Xorg) use an userspace helper listening to
this signal and sending X (or Y or Berlin) an expose event (perhaps
after waiting for the proper input device, depending on some policy).

Otherwise I like much your other idea of allocating memory by freeing
non-dirty pages if possible, but that doesn't solve the problem that the
restoration of the previous state (or the expose event) has to wait for
user input or a timeout or something. That kind of decision belongs to
userspace.

	Xav

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Alexander E. Patrakov wrote:
> Matheus Izvekov wrote:
>> On 5/24/06, Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>>> Jon Smirl wrote:
>>> > You can't change the mode, instead you have to track it and use the
>>> > one that is already set.
>>>
>>> OK, this doesn't change my other point: use in-kernel text output 
>>> facility for
>>> panics only.
>>>
>>
>> It would be a good idea to allow oopses to be shown too. For example,
>> your main disk controller driver may oops, and then you have no way to
>> tell what happened, because if you try to run dmesg it may deadlock,
>> and obviously the oops message wont be logged either.
>> So a BSOD which allows you to hit enter to continue after an oops is
>> not a bad idea.
>
> Now suppose this.
>
> The kernel has to save the video memory contents somewhereto restore 
> it after pressing Enter. This may swap something out. Whoops, swap is 
> on that failed disk.
No.  The kernel _tries_ to allocate memory for saving the screen, but
using routines that allocates memory immediately without waiting
for swapout.  (i.e. just use the free memory pools, and possibly discarding
non-dirty pages.) 

If this allocation fails, which it may do, just overwrite graphichs memory
anyway and loose the display contents.  The machine is in trouble anyway.


Helge Hafting

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 13:55, Alexander E. Patrakov wrote:
> Helge Hafting wrote:
> > Now, a panic/oops message is sure better than a silent hang, but that's
> > it, really.
> > Anything less than that should just go in a logfile where the admin can
> > look
> > it up later.  The very ability to write on the console will alway be
> > abused by some application programmer or kernel driver module vendor.
> > Blindly writing on the console won't be very useful either, the user
> > might be running a game or video which overwrites the message within
> > 1/30s anyway.
> > Well, perhaps it can be done better than that, with some thought. I.e. :
> >
> > * block all further access to /dev/fb0, processes will wait.
> > * Mark graphichs memory "not present" for any process that have it
> > mapped, so as to pagefault anyone using it directly.  (read-only is not
> > enough, processes should see the graphichs memory they expect, not
> >  the kernel message)
> > * Try to allocate memory for saving the screen image (assuming the
> >   machine won't hang completely, it will often keep running after an
> > oops) * Annoy the user by showing the message
> > * Provide some way of letting the user decide when to proceed, such
> >   as pressing a key
> > * Restore the saved screen memory (if that allocation was successful)
> > * Mark framebuffer memory present, releasing pagefaulted processes
> > * Unblock /dev/fb0
>
> Still too complex. Can't this be simplified to:
>
>   * Don't use the kernel text output facility for anything except panics,
> where there is no point in allowing userspace applications to continue
>   * Rely on userspace to display oopses and less important messages,
> because doing this from the kernel leads either to the complex procedure
> outlined above (where the policy is in the kernel, e.g., on which of the
> two keyboards should one wait for a keypress?) or to unreliable displaying
> of messages
>   * Have a method in the framebuffer driver for clearing the screen and
> setting a known good mode, for the Linux equivalent of a "blue screen of
> death"

Exactly - this is what I had planned on doing. Let userspace handle all other 
types of errors, as a panic is the only thing that should leave the kernel 
itself unstable.

The setting of a "known good" mode is also simple - just swap the card back to 
the boot video mode and clear the screen.

DRH

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Alexander E. Patrakov wrote:
> Helge Hafting wrote:
>> Now, a panic/oops message is sure better than a silent hang, but 
>> that's it, really.
>> Anything less than that should just go in a logfile where the admin 
>> can look
>> it up later.  The very ability to write on the console will alway be 
>> abused
>> by some application programmer or kernel driver module vendor.
>> Blindly writing on the console won't be very useful either, the user 
>> might
>> be running a game or video which overwrites the message within 1/30s 
>> anyway.
>> Well, perhaps it can be done better than that, with some thought. I.e. :
>>
>> * block all further access to /dev/fb0, processes will wait.
>> * Mark graphichs memory "not present" for any process that have it 
>> mapped,
>>   so as to pagefault anyone using it directly.  (read-only is not 
>> enough,
>>  processes should see the graphichs memory they expect, not
>>  the kernel message)
>> * Try to allocate memory for saving the screen image (assuming the
>>   machine won't hang completely, it will often keep running after an 
>> oops)
>> * Annoy the user by showing the message
>> * Provide some way of letting the user decide when to proceed, such
>>   as pressing a key
>> * Restore the saved screen memory (if that allocation was successful)
>> * Mark framebuffer memory present, releasing pagefaulted processes
>> * Unblock /dev/fb0
>
> Still too complex. 
Sure - which is why I sort of hope it won't happen.
> Can't this be simplified to:
>
>  * Don't use the kernel text output facility for anything except 
> panics, where there is no point in allowing userspace applications to 
> continue
That's an option, of course.
>  * Rely on userspace to display oopses and less important messages, 
> because doing this from the kernel leads either to the complex 
> procedure outlined above (where the policy is in the kernel, e.g., on 
> which of the two keyboards should one wait for a keypress?) or to 
> unreliable displaying of messages
"Which of the two keyboards to read, which of the three screens to use
for messages" is not a problem.  The kernel would use whatever devices
is associated with the primary console - any extra devices would be left 
alone.
The console is normally one particular keyboard (or possibly all of them),
and /dev/fb0 in case of graphical console.  Other framebuffers are
not the primary console. 

Someone with a network console or printer console should get their message
there instead - assuming the subsystems in question still works.

>  * Have a method in the framebuffer driver for clearing the screen and 
> setting a known good mode, for the Linux equivalent of a "blue screen 
> of death"
Those are there already, if you're using a framebuffer device driver 
that is.

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Alexander E. Patrakov]

Helge Hafting wrote:
> "Which of the two keyboards to read, which of the three screens to use
> for messages" is not a problem.  The kernel would use whatever devices
> is associated with the primary console - any extra devices would be left 
> alone.
> The console is normally one particular keyboard (or possibly all of them),
> and /dev/fb0 in case of graphical console.  Other framebuffers are
> not the primary console.

I am not sure how this can be achievable, assuming that udev is responsible for 
loading framebuffer modules. Since it loads them in parallel, the registration 
order is essentially random. See the following Debian bugs about other subsystems:

http://bugs.debian.org/339951
http://bugs.debian.org/365226

-- 
Alexander E. Patrakov

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Alexander E. Patrakov wrote:
> Helge Hafting wrote:
>> "Which of the two keyboards to read, which of the three screens to use
>> for messages" is not a problem.  The kernel would use whatever devices
>> is associated with the primary console - any extra devices would be 
>> left alone.
>> The console is normally one particular keyboard (or possibly all of 
>> them),
>> and /dev/fb0 in case of graphical console.  Other framebuffers are
>> not the primary console.
>
> I am not sure how this can be achievable, assuming that udev is 
> responsible for loading framebuffer modules. Since it loads them in 
> parallel, the registration order is essentially random. See the 
> following Debian bugs about other subsystems:
So what?  In that case, it is essentially random _which_ display you
get your PANIC on, but you will get it on one of them.

Of course this case is easily fixed by loading the preferred
framebuffer driver before running udev.  That way, it grabs
/dev/fb0 before anything else.

Helge Hafting

Re: OpenGL-based framebuffer concepts

[Xavier Bestel]

On Fri, 2006-05-26 at 12:58, Helge Hafting wrote:
> Alexander E. Patrakov wrote:
> > Helge Hafting wrote:
> >> "Which of the two keyboards to read, which of the three screens to use
> >> for messages" is not a problem.  The kernel would use whatever devices
> >> is associated with the primary console - any extra devices would be 
> >> left alone.
> >> The console is normally one particular keyboard (or possibly all of 
> >> them),
> >> and /dev/fb0 in case of graphical console.  Other framebuffers are
> >> not the primary console.
> >
> > I am not sure how this can be achievable, assuming that udev is 
> > responsible for loading framebuffer modules. Since it loads them in 
> > parallel, the registration order is essentially random. See the 
> > following Debian bugs about other subsystems:
> So what?  In that case, it is essentially random _which_ display you
> get your PANIC on, but you will get it on one of them.
> 
> Of course this case is easily fixed by loading the preferred
> framebuffer driver before running udev.  That way, it grabs
> /dev/fb0 before anything else.

Well, the oops/panic should probably be displayed on all fbdevs anyway.

	Xav

Re: OpenGL-based framebuffer concepts

[Geert Uytterhoeven]

On Wed, 24 May 2006, Helge Hafting wrote:
> Kyle Moffett wrote:
> > The one really significant potential problem with the exo-kernel model for
> > graphics is that the kernel *must* have a stable way to display kernel
> > panics regardless of current video mode, framebuffer settings, 3D rendering,
> > etc.  The kernel driver should be able to provide some fundamental
> > operations for compositing text on top of the framebuffer at the primary
> > viewport regardless of whatever changes userspace makes to the GPU
> > configuration.  We don't have this now, but I see it as an absolute
> > requirement for any replacement graphics system.  This means that the kernel
> > driver should be able to understand and modify the entire GPU state to the
> > extent necessary for such a text console.
> I am not so sure I want this at all.
> In the early 90's, I used unix machines wich did exactly this - spamming the
> framebuffer console with occational messages while X was running.
> Yuck yuck yuck yuck yuck .  .  .

And the funny thing is that Linux used to do this as well ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: OpenGL-based framebuffer concepts

[Alan Cox]

On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
> generation graphics system, I'd be interested in ideas on a new or  
> modified /dev/fbX device that offers native OpenGL rendering  
> support.  Someone once mentioned OpenGL ES as a possibility as it  

So for a low end video card you want to put a full software opengl es
stack into the kernel including the rendering loops which tend to be
large and slow, or dynamically generated code ?

> framebuffer.  There would also need to be a way for userspace to trap  
> and emulate or ignore unsupported OpenGL commands.  

That would be most of them for a lot of chips because the hardware can
only do "most" of the work, eg using software fixups after a rendering
command or splitting GL commands into a chain of simpler ones as Mesa
does. All large code.

> effort.  Given that sort of support, a rootless xserver would be a  
> fairly trivial wrapper over whatever underlying implementation there  
> was.

You mean move the X server from being root (privileged) to kernel (even
more privileged) and pray there are no bugs in it ?

Bits of the model are right - look at DRI for some (perhaps not pretty)
evidence of that. Clearly the kernel needs to control the GPU, DMA and
access to buffers. It isn't clear anything higher level belongs anywhere
but user space.

Alan

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Alan Cox wrote:
> On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
>> generation graphics system, I'd be interested in ideas on a new or  
>> modified /dev/fbX device that offers native OpenGL rendering  
>> support.  Someone once mentioned OpenGL ES as a possibility as it  
> 
> So for a low end video card you want to put a full software opengl es
> stack into the kernel including the rendering loops which tend to be
> large and slow, or dynamically generated code ?

Indeed, consider the extent of that phrase "dynamically generated code."

To do modern OpenGL (mostly fragment and vertex shaders), you basically 
must have a compiler front-end (C-like language), a code generator (JIT) 
backend for your architecture (x86, x86-64, ...), and a code generator 
backend for your GPU.

Further, as Keith Whitwell and others have rightly pointed out, a modern 
GPU needs such advanced resource management that the X server (or 
whatever driver) essentially becomes a _multi-tasking scheduler_. 
Consider the case of two resource-hungry 3D processes rendering to the 
same X11 screen, and you'll see why a GPU scheduler is needed.

Modern graphics is highly aligned with the Cell processor programming 
model:  shipping specialized binary code elsewhere, to be remotely executed.

OTOH, I think a perfect video driver would be in kernel space, and do

* delivery of GPU commands from userspace to hardware, hopefully via 
zero-copy DMA.  For older cards without a true instruction set, "GPU 
commands" simply means userspace prepares hardware register 
read/write/test commands, and blasts the sequence to hardware at the 
appropriate moment (a la S3 Savage's BCI).
* delivery of bytecode commands (faux GPU commands) from userspace to 
kernel to hardware.  Much like today's ioctls, but much more efficient 
delivery.  Used for mode switching commands, basic monitor management 
commands, and other not-vendor-specific operations that belong in the 
kernel.
* interrupt and DMA handling
* multi-context, multi-thread GPU resource scheduler (2D/3D context 
switching is lumped in here too)
* suspend and resume

and nothing else.

	Jeff

Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On May 23, 2006, at 06:28:40, Jeff Garzik wrote:
> Alan Cox wrote:
>> On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
>>> generation graphics system, I'd be interested in ideas on a new  
>>> or  modified /dev/fbX device that offers native OpenGL rendering   
>>> support.  Someone once mentioned OpenGL ES as a possibility as it
>>
>> So for a low end video card you want to put a full software opengl  
>> es stack into the kernel including the rendering loops which tend  
>> to be large and slow, or dynamically generated code ?

First of all, absolutely not.  I stated elsewhere in the email:
> There would also need to be a way for userspace to trap and emulate  
> or ignore unsupported OpenGL commands.

A GPU which does not support OpenGL at all would look virtually  
identical to the current framebuffer model.  If it does support a few  
2D-acceleration features, those should be exported through a similar  
but distinct interface.  Using 3D on a GPU would trigger something  
like the following series of events:

During boot:
1)  Userspace software renderer connects to a GL-framebuffer device  
first, determines device capabilities, and installs OpenGL traps for  
all unsupported operations that it can software-render (may be none).
2)  Window-server connects to a subset of the available GL- 
framebuffer and input devices.

At client start:
1)  Client connects to the window-server via TCP or UNIX socket.
2)  If client is over UNIX socket, it receives specially-configured  
open filehandles to the graphics device and mmaps those or performs  
other operations via them, otherwise it sends and receives commands  
and textures over the socket and the window-server does those  
operations locally.

For each rendering operation (either directly via filehandle or  
indirectly through TCP to window-server):
1)  Client program loads texture into mapped texture memory  
"allocated from the GPU" (may actually be system RAM, depending on  
card capabilities and memory utilization).
2)  Client program sends OpenGL commands through kernel framebuffer  
device.
3)  Kernel either passes the OpenGL commands to the GPU or if they  
were trapped by the software renderer it passes them to that, which  
can emulate them using more primitive operations.

IMHO, the way it should work is the kernel should export "rendering  
contexts" to which a single client can connect (EX: software  
renderer, window-server, The GIMP, etc).  By default the kernel would  
export a single rendering context associated with the actual display  
device as a whole.  A client can then use kernel calls to subdivide  
its rendering context to other clients such that the client can  
choose between trapping OpenGL calls, passing them up the stack, or  
pre-rendering them to a texture.  This would allow the kernel to  
manage CPU and GPU time, memory (it could "swap" data out from the  
GPU to system RAM if necessary).  If no parent-client trapped a given  
OpenGL command and it was unsupported by the GPU then the kernel  
would return an error to the originating client.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[Alan Cox]

On Maw, 2006-05-23 at 10:10 -0400, Kyle Moffett wrote:
> A GPU which does not support OpenGL at all would look virtually  

No GPU today "supports" OpenGL

> 2)  Client program sends OpenGL commands through kernel framebuffer  
> device.
> 3)  Kernel either passes the OpenGL commands to the GPU or if they  
> were trapped by the software renderer it passes them to that, which  
> can emulate them using more primitive operations.

You've no idea how a GPU works have you ?

The process generally goes something like this.

I build an OpenGL rendering context.
The supporting library JITs an engine which implements this rendering
context and pipeline. Only a JIT is really fast enough because there are
so many tests are otherwise involved.

Each poly is fired down the JIT engine which produces a mix of
	- AGP command streams
	- GPU bytecodes
	- Polygon breakdowns which go back into the engine
		(eg for clips the chip can't do)
	- Texture loads and swaps

The GPU view of the universe is far far from the OpenGL one. With the
possible exception of the big 3D Labs cards anyway.

Alan

Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On May 23, 2006, at 10:43:53, Alan Cox wrote:
> You've no idea how a GPU works have you ?
>
> [snipped eloquent description of how wrong I was]
>
> The GPU view of the universe is far far from the OpenGL one. With  
> the possible exception of the big 3D Labs cards anyway.

Not really, no.  My understanding is basically client-only, aside  
from looking at the Open Graphics Project prototype rendering model a  
bit.  As far as I can see from the discussions and models publicly  
available they are targeting a certain OpenGL standard for their  
card, although I can see I must have misunderstood what that really  
means.

So a modern GPU is essentially a proprietary CPU with an obscure  
instruction set and lots of specialized texel hardware?  Given the  
total lack of documentation from either ATI or NVidia about such  
cards I'd guess it's impossible for Linux to provide any kind of  
reasonable 3d engine for that kind of environment, and it might be  
better to target a design like the Open Graphics Project is working  
to provide.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[Alan Cox]

On Maw, 2006-05-23 at 11:41 -0400, Kyle Moffett wrote:
> So a modern GPU is essentially a proprietary CPU with an obscure  
> instruction set and lots of specialized texel hardware?  Given the  
> total lack of documentation from either ATI or NVidia about such  
> cards I'd guess it's impossible for Linux to provide any kind of  
> reasonable 3d engine for that kind of environment, and it might be  
> better to target a design like the Open Graphics Project is working  
> to provide.

Its typically a device you feed a series of fairly low level rendering
commands to sometimes including instructions (eg shaders). DRI provides
an interface that is chip dependant but typically looks like


      [User provided command buffer]
                    |
      [Kernel filtering/DMA interface]
                    |
      [Card command queue processing]


All the higher level graphic work is done in the 3D client itself.

Re: OpenGL-based framebuffer concepts

[Xiong Jiang]

---------- Forwarded message ----------
From: Xiong Jiang <linuster@gmail.com>
Date: May 23, 2006 10:15 AM
Subject: Re: OpenGL-based framebuffer concepts
To: Alan Cox <alan@lxorguk.ukuu.org.uk>


What about initialization, mode and context switching? From the
discussion I thought that people would like to see X server and
framebuffer console could coexist in a more coordinated way, which
could be coordinated DRI in kernel.

Agreed that kernel should only deal with necessary tasks as minimum as
possible. 2D/3D engine in user mode and the reorg of Xserver/APIs
around the engine is the thing people are discussing.

Designing the interface inevitably involves clear understanding of the
hardware capabilities and closed hardware spec is an obvious obstacle.
Open Graphics card (when becoming available) would be a great thing
and I wish a great X run it to its full strength.

It's a little offtopic for this list but, it's an interface between
kernel and user mode so both the Xorg and this mailing list would see
a lot discussion on it. I am glad to see such discussion is happening.

Of course a lot of education is needed for me to discuss such, with
the wish that a better X / GUI running on modern graphics hardware is
desirable for everyone.

Regards,

On 5/23/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2006-05-23 at 11:41 -0400, Kyle Moffett wrote:
> > So a modern GPU is essentially a proprietary CPU with an obscure
> > instruction set and lots of specialized texel hardware?  Given the
> > total lack of documentation from either ATI or NVidia about such
> > cards I'd guess it's impossible for Linux to provide any kind of
> > reasonable 3d engine for that kind of environment, and it might be
> > better to target a design like the Open Graphics Project is working
> > to provide.
>
> Its typically a device you feed a series of fairly low level rendering
> commands to sometimes including instructions (eg shaders). DRI provides
> an interface that is chip dependant but typically looks like
>
>
>      [User provided command buffer]
>                    |
>      [Kernel filtering/DMA interface]
>                    |
>      [Card command queue processing]
>
>
> All the higher level graphic work is done in the 3D client itself.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: OpenGL-based framebuffer concepts

[Alan Cox]

On Maw, 2006-05-23 at 10:21 -0700, Xiong Jiang wrote:
> What about initialization, mode and context switching? From the
> discussion I thought that people would like to see X server and
> framebuffer console could coexist in a more coordinated way, which
> could be coordinated DRI in kernel.


There has been some discussion of this in the past and it appears to
make a lot more sense. Really it needs bits of the driver model
reworking.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 23 May 2006 16:53, Alan Cox wrote:
> On Maw, 2006-05-23 at 11:41 -0400, Kyle Moffett wrote:
> > So a modern GPU is essentially a proprietary CPU with an obscure
> > instruction set and lots of specialized texel hardware?  Given the
> > total lack of documentation from either ATI or NVidia about such
> > cards I'd guess it's impossible for Linux to provide any kind of
> > reasonable 3d engine for that kind of environment, and it might be
> > better to target a design like the Open Graphics Project is working
> > to provide.
>
> Its typically a device you feed a series of fairly low level rendering
> commands to sometimes including instructions (eg shaders). DRI provides
> an interface that is chip dependant but typically looks like
>
>
>       [User provided command buffer]
>
>       [Kernel filtering/DMA interface]
>
>       [Card command queue processing]
>
>
> All the higher level graphic work is done in the 3D client itself.

Exactly! Alans above explanation is exactly why I proposed merging DRM with 
the framebuffer drivers. However, a day later and some new information 
received, it would be better to change the framebuffer system to use DRM as a 
backend where it's possible.

DRH

Re: OpenGL-based framebuffer concepts

[Rene Rebe]

Hi,

On Tuesday 23 May 2006 16:43, Alan Cox wrote:
> The GPU view of the universe is far far from the OpenGL one. With the
> possible exception of the big 3D Labs cards anyway.

And some sgi such as the Odyssey aka. VPro.

Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://exactcode.de | http://t2-project.org | http://rebe.name
            +49 (0)30 / 255 897 45

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 23 May 2006 10:28, Jeff Garzik wrote:
> Alan Cox wrote:
> > On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
> >> generation graphics system, I'd be interested in ideas on a new or
> >> modified /dev/fbX device that offers native OpenGL rendering
> >> support.  Someone once mentioned OpenGL ES as a possibility as it
> >
> > So for a low end video card you want to put a full software opengl es
> > stack into the kernel including the rendering loops which tend to be
> > large and slow, or dynamically generated code ?
>
> Indeed, consider the extent of that phrase "dynamically generated code."
>
> To do modern OpenGL (mostly fragment and vertex shaders), you basically
> must have a compiler front-end (C-like language), a code generator (JIT)
> backend for your architecture (x86, x86-64, ...), and a code generator
> backend for your GPU.
>
> Further, as Keith Whitwell and others have rightly pointed out, a modern
> GPU needs such advanced resource management that the X server (or
> whatever driver) essentially becomes a _multi-tasking scheduler_.
> Consider the case of two resource-hungry 3D processes rendering to the
> same X11 screen, and you'll see why a GPU scheduler is needed.
>
> Modern graphics is highly aligned with the Cell processor programming
> model:  shipping specialized binary code elsewhere, to be remotely
> executed.
>
> OTOH, I think a perfect video driver would be in kernel space, and do
>
> * delivery of GPU commands from userspace to hardware, hopefully via
> zero-copy DMA.  For older cards without a true instruction set, "GPU
> commands" simply means userspace prepares hardware register
> read/write/test commands, and blasts the sequence to hardware at the
> appropriate moment (a la S3 Savage's BCI).
> * delivery of bytecode commands (faux GPU commands) from userspace to
> kernel to hardware.  Much like today's ioctls, but much more efficient
> delivery.  Used for mode switching commands, basic monitor management
> commands, and other not-vendor-specific operations that belong in the
> kernel.
> * interrupt and DMA handling
> * multi-context, multi-thread GPU resource scheduler (2D/3D context
> switching is lumped in here too)
> * suspend and resume
>
> and nothing else.

Thanks for this list. Looks like if I'm going to do any code writing it won't 
be solo, because a lot of this stuff  - mostly the scheduler and interrupt 
handling - is way over my head. (However, I will try to learn and will be 
doing even more research when I get to the point where this is needed to be 
done)

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/23/06, Jeff Garzik <jeff@garzik.org> wrote:
> OTOH, I think a perfect video driver would be in kernel space, and do
>
> * delivery of GPU commands from userspace to hardware, hopefully via
> zero-copy DMA.  For older cards without a true instruction set, "GPU
> commands" simply means userspace prepares hardware register
> read/write/test commands, and blasts the sequence to hardware at the
> appropriate moment (a la S3 Savage's BCI).

You have to security check those commands in the kernel driver to keep
normal users from using the GPU to do nasty things. Users can only
play with memory that they own and no ones else's.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Jon Smirl wrote:
> On 5/23/06, Jeff Garzik <jeff@garzik.org> wrote:
>> OTOH, I think a perfect video driver would be in kernel space, and do
>>
>> * delivery of GPU commands from userspace to hardware, hopefully via
>> zero-copy DMA.  For older cards without a true instruction set, "GPU
>> commands" simply means userspace prepares hardware register
>> read/write/test commands, and blasts the sequence to hardware at the
>> appropriate moment (a la S3 Savage's BCI).
> 
> You have to security check those commands in the kernel driver to keep
> normal users from using the GPU to do nasty things. Users can only
> play with memory that they own and no ones else's.

Obviously.

	Jeff

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 23 May 2006 10:11, Alan Cox wrote:
> On Maw, 2006-05-23 at 01:08 -0400, Kyle Moffett wrote:
> > generation graphics system, I'd be interested in ideas on a new or
> > modified /dev/fbX device that offers native OpenGL rendering
> > support.  Someone once mentioned OpenGL ES as a possibility as it
>
> So for a low end video card you want to put a full software opengl es
> stack into the kernel including the rendering loops which tend to be
> large and slow, or dynamically generated code ?

Agreed. Anything of the sort should be in userspace. 

> > framebuffer.  There would also need to be a way for userspace to trap
> > and emulate or ignore unsupported OpenGL commands.
>
> That would be most of them for a lot of chips because the hardware can
> only do "most" of the work, eg using software fixups after a rendering
> command or splitting GL commands into a chain of simpler ones as Mesa
> does. All large code.

Putting a full GL stack into the kernel is just plain idiotic. Among the 
suggestions I made in an initial reply to this was keeping everything 
possible in userspace adn providing only the minimum necessary stuff 
in-kernel.

Doing otherwise - providing full emulation for unsupported commands or 
features - is just copying the mistakes made by M$ with DirectX.

> > effort.  Given that sort of support, a rootless xserver would be a
> > fairly trivial wrapper over whatever underlying implementation there
> > was.
>
> You mean move the X server from being root (privileged) to kernel (even
> more privileged) and pray there are no bugs in it ?
>
> Bits of the model are right - look at DRI for some (perhaps not pretty)
> evidence of that. Clearly the kernel needs to control the GPU, DMA and
> access to buffers. It isn't clear anything higher level belongs anywhere
> but user space.

Exactly what I suggested on seeing the original post.

I am currently looking for some information or help in making the Framebuffer 
devices use DRM and setting up a userspace system that interfaces with the 
DRM backed framebuffer device to provide full 2D and 3D acceleration of all 
supported features and *userspace* emulation of the unsupported stuff.

Mesa is a good place to start for the 3D stuff, and either XAA or one of the 
numerous 2D graphics packages would be a place to start for the 2D 
acceleration.

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

>
> I am currently looking for some information or help in making the Framebuffer
> devices use DRM and setting up a userspace system that interfaces with the
> DRM backed framebuffer device to provide full 2D and 3D acceleration of all
> supported features and *userspace* emulation of the unsupported stuff.
>

The first step is to provide some sort of communication between the
DRM and fb drivers so they know the other one exists,

previous attempts at this by myself have come apart in the device
model which just plainly cannot support this without adding a couple
of dirty hacks,

The two attempts I've done, were using a vgaclass device from Alan
Cox, and also adding a lowlevel driver for the radeon, hotplug became
my major issue each time, discussions last year at Kernel Summit were
had, but the results however never surfaced, I'm intending to go to KS
this year and actually try and get Greg-KH to fix the device model for
what we need as opposed to hacking the crap out of it.

All the other designs and stuff people have mentioned have all been
discussed to death before, people seem to love discussing graphics,
but no-one seems to care about fixing it properly, in nice incremental
steps that doesn't break older systems. The current systems are very
very fixable, however there always seem to be lots of people who want
to re-write it because it is a) ugly in their opinion b) don't care
about backwards compat.

Dave.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 04:08, Dave Airlie wrote:
> > I am currently looking for some information or help in making the
> > Framebuffer devices use DRM and setting up a userspace system that
> > interfaces with the DRM backed framebuffer device to provide full 2D and
> > 3D acceleration of all supported features and *userspace* emulation of
> > the unsupported stuff.
>
> The first step is to provide some sort of communication between the
> DRM and fb drivers so they know the other one exists,
>
> previous attempts at this by myself have come apart in the device
> model which just plainly cannot support this without adding a couple
> of dirty hacks,
>
> The two attempts I've done, were using a vgaclass device from Alan
> Cox, and also adding a lowlevel driver for the radeon, hotplug became
> my major issue each time, discussions last year at Kernel Summit were
> had, but the results however never surfaced, I'm intending to go to KS
> this year and actually try and get Greg-KH to fix the device model for
> what we need as opposed to hacking the crap out of it.
>
> All the other designs and stuff people have mentioned have all been
> discussed to death before, people seem to love discussing graphics,
> but no-one seems to care about fixing it properly, in nice incremental
> steps that doesn't break older systems. The current systems are very
> very fixable, however there always seem to be lots of people who want
> to re-write it because it is a) ugly in their opinion b) don't care
> about backwards compat.
>

I'd never advocate just killing a functioning system. What I've been talking 
about is building a new system that sits alongside the existing one in the 
tree, depends on EXPERIMENTAL and BROKEN in the Kconfig system and takes the 
place of the traditional framebuffer system if someone decides to use it.

I say have it depend on BROKEN because that should keep the masses away from 
it while it's being heavily tested, and I say it should sit alongside the 
existing code and be *new* for exactly the reason you've pointed out. 
Modifying the existing systems to integrate the new technology would require 
either changing the driver model or a lot fo dirty hacks. Neither seems that 
good of an option to me.

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > All the other designs and stuff people have mentioned have all been
> > discussed to death before, people seem to love discussing graphics,
> > but no-one seems to care about fixing it properly, in nice incremental
> > steps that doesn't break older systems. The current systems are very
> > very fixable, however there always seem to be lots of people who want
> > to re-write it because it is a) ugly in their opinion b) don't care
> > about backwards compat.
> >
>
> I'd never advocate just killing a functioning system. What I've been talking
> about is building a new system that sits alongside the existing one in the
> tree, depends on EXPERIMENTAL and BROKEN in the Kconfig system and takes the
> place of the traditional framebuffer system if someone decides to use it.
>
> I say have it depend on BROKEN because that should keep the masses away from
> it while it's being heavily tested, and I say it should sit alongside the
> existing code and be *new* for exactly the reason you've pointed out.
> Modifying the existing systems to integrate the new technology would require
> either changing the driver model or a lot fo dirty hacks. Neither seems that
> good of an option to me.
>

Not going to happen at this stage I believe, while people are in NIH
mode against trying to fix the current system, we are not going to
merge a third incompatible graphics layer into the kernel, we have
enough of them to do the job, we need people to fix the current crap
not add more.

The current system is fixable, we've discussed how to fix it a number
of times, however there have never been resources to do it, we
explained to Jon on a number of occasion how we as the maintainers
felt it should be fixed, the patches he produced didn't follow the
direction we wanted, he stated "the writer decides", we stated "the
maintainers don't accept it".

Step 1: add a layer between fbdev and DRM so that they can see each other.

Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
up merged but firstly let them at least become away of each others
existence, perhaps a lowerlayer driver that handles PCI functionality.
All other Step 1s are belong to us.

I could even drop the last hack I did in some sort of patch form
somewhere, I might even have a git tree (not sure...)

Dave.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 05:14, Dave Airlie wrote:
> > > All the other designs and stuff people have mentioned have all been
> > > discussed to death before, people seem to love discussing graphics,
> > > but no-one seems to care about fixing it properly, in nice incremental
> > > steps that doesn't break older systems. The current systems are very
> > > very fixable, however there always seem to be lots of people who want
> > > to re-write it because it is a) ugly in their opinion b) don't care
> > > about backwards compat.
> >
> > I'd never advocate just killing a functioning system. What I've been
> > talking about is building a new system that sits alongside the existing
> > one in the tree, depends on EXPERIMENTAL and BROKEN in the Kconfig system
> > and takes the place of the traditional framebuffer system if someone
> > decides to use it.
> >
> > I say have it depend on BROKEN because that should keep the masses away
> > from it while it's being heavily tested, and I say it should sit
> > alongside the existing code and be *new* for exactly the reason you've
> > pointed out. Modifying the existing systems to integrate the new
> > technology would require either changing the driver model or a lot fo
> > dirty hacks. Neither seems that good of an option to me.
>
> Not going to happen at this stage I believe, while people are in NIH
> mode against trying to fix the current system, we are not going to
> merge a third incompatible graphics layer into the kernel, we have
> enough of them to do the job, we need people to fix the current crap
> not add more.
>
> The current system is fixable, we've discussed how to fix it a number
> of times, however there have never been resources to do it, we
> explained to Jon on a number of occasion how we as the maintainers
> felt it should be fixed, the patches he produced didn't follow the
> direction we wanted, he stated "the writer decides", we stated "the
> maintainers don't accept it".

Okay. In this case, is there any way you provide me with the same information?

I suggested what I have because I lack the information about what exactly is 
wrong/bad and needs to be fixed.

> Step 1: add a layer between fbdev and DRM so that they can see each other.
>
> Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> up merged but firstly let them at least become away of each others
> existence, perhaps a lowerlayer driver that handles PCI functionality.
> All other Step 1s are belong to us.

Okay. This won't be simple, won't be pretty, but I should be able to handle 
it. The problem then becomes: What exactly should this system do? A layer 
that sits on top of the PCI/AGP stuff and mediates it for DRM/fbdev? Isn't 
easy, isn't simple but I think it is possible.

Any other option though, would seem to require rebuilding a good deal of both 
DRM and fbdev, if not replacing the driver model, because of difficulties you 
have previously pointed out.

If DRM makes use of the lower-level driver, and so does fbdev, then it's 
likely possible that the system can provide the information needed to allow 
the kernel to composite error messages onto the framebuffer.

And, really, if there is a common PCI layer beneath the two graphics systems, 
they could potentially have some interaction... though to retain the capacity 
to compile DRM or fbdev out of the kernel there is no way that one could 
depend on the other. Having them intercommunicate, it seems, would require a 
third mechanism. Any pointers?

> I could even drop the last hack I did in some sort of patch form
> somewhere, I might even have a git tree (not sure...)

That might be helpful. 

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > Step 1: add a layer between fbdev and DRM so that they can see each other.
> >
> > Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> > up merged but firstly let them at least become away of each others
> > existence, perhaps a lowerlayer driver that handles PCI functionality.
> > All other Step 1s are belong to us.
>
> Okay. This won't be simple, won't be pretty, but I should be able to handle
> it. The problem then becomes: What exactly should this system do? A layer
> that sits on top of the PCI/AGP stuff and mediates it for DRM/fbdev? Isn't
> easy, isn't simple but I think it is possible.

The scope of the lower layer system isn't defined, it should be able
to do what a driver needs it to do, so this can be in the simple case
provide a flag to tell the DRM the fb driver is loaded and vice versa,
up to doing suspend/resume handling and PCI handling.  I think at the
very least it will have to do PCI handling and device model support.

> If DRM makes use of the lower-level driver, and so does fbdev, then it's
> likely possible that the system can provide the information needed to allow
> the kernel to composite error messages onto the framebuffer.

That is the theory, the DRM usually knows where X has the framebuffer.

> to compile DRM or fbdev out of the kernel there is no way that one could
> depend on the other. Having them intercommunicate, it seems, would require a
> third mechanism. Any pointers?

Yes you could move some common functionality into a lowlevel driver
which they could talk to, then compiling out either one wouldn't
matter.

> > I could even drop the last hack I did in some sort of patch form
> > somewhere, I might even have a git tree (not sure...)
>
> That might be helpful.

Okay I've put up two patches at
http://www.skynet.ie/~airlied/patches/merge/three_tier.diff
http://www.skynet.ie/~airlied/patches/merge/three_tier_2.diff

The first is from Dec 27th of last year, the other from March 24 this
year, the three_tier_2 is probably the later patch, and I think is
from some kernel like 2.6.13 or something.

Neither of these do what I wanted to do but they give a lot of ideas
on how to do it, the device model required in the end using a bus to
do this, I actually had some thoughts about it at the X.org developers
conference earlier in the year while reading LDD, but I've been
swamped since and probably won't get back to it until OLS.

Dave.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 24 May 2006 05:48, Dave Airlie wrote:
> > > Step 1: add a layer between fbdev and DRM so that they can see each
> > > other.
> > >
> > > Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> > > up merged but firstly let them at least become away of each others
> > > existence, perhaps a lowerlayer driver that handles PCI functionality.
> > > All other Step 1s are belong to us.
> >
> > Okay. This won't be simple, won't be pretty, but I should be able to
> > handle it. The problem then becomes: What exactly should this system do?
> > A layer that sits on top of the PCI/AGP stuff and mediates it for
> > DRM/fbdev? Isn't easy, isn't simple but I think it is possible.
>
> The scope of the lower layer system isn't defined, it should be able
> to do what a driver needs it to do, so this can be in the simple case
> provide a flag to tell the DRM the fb driver is loaded and vice versa,
> up to doing suspend/resume handling and PCI handling.  I think at the
> very least it will have to do PCI handling and device model support.

Ah, okay. So I'll have to open-code the lower-level to provide 
extensibility... Planned on it anyway, but was hoping to be able to try and 
keep the lower-level a bit simpler by giving it a defined role.  Not that I 
can reject a request to open-code something... It's what I try to request of 
people :)

> > If DRM makes use of the lower-level driver, and so does fbdev, then it's
> > likely possible that the system can provide the information needed to
> > allow the kernel to composite error messages onto the framebuffer.
>
> That is the theory, the DRM usually knows where X has the framebuffer.

True, but is there a way we ould pull this information from DRM? I'll have to 
take a long hard look and see.

> > to compile DRM or fbdev out of the kernel there is no way that one could
> > depend on the other. Having them intercommunicate, it seems, would
> > require a third mechanism. Any pointers?
>
> Yes you could move some common functionality into a lowlevel driver
> which they could talk to, then compiling out either one wouldn't
> matter.

Okay. Good idea.

> > > I could even drop the last hack I did in some sort of patch form
> > > somewhere, I might even have a git tree (not sure...)
> >
> > That might be helpful.
>
> Okay I've put up two patches at
> http://www.skynet.ie/~airlied/patches/merge/three_tier.diff
> http://www.skynet.ie/~airlied/patches/merge/three_tier_2.diff
>
> The first is from Dec 27th of last year, the other from March 24 this
> year, the three_tier_2 is probably the later patch, and I think is
> from some kernel like 2.6.13 or something.
>
> Neither of these do what I wanted to do but they give a lot of ideas
> on how to do it, the device model required in the end using a bus to
> do this, I actually had some thoughts about it at the X.org developers
> conference earlier in the year while reading LDD, but I've been
> swamped since and probably won't get back to it until OLS.

Okay and thank you. I'll start going through all of it tomorrow, about the 
same time I grab the latest kernel to start working on this. (My current 
limited connection wouldn't support me using GIT unless I could dedicate it 
for more than 6 hours. THis should be changing in about two months, but...)

DRH

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> > Step 1: add a layer between fbdev and DRM so that they can see each other.
> >
> > Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> > up merged but firstly let them at least become away of each others
> > existence, perhaps a lowerlayer driver that handles PCI functionality.
> > All other Step 1s are belong to us.
> 
> Okay. This won't be simple, won't be pretty, but I should be able to handle 
> it. The problem then becomes: What exactly should this system do? A layer 
> that sits on top of the PCI/AGP stuff and mediates it for DRM/fbdev? Isn't 
> easy, isn't simple but I think it is possible.
> 
> Any other option though, would seem to require rebuilding a good deal of both 
> DRM and fbdev, if not replacing the driver model, because of difficulties you 
> have previously pointed out.
> 
> If DRM makes use of the lower-level driver, and so does fbdev, then it's 
> likely possible that the system can provide the information needed to allow 
> the kernel to composite error messages onto the framebuffer.
> 
> And, really, if there is a common PCI layer beneath the two graphics systems, 
> they could potentially have some interaction... though to retain the capacity 
> to compile DRM or fbdev out of the kernel there is no way that one could 
> depend on the other. Having them intercommunicate, it seems, would require a 
> third mechanism. Any pointers?

Well, if drm and fbdev become interdependend while cleaning up... I do
not think it is too big problem.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 26 May 2006 17:53, Pavel Machek wrote:
> Hi!
>
> > > Step 1: add a layer between fbdev and DRM so that they can see each
> > > other.
> > >
> > > Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> > > up merged but firstly let them at least become away of each others
> > > existence, perhaps a lowerlayer driver that handles PCI functionality.
> > > All other Step 1s are belong to us.
> >
> > Okay. This won't be simple, won't be pretty, but I should be able to
> > handle it. The problem then becomes: What exactly should this system do?
> > A layer that sits on top of the PCI/AGP stuff and mediates it for
> > DRM/fbdev? Isn't easy, isn't simple but I think it is possible.
> >
> > Any other option though, would seem to require rebuilding a good deal of
> > both DRM and fbdev, if not replacing the driver model, because of
> > difficulties you have previously pointed out.
> >
> > If DRM makes use of the lower-level driver, and so does fbdev, then it's
> > likely possible that the system can provide the information needed to
> > allow the kernel to composite error messages onto the framebuffer.
> >
> > And, really, if there is a common PCI layer beneath the two graphics
> > systems, they could potentially have some interaction... though to retain
> > the capacity to compile DRM or fbdev out of the kernel there is no way
> > that one could depend on the other. Having them intercommunicate, it
> > seems, would require a third mechanism. Any pointers?
>
> Well, if drm and fbdev become interdependend while cleaning up... I do
> not think it is too big problem.
> 							Pavel

It's not that, it's that if DRM uses the middle layer to ask the framebuffer 
for information about the memory layout then it becomes dependant on systems 
present in the framebuffer driver. The same holds true for the framebuffer 
using DRM to provide acceleration features.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/24/06, Dave Airlie <airlied@gmail.com> wrote:
> The current system is fixable, we've discussed how to fix it a number
> of times, however there have never been resources to do it, we
> explained to Jon on a number of occasion how we as the maintainers
> felt it should be fixed, the patches he produced didn't follow the
> direction we wanted, he stated "the writer decides", we stated "the
> maintainers don't accept it".

I have done the following things...
1) Repeatedly discussed the design of the fixes in depth on the mailing lists
2) Provided extensive documentation of a path to fix the current set of problems
3) Provided numerous patches fixing various parts of the problem

But now it is a year latter and kernel graphics sits exactly where it
was a year ago. There has been zero forward progress. The X developer
obsession of reducing all OSes to a least common denominator is
clearly holding back Linux graphics support. Merging DRM and fbdev is
a win for Linux since it eliminates one of the places where two
independent drivers are trying to control the same piece of hardware.
The merging is blocked because of issues with DRM on BSD (merging
would introduce GPL code into DRM which couldn't then be ported onto
BSD without forking).

So instead of doing a merge a complicated device driver sharing bus is
being constructed

>Okay I've put up two patches at
>http://www.skynet.ie/~airlied/patches/merge/three_tier.diff
>http://www.skynet.ie/~airlied/patches/merge/three_tier_2.diff
>Neither of these do what I wanted to do but they give a lot of ideas
>on how to do it, the device model required in the end using a bus to
>do this, I actually had some thoughts about it at the X.org developers
>conference earlier in the year while reading LDD, but I've been
>swamped since and probably won't get back to it until OLS.


I'm still sticking with my core driver principles:
1) One driver per device
2) A loaded driver must mark the device in use
3) Don't touch hardware that the driver doesn't own
4) Don't use root priv to bypass OS functions
The current graphics code violates all of these

Blocking my changes has resulted in the loss of a full time developer
from an area that is woefully understaffed. I would strongly suggest
that anyone considering doing work in this area to learn from my
experience. Since acceptance of any work you do is questionable, only
work on tiny pieces. Then when your work is blocked you won't have
lost months of effort. I would recommend doing no more that a week's
work before trying to get it merged. And don't start on other changes
while waiting on results from the first one. If the first one is
blocked (likely) you don't want your second change depending on it.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> But now it is a year latter and kernel graphics sits exactly where it
> was a year ago. There has been zero forward progress. The X developer
> obsession of reducing all OSes to a least common denominator is
> clearly holding back Linux graphics support. Merging DRM and fbdev is
> a win for Linux since it eliminates one of the places where two
> independent drivers are trying to control the same piece of hardware.
> The merging is blocked because of issues with DRM on BSD (merging
> would introduce GPL code into DRM which couldn't then be ported onto
> BSD without forking).

It has absolutely nothing to do with the GPL vs BSD licensing on the
code it has to do with the belief that fbdev isn't a complete enough
model to do what needs to be done and merging it into the DRM is just
going to make things worse rather than better, I've no idea where you
ever came up with it being a licensing thing at all... the FreeBSD ppl
have on interest in taking fbdev code anyways...

Having a shared layer allows the two drivers to at least discuss the
ownership of the hardware, we have two stacks of software, merging
them into one stack isn't going to solve any magical problems, it just
means we have one larger mess, my belief is once the two can
communicate, the DRM can disable fbdev if a proper solution on top of
the DRM becomes available...  merging fbdev into the DRM is always the
wrong answer, so please stop talking.

> I'm still sticking with my core driver principles:
> 1) One driver per device
> 2) A loaded driver must mark the device in use
> 3) Don't touch hardware that the driver doesn't own
> 4) Don't use root priv to bypass OS functions
> The current graphics code violates all of these

And that's nice for you, it isn't nice in the real world where we have
two drivers driving the device and need to fix it without breaking it
first.
>
> Blocking my changes has resulted in the loss of a full time developer
> from an area that is woefully understaffed. I would strongly suggest
> that anyone considering doing work in this area to learn from my
> experience. Since acceptance of any work you do is questionable, only
> work on tiny pieces. Then when your work is blocked you won't have
> lost months of effort. I would recommend doing no more that a week's
> work before trying to get it merged. And don't start on other changes
> while waiting on results from the first one. If the first one is
> blocked (likely) you don't want your second change depending on it.

That's called working in the kernel, it's always been like that, you
seemed to think your code wasn't going to require re-writes, it did,
you didn't agree with the maintainers suggestions stating you had all
those code depending on it working like you stated.. I could go on,
but I'm just wasting more of the small amounts of time I have to work
on this stuff.

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/24/06, Dave Airlie <airlied@gmail.com> wrote:
> It has absolutely nothing to do with the GPL vs BSD licensing on the
> code it has to do with the belief that fbdev isn't a complete enough
> model to do what needs to be done and merging it into the DRM is just
> going to make things worse rather than better, I've no idea where you
> ever came up with it being a licensing thing at all... the FreeBSD ppl
> have on interest in taking fbdev code anyways...

I got giant earfuls of the BSD issue from EricA. But, Dave, you are
more reasonable than some of the other X developers so I'm not putting
blame on you. I did notice that you didn't deny the part about zero
forward progress in the kernel.

I do stand by my opinion that building a driver bus so that three
independent drivers (fbdev, DRM, XAA/EXA) can simultaneously multitask
on a single piece of hardware is not a good design. It is a political
solution, not a technical one.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

>
> I got giant earfuls of the BSD issue from EricA. But, Dave, you are
> more reasonable than some of the other X developers so I'm not putting
> blame on you. I did notice that you didn't deny the part about zero
> forward progress in the kernel.
>

Well that part is true, which is totally to do with lack of developers
working on it in the correct direction, as I said lots of us know how
to do it and what direction it needs to go, lots of us however have
lots of other things that keep us occupied that are more urgent now,
the problem is for 90% of things the current systems work, so getting
the momentum to redesign a complete system just so root can't get root
is always going to be difficult... the people who care about the 10%
haven't contributed their time other than to complain about the 10%,
which puts them in the don't care category for the people trying their
best to please the other 90% with limited resources.

> I do stand by my opinion that building a driver bus so that three
> independent drivers (fbdev, DRM, XAA/EXA) can simultaneously multitask
> on a single piece of hardware is not a good design. It is a political
> solution, not a technical one.
>

Your problem is you never listen when someone tells you, you can't
break things, your solutions all took the easy path which is to bust
fbdev or make it require DRM, which isn't what people want, there is
no politics here other than Linus stating you can't break working
systems and trying to figure out how to do it technically, of course
it is going to be more work and of course most of the work might be
thrown away in two years, but that happens a lot transition code is
very important. The amount of dirty work I've  had to do to get the
r300 stuff so that the DRM doesn't break current systems is an example
of this, you would have just said, well let them fix X, I however
cannot accept that answer.

Dave.

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Jon Smirl wrote:
> I do stand by my opinion that building a driver bus so that three
> independent drivers (fbdev, DRM, XAA/EXA) can simultaneously multitask
> on a single piece of hardware is not a good design. It is a political
> solution, not a technical one.

Strongly agreed, there.  There should be ONE hardware driver for a piece 
of hardware.  The core hardware driver should register with various 
subsystems, and use the appropriate common code libraries from there.

Just like all other Linux drivers do...

	Jeff

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

Okay... 

Seeing the explosion of posts relating to this and the ideological split I see 
here I'm now left with the undesirable job of choosing which of two contested 
paths to follow with writing the code.

The path I agree with - the "One Device - One Driver" path - seems to be 
disliked by a lot of kernel developers, and would likely see my code not 
being merged anytime in the future.

The other path - that asking for a mediation layer so multiple drivers can use 
the same device - seems to be in large favor, will likely see the code 
merged... But it requires doing something that I'm not sure is the right 
thing to do.

I've spent a good portion of the past two days pondering this and trying to 
figure out a good way to go about things, and it seems to me that the best 
idea would be to add a "third" graphics system. However, this third graphics 
system would be mostly transitional code aimed at supplanting the fbdev and 
DRM kernel code.

The goal of adding said "third system" would be to provide a minimal 
kernel-level API for interfacing with the hardware acceleration features and 
providing a userspace library for doing most of the interfacing work. 

Done properly (something I always try for) this system would supplant DRM on 
Linux by providing a built-in system for accelerating all grahpics 
applications. This system would be quite similar to ALSA in nature and 
spirit.

I'm asking for advice from the experienced people on this list for help, since 
until I have a clear picture of what the kernel needs in a "modern" graphics 
system I cannot proceed. 

DRH

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

D. Hazelton wrote:
> The goal of adding said "third system" would be to provide a minimal 
> kernel-level API for interfacing with the hardware acceleration features and 
> providing a userspace library for doing most of the interfacing work. 
> 
> Done properly (something I always try for) this system would supplant DRM on 
> Linux by providing a built-in system for accelerating all grahpics 
> applications. This system would be quite similar to ALSA in nature and 
> spirit.
> 
> I'm asking for advice from the experienced people on this list for help, since 
> until I have a clear picture of what the kernel needs in a "modern" graphics 
> system I cannot proceed. 

I really hate to be a killjoy to one who is so enthusiastic, but to be 
perfectly blunt,

* I doubt you will get much help.  From GGI to today, the world has been 
full of people who have a clear picture of where Linux graphics needs to 
be... and they never got very far.  So if you don't already have a clear 
picture, you have ever farther to go.

* You really need to already know a good deal about graphics hardware, 
old and new, before starting down this path.

* Review Dave Airlie's posts, he's been pretty spot-on in this thread. 
There needs to be a lowlevel driver that handles PCI functionality, and 
registers itself with the fbdev and DRM layers.  The fbdev/DRM 
registrations need to be aware of each other.  Once that is done, work 
will proceed more rapidly.

And mind you, _I_ am saying all this as one of the crowd who wants to 
rewrite Linux video... once I get a free year or two.  I got my start in 
kernel graphics (fbdev) ~ a decade ago, and I've followed the graphics 
world intensely even since.  However, the more realistic people will 
just re-read DaveA's posts.

The path you suggest -- a third graphics system -- is going to be 
completely ignored by everyone unless/until its so wonderful that we 
just _have_ to switch.  And given past history (GGI, ...) it will be a 
lonely path for a long time.

	Jeff

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
> * Review Dave Airlie's posts, he's been pretty spot-on in this thread.
> There needs to be a lowlevel driver that handles PCI functionality, and
> registers itself with the fbdev and DRM layers.  The fbdev/DRM
> registrations need to be aware of each other.  Once that is done, work
> will proceed more rapidly.

Controlling which driver is bound to the hardware is an easy problem
that a low level driver handles nicely. But controlling binding
doesn't really fix anything. All of the drivers binding to it still
have to duplicate all of the code for things like VRAM allocation, GPU
start/stop, mode setting, etc. That's because the second level drivers
can't count on the other drivers being loaded. The giant mess of whose
state is loaded into the hardware still exists too. Just consider the
simple problem of who EOI's an interrupt.

I would instead start by making fbdev the low level driver. DRM could
then bind to it and redundant code in DRM could be removed. 90% of the
code in fbdev is always needed.  Hopefully X could be convinced to use
the services offered by the fbdev/DRM pair. New memory management code
would be added to this base driver since everyone needs it. Fbdev
would also pick up the ability to reset secondary cards at boot.

I concede that loading both drivers will increase RAM usage slightly.
At some point it will be worth the effort to split an API
compatibility layer off from the lowlevel fbdev driver. But this is a
lot of work to get back <40K of RAM.

A related issue to this is mode setting. Initially I would leave it
alone in the fbdev code. Later it would use a collection of apps like
this. Mode setting is at the core of why X has to run as root.

|A good first project would be to start building a set of user space
|apps for doing the mode setting on each card. All of the code for
|doing this exists in the X server but it is a pain to extract. X has
|1000s of internal APIs and typedefs. You would end up with a set of
|apps that would be able to list the valid modes on each head and then
|set them. The code for achieving this is all over the map, sometimes
|we know everything needed like for the Radeon, sometimes you need to
|make a VM86 call to the BIOS to get the info (Intel). Load an fbdev
|driver and check out the current support for this in sysfs.
|
|When you get done with a command it should be a tiny app statically
|linked to klibc and have no external dependencies. These apps should
|be 30K or less in size. You probably will end up with about ten apps
|since a lot of the uncommon cards only have a standard VBE BIOS and
|will all use the same command.

Mode setting has at least these requirements...
1) Ability to be done at boot from initramfs
2) Ability for a user to change their mode without being root
3) No ability for a normal user to change the mode on hardware that
they do not own
4) Some hardware requires modes to be set using vm/emu86.
5) Monitor hotplug event needs to ensure that the new monitor receives
a valid mode
6) An interlock needs to be in place to stop simultaneous attempts to
change the mode

A key design problem is not requiring root and making sure you can't
change the mode on hardware that you don't own. This introduces the
entire concept of video hardware belonging to the logged in user.
I've written up more thoughts on this in the Kernel section of
http://jonsmirl.googlepages.com/graphics.html

I'm certainly open to any solutions that can satisfy the requirements.
Every solution that I've come up with so far is fairly complex.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Jon Smirl wrote:
> On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
>> * Review Dave Airlie's posts, he's been pretty spot-on in this thread.
>> There needs to be a lowlevel driver that handles PCI functionality, and
>> registers itself with the fbdev and DRM layers.  The fbdev/DRM
>> registrations need to be aware of each other.  Once that is done, work
>> will proceed more rapidly.
> 
> Controlling which driver is bound to the hardware is an easy problem
> that a low level driver handles nicely. But controlling binding
> doesn't really fix anything. All of the drivers binding to it still
> have to duplicate all of the code for things like VRAM allocation, GPU
> start/stop, mode setting, etc. That's because the second level drivers
> can't count on the other drivers being loaded. The giant mess of whose
> state is loaded into the hardware still exists too. Just consider the
> simple problem of who EOI's an interrupt.

In Linux, the lowlevel driver registers irq handlers, so your simple 
problem has the simple and obvious answer.  Further, reviewing my 
statement above, if fbdev/DRM are aware of each other, and if they both 
are layered on top of the lowlevel driver, then it should also be 
obvious that they are cooperatively sharing resources, not competing 
against one another.


> I would instead start by making fbdev the low level driver. DRM could
> then bind to it and redundant code in DRM could be removed. 90% of the
> code in fbdev is always needed.  Hopefully X could be convinced to use

Take your pick.  An fbdev driver is nothing but a PCI driver that 
registers itself with the fbdev subsystem.  Ditto a DRM driver, though 
the DRM and agpgart layering is royally screwed up ATM.  Regardless, he 
who codes, wins.


> the services offered by the fbdev/DRM pair. New memory management code

No "hopefully."  X must be forced to use this driver, otherwise the 
system is unworkable.


> would be added to this base driver since everyone needs it. Fbdev

If fbdev and DRM are cooperating, then obviously they will cooperate 
when managing resources.  GPU memory is but one example of a resource.


> would also pick up the ability to reset secondary cards at boot.

But if you think the kernel will grow an x86 emulator, you're dreaming. 
That's what initramfs and friends are for.

	Jeff

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
> Jon Smirl wrote:
> In Linux, the lowlevel driver registers irq handlers, so your simple
> problem has the simple and obvious answer.  Further, reviewing my
> statement above, if fbdev/DRM are aware of each other, and if they both
> are layered on top of the lowlevel driver, then it should also be
> obvious that they are cooperatively sharing resources, not competing
> against one another.
>
>
> > I would instead start by making fbdev the low level driver. DRM could
> > then bind to it and redundant code in DRM could be removed. 90% of the
> > code in fbdev is always needed.  Hopefully X could be convinced to use
>
> Take your pick.  An fbdev driver is nothing but a PCI driver that
> registers itself with the fbdev subsystem.  Ditto a DRM driver, though
> the DRM and agpgart layering is royally screwed up ATM.  Regardless, he
> who codes, wins.

There is significant architectural difference between the two schemes.
Is the base driver an absolute minimal driver that only serves as a
switch to route into the other drivers, or does the base driver
contain all the common code? I'm in the common code camp, DaveA is in
the minimal switch camp.

Take memory management for example. I think the memory manager should
go into the base driver. The other strategy is for each driver to have
their own memory manager and then the base provides a way to select
which one is active. (Note that in all cases the complex part of
memory management is running in user space).

> > the services offered by the fbdev/DRM pair. New memory management code
>
> No "hopefully."  X must be forced to use this driver, otherwise the
> system is unworkable.

I have had no success in making this happen.

> > would be added to this base driver since everyone needs it. Fbdev
>
> If fbdev and DRM are cooperating, then obviously they will cooperate
> when managing resources.  GPU memory is but one example of a resource.

What is cooperation? Is it shared code in the base coordinating a
single state in the hardware, or is it save your state, I'm switching
to another driver, now I'm loading its state. We can't achieve
agreement on this.

> > would also pick up the ability to reset secondary cards at boot.
>
> But if you think the kernel will grow an x86 emulator, you're dreaming.
> That's what initramfs and friends are for.

Depends on what you mean by the kernel growing the emulator. I don't
want to put it in the kernel binary, but I would like to see it in the
kernel tree. It would use klibc and initramfs. There are some classes
of machines that cannot get video at boot without running the ROM.
Making this part of the boot process will guarantee that all cards
have been POSTed by the time normal user space is up.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > Take your pick.  An fbdev driver is nothing but a PCI driver that
> > registers itself with the fbdev subsystem.  Ditto a DRM driver, though
> > the DRM and agpgart layering is royally screwed up ATM.  Regardless, he
> > who codes, wins.
>
> There is significant architectural difference between the two schemes.
> Is the base driver an absolute minimal driver that only serves as a
> switch to route into the other drivers, or does the base driver
> contain all the common code? I'm in the common code camp, DaveA is in
> the minimal switch camp.

You should really stop saying what I want, and look at what I did, my
code is in those patches.

What you realise after working on this from both directions is that it
doesn't matter, you just need a lowlevel layer initially, that you can
bind functionality to, the first step is to allow the DRM and fb to
become aware and communicate with each other, once you have this, you
can then start shuffling code down into the lowlevel driver, without
breaking the functionality of the fbdev or DRM drivers.

I'm not having a switch between DRM and fbdev, its not one or the
other yet, you need to learn to take small steps, we just need to
formalise the relationship between the two so that they can deal with
each other being there in a better fashion than they do currently, and
also so we can better suspend/resume support etc.

> Take memory management for example. I think the memory manager should
> go into the base driver. The other strategy is for each driver to have
> their own memory manager and then the base provides a way to select
> which one is active. (Note that in all cases the complex part of
> memory management is running in user space).

So far we have no memory management, and most of the plans I've seen
involved using a userspace system to do it, really we just want the
fbdev driver to be able to ask the DRM, so where the hell is the
frontbuffer, if the DRM is loaded and if it isn't just say I'm using
here.

> > No "hopefully."  X must be forced to use this driver, otherwise the
> > system is unworkable.
>
> I have had no success in making this happen.

And won't as long as you fight against it, we don't have to force X to
use it, we have to make it an option in X that distros turn on... we
have to let the X people keep doing their drivers the way they do
drivers... I'm still not convinced putting modesetting in kernel is at
all necessary, I think a simple MMIO parser to stop bad commands from
getting to the hardware is all we should need, modesetting normally
consists of a small number of operations.

Write register,
Read register,
Wait for something to happen (vblank, bit set in a register X times..)

I think we can write an interface via the DRM to do these, but these
are a for later thing, until the fbdev and DRM layers can communicate
it is not practical.

> What is cooperation? Is it shared code in the base coordinating a
> single state in the hardware, or is it save your state, I'm switching
> to another driver, now I'm loading its state. We can't achieve
> agreement on this.

It'll be hopefully shared-state handling I dislike the amount of
save/restore stuff we do now, however you have to remember for
suspend/resume we normally have to this anyways, so we end up having
all the save/restore code in the end.

Dave.

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Dave Airlie wrote:
> So far we have no memory management, and most of the plans I've seen
> involved using a userspace system to do it, really we just want the
> fbdev driver to be able to ask the DRM, so where the hell is the
> frontbuffer, if the DRM is loaded and if it isn't just say I'm using
> here.

The kernel will need to do some amount of arbitration, some amount of 
scheduling between competing processes.  Doing a lot of that in 
userspace seems a bit questionable.


> And won't as long as you fight against it, we don't have to force X to
> use it, we have to make it an option in X that distros turn on... we
> have to let the X people keep doing their drivers the way they do
> drivers... I'm still not convinced putting modesetting in kernel is at
> all necessary, I think a simple MMIO parser to stop bad commands from
> getting to the hardware is all we should need, modesetting normally
> consists of a small number of operations.
> 
> Write register,
> Read register,
> Wait for something to happen (vblank, bit set in a register X times..)

Kernel needs to do suspend/resume, interrupt handling, DMA mapping, ...

Further, whatever the Linux kernel chooses to do, the X server will follow.

History has proven that it is COMPLETELY BROKEN to allow X to dictate 
these basic architectural decisions.  X11's ancient and broken PCI bus 
handling is a testament to this.  Tons of polling everywhere, rather 
than cleanly handling events in interrupts, is a further testament.

If we do it right, X will follow.  As will FreeBSD and other OS's.

	Jeff

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > So far we have no memory management, and most of the plans I've seen
> > involved using a userspace system to do it, really we just want the
> > fbdev driver to be able to ask the DRM, so where the hell is the
> > frontbuffer, if the DRM is loaded and if it isn't just say I'm using
> > here.
>
> The kernel will need to do some amount of arbitration, some amount of
> scheduling between competing processes.  Doing a lot of that in
> userspace seems a bit questionable.

Oh it won't all be in userspace, but at the moment the setup component
is, so things like setting the memory pools up is, however the TG work
won't solve all the problems in the world, so we need to wait for the
big code drop and then decide what needs to be done.

>
> > And won't as long as you fight against it, we don't have to force X to
> > use it, we have to make it an option in X that distros turn on... we
> > have to let the X people keep doing their drivers the way they do
> > drivers... I'm still not convinced putting modesetting in kernel is at
> > all necessary, I think a simple MMIO parser to stop bad commands from
> > getting to the hardware is all we should need, modesetting normally
> > consists of a small number of operations.
> >
> > Write register,
> > Read register,
> > Wait for something to happen (vblank, bit set in a register X times..)
>
> Kernel needs to do suspend/resume, interrupt handling, DMA mapping, ...

Sorry I meant on top of those things, it was the modesetting I'm
suspect on, if we can "secure" modesetting I think we can leave it in
userspace.

>
> Further, whatever the Linux kernel chooses to do, the X server will follow.
>
> History has proven that it is COMPLETELY BROKEN to allow X to dictate
> these basic architectural decisions.  X11's ancient and broken PCI bus
> handling is a testament to this.  Tons of polling everywhere, rather
> than cleanly handling events in interrupts, is a further testament.
>
> If we do it right, X will follow.  As will FreeBSD and other OS's.

Exactly, Jon's problem is he tried to force X and X developers to bend
to his world view, he never realised that you don't need the X
developers to bend to your view of the world, you just present your
world view as being better and then more importantly you fix all the X
code to work with your code as well and still work in the abscence of
your code.

Dave.

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Jon Smirl wrote:
> On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
>> Jon Smirl wrote:
>> In Linux, the lowlevel driver registers irq handlers, so your simple
>> problem has the simple and obvious answer.  Further, reviewing my
>> statement above, if fbdev/DRM are aware of each other, and if they both
>> are layered on top of the lowlevel driver, then it should also be
>> obvious that they are cooperatively sharing resources, not competing
>> against one another.
>>
>>
>> > I would instead start by making fbdev the low level driver. DRM could
>> > then bind to it and redundant code in DRM could be removed. 90% of the
>> > code in fbdev is always needed.  Hopefully X could be convinced to use
>>
>> Take your pick.  An fbdev driver is nothing but a PCI driver that
>> registers itself with the fbdev subsystem.  Ditto a DRM driver, though
>> the DRM and agpgart layering is royally screwed up ATM.  Regardless, he
>> who codes, wins.
> 
> There is significant architectural difference between the two schemes.
> Is the base driver an absolute minimal driver that only serves as a
> switch to route into the other drivers, or does the base driver
> contain all the common code? I'm in the common code camp, DaveA is in
> the minimal switch camp.

You are missing that both are the same camp.  It's just different paths 
to get to the same destination.  Common code will inevitably result.


> Take memory management for example. I think the memory manager should
> go into the base driver. The other strategy is for each driver to have
> their own memory manager and then the base provides a way to select
> which one is active. (Note that in all cases the complex part of
> memory management is running in user space).

That's an implementation detail that will naturally fall out of 
fbdev/DRM cooperation.  Don't worry, it will solve itself.


>> > the services offered by the fbdev/DRM pair. New memory management code
>>
>> No "hopefully."  X must be forced to use this driver, otherwise the
>> system is unworkable.
> 
> I have had no success in making this happen.

If the code is merged into the Linux kernel, X will follow.  Its axiomatic.

	Jeff

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote:
> > There is significant architectural difference between the two schemes.
> > Is the base driver an absolute minimal driver that only serves as a
> > switch to route into the other drivers, or does the base driver
> > contain all the common code? I'm in the common code camp, DaveA is in
> > the minimal switch camp.
>
> You are missing that both are the same camp.  It's just different paths
> to get to the same destination.  Common code will inevitably result.

Given that there are 60 fbdev drivers and only 7 DRM drivers. It sure
looks easier to me to declare the fbdev drivers as being the base
driver.  But if you want to spend the time needed to split up 60 fbdev
drivers, go ahead.

But one thing I do not want to see is only splitting the 7 fbdev
drivers that correspond to the DRM ones. The net effect of that will
be to create two different fbdev architectures. If you're going to
split fbdev you have to make the same split to all of them.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Paulo Marques]

Jeff Garzik wrote:
>[...]
>> would also pick up the ability to reset secondary cards at boot.
> 
> But if you think the kernel will grow an x86 emulator, you're dreaming. 
> That's what initramfs and friends are for.

I really don't want to push the x86 emulator idea, especially when 
kernel gurus that I respect very much, such as yourself, seem to be 
against it.

It just seems awkward that everyone thinks its fine to have a 30Kb ACPI 
interpreter in the kernel that loads a DSDT and executes it, but a 30Kb 
x86 emulator that loads a video ROM and executes it is completely absurd.

Some PC's need an ACPI interpreter to function properly, some video 
cards need a x86 emulator to function properly.

Why is everyone so keen on keeping the video drivers crippled, but no 
one says "ACPI should be done from user space with user mode helpers"?

-- 
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
            Dilbert: Sanity? Reality? The laws of physics?

Re: OpenGL-based framebuffer concepts

[Alan Cox]

On Iau, 2006-05-25 at 16:57 +0100, Paulo Marques wrote:
> Why is everyone so keen on keeping the video drivers crippled, but no 
> one says "ACPI should be done from user space with user mode helpers"?

Lots of people said that, and tried and it turns out you really can't
get ACPI to fly in user space without major major hackery.

Alan

Re: OpenGL-based framebuffer concepts

[Olivier Galibert]

On Wed, May 24, 2006 at 03:14:24PM +1000, Dave Airlie wrote:
> Step 1: add a layer between fbdev and DRM so that they can see each other.

Maybe a stupid question, but what do they need to talk about in
practice?  What should be shared/communicated about in a first time?

  OG.

Re: OpenGL-based framebuffer concepts

[Greg KH]

On Wed, May 24, 2006 at 02:08:02PM +1000, Dave Airlie wrote:
> The two attempts I've done, were using a vgaclass device from Alan
> Cox, and also adding a lowlevel driver for the radeon, hotplug became
> my major issue each time, discussions last year at Kernel Summit were
> had, but the results however never surfaced, I'm intending to go to KS
> this year and actually try and get Greg-KH to fix the device model for
> what we need as opposed to hacking the crap out of it.

I think we have what you need already done + a few minor patches.  I
think a few hours of working together will be all that is needed.
Looking forward to it.

greg k-h

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >I am currently looking for some information or help in 
> >making the Framebuffer
> >devices use DRM and setting up a userspace system that 
> >interfaces with the
> >DRM backed framebuffer device to provide full 2D and 3D 
> >acceleration of all
> >supported features and *userspace* emulation of the 
> >unsupported stuff.
> 
> The first step is to provide some sort of communication 
> between the
> DRM and fb drivers so they know the other one exists,
> 
> previous attempts at this by myself have come apart in 
> the device
> model which just plainly cannot support this without 
> adding a couple
> of dirty hacks,

Could fb and drm simply be 'merged' into one driver (at least as far
as rest of system is concerned)? That should have no driver model
issues...?
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 26 May 2006 17:39, Pavel Machek wrote:
> Hi!
>
> > >I am currently looking for some information or help in
> > >making the Framebuffer
> > >devices use DRM and setting up a userspace system that
> > >interfaces with the
> > >DRM backed framebuffer device to provide full 2D and 3D
> > >acceleration of all
> > >supported features and *userspace* emulation of the
> > >unsupported stuff.
> >
> > The first step is to provide some sort of communication
> > between the
> > DRM and fb drivers so they know the other one exists,
> >
> > previous attempts at this by myself have come apart in
> > the device
> > model which just plainly cannot support this without
> > adding a couple
> > of dirty hacks,
>
> Could fb and drm simply be 'merged' into one driver (at least as far
> as rest of system is concerned)? That should have no driver model
> issues...?
> 							Pavel

And such was my original idea. However I've been informed that doing such 
would either constitute "Breaking working systems" or "introducing a third 
and unneeded driver".

For that reason I've begun doing a bit of research and planning... it might 
show fruit in a couple of days.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> On Friday 26 May 2006 17:39, Pavel Machek wrote:
> > Could fb and drm simply be 'merged' into one driver (at least as far
> > as rest of system is concerned)? That should have no driver model
> > issues...?
> >                                                       Pavel
>
> And such was my original idea. However I've been informed that doing such
> would either constitute "Breaking working systems" or "introducing a third
> and unneeded driver".
>
> For that reason I've begun doing a bit of research and planning... it might
> show fruit in a couple of days.

The simplest solution to starting a DRM/fbdev merge is to declare
fbdev the bottom layer that binds to the hardware. Doing this is easy
since the fbdev drivers already contain code for binding to the
hardware. If you don't do this and instead create a new bottom layer
that binds, you are forced into modifying the 60 existing fbdev
drivers to remove their binding code and to use the new layer. I don't
see anyone volunteering to edit 60 fbdev drivers.

DRM drivers currently works in stealth mode. They use the graphics
hardware without attaching to it like a normal PCI driver would. Using
hardware in stealth mode is a bad design, but DRM can't be modified to
attach to the PCI device because it would conflict with the fbdev
driver that is already attached.

So, the easiest way to fix this is to change the eight DRM drivers in
the kernel so that they are linked to their corresponding fbdev
driver. After these changes you would not be able to load the DRM
drivers without also loading their corresponding base fbdev driver.
The embedded people are still happy since they can load fbdev and
ignore DRM. Note that you can use symbols to create a dependency
without changing the existing functions of either driver.

Making the drivers dependent starts us down the path of a full merge
and having one driver in control of the hardware. As part of the basic
merge patch I would also move the drm directory from drivers/char/drm
to drivers/video/drm. After this very basic linkage is established you
can start making real changes.

BTW, I have already submitted a patch that does this and it was
rejected. I might be able to find it somewhere, but the dependency
code is not very hard to write.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Sunday 28 May 2006 00:03, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > On Friday 26 May 2006 17:39, Pavel Machek wrote:
> > > Could fb and drm simply be 'merged' into one driver (at least as far
> > > as rest of system is concerned)? That should have no driver model
> > > issues...?
> > >                                                       Pavel
> >
> > And such was my original idea. However I've been informed that doing such
> > would either constitute "Breaking working systems" or "introducing a
> > third and unneeded driver".
> >
> > For that reason I've begun doing a bit of research and planning... it
> > might show fruit in a couple of days.
>
> The simplest solution to starting a DRM/fbdev merge is to declare
> fbdev the bottom layer that binds to the hardware. Doing this is easy
> since the fbdev drivers already contain code for binding to the
> hardware. If you don't do this and instead create a new bottom layer
> that binds, you are forced into modifying the 60 existing fbdev
> drivers to remove their binding code and to use the new layer. I don't
> see anyone volunteering to edit 60 fbdev drivers.

Okay. This, at least, sounds like a system that should work. I was thinking of 
similar, but after the shitstorm that I saw over the idea I decided to wait 
and do some research.

> DRM drivers currently works in stealth mode. They use the graphics
> hardware without attaching to it like a normal PCI driver would. Using
> hardware in stealth mode is a bad design, but DRM can't be modified to
> attach to the PCI device because it would conflict with the fbdev
> driver that is already attached.

Yes, I noticed this while studying the DRM code. Part of me doing this, 
actually, will also be updating the DRM in kernel to the latest release. 
(Doing such provides at least one new DRM driver that already has it's X 
counterpart in the 6.8.2 tree)

> So, the easiest way to fix this is to change the eight DRM drivers in
> the kernel so that they are linked to their corresponding fbdev
> driver. After these changes you would not be able to load the DRM
> drivers without also loading their corresponding base fbdev driver.
> The embedded people are still happy since they can load fbdev and
> ignore DRM. Note that you can use symbols to create a dependency
> without changing the existing functions of either driver.

Okay. Sounds easy enough. Just need to have DRM reliant on symbols in the 
fbdev code. And you are correct about the embedded people - I'd actually 
forgotten about them when I originally made the proposal of merging DRM with 
fbdev.

> Making the drivers dependent starts us down the path of a full merge
> and having one driver in control of the hardware. As part of the basic
> merge patch I would also move the drm directory from drivers/char/drm
> to drivers/video/drm. After this very basic linkage is established you
> can start making real changes.

Fully merging fbdev with DRM would really create some problems for the 
embedded people. If the design of using the fbdev driver as a base layer and 
the DRM drivers as an acceleration layer works then that's all that's truly 
needed. Merging the DRM and fbdev code bases would create a situation where 
the embedded people would have to configure *out* the DRM code that has been 
merged into the fbdev drivers. Not only would such a thing create potential 
bugs in the system, it is a step that could create problems with people 
maintaining the .config's for those systems.

> BTW, I have already submitted a patch that does this and it was
> rejected. I might be able to find it somewhere, but the dependency
> code is not very hard to write.

If you can find it Jon, I'd appreciate it. If not, then I'll have to dive into 
the code head first and hope I don't drown in it.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> Yes, I noticed this while studying the DRM code. Part of me doing this,
> actually, will also be updating the DRM in kernel to the latest release.
> (Doing such provides at least one new DRM driver that already has it's X
> counterpart in the 6.8.2 tree)

DaveA will take care of merging drivers from CVS into the kernel tree.
Drivers that are in CVS and not in the kernel are probably there
because their DMA engines are not secure. With Direct Rendering normal
users can submit DMA commands to the GPUs. The kernel drivers check
these commands and make sure that the user isn't using the DMA
controller to play with memory that they don't own. If the DRM driver
is missing these checks it can't go into the kernel since it isn't
secure. I'd ignore DRM CVS and just play with the code in the kernel
tree.

> Fully merging fbdev with DRM would really create some problems for the
> embedded people. If the design of using the fbdev driver as a base layer and
> the DRM drivers as an acceleration layer works then that's all that's truly
> needed. Merging the DRM and fbdev code bases would create a situation where
> the embedded people would have to configure *out* the DRM code that has been
> merged into the fbdev drivers. Not only would such a thing create potential
> bugs in the system, it is a step that could create problems with people
> maintaining the .config's for those systems.

It may cause problems for some embedded people but I wouldn't worry
about them right now. If they don't like something I'm sure we'll hear
from them. Most people don't go to the expense of putting a DRM
capable chip into a system and then not use all of its capabilities.
Remember, only 8 out of the 60 fbdev drivers have DRM modules.

Worst thing that can happen is that they lose 50K of memory. Don't
spend a lot of effort worrying about this especially if no one is
complaining. Issues like this can be addressed later.


> > BTW, I have already submitted a patch that does this and it was
> > rejected. I might be able to find it somewhere, but the dependency
> > code is not very hard to write.
>
> If you can find it Jon, I'd appreciate it. If not, then I'll have to dive into
> the code head first and hope I don't drown in it.

I'll poke around and see if I can find it, but it probably wouldn't
merge anymore.  It took me less than a day to write it so it shouldn't
be too hard to recreate. Just add a do nothing function to each of the
8 fbdev drivers and then make each of the 8 DRM drivers call it. Then
adjust the include and make files until everything compiles. You're
not trying to change anything yet, you're just trying to bind them to
each other.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Sunday 28 May 2006 02:34, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > Yes, I noticed this while studying the DRM code. Part of me doing this,
> > actually, will also be updating the DRM in kernel to the latest release.
> > (Doing such provides at least one new DRM driver that already has it's X
> > counterpart in the 6.8.2 tree)
>
> DaveA will take care of merging drivers from CVS into the kernel tree.
> Drivers that are in CVS and not in the kernel are probably there
> because their DMA engines are not secure. With Direct Rendering normal
> users can submit DMA commands to the GPUs. The kernel drivers check
> these commands and make sure that the user isn't using the DMA
> controller to play with memory that they don't own. If the DRM driver
> is missing these checks it can't go into the kernel since it isn't
> secure. I'd ignore DRM CVS and just play with the code in the kernel
> tree.

Okay. Wasn't aware of any major differences in the code - in fact, I'm using 
the CVS on my machine right now. (Not that it works - I can't get *any* 
acceleration, even using binary-only drivers from the card manufacturer)

> > Fully merging fbdev with DRM would really create some problems for the
> > embedded people. If the design of using the fbdev driver as a base layer
> > and the DRM drivers as an acceleration layer works then that's all that's
> > truly needed. Merging the DRM and fbdev code bases would create a
> > situation where the embedded people would have to configure *out* the DRM
> > code that has been merged into the fbdev drivers. Not only would such a
> > thing create potential bugs in the system, it is a step that could create
> > problems with people maintaining the .config's for those systems.
>
> It may cause problems for some embedded people but I wouldn't worry
> about them right now. If they don't like something I'm sure we'll hear
> from them. Most people don't go to the expense of putting a DRM
> capable chip into a system and then not use all of its capabilities.
> Remember, only 8 out of the 60 fbdev drivers have DRM modules.
>
> Worst thing that can happen is that they lose 50K of memory. Don't
> spend a lot of effort worrying about this especially if no one is
> complaining. Issues like this can be addressed later.

Yes, however, I don't think a lot of embedded people are putting DRM capable 
chips in their machines. And I will worry about that at all points, to great 
length - I will actually fight to keep a complete merger from happening. For 
exactly the reasons I stated above.

> > > BTW, I have already submitted a patch that does this and it was
> > > rejected. I might be able to find it somewhere, but the dependency
> > > code is not very hard to write.
> >
> > If you can find it Jon, I'd appreciate it. If not, then I'll have to dive
> > into the code head first and hope I don't drown in it.
>
> I'll poke around and see if I can find it, but it probably wouldn't
> merge anymore.  It took me less than a day to write it so it shouldn't
> be too hard to recreate. Just add a do nothing function to each of the
> 8 fbdev drivers and then make each of the 8 DRM drivers call it. Then
> adjust the include and make files until everything compiles. You're
> not trying to change anything yet, you're just trying to bind them to
> each other.

Thanks.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > Fully merging fbdev with DRM would really create some problems for the
> > > embedded people. If the design of using the fbdev driver as a base layer
> > > and the DRM drivers as an acceleration layer works then that's all that's
> > > truly needed. Merging the DRM and fbdev code bases would create a
> > > situation where the embedded people would have to configure *out* the DRM
> > > code that has been merged into the fbdev drivers. Not only would such a
> > > thing create potential bugs in the system, it is a step that could create
> > > problems with people maintaining the .config's for those systems.
> >
> > It may cause problems for some embedded people but I wouldn't worry
> > about them right now. If they don't like something I'm sure we'll hear
> > from them. Most people don't go to the expense of putting a DRM
> > capable chip into a system and then not use all of its capabilities.
> > Remember, only 8 out of the 60 fbdev drivers have DRM modules.
> >
> > Worst thing that can happen is that they lose 50K of memory. Don't
> > spend a lot of effort worrying about this especially if no one is
> > complaining. Issues like this can be addressed later.
>
> Yes, however, I don't think a lot of embedded people are putting DRM capable
> chips in their machines. And I will worry about that at all points, to great
> length - I will actually fight to keep a complete merger from happening. For
> exactly the reasons I stated above.

For a specific DRM chip there are currently four modules:
fbdev-core
fbdev-chip depends on fbdev-core
drm-core
drm-chip depends on drm-core
RIght now drm and fbdev can be loaded independently.

I would always keep fbdev-core and drm-core as separate modules.  But
drm-core may become dependent on fbdev-core.

So after merging, drivers without DRM would still load exactly what
they load today. They wouldn't need to load the dependent drm-core
module. These non-DRM modules are essentially unchanged.
fbdev-core
fbdev-chip depends on fbdev-core

Merged DRM drivers can end up in one of two configurations
fbdev-core
fbdev-chip depends on fbdev-core
drm-core depends on fbdev-core
drm-chip depends on fbdev-chip, drm-core, fbdev-core

fbdev-core
drm-core depends on fbdev-core
merged-chip depends on drm-core, fbdev-core

I'm saying don't worry too much if it is more efficient to create
merged-chip for somthing like the Radeon instead of keeping fbdev-chip
and drm-chip. It is more important to get a stable functioning driver
working. If someone really complains the driver can be broken back up
at a later date (they can always use the old fbdev driver in the
meanwhile). If you spend all of your time worrying about 10K of memory
for some embedded system that may or may not use the driver, you won't
be spending enough time on getting the basic driver right.

In the new model you won't be able to load standalone DRM. That's
becuase both of those modules are now dependent on their fbdev counter
parts.
drm-core - standalone disallowed
drm-chip - standalone disallowed

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Sunday 28 May 2006 03:27, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > > Fully merging fbdev with DRM would really create some problems for
> > > > the embedded people. If the design of using the fbdev driver as a
> > > > base layer and the DRM drivers as an acceleration layer works then
> > > > that's all that's truly needed. Merging the DRM and fbdev code bases
> > > > would create a situation where the embedded people would have to
> > > > configure *out* the DRM code that has been merged into the fbdev
> > > > drivers. Not only would such a thing create potential bugs in the
> > > > system, it is a step that could create problems with people
> > > > maintaining the .config's for those systems.
> > >
> > > It may cause problems for some embedded people but I wouldn't worry
> > > about them right now. If they don't like something I'm sure we'll hear
> > > from them. Most people don't go to the expense of putting a DRM
> > > capable chip into a system and then not use all of its capabilities.
> > > Remember, only 8 out of the 60 fbdev drivers have DRM modules.
> > >
> > > Worst thing that can happen is that they lose 50K of memory. Don't
> > > spend a lot of effort worrying about this especially if no one is
> > > complaining. Issues like this can be addressed later.
> >
> > Yes, however, I don't think a lot of embedded people are putting DRM
> > capable chips in their machines. And I will worry about that at all
> > points, to great length - I will actually fight to keep a complete merger
> > from happening. For exactly the reasons I stated above.
>
> For a specific DRM chip there are currently four modules:
> fbdev-core
> fbdev-chip depends on fbdev-core
> drm-core
> drm-chip depends on drm-core
> RIght now drm and fbdev can be loaded independently.
>
> I would always keep fbdev-core and drm-core as separate modules.  But
> drm-core may become dependent on fbdev-core.

yeah, that could work. Have fbdev-core handle all PCI interactions and 
drm-core uses those functions.

> So after merging, drivers without DRM would still load exactly what
> they load today. They wouldn't need to load the dependent drm-core
> module. These non-DRM modules are essentially unchanged.
> fbdev-core
> fbdev-chip depends on fbdev-core
>
> Merged DRM drivers can end up in one of two configurations
> fbdev-core
> fbdev-chip depends on fbdev-core
> drm-core depends on fbdev-core
> drm-chip depends on fbdev-chip, drm-core, fbdev-core

Not exactly. drm-chip would depend on fbdev-chip and drm-core, which both 
depend on fbdev-core -- not a direct dependency. However, the layering model 
you present would likely keep the embedded people happy. Provided the 
drm-chip and fbdev-chip interfaces are kept seperate. Such a seperation need 
only hold true for the current generation of fbdev drivers. New drivers added 
at a later date could be unified drm/fbdev-chip modules or split, as the 
creator determines.

> fbdev-core
> drm-core depends on fbdev-core
> merged-chip depends on drm-core, fbdev-core
>
> I'm saying don't worry too much if it is more efficient to create
> merged-chip for somthing like the Radeon instead of keeping fbdev-chip
> and drm-chip. It is more important to get a stable functioning driver
> working. If someone really complains the driver can be broken back up
> at a later date (they can always use the old fbdev driver in the
> meanwhile). If you spend all of your time worrying about 10K of memory
> for some embedded system that may or may not use the driver, you won't
> be spending enough time on getting the basic driver right.

Okay. That works. I wasn't going to worry about the embedded stuff, so much as 
try to keep a clean division of things so stuff the embedded people don't 
need isn't used.

> In the new model you won't be able to load standalone DRM. That's
> becuase both of those modules are now dependent on their fbdev counter
> parts.
> drm-core - standalone disallowed
> drm-chip - standalone disallowed


DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > For a specific DRM chip there are currently four modules:
> > fbdev-core
> > fbdev-chip depends on fbdev-core
> > drm-core
> > drm-chip depends on drm-core
> > RIght now drm and fbdev can be loaded independently.
> >
> > I would always keep fbdev-core and drm-core as separate modules.  But
> > drm-core may become dependent on fbdev-core.

I've already pointed out to Jon the problems with this approach on
numerous occasions and to be honest do not have the time to do so
again,

I will not accept patches to make DRM drivers rely on fbdev drivers in
the kernel for many many many reasons, two quick ones :

a) we don't always have a fully functional fbdev driver, see intel fb drivers.
b) loading fbdev drivers breaks X in a lot of cases, we need to be a
bit more careful.
c) Lots of distros don't use fbdev drivers, forcing this on them to
use drm isn't an option.

should I go on?

I've made suggestions I've given you patches that start the work, I'm
going to finish that work, but I've no timeline, I'd hope at KS/OLS
this year to do it..

Dave.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Sunday 28 May 2006 23:13, Dave Airlie wrote:
> > > For a specific DRM chip there are currently four modules:
> > > fbdev-core
> > > fbdev-chip depends on fbdev-core
> > > drm-core
> > > drm-chip depends on drm-core
> > > RIght now drm and fbdev can be loaded independently.
> > >
> > > I would always keep fbdev-core and drm-core as separate modules.  But
> > > drm-core may become dependent on fbdev-core.
>
> I've already pointed out to Jon the problems with this approach on
> numerous occasions and to be honest do not have the time to do so
> again,
>
> I will not accept patches to make DRM drivers rely on fbdev drivers in
> the kernel for many many many reasons, two quick ones :

So it's a personal thing? God, kernel politics are starting to sicken me.

> a) we don't always have a fully functional fbdev driver, see intel fb
> drivers. 

Okay. That means the intel fbdev drivers will advance significantly through 
the process of having the DRM drivers rely on the fbdev driver as a lower 
layer. I've already started work on this and find that the current fbdev code 
does things in a strange manner, not even using the PCI bus mechanisms in the 
kernel to find the hardware.

Yes, a few drivers do this, but by and large any system currently in use will 
have it's video card on the PCI or AGP bus, including all those cards now 
being manufactured for the PCI-E systems.

Furthermore, having DRM rely on fbdev for device discovery and memory 
allocation means that the kernel, via the fbdev layer, will gain the capacity 
to flip the video mode to something sane on an oops or panic and display the 
information.

While I feel it isn't exactly necessary for an oops, having the kernel able to 
tell the user what's going on when it panics is a good thing. Doubly so for 
those panics that happen when X is running - currently that's a silent death. 
I've had to rebuild my system twice because of panics during X that killed 
various bits.

> b) loading fbdev drivers breaks X in a lot of cases, we need to be 
> a bit more careful.

Unlike what Jon says about this being a problem with X, I happen to feel this 
is more likely a problem with the way only 2 (of 60 or so) fbdev drivers find 
and bind to the hardware.

Yes, this is a strange thing to do, relying on finding the ROM of a card at a 
specific location and requiring said ROM to have certain signatures. An 
easier method is to use PCI bus discovery - pci_get_subsys() and 
pci_dev_get() - for locating the cards.

Yes, there should be an alternate probe method for systems where this won't 
work. I can't argue against that, but the current method used in most of the 
drivers should be the alternate, not the other way around.

> c) Lots of distros don't use fbdev drivers, forcing this on them to
> use drm isn't an option.

what distro's? The only ones that don't are either the ones that hold the 
users hand or the ones where the user is meant to be able to quickly change 
and modify the system.

In the first case the user is likely not going to see much of the console. But 
having fbdev act as a low-level system for those DRM drivers that fbdev 
drivers exist for (sometimes doubled or tripled - like the case of DRM-CVS's 
nv driver and the nvidiafb and rivafb drivers and sometimes not) is a step 
towards fully modernizing the linux graphics system and bringing it back to a 
"one device, one driver" system that should exist.

> should I go on?
>
> I've made suggestions I've given you patches that start the work, I'm
> going to finish that work, but I've no timeline, I'd hope at KS/OLS
> this year to do it..
>
> Dave.

I'm using those patches and a lot of sweat as a guide for turning the fbdev 
core layer for graphics drivers. This solves a lot of the complexity of a 
middle-layer because the fbdev core layer is going to do nothing more than 
handle device discovery, device DMA and such things. The fbdev chip drivers 
and the DRM system will use it as the backbone and a way of 
cross-communicating.

In such a case as where a DRM chip driver and an fbdev chip driver both exist 
for a piece of hardware, the DRM driver will use facilities exposed in the 
fbdev chip driver to function. Yes, binding the DRM chip driver like that 
will force distro's to support the fbdev system, but the conflicts you 
mention above will disappear because the systems now know the other exists 
and don't do things that the other doesn't know about.

I'm sure any patches I produce will get NACK'd by you because of some arcane 
kernel politics, but after witnessing this shitstorm and letting myself get 
talked into the work after just tossing out a few ideas I really could care 
less. Something needs to be done, has been needed to be done since the 
fbdev/DRM split appeared and nobody is doing it.

I've got a hell of a lot of free time right now, I'm so totally bored wityh my 
private projects it's not funny and this is something to keep me busy for a 
long time. You fdon't like it? Fine - but at least look at it for the code 
and it's merits - because I don't deal with people that will let their 
personal feelings get in the way of their judgement.

DRH
(and yes, I am a bit pissed off. Deal with it.)

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > numerous occasions and to be honest do not have the time to do so
> > again,
> >
> > I will not accept patches to make DRM drivers rely on fbdev drivers in
> > the kernel for many many many reasons, two quick ones :
>
> So it's a personal thing? God, kernel politics are starting to sicken me.

Dude, calm down, this isn't about any kernel politics, I see you've
been talking to Jon off-thread if I had to guess..

Jon is trying to force something into the kernel that no-one wanted
then, an no-one wants now, he is the one playing politics, we've
described a perfectly workable solution a number of times.

We all agree that "one driver for one piece of hardware" is the ideal,
unfortunately sometimes you have to take a view of the way things are,
and forcing the DRM on top of the fbdev drivers is not the way to do
it, not alone will I NACK the patches I'm pretty sure no other kernel
maintainer is going to try and put them in.

> Okay. That means the intel fbdev drivers will advance significantly through
> the process of having the DRM drivers rely on the fbdev driver as a lower
> layer. I've already started work on this and find that the current fbdev code
> does things in a strange manner, not even using the PCI bus mechanisms in the
> kernel to find the hardware.

No they won't. the intel fbdev drivers can only progress via
information from Intel on how their cards work, all the wishing the
world on your part won't help that. From my point of view I've already
done a lot of work on the intelfb drivers just to get them into a
state for EGL on i915.

> Yes, a few drivers do this, but by and large any system currently in use will
> have it's video card on the PCI or AGP bus, including all those cards now
> being manufactured for the PCI-E systems.

Lots of the world isn't a PCI device, and of the 60 fbdev drivers that
Jon relishes in mentioning (at least 5 times in this thread so far), a
lot of them are for arcane hw that needs an fbdev driver to show
anything.... these don't need to be worked on, they are old drivers,
if someone wants to pick them up they can, we just make sure they
still work. THERE IS NO NEED TO PORT 60 DRIVERS, Jon just likes saying
numbers to discourage one course of action over another....

>
> > b) loading fbdev drivers breaks X in a lot of cases, we need to be
> > a bit more careful.
>
> Unlike what Jon says about this being a problem with X, I happen to feel this
> is more likely a problem with the way only 2 (of 60 or so) fbdev drivers find
> and bind to the hardware.

no I'm sorry you've been listening to Jon, the kernel fbdev drivers on
x86 are generally very very difficult to get working in all situations
, and while you may claim that is fixable it would be a pretty major
regression over what we have so no-one will accept it.

> Yes, this is a strange thing to do, relying on finding the ROM of a card at a
> specific location and requiring said ROM to have certain signatures. An
> easier method is to use PCI bus discovery - pci_get_subsys() and
> pci_dev_get() - for locating the cards.

ISA? SBUS? NUBUS? should I go on? have you got a copy of Linux Device
Drivers v3 at least to read?

Look I don't care how pissed off or not you are, I've got a job to do
in the real world and maintaining this stuff is just part-time
work.... I'm telling you what is acceptable in the kernel from my
point of view and the point-of-view of a number of kernel developers
that I've discussed this with over the past 2 years, Jon's view isn't
acceptable otherwise we would have accepted his patches.

There is no reason for the DRM to live on top of fbdev and any
attempts to make it live there will not be accepted by me into the
DRM, for technical reasons not whatever reasons Jon wants to use
(licensing, political etc..). If you can convince Andrew or Linus or
Antonio (the fbdev maintainer) to accept your patches I'll work with
them, but we've been over this at Kernel Summit last year we all
agreed on the way forward, it hasn't moved due to manpower not due to
clarity of direction. Jon just further obscures the directional
clarity by getting involved at all and I'd thank him to please stop,
his world view is not correctly aligned with the actual world in this
area.

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/28/06, D. Hazelton <dhazelton@enter.net> wrote:
> Okay. That means the intel fbdev drivers will advance significantly through
> the process of having the DRM drivers rely on the fbdev driver as a lower
> layer. I've already started work on this and find that the current fbdev code
> does things in a strange manner, not even using the PCI bus mechanisms in the
> kernel to find the hardware.

Most of the fbdev drivers use the PCI bus mechanism to find their
hardware. Some of the ones that don't run in boxes that don't have a
PCI bus. I don't know of any PCI based fbdev drivers not using the PCI
support, what is an example of one?

> > b) loading fbdev drivers breaks X in a lot of cases, we need to be
> > a bit more careful.
>
> Unlike what Jon says about this being a problem with X, I happen to feel this
> is more likely a problem with the way only 2 (of 60 or so) fbdev drivers find
> and bind to the hardware.

It a problem with X because shouldn't be messing with hardware
controlled by a device driver loaded by the kernel. My choice of
kernel device drivers I have loaded should not break X if X was
obeying the rules.

> Yes, this is a strange thing to do, relying on finding the ROM of a card at a
> specific location and requiring said ROM to have certain signatures. An
> easier method is to use PCI bus discovery - pci_get_subsys() and
> pci_dev_get() - for locating the cards.

The DRM modules don't use PCI support for locating their cards.
Instead they use a convoluted scheme where the X server tell them
which cards to bind to. The fbdev drivers should be using the normal
PCI system.

Look in include/pci.h, there is an API for accessing the ROMs. The
signature is verified just to make sure that the right ROM was found.
That check only fails when your hardware is messed up. There are three
(sti, matrox, sis) fbdev drivers directly manipulating their ROM when
they should be using the ROM API.
http://bugzilla.kernel.org/show_bug.cgi?id=6572 Look at the radeon
driver for an example.

Don't use the code in DRM CVS that loops over the PCI devices checking
to see if they are bound or not. That code was only there as a way to
work around fbdev, merging with fbdev eliminates the need for it.

> In such a case as where a DRM chip driver and an fbdev chip driver both exist
> for a piece of hardware, the DRM driver will use facilities exposed in the
> fbdev chip driver to function. Yes, binding the DRM chip driver like that
> will force distro's to support the fbdev system, but the conflicts you
> mention above will disappear because the systems now know the other exists
> and don't do things that the other doesn't know about.

This is accurate, the problems are caused by the various drivers
conflicting. Get rid of multiple drivers and the conflicts go away.

> I'm sure any patches I produce will get NACK'd by you because of some arcane
> kernel politics, but after witnessing this shitstorm and letting myself get
> talked into the work after just tossing out a few ideas I really could care
> less. Something needs to be done, has been needed to be done since the
> fbdev/DRM split appeared and nobody is doing it.

Historically fbdev existed first and DRM came along later so they have
always been split. The OS independent model of X and DRM made sense in
the 90s, but now Linux has advanced to the point where this no longer
makes sense. It's time to update our thinking on how video works.

> I've got a hell of a lot of free time right now, I'm so totally bored wityh my
> private projects it's not funny and this is something to keep me busy for a
> long time. You fdon't like it? Fine - but at least look at it for the code
> and it's merits - because I don't deal with people that will let their
> personal feelings get in the way of their judgement.

There is plenty of work to do on graphics and lots of flame wars too.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Monday 29 May 2006 04:05, Jon Smirl wrote:
> On 5/28/06, D. Hazelton <dhazelton@enter.net> wrote:
> > Okay. That means the intel fbdev drivers will advance significantly
> > through the process of having the DRM drivers rely on the fbdev driver as
> > a lower layer. I've already started work on this and find that the
> > current fbdev code does things in a strange manner, not even using the
> > PCI bus mechanisms in the kernel to find the hardware.
>
> Most of the fbdev drivers use the PCI bus mechanism to find their
> hardware. Some of the ones that don't run in boxes that don't have a
> PCI bus. I don't know of any PCI based fbdev drivers not using the PCI
> support, what is an example of one?


Radeon, Riva, Nvidia... Shall I continue? I've only found 2 that actually use 
the PCI binding calls like "pci_get_subsys()" and "pci_dev_get()"

> > > b) loading fbdev drivers breaks X in a lot of cases, we need to be
> > > a bit more careful.
> >
> > Unlike what Jon says about this being a problem with X, I happen to feel
> > this is more likely a problem with the way only 2 (of 60 or so) fbdev
> > drivers find and bind to the hardware.
>
> It a problem with X because shouldn't be messing with hardware
> controlled by a device driver loaded by the kernel. My choice of
> kernel device drivers I have loaded should not break X if X was
> obeying the rules.

As noted above, only 2 of the fbdev drivers (that I've grepped the soruce of) 
actually use the PCI subsystem calls such as "pci_get_subsys()" and 
"pci_dev_get()"

> > Yes, this is a strange thing to do, relying on finding the ROM of a card
> > at a specific location and requiring said ROM to have certain signatures.
> > An easier method is to use PCI bus discovery - pci_get_subsys() and
> > pci_dev_get() - for locating the cards.
>
> The DRM modules don't use PCI support for locating their cards.
> Instead they use a convoluted scheme where the X server tell them
> which cards to bind to. The fbdev drivers should be using the normal
> PCI system.

Incorrect. In the DRI code currently in the 2.6.16.18 kernel the DRM modules 
use "pci_find_subsys()" and "pci_dev_get()" to locate the devices in a 
system.

> Look in include/pci.h, there is an API for accessing the ROMs. The
> signature is verified just to make sure that the right ROM was found.
> That check only fails when your hardware is messed up. There are three
> (sti, matrox, sis) fbdev drivers directly manipulating their ROM when
> they should be using the ROM API.
> http://bugzilla.kernel.org/show_bug.cgi?id=6572 Look at the radeon
> driver for an example.
>
> Don't use the code in DRM CVS that loops over the PCI devices checking
> to see if they are bound or not. That code was only there as a way to
> work around fbdev, merging with fbdev eliminates the need for it.
>
> > In such a case as where a DRM chip driver and an fbdev chip driver both
> > exist for a piece of hardware, the DRM driver will use facilities exposed
> > in the fbdev chip driver to function. Yes, binding the DRM chip driver
> > like that will force distro's to support the fbdev system, but the
> > conflicts you mention above will disappear because the systems now know
> > the other exists and don't do things that the other doesn't know about.
>
> This is accurate, the problems are caused by the various drivers
> conflicting. Get rid of multiple drivers and the conflicts go away.

Same difference, Jon.

> > I'm sure any patches I produce will get NACK'd by you because of some
> > arcane kernel politics, but after witnessing this shitstorm and letting
> > myself get talked into the work after just tossing out a few ideas I
> > really could care less. Something needs to be done, has been needed to be
> > done since the fbdev/DRM split appeared and nobody is doing it.
>
> Historically fbdev existed first and DRM came along later so they have
> always been split. The OS independent model of X and DRM made sense in
> the 90s, but now Linux has advanced to the point where this no longer
> makes sense. It's time to update our thinking on how video works.

I know, but I wasn't going to point this out to people on LKML who should 
already know things like this.

> > I've got a hell of a lot of free time right now, I'm so totally bored
> > wityh my private projects it's not funny and this is something to keep me
> > busy for a long time. You fdon't like it? Fine - but at least look at it
> > for the code and it's merits - because I don't deal with people that will
> > let their personal feelings get in the way of their judgement.
>
> There is plenty of work to do on graphics and lots of flame wars too.

Not by me. I give up - nothing I might do stands a smowballs chance in hell of 
surviving in a recognizable form  through the web of kernel politics.

DRH

Re: OpenGL-based framebuffer concepts

[Neil Brown]

On Monday May 29, dhazelton@enter.net wrote:
> >
> > There is plenty of work to do on graphics and lots of flame wars too.
> 
> Not by me. I give up - nothing I might do stands a smowballs chance in hell of 
> surviving in a recognizable form  through the web of kernel politics.

I must say I find that quite disappointing.
It seemed like you had the background knowledge, the enthusiasm and
the time to make something happen here, and I think everyone agrees
that something needs to happen.

You seem to be caught at an impasse between Jon and Dave without a
clear idea who is "right" - I know I have no clear idea!  I suspect
that they are both right and are both wrong, but figuring which bit is
which will be tricky.  Very.

And we really have no tie-breaker mechanism in the kernel - I know
Linus is very loathe to play that role.  Negotiation, compromise, and
persistence are what is needed.

I suspect that to make progress you will have to start out by doing
something that you don't completely agree with.  But that doesn't need
to be a loss.  It will be both a learning experience and a credibility
earning exercise.

Maybe if you are really genuine about putting effort into this we
should see if something can be arranged to get you to the
kernel-summit so that you, Jon, and Dave can yell at each other for a
while and come to some understanding:-)

Anyway, while I personal cannot offer you any incentives I would
implore you: don't give up.  At least not yet.

NeilBrown

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Monday 29 May 2006 04:58, Neil Brown wrote:
> On Monday May 29, dhazelton@enter.net wrote:
> > > There is plenty of work to do on graphics and lots of flame wars too.
> >
> > Not by me. I give up - nothing I might do stands a smowballs chance in
> > hell of surviving in a recognizable form  through the web of kernel
> > politics.
>
> I must say I find that quite disappointing.
> It seemed like you had the background knowledge, the enthusiasm and
> the time to make something happen here, and I think everyone agrees
> that something needs to happen.

Yes, it seems everyone does agree that it needs to happen. However, nobody can 
give me a *sane* reason why there should be two drivers for a piece of 
hardware in the kernel when, like my original proposal, those drivers could 
exist in userspace and a small core of functionality could sit in the kernel.

And since I've had DaveA and several others insult me in various rather 
diplomatic ways (Sorry, Dave, but it is true) I see no reason why I should 
waste my time doing work that is just going to be rejected whether I do it 
their way or not.

> You seem to be caught at an impasse between Jon and Dave without a
> clear idea who is "right" - I know I have no clear idea!  I suspect
> that they are both right and are both wrong, but figuring which bit is
> which will be tricky.  Very.

Where I'm caught at is my personal ethic when it comes to code and the 
requirement, stated through Dave, that a broken model must be maintained.

> And we really have no tie-breaker mechanism in the kernel - I know
> Linus is very loathe to play that role.  Negotiation, compromise, and
> persistence are what is needed.

I've tried to compromise. I dropped my arguments about having 90% of the 
driver out of the kernel except in a rhetorical sense, agreed that a new 
lower or middle layer that could mediate between fbdev and DRM is needed and 
found a way to implement it by creating a common base of code shared between 
the two. From that common base I could then implement the mediation 
functionality.

Unfortunately I was told "No, that's not the way we want it done" - even 
though it does exactly what Dave originally told me had to be done.

> I suspect that to make progress you will have to start out by doing
> something that you don't completely agree with.  But that doesn't need
> to be a loss.  It will be both a learning experience and a credibility
> earning exercise.

I don't completely agree with what I started doing. To me there should never 
be more than one active driver for any given device in a system. Yet the code 
I was working on when I finally gave up would have allowed any number of 
drivers to use the same piece of hardware at the same time.

> Maybe if you are really genuine about putting effort into this we
> should see if something can be arranged to get you to the
> kernel-summit so that you, Jon, and Dave can yell at each other for a
> while and come to some understanding:-)

That would be nice. But I'm afraid I'd just wind up walking out and leaving. 
Jon doesn't strike me as the type to compromise about anything, Dave seems to 
think he's right about everything no matter what and I've spent my life 
avoiding having discussions with people like that.

If I hadn't already deleted the work I'd finished I'd attach a patch of what 
I'd finished to this mail. But it's not in my nature to hang onto code for 
projects I've abandoned.

> Anyway, while I personal cannot offer you any incentives I would
> implore you: don't give up.  At least not yet.

Neil, Thank you for the vote of confidence, but I can tell when my help isn't 
wanted. 

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

>
> And we really have no tie-breaker mechanism in the kernel - I know
> Linus is very loathe to play that role.  Negotiation, compromise, and
> persistence are what is needed.
>
> I suspect that to make progress you will have to start out by doing
> something that you don't completely agree with.  But that doesn't need
> to be a loss.  It will be both a learning experience and a credibility
> earning exercise.
>
> Maybe if you are really genuine about putting effort into this we
> should see if something can be arranged to get you to the
> kernel-summit so that you, Jon, and Dave can yell at each other for a
> while and come to some understanding:-)

We did this at last years Kernel Summit :-)

When I state these views they are not all my own, they are the
aggregate of a number of developers who were at KS last year and a few
we've talked to since.

Dave.

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Monday 29 May 2006 05:14, Dave Airlie wrote:
> > And we really have no tie-breaker mechanism in the kernel - I know
> > Linus is very loathe to play that role.  Negotiation, compromise, and
> > persistence are what is needed.
> >
> > I suspect that to make progress you will have to start out by doing
> > something that you don't completely agree with.  But that doesn't need
> > to be a loss.  It will be both a learning experience and a credibility
> > earning exercise.
> >
> > Maybe if you are really genuine about putting effort into this we
> > should see if something can be arranged to get you to the
> > kernel-summit so that you, Jon, and Dave can yell at each other for a
> > while and come to some understanding:-)
>
> We did this at last years Kernel Summit :-)
>
> When I state these views they are not all my own, they are the
> aggregate of a number of developers who were at KS last year and a few
> we've talked to since.

I'd be willing to think about restoring a working code tree and starting over 
if you have notes and/or minutes of the KS discussion and any talks that have 
happened since.

This way I can get a clear picture of exactly what people want done regardless 
of what I feel needs to be or should be done.

DRH

Re: OpenGL-based framebuffer concepts

[Neil Brown]

On Monday May 29, airlied@gmail.com wrote:
> >
> > And we really have no tie-breaker mechanism in the kernel - I know
> > Linus is very loathe to play that role.  Negotiation, compromise, and
> > persistence are what is needed.
> >
> > I suspect that to make progress you will have to start out by doing
> > something that you don't completely agree with.  But that doesn't need
> > to be a loss.  It will be both a learning experience and a credibility
> > earning exercise.
> >
> > Maybe if you are really genuine about putting effort into this we
> > should see if something can be arranged to get you to the
> > kernel-summit so that you, Jon, and Dave can yell at each other for a
> > while and come to some understanding:-)
> 
> We did this at last years Kernel Summit :-)

Apparently.  The difference would be that this time there is someone
who claims to have the time and interest to actually do something,
which doesn't seem to have been the case last year.  I would hate to
see that offer wasted.

> 
> When I state these views they are not all my own, they are the
> aggregate of a number of developers who were at KS last year and a few
> we've talked to since.

I don't doubt it.  
But I can see that Mr Hazelton (I cannot seem to find a first name,
and I hope I'm offending by assuming it is a Mr...) is in a difficult
position, despite good intentions on all side.  I was looking for a way
to short-circuit the 'politics'.

NeilBrown

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> >
> > Most of the fbdev drivers use the PCI bus mechanism to find their
> > hardware. Some of the ones that don't run in boxes that don't have a
> > PCI bus. I don't know of any PCI based fbdev drivers not using the PCI
> > support, what is an example of one?
>
>
> Radeon, Riva, Nvidia... Shall I continue? I've only found 2 that actually use
> the PCI binding calls like "pci_get_subsys()" and "pci_dev_get()"

Earlier I asked if you had a copy of LDD v3 for a reason, you seemed
to take this as a direct insult or something like that... please take
a look at the LDD chapter on PCI device drivers, see how the
pci_register_driver and struct pci_driver work in order to register
devices, the pci_get_subsys and stuff is old code.

All the important fb drivers use the correct PCI interface.

The DRM uses the incorrect interface in-tree, and in CVS has both.

I really think you've somehow taken things a bit personally, which
might be understandable, but by the standards of some of the flame
wars on this list, this thread is tame in the least...

Dave.

Re: OpenGL-based framebuffer concepts

[Jan Engelhardt]

>
>> c) Lots of distros don't use fbdev drivers, forcing this on them to
>> use drm isn't an option.
>
>what distro's? The only ones that don't are either the ones that hold the 
>users hand or the ones where the user is meant to be able to quickly change 
>and modify the system.
>
As long as I can continue to use 80x25 or any of the "pure text modes"
(vga=scan boot option says more) without loading any FB/DRM, I am satisfied :)



Jan Engelhardt
-- 

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 31 May 2006 21:42, Jan Engelhardt wrote:
> >> c) Lots of distros don't use fbdev drivers, forcing this on them to
> >> use drm isn't an option.
> >
> >what distro's? The only ones that don't are either the ones that hold the
> >users hand or the ones where the user is meant to be able to quickly
> > change and modify the system.
>
> As long as I can continue to use 80x25 or any of the "pure text modes"
> (vga=scan boot option says more) without loading any FB/DRM, I am satisfied
> :)
>
>
>
> Jan Engelhardt

Jan, I don't plan on forcing fbdev/DRM on anyone. My work is going to leave 
vgacon alone, and if my work at making DRM and FBdev cooperate goes as 
planned, those two will remain independant, though part of my work aims at 
having fbdev provide all 2D graphics acceleration for DRM while DRM handles 
the 3D stuff via the Mesa libraries or similar.

DRH

Re: OpenGL-based framebuffer concepts

[Jan Engelhardt]

>> As long as I can continue to use 80x25 or any of the "pure text modes"
>> (vga=scan boot option says more) without loading any FB/DRM, I am satisfied
>
>Jan, I don't plan on forcing fbdev/DRM on anyone. My work is going to leave 
>vgacon alone, and if my work at making DRM and FBdev cooperate goes as 
>planned, those two will remain independant, though part of my work aims at 
>having fbdev provide all 2D graphics acceleration for DRM while DRM handles 
>the 3D stuff via the Mesa libraries or similar.
>
That sounds acceptable.

But current vesafb is slower, noticable with scrolling as in `ls -Rl /`.
Does it lack 2D acceleration?


Jan Engelhardt
-- 

Re: OpenGL-based framebuffer concepts

[Marko M]

Sure it is. I mean, it uses only VESA (extended VGA) registers and
doesn't know anything about present bliters, backend scalers or
similar hw features, AFAIK.

I think DirectFB guy have right approach, only they do it from user
space. fbdev should be capable of detecting present chip(s) and load
appropriate (acceleration) module, which describes hardware more
precisely.

If there is no specific (fbdev) driver module for your gfx then
everything should work with generic (VESA) one, though it would be
somewhat slower.

On 6/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> As long as I can continue to use 80x25 or any of the "pure text modes"
> >> (vga=scan boot option says more) without loading any FB/DRM, I am satisfied
> >
> >Jan, I don't plan on forcing fbdev/DRM on anyone. My work is going to leave
> >vgacon alone, and if my work at making DRM and FBdev cooperate goes as
> >planned, those two will remain independant, though part of my work aims at
> >having fbdev provide all 2D graphics acceleration for DRM while DRM handles
> >the 3D stuff via the Mesa libraries or similar.
> >
> That sounds acceptable.
>
> But current vesafb is slower, noticable with scrolling as in `ls -Rl /`.
> Does it lack 2D acceleration?
>
>
> Jan Engelhardt
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Thursday 01 June 2006 11:51, Marko M wrote:
> Sure it is. I mean, it uses only VESA (extended VGA) registers and
> doesn't know anything about present bliters, backend scalers or
> similar hw features, AFAIK.
>
> I think DirectFB guy have right approach, only they do it from user
> space. fbdev should be capable of detecting present chip(s) and load
> appropriate (acceleration) module, which describes hardware more
> precisely.
>
> If there is no specific (fbdev) driver module for your gfx then
> everything should work with generic (VESA) one, though it would be
> somewhat slower.

(Ewww, top-posting!)

Anyway, this method is what drmcon is going to do. For fbdev the plan is to 
make it a very minimal driver under most circumstances, and capable of being 
told to shut down so that the drmcon that I am working on can take over.

Jon makes a good point about daemons being able to get killed by the OOM 
killer. However, because drmcon is going to provide the full DRI capacity to 
userspace, having tons of helpers that need to be launched for various tasks 
isn't a good choice. Sure X could retain it's own DRI system and not require 
the helpers or whatever, but what of an app written using Qt or GTK that runs 
on the console rather than under X?

Such an application would continuously be using the 2D acceleration features 
(which will all be merged into DRM) - having to start the helpers for every 
acceleration call would be stupid. By providing a daemon to do the work we 
simplify things immensely.

And in the case that the daemon is killed (for any reason) the console itself 
should survive, since it doesn't need the daemon to run. What will die is the 
application that depends on it... Yes, that isn't good, but it's better than 
the whole system coming down. And since the OOM killer does provide an error 
message that nominally hits the console, the user will know what occurred.

DRH

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jan Engelhardt wrote:
>>> As long as I can continue to use 80x25 or any of the "pure text modes"
>>> (vga=scan boot option says more) without loading any FB/DRM, I am satisfied
>> Jan, I don't plan on forcing fbdev/DRM on anyone. My work is going to leave 
>> vgacon alone, and if my work at making DRM and FBdev cooperate goes as 
>> planned, those two will remain independant, though part of my work aims at 
>> having fbdev provide all 2D graphics acceleration for DRM while DRM handles 
>> the 3D stuff via the Mesa libraries or similar.
>>
> That sounds acceptable.
> 
> But current vesafb is slower, noticable with scrolling as in `ls -Rl /`.
> Does it lack 2D acceleration?

No, vesafb does not support console acceleration.

If you use x86_32, adding video=vesafb:ypan,mtrr:3 in your boot option will
help.  Also using the lowest color depth will also help.

Tony 

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/28/06, Dave Airlie <airlied@gmail.com> wrote:
> I've already pointed out to Jon the problems with this approach on
> numerous occasions and to be honest do not have the time to do so
> again,
>
> I will not accept patches to make DRM drivers rely on fbdev drivers in
> the kernel for many many many reasons, two quick ones :

Hence we will have no forward progress in kernel graphics for the next
few decades.

>
> a) we don't always have a fully functional fbdev driver, see intel fb drivers.

Binding the drivers to each other does not cause any code to be called
in either driver. This is just the first step down a long path to
making the merged drivers work.

> b) loading fbdev drivers breaks X in a lot of cases, we need to be a
> bit more careful.

It is perfectly legal to load an fbdev driver with X today. If it
doesn't work it is a bug in X and should be fixed.

> c) Lots of distros don't use fbdev drivers, forcing this on them to
> use drm isn't an option.

Why isn't this an option? Will the distros that insist on continuing
to ship three conflicting video drivers fighting over a single piece
of hardware please stand up and be counted? Distros get new drivers
all the time, why will this be any different?

> should I go on?

yes

You do realize that in a merged fbdev/DRM driver that if the mode
setting code is pushed into a user space library (I've said that would
be part of the path to a fully merged driver) that there really isn't
much left to a fbdev driver besides the binding and initialization
code.

> I've made suggestions I've given you patches that start the work, I'm
> going to finish that work, but I've no timeline, I'd hope at KS/OLS
> this year to do it..

In your scheme the 60 existing fbdev drivers need to be edited to
remove their code that binds them to the hardware and make them use a
new low level driver. Are you signing up to edit all of these drivers?
I'll shut up when I see a tested patch that edits all 60 drivers and
make them use the new layer. My fear is that half the fbdev drivers
will get adjusted and no one will get around to fixing the rest,
effectively creating two fbdev architectures. A complete patch would
address that concern.

BTW, I've done patches that touched all of those drivers and it is a
very painful process. Be prepared to work on code for every
architecture supported by Linux.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Sun, May 28, 2006 at 08:59:19PM -0400, Jon Smirl wrote:
> On 5/28/06, Dave Airlie <airlied@gmail.com> wrote:
> >c) Lots of distros don't use fbdev drivers, forcing this on them to
> >use drm isn't an option.
> 
> Why isn't this an option? Will the distros that insist on continuing
> to ship three conflicting video drivers fighting over a single piece
> of hardware please stand up and be counted? Distros get new drivers
> all the time, why will this be any different?

Often they flat-out don't work.  Walk into a store and buy a random
laptop.  Odds are it uses an Intel graphics chip.  Now load intelfb on
this.  Watch it completely fail to set a mode, as intelfb has no
knowledge beyond what the CRTC was like on i810.

The support offered by fbdev drivers is laughable in comparison to the
support offered by X drivers.  If you're lucky, it fails cleanly.  If
not, you're silently failing to get a working display.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/28/06, Daniel Stone <daniel@fooishbar.org> wrote:
> On Sun, May 28, 2006 at 08:59:19PM -0400, Jon Smirl wrote:
> > On 5/28/06, Dave Airlie <airlied@gmail.com> wrote:
> > >c) Lots of distros don't use fbdev drivers, forcing this on them to
> > >use drm isn't an option.
> >
> > Why isn't this an option? Will the distros that insist on continuing
> > to ship three conflicting video drivers fighting over a single piece
> > of hardware please stand up and be counted? Distros get new drivers
> > all the time, why will this be any different?
>
> Often they flat-out don't work.  Walk into a store and buy a random
> laptop.  Odds are it uses an Intel graphics chip.  Now load intelfb on
> this.  Watch it completely fail to set a mode, as intelfb has no
> knowledge beyond what the CRTC was like on i810.

If you read the whole thread you will see that we're only talking
about binding the existing DRM and fbdev drivers together. I believe I
said "This is just the first step down a long path to making the
merged drivers work." We can talk all we want be forward progress
never seems to happen - we have to start somewhere.

>
> The support offered by fbdev drivers is laughable in comparison to the
> support offered by X drivers.  If you're lucky, it fails cleanly.  If
> not, you're silently failing to get a working display.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFEek59RkzMgPKxYGwRAmstAJ0cz8m7JVtOs3GfioNKvKmRWZoAygCferj1
> rO+SzW1gg2qxZwWe/o4W+7Q=
> =mjgG
> -----END PGP SIGNATURE-----
>
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[David Lang]

On Sun, 28 May 2006, Jon Smirl wrote:

>> b) loading fbdev drivers breaks X in a lot of cases, we need to be a
>> bit more careful.
>
> It is perfectly legal to load an fbdev driver with X today. If it
> doesn't work it is a bug in X and should be fixed.
>
>> c) Lots of distros don't use fbdev drivers, forcing this on them to
>> use drm isn't an option.
>
> Why isn't this an option? Will the distros that insist on continuing
> to ship three conflicting video drivers fighting over a single piece
> of hardware please stand up and be counted? Distros get new drivers
> all the time, why will this be any different?

as a long time linux user I tend to not to use the framebuffer, but 
instead use the standard vga text drivers (with X and sometimes dri/drm).

in part this dates back to my early experiances with the framebuffer code 
when it was first introduced, but I still find that the framebuffer is not 
as nice to use as the simpler direct access for text modes. and when I 
start X up it doesn't need a framebuffer, so why suffer with the 
performance hit of the framebuffer?

yes, some hardware requires a framebuffer to display anything, but for 
most video cards, the hardware scrolling of a pure text mode is better 
(faster, smoother, less cpu required, etc) then the framebuffer 
equivalent.

David Lang

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

David Lang wrote:
> On Sun, 28 May 2006, Jon Smirl wrote:
> 
 > in part this dates back to my early experiances with the framebuffer
> code when it was first introduced, but I still find that the framebuffer
> is not as nice to use as the simpler direct access for text modes. and
> when I start X up it doesn't need a framebuffer, so why suffer with the
> performance hit of the framebuffer?

This might be true with the framebuffer in 2.2 and 2.4, but you may want
to reconsider in 2.6:

time cat linux/MAINTAINERS

vgacon (80x25 or 640x400, CONFIG_VGACON_SOFT_SCROLLBACK=n)

real    0m0.637s
user    0m0.000s
sys     0m0.637s

vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3)

real    0m0.572s
user    0m0.001s
sys     0m0.571s

vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3,vremap:4)

# vremap:4 gives approximately 12 extra pages of text for hardware
# scrolling, vgacon has 16.

real    0m0.409s
user    0m0.001s
sys     0m0.408s

So even a dumb driver such as vesafb that has to do on the fly
color conversions while pushing 64x more data to the bus can be
faster than vgacon.

Note the above is true for x86_32. For x86_64 and ia64, vesafb will
be slow because in it cannot do ypan in these archs.

But using a chipset specific driver on any arch, you can achieve a
fivefold increase:

nvidiafb 640x480-8 accel=true

real    0m0.145s
user    0m0.001s
sys     0m0.144s

> 
> yes, some hardware requires a framebuffer to display anything, but for
> most video cards, the hardware scrolling of a pure text mode is better
> (faster, smoother, less cpu required, etc) then the framebuffer equivalent.

A framebuffer driver can be faster than vgacon.  Scrolling is also smooth
even for vesafb because of a new scrolling method (pan_redraw) introduced
sometime in 2.6.10.  I don't know about less cpu required, that's probably
true.

Tony

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Antonino A. Daplas wrote:
> David Lang wrote:
>> On Sun, 28 May 2006, Jon Smirl wrote:
>>

Correcting myself:
> 
> vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3)

vga=0x301

> 
> real    0m0.572s
> user    0m0.001s
> sys     0m0.571s
> 
> vesafb 640x480-8 (vga=0x305 video=vesafb:ypan,mtrr:3,vremap:4)

vga=0x301

Tony

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> A framebuffer driver can be faster than vgacon.  Scrolling is also smooth
> even for vesafb because of a new scrolling method (pan_redraw) introduced
> sometime in 2.6.10.  I don't know about less cpu required, that's probably
> true.

To put this in perspective all of those numbers are drawing screens
way faster than your monitor refresh rate so the text isn't visible.

Highest speed where you could actually see the data, assuming that you
can read at 70 FPS...
3229 lines / 25 lines per screen / 70Hz refresh = 1.85s
3229 lines / 50 lines per screen / 70Hz refresh = 0.92s

But faster code in fbdev is good since it lowers the overall CPU load.

I would like to see fbdev acceleration unified with the other drivers
(DRM/X) so that a single state is maintained in the hardware.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Ondrej Zajicek]

On Wed, May 31, 2006 at 05:53:09AM +0800, Antonino A. Daplas wrote:
> David Lang wrote:
> > On Sun, 28 May 2006, Jon Smirl wrote:
> So even a dumb driver such as vesafb that has to do on the fly
> color conversions while pushing 64x more data to the bus can be
> faster than vgacon.

I just implemented text mode switch and tileblit ops into viafb
(http://davesdomain.org.uk/viafb/index.php) and it is about four
times faster than accelerated graphics mode and about eight times
faster than unaccelerated graphics mode (both measured using cat
largefile with ypan disabled). So textmode is meaningful
alternative.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Pá 02-06-06 10:36:04, Ondrej Zajicek wrote:
> On Wed, May 31, 2006 at 05:53:09AM +0800, Antonino A. Daplas wrote:
> > David Lang wrote:
> > > On Sun, 28 May 2006, Jon Smirl wrote:
> > So even a dumb driver such as vesafb that has to do on the fly
> > color conversions while pushing 64x more data to the bus can be
> > faster than vgacon.
> 
> I just implemented text mode switch and tileblit ops into viafb
> (http://davesdomain.org.uk/viafb/index.php) and it is about four
> times faster than accelerated graphics mode and about eight times
> faster than unaccelerated graphics mode (both measured using cat
> largefile with ypan disabled). So textmode is meaningful
> alternative.

I mean.... it is displaying text faster than refresh rate... so who
cares?

You can only *display* so much text a second (and then, user is only
able to see *much* less text) and both text mode and frame buffers are
way past that limits. so.... who cares?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[David Lang]

On Fri, 2 Jun 2006, Pavel Machek wrote:

>> I just implemented text mode switch and tileblit ops into viafb
>> (http://davesdomain.org.uk/viafb/index.php) and it is about four
>> times faster than accelerated graphics mode and about eight times
>> faster than unaccelerated graphics mode (both measured using cat
>> largefile with ypan disabled). So textmode is meaningful
>> alternative.
>
> I mean.... it is displaying text faster than refresh rate... so who
> cares?
>
> You can only *display* so much text a second (and then, user is only
> able to see *much* less text) and both text mode and frame buffers are
> way past that limits. so.... who cares?

there are quite a few times when you have text output that you need to 
scroll through, but you really don't need to read it as it goes by.

for example, accidently cating a large file, running a program with overly 
verbose debugging output, etc.

yes, if you never make mistakes and know that these are problem cases 
ahead of time you can redirect the output. but in the real world sysadmins 
really do notice when they are on a console that is slower.

if reading speed was the limiting factor very few people would need 
anything faster then a 9600 baud terminal.

David Lang

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >>I just implemented text mode switch and tileblit ops into viafb
> >>(http://davesdomain.org.uk/viafb/index.php) and it is about four
> >>times faster than accelerated graphics mode and about eight times
> >>faster than unaccelerated graphics mode (both measured using cat
> >>largefile with ypan disabled). So textmode is meaningful
> >>alternative.
> >
> >I mean.... it is displaying text faster than refresh rate... so who
> >cares?
> >
> >You can only *display* so much text a second (and then, user is only
> >able to see *much* less text) and both text mode and frame buffers are
> >way past that limits. so.... who cares?
> 
> there are quite a few times when you have text output that you need to 
> scroll through, but you really don't need to read it as it goes by.
> 
> for example, accidently cating a large file, running a program with overly 
> verbose debugging output, etc.
> 
> yes, if you never make mistakes and know that these are problem cases 
> ahead of time you can redirect the output. but in the real world sysadmins 
> really do notice when they are on a console that is slower.
> 
> if reading speed was the limiting factor very few people would need 
> anything faster then a 9600 baud terminal.

I'm not talking about reading speed, I'm talking about displaying
speed. Once you display more than refresh rate times screen
size... you may as well cheat -- xterm-like. If xterm detects too much
stuff is being displayed, it simply stops displaying it, only
refreshing screen few times a second...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[David Lang]

On Sat, 3 Jun 2006, Pavel Machek wrote:

> Hi!
>
>>>> I just implemented text mode switch and tileblit ops into viafb
>>>> (http://davesdomain.org.uk/viafb/index.php) and it is about four
>>>> times faster than accelerated graphics mode and about eight times
>>>> faster than unaccelerated graphics mode (both measured using cat
>>>> largefile with ypan disabled). So textmode is meaningful
>>>> alternative.
>>>
>>> I mean.... it is displaying text faster than refresh rate... so who
>>> cares?
>>>
>>> You can only *display* so much text a second (and then, user is only
>>> able to see *much* less text) and both text mode and frame buffers are
>>> way past that limits. so.... who cares?
>>
>> there are quite a few times when you have text output that you need to
>> scroll through, but you really don't need to read it as it goes by.
>>
>> for example, accidently cating a large file, running a program with overly
>> verbose debugging output, etc.
>>
>> yes, if you never make mistakes and know that these are problem cases
>> ahead of time you can redirect the output. but in the real world sysadmins
>> really do notice when they are on a console that is slower.
>>
>> if reading speed was the limiting factor very few people would need
>> anything faster then a 9600 baud terminal.
>
> I'm not talking about reading speed, I'm talking about displaying
> speed. Once you display more than refresh rate times screen
> size... you may as well cheat -- xterm-like. If xterm detects too much
> stuff is being displayed, it simply stops displaying it, only
> refreshing screen few times a second...

That would work, however AFAIK it's not implemented in any existing 
framebuffer.

David Lang

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

David Lang wrote:
> On Sat, 3 Jun 2006, Pavel Machek wrote:
>> I'm not talking about reading speed, I'm talking about displaying
>> speed. Once you display more than refresh rate times screen
>> size... you may as well cheat -- xterm-like. If xterm detects too much
>> stuff is being displayed, it simply stops displaying it, only
>> refreshing screen few times a second...
> 
> That would work, however AFAIK it's not implemented in any existing
> framebuffer.

Besides implementaton, the main concern with this is that you might miss
a very important kernel message.  Though one can always use the scrollback
buffer.

Tony

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On So 03-06-06 07:25:13, Antonino A. Daplas wrote:
> David Lang wrote:
> > On Sat, 3 Jun 2006, Pavel Machek wrote:
> >> I'm not talking about reading speed, I'm talking about displaying
> >> speed. Once you display more than refresh rate times screen
> >> size... you may as well cheat -- xterm-like. If xterm detects too much
> >> stuff is being displayed, it simply stops displaying it, only
> >> refreshing screen few times a second...
> > 
> > That would work, however AFAIK it's not implemented in any existing
> > framebuffer.
> 
> Besides implementaton, the main concern with this is that you might miss
> a very important kernel message.  Though one can always use the scrollback
> buffer.

Well, you can only miss a message *you would not see anyway*. I guess
the main concern is that it tends to look ugly on the screen (and it
will not be quite easy code).

Anyway, no, I do not think it is needed. framebuffers are fast enough
these days. When I used to have 300MHz toshiba laptop with UHCI
bogging down the system, something like that would be handy... (2sec
to do screen update in loaded-with-usb cases).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Pavel Machek wrote:
> On So 03-06-06 07:25:13, Antonino A. Daplas wrote:
>> David Lang wrote:
>>> On Sat, 3 Jun 2006, Pavel Machek wrote:
>>>> I'm not talking about reading speed, I'm talking about displaying
>>>> speed. Once you display more than refresh rate times screen
>>>> size... you may as well cheat -- xterm-like. If xterm detects too much
>>>> stuff is being displayed, it simply stops displaying it, only
>>>> refreshing screen few times a second...
>>> That would work, however AFAIK it's not implemented in any existing
>>> framebuffer.
>> Besides implementaton, the main concern with this is that you might miss
>> a very important kernel message.  Though one can always use the scrollback
>> buffer.
> 
> Well, you can only miss a message *you would not see anyway*.

There are some things that one can see but not read, and still be
recognizable even if your console is scrolling by.

An oops tracing, for one, is very unique and it's easy to pick them off
from regular text, especially on a relatively slow console such as vesafb.
We may even choose to colorize the output so they can stand out further.
  
> I guess
> the main concern is that it tends to look ugly on the screen (and it
> will not be quite easy code).
> 
> Anyway, no, I do not think it is needed. framebuffers are fast enough

I agree, I don't think it's needed.

Tony

Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On Jun 3, 2006, at 03:05:17, Antonino A. Daplas wrote:
> Pavel Machek wrote:
>> Well, you can only miss a message *you would not see anyway*.
>
> There are some things that one can see but not read, and still be  
> recognizable even if your console is scrolling by.

You would not even be able to recongnize it; we're talking about  
displaying text faster than the refresh rate, as pavel mentioned  
earlier:

On Sat, 3 Jun 2006, Pavel Machek wrote:
> I'm not talking about reading speed, I'm talking about displaying  
> speed. Once you display more than refresh rate times screen size...  
> you may as well cheat -- xterm-like. If xterm detects too much  
> stuff is being displayed, it simply stops displaying it, only  
> refreshing screen few times a second...

On the other hand, making the text console much more efficient would  
save a some CPU for *other* processes, say the one that's outputting  
text at such a high rate of speed, so it's probably worth it if it's  
not too hard.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Kyle Moffett wrote:
> On Jun 3, 2006, at 03:05:17, Antonino A. Daplas wrote:
>> Pavel Machek wrote:
>>> Well, you can only miss a message *you would not see anyway*.
>>
>> There are some things that one can see but not read, and still be
>> recognizable even if your console is scrolling by.
> 
> You would not even be able to recongnize it; we're talking about
> displaying text faster than the refresh rate, as pavel mentioned earlier:

We're talking about displaying a snapshot of the screen buffer at
specific intervals, perhaps during vblank.  And not all configurations
of framebuffers can scroll text that fast.  Just try vesafb at the
highest resolution and color depth without ypan and mtrr. (Default
for most distribs is vesafb at 1024x768-16, no ypan, no mtrr -- this
is a slow enough configuration that the scrolling text is recognizable,
Especially if you have a splash enabled, which further slows down
vesafb).

And the slower the console is, the more data that will fail to show
on the screen, the higher the likelihood of missing things, and the
uglier it will be.

Tony

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> On Wed, May 31, 2006 at 05:53:09AM +0800, Antonino A. Daplas wrote:
>> David Lang wrote:
>>> On Sun, 28 May 2006, Jon Smirl wrote:
>> So even a dumb driver such as vesafb that has to do on the fly
>> color conversions while pushing 64x more data to the bus can be
>> faster than vgacon.
> 
> I just implemented text mode switch and tileblit ops into viafb
> (http://davesdomain.org.uk/viafb/index.php) and it is about four
> times faster than accelerated graphics mode and about eight times
> faster than unaccelerated graphics mode (both measured using cat
> largefile with ypan disabled).

Never said that framebuffer can ever be faster than text mode, the
comparison was made against vgacon only. The reason why vgacon is
slow is because the screen buffer of vgacon is the actual VGA RAM.
So all operations (copies, fills, blits) are done in io memory.
And access to graphics memory is always slow, especially reads.

> So textmode is meaningful
> alternative.

This point was never questioned.

Tony
 

Re: OpenGL-based framebuffer concepts

[Ondrej Zajicek]

On Tue, May 30, 2006 at 10:40:20AM -0700, David Lang wrote:
> as a long time linux user I tend to not to use the framebuffer, but 
> instead use the standard vga text drivers (with X and sometimes dri/drm).
> 
> in part this dates back to my early experiances with the framebuffer code 
> when it was first introduced, but I still find that the framebuffer is not 
> as nice to use as the simpler direct access for text modes. and when I 
> start X up it doesn't need a framebuffer, so why suffer with the 
> performance hit of the framebuffer?

Many users want to use text mode for console. But this request is not
in contradiction with fbdev and fbcon. It just requires to do some work:

1) To extend fbcon to be able to handle framebuffer in text mode.
2) To modify appropriate fbdev drivers to not do mode change at startup.
   Fill fb_*_screeninfo with appropriate values for text mode instead.
3) (optional) To modify appropriate fbdev drivers to be able to switch
   back from graphics mode to text mode.
   
Step 2) could be done easily - just disable mode switch and examine structure
of fb. Step 3) could be hacked using store and restore of vga registers
if better way is not available.

If someone do that, then there should be no difference in user experience
with vgacon and fbcon/vga16fb (or specific fb driver), which can result to
better acceptance of fb drivers between users.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Ondrej Zajicek <santiago@mail.cz> wrote:
> On Tue, May 30, 2006 at 10:40:20AM -0700, David Lang wrote:
> > as a long time linux user I tend to not to use the framebuffer, but
> > instead use the standard vga text drivers (with X and sometimes dri/drm).
> >
> > in part this dates back to my early experiances with the framebuffer code
> > when it was first introduced, but I still find that the framebuffer is not
> > as nice to use as the simpler direct access for text modes. and when I
> > start X up it doesn't need a framebuffer, so why suffer with the
> > performance hit of the framebuffer?
>
> Many users want to use text mode for console. But this request is not
> in contradiction with fbdev and fbcon. It just requires to do some work:

My thoughts are mixed on continuing to support text mode for anything
other than initial boot/install. Linux is all about multiple languages
and the character ROMs for text mode don't support all of these
languages. Moving towards only bitmapped consoles means that all the
Unicode languages can be made available with a standard API. This is
an area that deserves more discussion.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Martin Mares]

Hi!

> My thoughts are mixed on continuing to support text mode for anything
> other than initial boot/install. Linux is all about multiple languages
> and the character ROMs for text mode don't support all of these
> languages.

On most servers, you don't need (and you don't want) anything like that.
In such cases, everything should be kept simple.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Minimalist definition of maximalism: `more!'.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, Martin Mares <mj@ucw.cz> wrote:
> > My thoughts are mixed on continuing to support text mode for anything
> > other than initial boot/install. Linux is all about multiple languages
> > and the character ROMs for text mode don't support all of these
> > languages.
>
> On most servers, you don't need (and you don't want) anything like that.
> In such cases, everything should be kept simple.

Not so simple if you only speak Chinese and are installing that server.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 31 May 2006 07:13, Jon Smirl wrote:
> On 5/31/06, Martin Mares <mj@ucw.cz> wrote:
> > > My thoughts are mixed on continuing to support text mode for anything
> > > other than initial boot/install. Linux is all about multiple languages
> > > and the character ROMs for text mode don't support all of these
> > > languages.
> >
> > On most servers, you don't need (and you don't want) anything like that.
> > In such cases, everything should be kept simple.
>
> Not so simple if you only speak Chinese and are installing that server.

In cases such as that there is more needed than just having the display 
showing the language in it's proper characters, be that zhongwen for the 
Chinese, Katakana for the Japanese or Cyrillic for the Russians.

In the case of Oriental languages the system also needs to understand the 
keyboard and it's input method. Research I have done for a project not 
related to the kernel (or programming) has led me to the fact that the most 
common Chinese system uses a combination of several keystrokes to generate 
each character. The other systems rely on a "smart" system to translate 
pinyin or related systems of writing chinese in roman characters into 
zhongwen.

That being the case, the kernel would then be best served by also 
understanding this input method. The work I am currently doing should enable 
the console to display any true-type font, not just the ones currently 
allowed, though vgacon and the fbdev drivers will still have the current 
limitation.

DRH

Re: OpenGL-based framebuffer concepts

[Martin Mares]

> >On most servers, you don't need (and you don't want) anything like that.
> >In such cases, everything should be kept simple.
> 
> Not so simple if you only speak Chinese and are installing that server.

Then, you are free to run fbcon.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI?

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Martin Mares wrote:
> Hi!
>
>   
>> My thoughts are mixed on continuing to support text mode for anything
>> other than initial boot/install. Linux is all about multiple languages
>> and the character ROMs for text mode don't support all of these
>> languages.
>>     
>
> On most servers, you don't need (and you don't want) anything like that.
> In such cases, everything should be kept simple.
Linux isn't all about servers - but still, a framebuffer is not
"complicated" compared to vga textmode.  It uses more
memory, but that is graphichs memory the server can't
put to better use anyway.


Helge Hafting

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On St 31-05-06 08:48:15, Martin Mares wrote:
> Hi!
> 
> > My thoughts are mixed on continuing to support text mode for anything
> > other than initial boot/install. Linux is all about multiple languages
> > and the character ROMs for text mode don't support all of these
> > languages.
> 
> On most servers, you don't need (and you don't want) anything like that.
> In such cases, everything should be kept simple.

Problem is: it messes up design for everyone else. (And no, Santiago,
most people are not using vgacon. Most people use vesafb these days,
because that's what allows whole screen to be used, not just 80x25).

fbcon is simple enough. Okay, vgacon may be useful for recovery, but
supporting accelerated 3D over vgacon is quite crazy.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Martin Mares]

Hello!

> Problem is: it messes up design for everyone else. (And no, Santiago,
> most people are not using vgacon. Most people use vesafb these days,
> because that's what allows whole screen to be used, not just 80x25).
> 
> fbcon is simple enough. Okay, vgacon may be useful for recovery, but
> supporting accelerated 3D over vgacon is quite crazy.

I don't say accelerated 3D over vgacon should be supported.

It might be nice to have a choice of either the most basic vgacon,
or a frame buffer console with acceleration and everything else.
Even better with easy switching between these two.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> On Tue, May 30, 2006 at 10:40:20AM -0700, David Lang wrote:
>> as a long time linux user I tend to not to use the framebuffer, but 
>> instead use the standard vga text drivers (with X and sometimes dri/drm).
>>
>> in part this dates back to my early experiances with the framebuffer code 
>> when it was first introduced, but I still find that the framebuffer is not 
>> as nice to use as the simpler direct access for text modes. and when I 
>> start X up it doesn't need a framebuffer, so why suffer with the 
>> performance hit of the framebuffer?
> 
> Many users want to use text mode for console. But this request is not
> in contradiction with fbdev and fbcon. It just requires to do some work:
> 
> 1) To extend fbcon to be able to handle framebuffer in text mode.

And it can be done.  The matrox driver in 2.4 can do just that.  For 2.6,
we have tileblitting which is a drawing method that can handle pure text.
None of the drivers use this, but vgacon can be trivially written as a
framebuffer driver that uses tileblitting (instead of the default bitblit).

I believe that there was a vgafb driver before that does exactly what you
want.

> 2) To modify appropriate fbdev drivers to not do mode change at startup.
>    Fill fb_*_screeninfo with appropriate values for text mode instead.

Most drivers do not change the mode at startup.  Do not load fbcon, and
you will retain your text mode even if a framebuffer is loaded.  This is
not a hard and fast rule, so some drivers, especially those in embedded,
will explicitly change the mode at startup, that's a developer choice.

> 3) (optional) To modify appropriate fbdev drivers to be able to switch
>    back from graphics mode to text mode.

And a few drivers already do that, i810fb and rivafb.  Load rivafb or i810fb,
switch to graphics mode, unload, and you're back to text mode. The main problem
is that fbcon cannot be unloaded, but it's again trivial to rewrite fbcon so it
can be unloaded.  What prevents me for doing the rewrite is that only a few
drivers restore the hardware to text mode.

And this is one argument against making vgacon the primary console driver.
It does not have the capability to reset itself, it has to be done by
an external driver, whether by X or fbdev.

Tony

Re: OpenGL-based framebuffer concepts

[Ondrej Zajicek]

On Wed, May 31, 2006 at 07:21:11AM +0800, Antonino A. Daplas wrote:
> > 2) To modify appropriate fbdev drivers to not do mode change at startup.
> >    Fill fb_*_screeninfo with appropriate values for text mode instead.
> 
> Most drivers do not change the mode at startup.  Do not load fbcon, and
> you will retain your text mode even if a framebuffer is loaded. 

Yes, but i wrote about _using_ fbcon and fbdev without mode change.

> > 3) (optional) To modify appropriate fbdev drivers to be able to switch
> >    back from graphics mode to text mode.
> 
> And a few drivers already do that, i810fb and rivafb.  Load rivafb or i810fb,
> switch to graphics mode, unload, and you're back to text mode.

I though about being able to explicitly change mode from graphics to text 
(for example when fbdev-only X switch to fbcon) while using fbdev.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: OpenGL-based framebuffer concepts

[Marko M]

This is actually over my head, but would it be possible to dynamically
switch between two drivers by saving and restoring whole context, much
like in suspend-resume process?

Lowest layer of fbdev/DRM would control basic PCI/memory management
and load/unload appropriate (module) driver, so we could safely switch
between different hardware management (driver) policies. Or I'm just
to fancy?

On 5/31/06, Ondrej Zajicek <santiago@mail.cz> wrote:
> On Wed, May 31, 2006 at 07:21:11AM +0800, Antonino A. Daplas wrote:
> > > 2) To modify appropriate fbdev drivers to not do mode change at startup.
> > >    Fill fb_*_screeninfo with appropriate values for text mode instead.
> >
> > Most drivers do not change the mode at startup.  Do not load fbcon, and
> > you will retain your text mode even if a framebuffer is loaded.
>
> Yes, but i wrote about _using_ fbcon and fbdev without mode change.
>
> > > 3) (optional) To modify appropriate fbdev drivers to be able to switch
> > >    back from graphics mode to text mode.
> >
> > And a few drivers already do that, i810fb and rivafb.  Load rivafb or i810fb,
> > switch to graphics mode, unload, and you're back to text mode.
>
> I though about being able to explicitly change mode from graphics to text
> (for example when fbdev-only X switch to fbcon) while using fbdev.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Ondrej Zajicek wrote:
> On Wed, May 31, 2006 at 07:21:11AM +0800, Antonino A. Daplas wrote:
>>> 2) To modify appropriate fbdev drivers to not do mode change at startup.
>>>    Fill fb_*_screeninfo with appropriate values for text mode instead.
>> Most drivers do not change the mode at startup.  Do not load fbcon, and
>> you will retain your text mode even if a framebuffer is loaded. 
> 
> Yes, but i wrote about _using_ fbcon and fbdev without mode change.

boot with fbcon=map:9 /* or any number greater than the number of fbdev's loaded */

> 
>>> 3) (optional) To modify appropriate fbdev drivers to be able to switch
>>>    back from graphics mode to text mode.
>> And a few drivers already do that, i810fb and rivafb.  Load rivafb or i810fb,
>> switch to graphics mode, unload, and you're back to text mode.
> 
> I though about being able to explicitly change mode from graphics to text 
> (for example when fbdev-only X switch to fbcon) while using fbdev.
 
This will require the following:

1. a generic text mode framebuffer driver, ie, an fbdev version of vgacon
2. a chipset driver that can fully restore VGA text mode.

The framebuffer layer already has helper functions that will save and restore
the standard VGA registers. It's the save/restore of extended registers that
only the chipset driver know about which is lacking.
 
Once the above 2 are satisfied, the infrastructure is already present that
will do what you want.

Tony

Re: OpenGL-based framebuffer concepts

[Geert Uytterhoeven]

On Wed, 31 May 2006, Antonino A. Daplas wrote:
> Ondrej Zajicek wrote:
> > On Tue, May 30, 2006 at 10:40:20AM -0700, David Lang wrote:
> >> as a long time linux user I tend to not to use the framebuffer, but 
> >> instead use the standard vga text drivers (with X and sometimes dri/drm).
> >>
> >> in part this dates back to my early experiances with the framebuffer code 
> >> when it was first introduced, but I still find that the framebuffer is not 
> >> as nice to use as the simpler direct access for text modes. and when I 
> >> start X up it doesn't need a framebuffer, so why suffer with the 
> >> performance hit of the framebuffer?
> > 
> > Many users want to use text mode for console. But this request is not
> > in contradiction with fbdev and fbcon. It just requires to do some work:
> > 
> > 1) To extend fbcon to be able to handle framebuffer in text mode.
> 
> And it can be done.  The matrox driver in 2.4 can do just that.  For 2.6,
> we have tileblitting which is a drawing method that can handle pure text.
> None of the drivers use this, but vgacon can be trivially written as a
> framebuffer driver that uses tileblitting (instead of the default bitblit).
> 
> I believe that there was a vgafb driver before that does exactly what you
> want.

Indeed. Early 2.1.x had a vgafb and an fbcon-vga, before vgacon existed in its
current form.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, 31 May 2006, Antonino A. Daplas wrote:
> > And it can be done.  The matrox driver in 2.4 can do just that.  For 2.6,
> > we have tileblitting which is a drawing method that can handle pure text.
> > None of the drivers use this, but vgacon can be trivially written as a
> > framebuffer driver that uses tileblitting (instead of the default bitblit).
> >
> > I believe that there was a vgafb driver before that does exactly what you
> > want.
>
> Indeed. Early 2.1.x had a vgafb and an fbcon-vga, before vgacon existed in its
> current form.

Moving back to a vgafb with text mode support in fbcon would be one
way to eliminate a few of the way too many graphics drivers. I don't
see any real downside side to doing this, does any one else see any
problems?


-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Matthew Garrett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> Moving back to a vgafb with text mode support in fbcon would be one
> way to eliminate a few of the way too many graphics drivers. I don't
> see any real downside side to doing this, does any one else see any
> problems?

Just to check what you mean by "text mode" - is this vga mode 3, or 
a graphical vga mode with text drawn in it? vga16fb doesn't work on all 
hardware that vgacon works on, much to my continued misery.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > Moving back to a vgafb with text mode support in fbcon would be one
> > way to eliminate a few of the way too many graphics drivers. I don't
> > see any real downside side to doing this, does any one else see any
> > problems?
>
> Just to check what you mean by "text mode" - is this vga mode 3, or
> a graphical vga mode with text drawn in it? vga16fb doesn't work on all
> hardware that vgacon works on, much to my continued misery.

Text mode meaning the non-bitmap display modes where the video
hardware generates the glyphs.

>
> --
> Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 5/31/06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Wed, 31 May 2006, Antonino A. Daplas wrote:
>> > And it can be done.  The matrox driver in 2.4 can do just that.  For
>> 2.6,
>> > we have tileblitting which is a drawing method that can handle pure
>> text.
>> > None of the drivers use this, but vgacon can be trivially written as a
>> > framebuffer driver that uses tileblitting (instead of the default
>> bitblit).
>> >
>> > I believe that there was a vgafb driver before that does exactly
>> what you
>> > want.
>>
>> Indeed. Early 2.1.x had a vgafb and an fbcon-vga, before vgacon
>> existed in its
>> current form.
> 
> Moving back to a vgafb with text mode support in fbcon would be one
> way to eliminate a few of the way too many graphics drivers. I don't
> see any real downside side to doing this, does any one else see any
> problems?

An optional vgafb driver is probably a good idea. It's downside
is probably slower performance.

I may start work on a userland fb driver that can support both
graphics and text mode this weekend.

Tony

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >> For a specific DRM chip there are currently four modules:
> >> fbdev-core
> >> fbdev-chip depends on fbdev-core
> >> drm-core
> >> drm-chip depends on drm-core
> >> RIght now drm and fbdev can be loaded independently.
> >>
> >> I would always keep fbdev-core and drm-core as separate modules.  But
> >> drm-core may become dependent on fbdev-core.
> 
> I've already pointed out to Jon the problems with this approach on
> numerous occasions and to be honest do not have the time to do so
> again,
> 
> I will not accept patches to make DRM drivers rely on fbdev drivers in
> the kernel for many many many reasons, two quick ones :
> 
> a) we don't always have a fully functional fbdev driver, see intel fb 
> drivers.

Well, we need to write those fbdev drivers, then.

> b) loading fbdev drivers breaks X in a lot of cases, we need to be a
> bit more careful.

Fix X and/or fbdev, then.

> c) Lots of distros don't use fbdev drivers, forcing this on them to
> use drm isn't an option.

Let the distros catch up with current state of technology....

I mean, it is crazy. We have complex subsystem (graphics), that is
made even more complex because of crazy design (independend fbdev and
DRM, X handling PCI from userspace).

Now, lets take common hardware like radeon. You want these
combinations to be supported:

vgacon 
vesafb ( + unaccelerated X )
radeonfb ( + unaccelerated X )

vgacon + accelerated X
vesafb + accelerated X
radeonfb + accelerated X

vgacon + DRM + accelerated X
vesafb + DRM + accelerated X
radeonfb + DRM + accelerated X

...that's crazy! You claim that for various reasons (mostly bugs) we
need to keep that complexity. That's not the way forward, with
manpower we have I'm afraid.

I believe we can trim supported combinations to half... for hardware
that works anyway. For special cases like intel when some driver is
unavailable /broken, well we may need to do different choices, or
better write missing parts / fix broken cards. I believe that these
combinations make sense:

vgacon 
vesafb ( + unaccelerated X )
radeonfb ( + unaccelerated X )
radeonfb + accelerated X
radeonfb + DRM + accelerated X

That's half of combinations to care about! Plus first two are really
generic across x86...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > a) we don't always have a fully functional fbdev driver, see intel fb
> > drivers.
>
> Well, we need to write those fbdev drivers, then.

And you propose to get specs from hw vendors how? (please provide
solutions for practical problems)

> > b) loading fbdev drivers breaks X in a lot of cases, we need to be a
> > bit more careful.
>
> Fix X and/or fbdev, then.

we don't have the manpower to do even that...

> > c) Lots of distros don't use fbdev drivers, forcing this on them to
> > use drm isn't an option.
>
> Let the distros catch up with current state of technology....
>
> I mean, it is crazy. We have complex subsystem (graphics), that is
> made even more complex because of crazy design (independend fbdev and
> DRM, X handling PCI from userspace).

and you are not going to fix it with a big lot of code, you need to
fix it one problem at a time,

> Now, lets take common hardware like radeon. You want these
> combinations to be supported:
>
> vgacon
> vesafb ( + unaccelerated X )
> radeonfb ( + unaccelerated X )
>
> vgacon + accelerated X
> vesafb + accelerated X
> radeonfb + accelerated X
>
> vgacon + DRM + accelerated X
> vesafb + DRM + accelerated X
> radeonfb + DRM + accelerated X
>
> ...that's crazy! You claim that for various reasons (mostly bugs) we
> need to keep that complexity. That's not the way forward, with
> manpower we have I'm afraid.

We have to support what we support now, regressions in what we support
are not acceptable, we would spend all our time just having Linus
backing out changes, I'm sorry Pavel I respect what you've done with
input, but your list below cuts out a number of currently support
configurations the main ones currently in use are:

vgacon + DRM + accelerated X
vesafb + DRM + accelerated X

If you take a look at the stuff required to get r300 support in the
drm and X into the kernel without breaking current systems you'll get
an idea of what we have to do..

Linus has so far reverted a number of patches from the DRM as they
cause regressions, anything done in this area has to be careful to
have a complete understanding of the area.

> vgacon
> vesafb ( + unaccelerated X )
> radeonfb ( + unaccelerated X )
> radeonfb + accelerated X
> radeonfb + DRM + accelerated X
>

Again this gets rid of the two most popular combinations in use today.
I don't think this is acceptable, and you'll also break suspend/resume
on every radeon based laptop in use today, but I'm sure you thought
about all of that before posting :-)

I'm not knocking solutions here for the fun of it, I've tried a lot of
different combinations of things to find an answer, and until someone
supplies some code that doesn't regress or works in an incremental
manner to improve the situation....

Here are the rules:
1. No regressions.
2. Doesn't require lockstep changes in X and kernel, i.e. a new kernel
can't break old X, and new kernel can't require a new X, new config
features in the kernel can require a new X of course but anything
using and old config feature must still work.

Dave.

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >Now, lets take common hardware like radeon. You want these
> >combinations to be supported:
> >
> >vgacon
> >vesafb ( + unaccelerated X )
> >radeonfb ( + unaccelerated X )
> >
> >vgacon + accelerated X
> >vesafb + accelerated X
> >radeonfb + accelerated X
> >
> >vgacon + DRM + accelerated X
> >vesafb + DRM + accelerated X
> >radeonfb + DRM + accelerated X
> >
> >...that's crazy! You claim that for various reasons (mostly bugs) we
> >need to keep that complexity. That's not the way forward, with
> >manpower we have I'm afraid.
> 
> We have to support what we support now, regressions in what we support
> are not acceptable, we would spend all our time just having Linus
> backing out changes, I'm sorry Pavel I respect what you've done with
> input, but your list below cuts out a number of currently support
> configurations the main ones currently in use are:

Vojtech Pavlik is the one who done inputs... not me. (I admit we have
similar names).

> vgacon + DRM + accelerated X
> vesafb + DRM + accelerated X

Okay, we are in deeper trouble then I thought, then.

> >vgacon
> >vesafb ( + unaccelerated X )
> >radeonfb ( + unaccelerated X )
> >radeonfb + accelerated X
> >radeonfb + DRM + accelerated X
> 
> Again this gets rid of the two most popular combinations in use today.
> I don't think this is acceptable, and you'll also break suspend/resume
> on every radeon based laptop in use today, but I'm sure you thought
> about all of that before posting :-)

No, to the contrary. suspend/resume can't ever work properly with
vgacon and vesafb. It works okay with radeonfb tooday, and in fact
radeonfb is neccessary today for saving power over S3.

> Here are the rules:
> 1. No regressions.
> 2. Doesn't require lockstep changes in X and kernel, i.e. a new kernel
> can't break old X, and new kernel can't require a new X, new config
> features in the kernel can require a new X of course but anything
> using and old config feature must still work.

These are very reasonable rules... but still, I think we need to move
away from vgacon/vesafb. We need proper hardware drivers for our
hardware.

Now, having DRM depend on framebuffer driver sounds like a right
long-term solution. We probably need to do something with
vesafb/vgacon... like stub it out or something, and deprecate them,
long-term.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Jeff Garzik]

Pavel Machek wrote:
> These are very reasonable rules... but still, I think we need to move
> away from vgacon/vesafb. We need proper hardware drivers for our
> hardware.

I agree we need proper drivers, but moving away from vesafb will be 
tough... moving away from vgacon is likely impossible for many many 
years yet.

Once proper hardware drivers exist, you will still need to support 
booting into a situation where you probably need video before a driver 
can be loaded -- e.g. distro installers.  Server owners will likely 
prefer vgacon over a huge video driver they will never use for anything 
but text mode console.

	Jeff

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Po 29-05-06 17:23:59, Jeff Garzik wrote:
> Pavel Machek wrote:
> >These are very reasonable rules... but still, I think we need to move
> >away from vgacon/vesafb. We need proper hardware drivers for our
> >hardware.
> 
> I agree we need proper drivers, but moving away from vesafb will be 
> tough... moving away from vgacon is likely impossible for many many 
> years yet.
> 
> Once proper hardware drivers exist, you will still need to support 
> booting into a situation where you probably need video before a driver 
> can be loaded -- e.g. distro installers.  Server owners will likely 
> prefer vgacon over a huge video driver they will never use for anything 
> but text mode console.

Well, I agree that vesafb and vgacon need to exist and are useful for
installation/servers/etc. I was arguing that some combinations are
bad.

Like vgacon + X + 3D acceleration.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[David Lang]

On Mon, 29 May 2006, Pavel Machek wrote:

> Well, I agree that vesafb and vgacon need to exist and are useful for
> installation/servers/etc. I was arguing that some combinations are
> bad.
>
> Like vgacon + X + 3D acceleration.

why is this bad?

this lets the user of the box use as much as is needed, from plain text 
mode on up to accelerated modes. perfect for the user who sometimes needs 
a nimple, stripped down system and sometimes needs graphics (and if they 
need graphics it seems silly to deny them access to the accelerated 
features)

David Lang

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >Well, I agree that vesafb and vgacon need to exist and are useful for
> >installation/servers/etc. I was arguing that some combinations are
> >bad.
> >
> >Like vgacon + X + 3D acceleration.
> 
> why is this bad?
> 
> this lets the user of the box use as much as is needed, from plain text 
> mode on up to accelerated modes. perfect for the user who sometimes needs 
> a nimple, stripped down system and sometimes needs graphics (and if they 
> need graphics it seems silly to deny them access to the accelerated 
> features)

Because you have vgacon that knows nothing about your videocard, then
try to run 3D acceleration over it. Suspend/resume can't work properly
in such case... fbcon is pretty good for your stripped-down system,
too.

...and we do not want to support 1000 different configs, because then
they all become buggy.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/29/06, Jeff Garzik <jeff@garzik.org> wrote:
> Pavel Machek wrote:
> > These are very reasonable rules... but still, I think we need to move
> > away from vgacon/vesafb. We need proper hardware drivers for our
> > hardware.
>
> I agree we need proper drivers, but moving away from vesafb will be
> tough... moving away from vgacon is likely impossible for many many
> years yet.
>
> Once proper hardware drivers exist, you will still need to support
> booting into a situation where you probably need video before a driver
> can be loaded -- e.g. distro installers.  Server owners will likely
> prefer vgacon over a huge video driver they will never use for anything
> but text mode console.

These are areas that definitely need more discussion and design work
once we can come to some kind of basic agreement on where to start. I
would definitely like to reduce the number of permutations on how
video drivers can be combined to an absolute minimum. For example
vesafb has caused me a number of problems when it is used
simultaneously with other drivers.

Other areas that can be explored:
1) Multiple active consoles on multiple video cards
2) User space console driver
3) Ownership of video hardware by the logged in user
4) Using graphics mode to do console for complex Asian languages
5) Concept of a safe mode console that will work in all environments

There are probably a lot more areas that can be added to this list.
But none of this can be built until the foundation is laid.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Monday 29 May 2006 22:10, Jon Smirl wrote:
> On 5/29/06, Jeff Garzik <jeff@garzik.org> wrote:
> > Pavel Machek wrote:
> > > These are very reasonable rules... but still, I think we need to move
> > > away from vgacon/vesafb. We need proper hardware drivers for our
> > > hardware.
> >
> > I agree we need proper drivers, but moving away from vesafb will be
> > tough... moving away from vgacon is likely impossible for many many
> > years yet.
> >
> > Once proper hardware drivers exist, you will still need to support
> > booting into a situation where you probably need video before a driver
> > can be loaded -- e.g. distro installers.  Server owners will likely
> > prefer vgacon over a huge video driver they will never use for anything
> > but text mode console.
>
> These are areas that definitely need more discussion and design work
> once we can come to some kind of basic agreement on where to start. I
> would definitely like to reduce the number of permutations on how
> video drivers can be combined to an absolute minimum. For example
> vesafb has caused me a number of problems when it is used
> simultaneously with other drivers.
>
> Other areas that can be explored:
> 1) Multiple active consoles on multiple video cards
> 2) User space console driver
> 3) Ownership of video hardware by the logged in user
> 4) Using graphics mode to do console for complex Asian languages
> 5) Concept of a safe mode console that will work in all environments

Not until the framework gets layed, and preferably not unless someone can 
provide a good reason for taking these steps (besides #1 - that is one I 
think has potential. A console set aside for, perhaps, little more that 
keeping a log of error messages.)

DRH

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Monday 29 May 2006 21:23, Jeff Garzik wrote:
> Pavel Machek wrote:
> > These are very reasonable rules... but still, I think we need to move
> > away from vgacon/vesafb. We need proper hardware drivers for our
> > hardware.
>
> I agree we need proper drivers, but moving away from vesafb will be
> tough... moving away from vgacon is likely impossible for many many
> years yet.

After my rant last night I spent some time thinking... Thanks to a private 
message from Dave Arlie today the conclusion I came to proved correct.

The model I was working towards, where there is a low-level mediation layer 
for the video-hardware is what is needed. The argument was over where to 
start, and I started at the wrong end.

> Once proper hardware drivers exist, you will still need to support
> booting into a situation where you probably need video before a driver
> can be loaded -- e.g. distro installers.  Server owners will likely
> prefer vgacon over a huge video driver they will never use for anything
> but text mode console.

vgacon will likely never be removed from the kernel. If the direction Dave has 
told me things should go in works, vgacon will be needed for distro 
installers, servers and early boot. The fbdev system itself will survive for 
those servers where people want it and for the embedded people that depend on 
it. WHat is likely to change is the common user...

I'm making an assumption here based on several statements Dave made in a 
private e-mail to me, but the direction things would likely go for "normal" 
users is that the DRM system will be used for everything. If this is the 
case, then the likely best solution for all kernel errors would be 
transferring control of the primary display and input devices to vgacon and 
switching to it's preferred mode. Done properly the driver state (at an oops) 
could be stored and then restored after the user acknowledges the error 
(unless the user has configured the system not to wait on a recoveable 
error).

Before I can restart my work at trying to move the kernel graphics system 
forward, I would like to apologize to people for my behaviour.

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > We have to support what we support now, regressions in what we support
> > are not acceptable, we would spend all our time just having Linus
> > backing out changes, I'm sorry Pavel I respect what you've done with
> > input, but your list below cuts out a number of currently support
> > configurations the main ones currently in use are:
>
> Vojtech Pavlik is the one who done inputs... not me. (I admit we have
> similar names).

Sorry by brain slipped I meant suspend/resume... not enough sleep too
much flamage..

>
> No, to the contrary. suspend/resume can't ever work properly with
> vgacon and vesafb. It works okay with radeonfb tooday, and in fact
> radeonfb is neccessary today for saving power over S3.

But the things is today for many users suspend/resume to RAM works for
people running X drivers, I know on my laptop that my radeon
suspends/resumes fine when running vgacon/DRM/accelerated X, it
doesn't suspend/resume at all well when running vgacon on its own of
course. or with radeonfb for that matter. so I still believe the
suspend/resume code for a card can live in userspace if necessary but
it just shouldn't be part of X... it needs to be part of another
graphics controller process.

> > Here are the rules
> > 1. No regressions.
> > 2. Doesn't require lockstep changes in X and kernel, i.e. a new kernel
> > can't break old X, and new kernel can't require a new X, new config
> > features in the kernel can require a new X of course but anything
> > using and old config feature must still work.
>
> These are very reasonable rules... but still, I think we need to move
> away from vgacon/vesafb. We need proper hardware drivers for our
> hardware.
>
> Now, having DRM depend on framebuffer driver sounds like a right
> long-term solution. We probably need to do something with
> vesafb/vgacon... like stub it out or something, and deprecate them,
> long-term.

To be honest, not using fbdev may be a better long-term solutions I'm
wholly not convinced we can put enough support for things into the
fbdev drivers without a lot of work, I've concentrated before on
splitting X.org into two pieces, a device setup and control process
running most of the X driver, and a rendering server. The thing
currently missing from the equation is the memory management unit, so
I can say this buffer is the current front buffer, and things like
that, so that we can invalidate the front buffer on rotations and
other operations where it needs to be. This can all be built on top of
the DRM. We can then perhaps have an fbcon or drmcon that knows where
the card's frontbuffer is and what mode is set on it, so it can dump
oops etc...

vgacon causes problems of course with memory management, as I believe
that most graphics cards when in text mode, don't allow you to specify
what pieces of their VRAM are being used to display the text mode, so
you have to try and keep framebuffers at the start of RAM, when really
you'd like to not have that sort of restriction.

Dave.

Re: OpenGL-based framebuffer concepts

[Marko M]

There is no doubt in my mind. If we want a robust, clean and feature
rich graphical subsystem in Linux, we shall re implement lower layer as
much as possible (AMAP). Transition as always will not be painless,
but nevertheless is much needed.

AFAIC Jon's approach is about "doing things right" AMAP and
maintainer's approach is keeping things backward compatible AMAP -
which is the meaning of "doing things right" in their books and both
goals are legitimate. So things sum up to this:

1) Current framework is inefficient (duplicated work) and inconsistent
(with good OS design). Modifying it with backward compatibility in
mind adds to the complexity of the solution and probably results in
lots of nasty hacks, which in return slows down development and
inevitably invokes more disputation. => Slow development with
questionable results.

2) Any breakage of currently working drivers or applications demand
lots of work on fixing them. => Slow deployment of usable solutions
and painful death from irrelevance.

So, we need a new subsystem as clean as possible, which on the other
hand would require as lees modified LOCs as possible
(driver/application base). It is basically a balance between principles
and real world demands (as always).

My solution:

1) Make a new subsystem (fbdev+DRM or so), which would be an OPTIONAL
replacement for current one, but in such way that porting existing
drivers would be fast and easy AMAP. Pretty much like XAA -> EXA.

2) After porting drivers for most relevant chips (R200, GF2/4,
i810/i915, Unichrome...), offer help to Xorg guys in writing DDX part
of the server for this OPTIONAL target.

3) Help adding backends for this subsystem to all relevant rendering
libraries (SDL, DirectFB, Cairo, Evas...) and gain acceptance.
Backward compatibility with frame buffer applications is implied,
either generic or through compatibility layer.

4) Write a good documentation and if system is functioning well,
people will start using it as it will provide clear advantage over the
old one (at least for security). Then, some distributions will start
using it by default, and if everything goes well (almost never),
vendors will eventually start releasing proprietary drivers for it.

5) New subsystem is all new and fancy Linux thing, while old one is
becoming legacy.

The key point is making porting of current fbdev/DRM drivers as easy
as possible. This is where KGI failed in my opinion, so lets not
repeat that mistake.

My $0,05 to gfx subsystem architecture:

The key point is to provide a good drawing API which wouldn't fight
abstracting different hardware and at the same time would be adequate
for accelerating most current rendering libraries (Porter/Duff,
splines, etc). The fbdev should undoubtedly provide more
advanced/usable API, so maybe DirectFB could give us a good waymark.

It would be neat if we could create many (virtual) frame buffers and
interact with them on different consoles, or redirect them to
different CRTCs. They would be just like different applications (with
their contexts) running on gfx cards and underlying framework
(fbdev/DRM) would control their switching and card(s)
detection/resource management.

Regarding separation of gfx drivers to 2D and 3D parts, I think that
it should exist i some way, but with all memory and bus management in
2D one. I'm not that familiar with 3D hardware and rendering pipes,
but we should try to make it like loadable module/extension to this
new 2D core driver/API (fused fbdev/DRM), even if it's not so
distinctively separated from 2D core. There is no much wisdom in
hardware blitters, backend scalers, DMA engines or PCI(E)/AGP bus
mastering, although graphic memory management (controller) could be an
issue here...

As I see it, gfx vendors are concerned about exposure of their
proprietary 3D hardware design, and possibly some parts of
sophisticated video encoding hardware, which is protected by patents
(MPEG2, Macromedia protected TV-out, etc). So, we should enable them
(ATi, NVidia) to provide us with good OpenSource 2D part on which they
would cooperate with community - improving quality and reducing their
costs - without concern of compromising their IP, or exposing themselves
to legal actions of other parties.

My point is that we should design a new framework, with more
meaningful and practical separation in mind. So, instead 2D and 3D
parts, with duplicated functions, we should have "basic 2D" Open Source
part, which will handle all basic PCI/memory/mode_setting and 2D core
functionality, and optional open or closed source part for 3D
acceleration and proprietary features/extensions.

Before flaming me for supporting those corporate blood-suckers, just
think about it... Proprietary software will not disappear just because
some of us don't like it. We should reach the point where everybody
will listen to what we'll have to say, and isolation is not a way to
get there. Making people share is communism - stimulating them and
making friendly environment for sharing is business and democracy. So
lets make that environment! This will actually promote FOSS drivers,
while keeping vendors happy about their dirty secrets. If we could
extract all basic, IP non-violate, functions into the "basic 2D"
driver, then we would have excellent OSS drivers for offices and
enterprise with less effort, so we could focus on hacking just 3D and
possibly other proprietary/closed parts for our cause and enjoyment
(it would certainly be much easier). Big digital content producers,
which utilize 3D workstations, will use proprietary drivers any way,
because only vendors can afford to pay application and driver
certificates, while gamers could use whatever they want - much like
now days.

Regarding obsolescence of vgacon and vesafb:

These drivers are so fundamental that this isn't even discussable. Do
what ever you want but provide vgacon and generic vesafb drivers.
Though I really fail to understand way vgacon can't be loaded and
unloaded as needed before actual driver kicks in.

And another slightly off topic thing about gfx drivers issue:

Being video engineer, I must say that I'm all against neglecting 2D
core functions and using mainly 3D hardware for things like color
space conversions, video scaling or font rendering. It is not
efficient (more power hungry) and in some cases even hardly plausible
at all (multiple video overlays), not to mention dependency on right
software implementation. Video processing is often misunderstood by
programmers and computer graphic guys which often leads to terminology
misuse and erroneous implementations. Relying on dedicated hardware is
more neat then reimplementing that feature by coding through several
software layers (library/API/driver).

That said, I think you guys are underestimating momentum which Linux
graphics (desktop) has gained. If Linux community could pull off
something like discussed above, it would certainly gain enormous
attention in just couple of months.

Regards

Marko M

Re: OpenGL-based framebuffer concepts

[Ian Kester-Haney]

Well, from the flames you'd expect something to emerge.
>From an end-user standpoint, you are all raving lunatics.

Regressions, the graphics subsystem is a regression,
   back to the days of dos and basic video cad functionality.
   linux kernel development has switched to a very rapid pace of development
           internal ABIs and APIs are in a constant state of flux and
you argue that no
                 regressions are allowed
   you support the newest processor and chipset technology and yet
graphics are text
          and X windows only?
I don't suggest that vgacon and fbdev should be dropped, merely that a better
alternative may be introduces into the -mm kernel.   Using hacks and under
 appreciated drm and forcing the Corporate Vendors to work between
 X and the console is a retarded way of doing things.

So let me offer a suggestion,
     Add an experimental 'accelfb' system to accompany the basic vgacon
     Start with the proper code and plug away, us lunatics can test it
     Merge new functionality while removing old crud.
     Accelfb should not be forced onto old hardware that can't support it
     Neither can the kernel rely on third parties to do all the heavy lifting
           xorg and the distro maintainers

Backwards Compatibility
     As far as I can tell, the kernel user-land interface has been
rapidly changing
     Why shouldn't new power be added to the linux kernel
     Do all features and drivers in the linux kernel fully maintain
backwards compat.

Linux will never take the desktop or even come close if you excuses
for developers
     run the show.  Looks like you guys are starting to resemble
Microsoft, DOS had
     the same problems you are having now with regard to graphics and you
     are repeating the same mistakes that made windows and the mac os more
     dominant than *nix in the corporate and retail world.

Grow up and get real, give hardware manufacurers real solid and stable
interfaces
so that they don't have to be in lock-step with the kernel.

Thanks,
     Ian

FLAMES WELCOME

Re: OpenGL-based framebuffer concepts

[Randy.Dunlap]

On Mon, 29 May 2006 20:39:53 -0500 Ian Kester-Haney wrote:

> Well, from the flames you'd expect something to emerge.
> >From an end-user standpoint, you are all raving lunatics.
> 
> Regressions, the graphics subsystem is a regression,
>    back to the days of dos and basic video cad functionality.
>    linux kernel development has switched to a very rapid pace of development
>            internal ABIs and APIs are in a constant state of flux and
> you argue that no
>                  regressions are allowed
>    you support the newest processor and chipset technology and yet
> graphics are text
>           and X windows only?
> I don't suggest that vgacon and fbdev should be dropped, merely that a better
> alternative may be introduces into the -mm kernel.   Using hacks and under
>  appreciated drm and forcing the Corporate Vendors to work between
>  X and the console is a retarded way of doing things.
> 
> So let me offer a suggestion,
>      Add an experimental 'accelfb' system to accompany the basic vgacon
>      Start with the proper code and plug away, us lunatics can test it
>      Merge new functionality while removing old crud.
>      Accelfb should not be forced onto old hardware that can't support it
>      Neither can the kernel rely on third parties to do all the heavy lifting
>            xorg and the distro maintainers
> 
> Backwards Compatibility
>      As far as I can tell, the kernel user-land interface has been
> rapidly changing
>      Why shouldn't new power be added to the linux kernel
>      Do all features and drivers in the linux kernel fully maintain
> backwards compat.
> 
> Linux will never take the desktop or even come close if you excuses
> for developers
>      run the show.  Looks like you guys are starting to resemble
> Microsoft, DOS had
>      the same problems you are having now with regard to graphics and you
>      are repeating the same mistakes that made windows and the mac os more
>      dominant than *nix in the corporate and retail world.
> 
> Grow up and get real, give hardware manufacurers real solid and stable
> interfaces
> so that they don't have to be in lock-step with the kernel.
> 
> Thanks,
>      Ian
> 
> FLAMES WELCOME

sounds more like Flames Invited.

Are you a hardware manufacturer?  i.e., do you work for one or
represent one?  If so, what would it take for you (your company/
your employer) to provide specs for a GPL-compatible-licensed
driver?  or better yet of course, such a driver?

---
~Randy

Fwd: OpenGL-based framebuffer concepts

[Ian Kester-Haney]

Look at it this way,
    by refusing to allow forward progress, many people have to work
around the kernel
    xorg and other developers have had to hack their way around the
kernel limitations
          to get hardware acceleration.
    Don't you think Intel might release a binary driver if the options
were available.
    While legacy systems still exist, they should not hamper the newer ones.
    As long as ATI and Nvidia, Intel and AMD, and Cisco and IBM compete against
          each other closed source and binary drivers are needed.
Does Linux want
          to oppose innovation in graphics and networking.
    It looks like a cockfight to me and that is not good for the image
of developers.

I bet SUSE would rather get the kernel fixed than to hack around it
for XGL and compviz

Regards,
      Ian

Re: OpenGL-based framebuffer concepts

[Alexey Dobriyan]

On Mon, May 29, 2006 at 08:39:53PM -0500, Ian Kester-Haney wrote:
> Backwards Compatibility
>     As far as I can tell, the kernel user-land interface has been
> rapidly changing

My gut feeling is that you don't even know what this "kernel user-land
interface" include.

Post a list of kernel userland breakages you're aware of, so they can
be fixed, OK?. Preferably with version numbers.

>     Why shouldn't new power be added to the linux kernel
>     Do all features and drivers in the linux kernel fully maintain
> backwards compat.
>
> Linux will never take the desktop
Buzzword detected (core dumped)

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >No, to the contrary. suspend/resume can't ever work properly with
> >vgacon and vesafb. It works okay with radeonfb tooday, and in fact
> >radeonfb is neccessary today for saving power over S3.
> 
> But the things is today for many users suspend/resume to RAM works for
> people running X drivers, I know on my laptop that my radeon
> suspends/resumes fine when running vgacon/DRM/accelerated X, it
> doesn't suspend/resume at all well when running vgacon on its own of
> course. or with radeonfb for that matter. so I still believe the
> suspend/resume code for a card can live in userspace if necessary but
> it just shouldn't be part of X... it needs to be part of another
> graphics controller process.

So we are mostly in agreement. I'd prefer to have suspend/resume code
in kernel in cases it is simple... but separate userspace process is
better than having it in X.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > >No, to the contrary. suspend/resume can't ever work properly with
> > >vgacon and vesafb. It works okay with radeonfb tooday, and in fact
> > >radeonfb is neccessary today for saving power over S3.
> >
> > But the things is today for many users suspend/resume to RAM works for
> > people running X drivers, I know on my laptop that my radeon
> > suspends/resumes fine when running vgacon/DRM/accelerated X, it
> > doesn't suspend/resume at all well when running vgacon on its own of
> > course. or with radeonfb for that matter. so I still believe the
> > suspend/resume code for a card can live in userspace if necessary but
> > it just shouldn't be part of X... it needs to be part of another
> > graphics controller process.
>
> So we are mostly in agreement. I'd prefer to have suspend/resume code
> in kernel in cases it is simple... but separate userspace process is
> better than having it in X.

Don't draw any conclusions from saying that suspend/resume works in X
and doesn't work on xx_fb. What matters is that a set of code that can
perform suspend/resumes exists at all. Once a coherent driver model is
designed the relevant code can be moved to the correct place.

Another reason for moving things like this out of X is to allow the
implementation of alternative graphics systems. It makes no sense that
every new graphics system has to develop their own video and keyboard
drivers. ALSA is a good model for this, it is shared by everyone.
Imagine what things would be like if X built in drivers for every
sound card,.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Ian Kester-Haney]

Good Day,

I think this debate boils down ti a few issues that could be easily resolved.
  As far as I can tell, the OpenGL Framebuffer is for an accelerated
console in 2D
  While expecting Intel, ATI and Nvidia to cough up specs for their
cards, a simpler
    implementation of OpenGL for the console could be offered up.
  The existing system works well for most people and a newer system could either
    tranisition from the base or take over if the installer or distro
supports it.
  I don't see the hardware folks releasing all the details, but I can
see them releasing a
    mini-GL driver ala the quake era in LGPL or other comparable liscense.
  It just seems that those of us with Expensive GPUs should be able to
get a better
    console experience.
  I think a main goal would be to allow the existing code to
gracefully release the hardware
    for a different driver to take over, be it a Xorg driver, a GLX
driver, an Open Source driver or
    a binary driver that 'taints' the kernel.  I want X to release to
the console in some cases
    and I want the consoles basic driver to release to the Xorg driver.
Most 'power users' run the binary drivers just fine.

I hope it makes sense to you guys.  I love Linux and want it to get better.
Just as the static /dev gave way to udev, the basic console should
make/prepare the way
    for an accelerated console that uses newer and more powerful
grapics cards to better
    use.

Thank You for reading.
Regards,
           Ian

On 5/30/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 5/30/06, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > > >No, to the contrary. suspend/resume can't ever work properly with
> > > >vgacon and vesafb. It works okay with radeonfb tooday, and in fact
> > > >radeonfb is neccessary today for saving power over S3.
> > >
> > > But the things is today for many users suspend/resume to RAM works for
> > > people running X drivers, I know on my laptop that my radeon
> > > suspends/resumes fine when running vgacon/DRM/accelerated X, it
> > > doesn't suspend/resume at all well when running vgacon on its own of
> > > course. or with radeonfb for that matter. so I still believe the
> > > suspend/resume code for a card can live in userspace if necessary but
> > > it just shouldn't be part of X... it needs to be part of another
> > > graphics controller process.
> >
> > So we are mostly in agreement. I'd prefer to have suspend/resume code
> > in kernel in cases it is simple... but separate userspace process is
> > better than having it in X.
>
> Don't draw any conclusions from saying that suspend/resume works in X
> and doesn't work on xx_fb. What matters is that a set of code that can
> perform suspend/resumes exists at all. Once a coherent driver model is
> designed the relevant code can be moved to the correct place.
>
> Another reason for moving things like this out of X is to allow the
> implementation of alternative graphics systems. It makes no sense that
> every new graphics system has to develop their own video and keyboard
> drivers. ALSA is a good model for this, it is shared by everyone.
> Imagine what things would be like if X built in drivers for every
> sound card,.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> >
> > > >No, to the contrary. suspend/resume can't ever work properly with
> > > >vgacon and vesafb. It works okay with radeonfb tooday, and in fact
> > > >radeonfb is neccessary today for saving power over S3.
> > >
> > > But the things is today for many users suspend/resume to RAM works for
> > > people running X drivers, I know on my laptop that my radeon
> > > suspends/resumes fine when running vgacon/DRM/accelerated X, it
> > > doesn't suspend/resume at all well when running vgacon on its own of
> > > course. or with radeonfb for that matter. so I still believe the
> > > suspend/resume code for a card can live in userspace if necessary but
> > > it just shouldn't be part of X... it needs to be part of another
> > > graphics controller process.
> >
> > So we are mostly in agreement. I'd prefer to have suspend/resume code
> > in kernel in cases it is simple... but separate userspace process is
> > better than having it in X.
>
> Don't draw any conclusions from saying that suspend/resume works in X
> and doesn't work on xx_fb. What matters is that a set of code that can
> perform suspend/resumes exists at all. Once a coherent driver model is
> designed the relevant code can be moved to the correct place.
>

Actually the suspend/resume has to be in userspace, X just re-posts
the video ROM and reloads the registers... so the repost on resume has
to happen... so some component needs to be in userspace..

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> Actually the suspend/resume has to be in userspace, X just re-posts
> the video ROM and reloads the registers... so the repost on resume has
> to happen... so some component needs to be in userspace..

I'd like to see the simple video POST program get finished. All of the
pieces are lying around. A key step missing is to getting klibc added
to the kernel tree which is being worked on.

BenH has the emu86 code. I agree that is simpler to always use emu86
and not bother with vm86. He also pointed out that we need to copy the
image back into the kernel after the ROM runs. Right now you can only
read the ROM image from the sysfs attribute. The ROM code has support
for keeping an image in RAM, it just isn't hooked up to the sysfs
attribute for writing it.

The pci device struct tracks primary vs secondary cards. How does this
reposting work on laptops where the primary ROM may not really be
there? We have the shadow copy, is it always safe to rerun it?

At boot, inside the kernel device driver of the video card there would
be a small piece of logic that check the pci device struct, if
secondary it uses call_userspace() to trigger the reset program. The
driver has to suspend at this point until user space hits an sysfs
attribute and tells it that it is safe to proceed. This mechanism will
allow us to reset secondary cards at boot.

Small programs like this are the same way I would handle mode setting
for cards that have to do it in user space. A normal user could use an
IOCTL to set the mode and then the driver uses call_userspace() to do
the actual mode setting in root context. This lets you set your mode
without being root and it stops you from setting the mode on video
hardware that you don't own. Everything happens through a device node
making it easy for PAM to assign ownership.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> > Actually the suspend/resume has to be in userspace, X just re-posts
> > the video ROM and reloads the registers... so the repost on resume has
> > to happen... so some component needs to be in userspace..
>
> I'd like to see the simple video POST program get finished. All of the
> pieces are lying around. A key step missing is to getting klibc added
> to the kernel tree which is being worked on.

True. But how long is it going to be before klibc is merged?

> BenH has the emu86 code. I agree that is simpler to always use emu86
> and not bother with vm86. He also pointed out that we need to copy the
> image back into the kernel after the ROM runs. Right now you can only
> read the ROM image from the sysfs attribute. The ROM code has support
> for keeping an image in RAM, it just isn't hooked up to the sysfs
> attribute for writing it.

I'll add this to my todo list for the stuff I'm working on. I actually needed 
to figure this out anyway, so...

> The pci device struct tracks primary vs secondary cards. How does this
> reposting work on laptops where the primary ROM may not really be
> there? We have the shadow copy, is it always safe to rerun it?

On laptops where the BIOS may be compressed and stored somewhere I doubt it'd 
be safe to run any parts of that image from a saved copy. It might try 
calling into routines that no longer exist outside the compressed ROM. THat 
could seriously compromise the stability of the system.

> At boot, inside the kernel device driver of the video card there would
> be a small piece of logic that check the pci device struct, if
> secondary it uses call_userspace() to trigger the reset program. The
> driver has to suspend at this point until user space hits an sysfs
> attribute and tells it that it is safe to proceed. This mechanism will
> allow us to reset secondary cards at boot.

Simple and effective. This, as well, is going onto my ever growing list. 
Because of the seriousness of this single issue this is going near the top of 
the "After you get the first bits merged" part.

> Small programs like this are the same way I would handle mode setting
> for cards that have to do it in user space. A normal user could use an
> IOCTL to set the mode and then the driver uses call_userspace() to do
> the actual mode setting in root context. This lets you set your mode
> without being root and it stops you from setting the mode on video
> hardware that you don't own. Everything happens through a device node
> making it easy for PAM to assign ownership.

Good idea and highly effective.

Like I've said, this has gone onto my list. Now to get back to the code... I 
really do want to see about getting this stuff into the kernel ASAP.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> > On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> > > Actually the suspend/resume has to be in userspace, X just re-posts
> > > the video ROM and reloads the registers... so the repost on resume has
> > > to happen... so some component needs to be in userspace..
> >
> > I'd like to see the simple video POST program get finished. All of the
> > pieces are lying around. A key step missing is to getting klibc added
> > to the kernel tree which is being worked on.
>
> True. But how long is it going to be before klibc is merged?

The merged tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git

I don't know the plans for when the final merge will happen.

A standalone version of klibc is also available here:
http://www.kernel.org/pub/linux/libs/klibc/
Looks like version 1.3 is the latest

The standalone version is perfectly fine for development. You only
need to worry about the kernel tree version when it everything is
finished. I've used klibc for several apps like this and it is a great
tool. The binaries it produces are tiny.

vbetool is a good way to practice resetting the cards if you do the
mods to /sys/class/firmware. The other features like emu86 support can
be added later.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 31 May 2006 04:02, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> > On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> > > On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> > > > Actually the suspend/resume has to be in userspace, X just re-posts
> > > > the video ROM and reloads the registers... so the repost on resume
> > > > has to happen... so some component needs to be in userspace..
> > >
> > > I'd like to see the simple video POST program get finished. All of the
> > > pieces are lying around. A key step missing is to getting klibc added
> > > to the kernel tree which is being worked on.
> >
> > True. But how long is it going to be before klibc is merged?
>
> The merged tree is here:
> git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git

At the moment I don't have a connection that makes gits useful... I'm hoping 
to upgrade my connection within the next two months, but finances (for me) 
are never certain because bills come in seemingly at random.

> I don't know the plans for when the final merge will happen.
>
> A standalone version of klibc is also available here:
> http://www.kernel.org/pub/linux/libs/klibc/
> Looks like version 1.3 is the latest

I'll have to install it, then. But none of my work in the kernel is going to 
depend on it until it is merged into Linus' tree.

> The standalone version is perfectly fine for development. You only
> need to worry about the kernel tree version when it everything is
> finished. I've used klibc for several apps like this and it is a great
> tool. The binaries it produces are tiny.
>
> vbetool is a good way to practice resetting the cards if you do the
> mods to /sys/class/firmware. The other features like emu86 support can
> be added later.

As I said, I will be taking a look at it in the hopes that I can assist them 
once I get most of the framework layed down.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> Like I've said, this has gone onto my list. Now to get back to the code... I
> really do want to see about getting this stuff into the kernel ASAP.

You might want to leave the DRM hot potato alone for a while and just
work on fbdev. Fbdev is smaller and it is easier to get changes
accepted.

A small project would be to get secondary adapter reset working. I
believe the work would be well received by the fbdev people.

You can start by using vbetool with a slight modification to get the
ROM image from sysfs
Then add the check in fbcore to see if it is a secondary adapter.
Modify /sys/class/firmware/ to handle generic helpers instead of just
the firmware one
After you get that going make the real reset app with emu86 support, etc
Finally modify the ROM attribute so that you can write the altered ROM
image back in
Keep everything as a separate project until the kernel (klibc merge)
tree is ready to accept it

This is not a big project but it could take up to a month to complete
since you need to familiarize yourself with how everything works.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> > Like I've said, this has gone onto my list. Now to get back to the
> > code... I really do want to see about getting this stuff into the kernel
> > ASAP.
>
> You might want to leave the DRM hot potato alone for a while and just
> work on fbdev. Fbdev is smaller and it is easier to get changes
> accepted.

Yes, but I have accepted that there is a certain direction and order the 
maintainers want things done in. For this reason I can't just leave DRM 
alone.

> A small project would be to get secondary adapter reset working. I
> believe the work would be well received by the fbdev people.
>
> You can start by using vbetool with a slight modification to get the
> ROM image from sysfs
> Then add the check in fbcore to see if it is a secondary adapter.
> Modify /sys/class/firmware/ to handle generic helpers instead of just
> the firmware one
> After you get that going make the real reset app with emu86 support, etc
> Finally modify the ROM attribute so that you can write the altered ROM
> image back in
> Keep everything as a separate project until the kernel (klibc merge)
> tree is ready to accept it
>
> This is not a big project but it could take up to a month to complete
> since you need to familiarize yourself with how everything works.

On the list already, almost exactly as you describer it. It's going to wait 
until I have a solid framework layed out.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> > On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > Like I've said, this has gone onto my list. Now to get back to the
> > > code... I really do want to see about getting this stuff into the kernel
> > > ASAP.
> >
> > You might want to leave the DRM hot potato alone for a while and just
> > work on fbdev. Fbdev is smaller and it is easier to get changes
> > accepted.
>
> Yes, but I have accepted that there is a certain direction and order the
> maintainers want things done in. For this reason I can't just leave DRM
> alone.

fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie
<airlied@gmail.com>) have two different maintainers. I have not seen
Tony comment on what he thinks of Dave's plans so I don't know what
his position is how driver merging can be acomplished.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Wednesday 31 May 2006 04:39, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> > On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> > > On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > > Like I've said, this has gone onto my list. Now to get back to the
> > > > code... I really do want to see about getting this stuff into the
> > > > kernel ASAP.
> > >
> > > You might want to leave the DRM hot potato alone for a while and just
> > > work on fbdev. Fbdev is smaller and it is easier to get changes
> > > accepted.
> >
> > Yes, but I have accepted that there is a certain direction and order the
> > maintainers want things done in. For this reason I can't just leave DRM
> > alone.
>
> fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie
> <airlied@gmail.com>) have two different maintainers. I have not seen
> Tony comment on what he thinks of Dave's plans so I don't know what
> his position is how driver merging can be acomplished.

True, and neither have I. But lacking Tony's comment I have to trust Dave's 
statement that the direction he has pointed me in is the one settled on at 
the last Kernel Summit.

DRH

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
>> On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
>> > On 5/30/06, D. Hazelton <dhazelton@enter.net> wrote:
>> > > Like I've said, this has gone onto my list. Now to get back to the
>> > > code... I really do want to see about getting this stuff into the
>> kernel
>> > > ASAP.
>> >
>> > You might want to leave the DRM hot potato alone for a while and just
>> > work on fbdev. Fbdev is smaller and it is easier to get changes
>> > accepted.
>>
>> Yes, but I have accepted that there is a certain direction and order the
>> maintainers want things done in. For this reason I can't just leave DRM
>> alone.
> 
> fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie
> <airlied@gmail.com>) have two different maintainers. I have not seen
> Tony comment on what he thinks of Dave's plans so I don't know what
> his position is how driver merging can be acomplished.
> 

A minimal framebuffer driver is nothing but a pointer to a structure
(struct fb_info) which contains a pointer to a memory and the description
of the layout of this memory. There is nothing there that absolutely
requires the services of the kernel, nor requires touching the hardware.
If you look at vesafb, the only time it touches the hardware is in
setcolreg (only if in pseudocolor), and pan_display, which is an optional
function.

The point here is that you can do the mode setting anywhere, including in
userland.  Describe this mode as struct fb_info and register it to
the framebuffer core, you already have a working driver and a working
console.

So, it should be easy enough to write a kernel framebuffer module that
listens to userland, waiting for a struct fb_info to arrive. The userland
driver can be anything, it can be a simple driver that executes a few VBE
function calls, or a driver that uses a library, such as svgalib or Xorg.
Add a few user API's for setcolreg and pan_display, and it will be a complete
driver. Optionally, to fully accelerate the console, we only need these in X:

ScreenToScreenCopy
SolidFill
CPUToScreenColorExpand

Once the X library is used for this userland driver, we have eliminated the
problem of fbdev conflicting with X or DRM. (This assumes that we can load
an X instance at bare minimum, ie, without capturing the keyboard or the mouse).

I believe that there will be problems that I haven't foreseen (trustworthiness
of this driver?), but personally it's the best way to go, as we can work on
one subsystem without affecting the others and without breaking compatibility.
It should also be easy to work on, as the framebuffer layer has the simplest
architecture among the three.

Tony 



  




  

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> A minimal framebuffer driver is nothing but a pointer to a structure
> (struct fb_info) which contains a pointer to a memory and the description
> of the layout of this memory. There is nothing there that absolutely
> requires the services of the kernel, nor requires touching the hardware.
> If you look at vesafb, the only time it touches the hardware is in
> setcolreg (only if in pseudocolor), and pan_display, which is an optional
> function.
>
> The point here is that you can do the mode setting anywhere, including in
> userland.  Describe this mode as struct fb_info and register it to
> the framebuffer core, you already have a working driver and a working
> console.
>
> So, it should be easy enough to write a kernel framebuffer module that
> listens to userland, waiting for a struct fb_info to arrive. The userland
> driver can be anything, it can be a simple driver that executes a few VBE
> function calls, or a driver that uses a library, such as svgalib or Xorg.
> Add a few user API's for setcolreg and pan_display, and it will be a complete
> driver. Optionally, to fully accelerate the console, we only need these in X:
>
> ScreenToScreenCopy
> SolidFill
> CPUToScreenColorExpand
>
> Once the X library is used for this userland driver, we have eliminated the
> problem of fbdev conflicting with X or DRM. (This assumes that we can load
> an X instance at bare minimum, ie, without capturing the keyboard or the mouse).
>
> I believe that there will be problems that I haven't foreseen (trustworthiness
> of this driver?), but personally it's the best way to go, as we can work on
> one subsystem without affecting the others and without breaking compatibility.
> It should also be easy to work on, as the framebuffer layer has the simplest
> architecture among the three.

I'm with most of this it's when you get to the 'everything' in user
space part that I have concerns.

1) I think we have to maintain a device node and something like an
IOCTL interface. This allows a normal user to control the device
without needing root. I'm fine with the idea of the kernel driver
calling out to user space helpers. Not needing root to run the main X
server is a big issue for me.

2) I'd prefer the model of calling out to helper apps that exit
instead of having persistent daemons. Daemons can die and there is
difficulty in telling if they are unresponsive and need to be
restarted. I also think the callouts will be infrequent so why keep a
daemon hanging around. This implies a few things need to be cached in
the kernel driver, like the list of legal modes and the altered ROM
image.

3) fbdev, DRM and EXA are all programming the acceleration hardware.
This needs to move to a single interface. I'd suggest using DRM to
achieve acceleration and then modify the other two subsystems to call
it.

4) Some things are so tiny it is pointless to move them to user space
and they need root to work. Things like screen blank, set the hardware
cursor, set the cmap, etc. I think these are best implemented as
additions to the DRM driver.

5) All of this has to be small enough to fit into initramfs if we're
going to have a boot console on non-VGA systems.

6) There is no need to require a bounce out to user space and back for
these calls: ScreenToScreenCopy, SolidFill, CPUToScreenColorExpand.
DRM can optionally implement in-kernel entry points for these.

7) Since there isn't much left to a device specific fbdev driver after
you push mode setting out to user space, I would just add the
remaining functions to the device specific DRM driver. But that would
be 'evil' since it merges fbdev and DRM.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 5/31/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> A minimal framebuffer driver is nothing but a pointer to a structure
>> (struct fb_info) which contains a pointer to a memory and the description
>> of the layout of this memory. There is nothing there that absolutely
>> requires the services of the kernel, nor requires touching the hardware.
>> If you look at vesafb, the only time it touches the hardware is in
>> setcolreg (only if in pseudocolor), and pan_display, which is an optional
>> function.
>>
>> The point here is that you can do the mode setting anywhere, including in
>> userland.  Describe this mode as struct fb_info and register it to
>> the framebuffer core, you already have a working driver and a working
>> console.
>>
>> So, it should be easy enough to write a kernel framebuffer module that
>> listens to userland, waiting for a struct fb_info to arrive. The userland
>> driver can be anything, it can be a simple driver that executes a few VBE
>> function calls, or a driver that uses a library, such as svgalib or Xorg.
>> Add a few user API's for setcolreg and pan_display, and it will be a
>> complete
>> driver. Optionally, to fully accelerate the console, we only need
>> these in X:
>>
>> ScreenToScreenCopy
>> SolidFill
>> CPUToScreenColorExpand
>>
>> Once the X library is used for this userland driver, we have
>> eliminated the
>> problem of fbdev conflicting with X or DRM. (This assumes that we can
>> load
>> an X instance at bare minimum, ie, without capturing the keyboard or
>> the mouse).
>>
>> I believe that there will be problems that I haven't foreseen
>> (trustworthiness
>> of this driver?), but personally it's the best way to go, as we can
>> work on
>> one subsystem without affecting the others and without breaking
>> compatibility.
>> It should also be easy to work on, as the framebuffer layer has the
>> simplest
>> architecture among the three.
> 
> I'm with most of this it's when you get to the 'everything' in user
> space part that I have concerns.
> 
> 1) I think we have to maintain a device node and something like an
> IOCTL interface. This allows a normal user to control the device
> without needing root. I'm fine with the idea of the kernel driver
> calling out to user space helpers. Not needing root to run the main X
> server is a big issue for me.
> 
> 2) I'd prefer the model of calling out to helper apps that exit
> instead of having persistent daemons. Daemons can die and there is
> difficulty in telling if they are unresponsive and need to be
> restarted. I also think the callouts will be infrequent so why keep a
> daemon hanging around. This implies a few things need to be cached in
> the kernel driver, like the list of legal modes and the altered ROM
> image.

Does not matter.
 
> 
> 3) fbdev, DRM and EXA are all programming the acceleration hardware.
> This needs to move to a single interface. I'd suggest using DRM to
> achieve acceleration and then modify the other two subsystems to call
> it.

Programming 2D is entirely optional in terms of fbdev.  It's only user
is fbcon.  You can leave 2D to DRM or X if you want.

> 
> 4) Some things are so tiny it is pointless to move them to user space
> and they need root to work. Things like screen blank, set the hardware
> cursor, set the cmap, etc. I think these are best implemented as
> additions to the DRM driver.

These small things (cmap, blanking) are sometimes difficult to do, and
the driver is not always right about that. A user helper may be needed.
vesafb in x86_64 may not be able to set the cmap properly without calling
out to the BIOS.

> 
> 5) All of this has to be small enough to fit into initramfs if we're
> going to have a boot console on non-VGA systems.

We can always leave fbdev drivers in the kernel for architectures where
they're the only ones available.

> 
> 6) There is no need to require a bounce out to user space and back for
> these calls: ScreenToScreenCopy, SolidFill, CPUToScreenColorExpand.
> DRM can optionally implement in-kernel entry points for these.

Agree, fbdev does not require acceleration to be fast.  This is something
we can leave out. As mentioned in another thread, an unaccelerated fbdev
driver can have comparable performance with a pure text mode driver.

> 
> 7) Since there isn't much left to a device specific fbdev driver after
> you push mode setting out to user space, I would just add the
> remaining functions to the device specific DRM driver. But that would
> be 'evil' since it merges fbdev and DRM.
> 

Actually, there's no need for a merge as there is nothing in DRM that
is absolutely needed by fbdev or the other way around, as long as
console acceleration is disabled. In-kernel fbdev drivers may not even
be necessary.

Tony

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > 4) Some things are so tiny it is pointless to move them to user space
> > and they need root to work. Things like screen blank, set the hardware
> > cursor, set the cmap, etc. I think these are best implemented as
> > additions to the DRM driver.
>
> These small things (cmap, blanking) are sometimes difficult to do, and
> the driver is not always right about that. A user helper may be needed.
> vesafb in x86_64 may not be able to set the cmap properly without calling
> out to the BIOS.

Call out to user space if it is complex. But it only takes few lines
of code to to these things on a radeon.

> > 7) Since there isn't much left to a device specific fbdev driver after
> > you push mode setting out to user space, I would just add the
> > remaining functions to the device specific DRM driver. But that would
> > be 'evil' since it merges fbdev and DRM.
> >
>
> Actually, there's no need for a merge as there is nothing in DRM that
> is absolutely needed by fbdev or the other way around, as long as
> console acceleration is disabled. In-kernel fbdev drivers may not even
> be necessary.

Something needs to bind to the hardware, that code is in the device
specific fbdev drivers currently. The fbdev drivers also contain those
small functions I mentioned like cmap, cursor, etc. Some of the fbdev
drivers also contain initialization code.

If fbdev is eliminated the DRM code will need to provide a compatible
fbdev device in user space for legacy apps. It makes sense to get that
code from fbdev.

Any concerns about having two device nodes for a single piece of
hardware, fb0 and dri0? Since dri0 has a single user it may be
possible to rework its IOCTLs to use the fb0 device.

As part of multiuser support you need to make one device per head
instead of one device per card. Each independent user needs their own
deivce to control.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Thursday 01 June 2006 02:19, Jon Smirl wrote:
> On 5/31/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > > 4) Some things are so tiny it is pointless to move them to user space
> > > and they need root to work. Things like screen blank, set the hardware
> > > cursor, set the cmap, etc. I think these are best implemented as
> > > additions to the DRM driver.
> >
> > These small things (cmap, blanking) are sometimes difficult to do, and
> > the driver is not always right about that. A user helper may be needed.
> > vesafb in x86_64 may not be able to set the cmap properly without calling
> > out to the BIOS.
>
> Call out to user space if it is complex. But it only takes few lines
> of code to to these things on a radeon.

I'll be working with Tony on a lot of the fbdev side of things. Hopefully we 
won't run into problems providing for backwards compatability.

> > > 7) Since there isn't much left to a device specific fbdev driver after
> > > you push mode setting out to user space, I would just add the
> > > remaining functions to the device specific DRM driver. But that would
> > > be 'evil' since it merges fbdev and DRM.
> >
> > Actually, there's no need for a merge as there is nothing in DRM that
> > is absolutely needed by fbdev or the other way around, as long as
> > console acceleration is disabled. In-kernel fbdev drivers may not even
> > be necessary.
>
> Something needs to bind to the hardware, that code is in the device
> specific fbdev drivers currently. The fbdev drivers also contain those
> small functions I mentioned like cmap, cursor, etc. Some of the fbdev
> drivers also contain initialization code.
>
> If fbdev is eliminated the DRM code will need to provide a compatible
> fbdev device in user space for legacy apps. It makes sense to get that
> code from fbdev.

I've been talking with Tony and this seems to be the direction he'd like to 
take the Kernel. While I'd like to keep the full complement of fbdev drivers 
in the kernel for the embedded people to use (or not) as they please, this 
might not be a good idea.

> Any concerns about having two device nodes for a single piece of
> hardware, fb0 and dri0? Since dri0 has a single user it may be
> possible to rework its IOCTLs to use the fb0 device.
>
> As part of multiuser support you need to make one device per head
> instead of one device per card. Each independent user needs their own
> deivce to control.

I was thinking that the dri? nodes could redirect fb specific IOCTL's 
internally and still maintain the two device nodes. This is actually part of 
not breaking anything, since a lot of legacy apps will look for the dri* or 
fb* nodes.

And yes, providing a device per head is something that needs to happen, if 
just to make things like a multi-head Radeon easier to configure and bring up 
both heads on under X.

As to having seperate devices per user - the only cases this would be really 
required are:
1) Multiple users logged onto different VT's
2) Remote users doing server-side acceleration of graphics

For #1 there is no need for seperate devices, since both users are using the 
same display and input methods (unless configured different - say with 
multiple heads and input devices, in which case the second head would already 
have a node available for it).

For #2 I have no real solution. Personally I think that most of the drawing 
commands that can be accelerated should be left to the remote client. As far 
as a remote client wanting sever side rendering and acceleration... This can 
use the same device node and a seperate rendering buffer.The driver itself 
*should* be able to handle accelerating offscreen and oinscreen rendering at 
the same time.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/31/06, D. Hazelton <dhazelton@enter.net> wrote:
> As to having seperate devices per user - the only cases this would be really
> required are:
> 1) Multiple users logged onto different VT's
> 2) Remote users doing server-side acceleration of graphics
>
> For #1 there is no need for seperate devices, since both users are using the
> same display and input methods (unless configured different - say with
> multiple heads and input devices, in which case the second head would already
> have a node available for it).

WIth multiple users logged into each head the heads need to be
controlled independently. One user might set text mode and the other
1024x768 graphics. The IOCTL will need to list the different modes
available for each monitor. Some matrox cards support three heads so
they get three devices. Things are much simpler if there is one device
node per monitor/head.

This brings up the problem of merged fb support.

1) heads are owned by two different users, no merged fb modes available
2) heads are owned by same user, merged fb modes appear in the mode list
3) if a mode is in the list, then you can set it
4) setting a merged fb mode on one device node will make the other
device node return some kind of error if you try and use it.
5) A head owned by PAM ( no logged in user) functions as a wild card.
If you have control of the other head you can set merged fb mode and
disable PAM.

DRM will need some work to be able to deal with this.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Ondrej Zajicek]

On Wed, May 31, 2006 at 12:39:19AM -0400, Jon Smirl wrote:
> >Yes, but I have accepted that there is a certain direction and order the
> >maintainers want things done in. For this reason I can't just leave DRM
> >alone.
> 
> fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie
> <airlied@gmail.com>) have two different maintainers. I have not seen
> Tony comment on what he thinks of Dave's plans so I don't know what
> his position is how driver merging can be acomplished.

Is there some document describing long-term direction or plans for this?
(another than http://jonsmirl.googlepages.com/graphics.html)
I googled for last Kernel Summit mentioned here but didn't found anything
specific.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Ondrej Zajicek <santiago@mail.cz> wrote:
> On Wed, May 31, 2006 at 12:39:19AM -0400, Jon Smirl wrote:
> > >Yes, but I have accepted that there is a certain direction and order the
> > >maintainers want things done in. For this reason I can't just leave DRM
> > >alone.
> >
> > fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie
> > <airlied@gmail.com>) have two different maintainers. I have not seen
> > Tony comment on what he thinks of Dave's plans so I don't know what
> > his position is how driver merging can be acomplished.
>
> Is there some document describing long-term direction or plans for this?
> (another than http://jonsmirl.googlepages.com/graphics.html)
> I googled for last Kernel Summit mentioned here but didn't found anything
> specific.

I wish everyone involved would write up their positions. It is very
hard trying to determine what someone's overall plan is based on
hundreds of emails spread over multiple lists.

Half of what we are auguring about probably isn't even a real issue,
it is just mistaken perceptions of what the other parties want.

It doesn't even need to be a global write up. I'd just like to see
design write ups for the kernel issues around fbdev, console, DRM
integration, boot display, device nodes, multiuser console, etc. Leave
out everything around X and OpenGL.  Since there aren't very many ways
to solve these problems I suspect everyone is closer together than we
may think.

Without specifying a design here are a few requirements I would have:

1) The kernel subsystem should be agnostic of the display server. The
solution should not be X specific. Any display system should be able
to use it, SDL, Y Windows, Fresco, etc...

2) State inside the hardware is maintained by a single driver. No
hooks for state swapping (ie, save your state, now I'll load mine,
...).

3) A non-root user can control their graphics device.

4) Multiple independent users should work

5) The system needs to be robust. Daemons can be killed by the OOM
mechanism, you don't want to lose your console in the middle of trying
to fix a problem. This also means that you have to be able to display
printk's from inside interrupt handles.

6) Things like panics should be visible no matter what is running. No
more silent deaths.

7) Obviously part of this is going to exist in user space since some
cards can only be controlled by VBIOS calls. Has anyone explored using
the in-kernel protected mode VESA hooks for this?

8) The user space fbdev API has to be maintained for legacy apps. DRM
can be changed if needed since there is only a single user of it, but
there is no obvious need to change it.

9) there needs to be a way to control the mode on each head, merged fb
should also work. Monitor hotplug should work. Video card hot plug
should work. These should all work for console and the display
servers.

10) Console support for complex scripts should get consideration.

11) VGA is x86 specific. Solutions have to work on all architectures.
That implies that the code needed to get a basic console up needs to
fit on initramfs. Use PPC machines as an example.

12) If a driver system is loaded is has to inform the kernel of what
resources it is using.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[David Lang]

On Thu, 1 Jun 2006, Jon Smirl wrote:

> 1) The kernel subsystem should be agnostic of the display server. The
> solution should not be X specific. Any display system should be able
> to use it, SDL, Y Windows, Fresco, etc...
>
> 2) State inside the hardware is maintained by a single driver. No
> hooks for state swapping (ie, save your state, now I'll load mine,
> ...).
>
> 3) A non-root user can control their graphics device.
>
> 4) Multiple independent users should work
>
> 5) The system needs to be robust. Daemons can be killed by the OOM
> mechanism, you don't want to lose your console in the middle of trying
> to fix a problem. This also means that you have to be able to display
> printk's from inside interrupt handles.
>
> 6) Things like panics should be visible no matter what is running. No
> more silent deaths.
>
> 7) Obviously part of this is going to exist in user space since some
> cards can only be controlled by VBIOS calls. Has anyone explored using
> the in-kernel protected mode VESA hooks for this?
>
> 8) The user space fbdev API has to be maintained for legacy apps. DRM
> can be changed if needed since there is only a single user of it, but
> there is no obvious need to change it.
>
> 9) there needs to be a way to control the mode on each head, merged fb
> should also work. Monitor hotplug should work. Video card hot plug
> should work. These should all work for console and the display
> servers.
>
> 10) Console support for complex scripts should get consideration.
>
> 11) VGA is x86 specific. Solutions have to work on all architectures.
> That implies that the code needed to get a basic console up needs to
> fit on initramfs. Use PPC machines as an example.
>
> 12) If a driver system is loaded is has to inform the kernel of what
> resources it is using.
>

13) for hardware that supports it a text mode should be supported

David Lang

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Thursday 01 June 2006 14:59, David Lang wrote:
> On Thu, 1 Jun 2006, Jon Smirl wrote:
> > 1) The kernel subsystem should be agnostic of the display server. The
> > solution should not be X specific. Any display system should be able
> > to use it, SDL, Y Windows, Fresco, etc...

Stated goal of mine already.

> > 2) State inside the hardware is maintained by a single driver. No
> > hooks for state swapping (ie, save your state, now I'll load mine,
> > ...).

Thanks to Tony's input this has become a reachable goal. DRM will be the only 
system, save in those cases (like PPC) where fbdev is needed to provide a 
boot console. In those cases the fb driver will be removed when the DRM 
driver is ready to take over.

> > 3) A non-root user can control their graphics device.

Stated goal

> > 4) Multiple independent users should work

Stated goal

> > 5) The system needs to be robust. Daemons can be killed by the OOM
> > mechanism, you don't want to lose your console in the middle of trying
> > to fix a problem. This also means that you have to be able to display
> > printk's from inside interrupt handles.

Point of disagreement. Tons of userspace helpers isn't a good choice.

I don't know about doing a printk from inside interrupt context - the current 
architecture doesn't, IIRC, support printk from inside interrupt context for 
certain drivers for various reasons.

> > 6) Things like panics should be visible no matter what is running. No
> > more silent deaths.

Stated goal

> > 7) Obviously part of this is going to exist in user space since some
> > cards can only be controlled by VBIOS calls. Has anyone explored using
> > the in-kernel protected mode VESA hooks for this?

I'll look into this, though I suspect Tony will have the solution first.

> > 8) The user space fbdev API has to be maintained for legacy apps. DRM
> > can be changed if needed since there is only a single user of it, but
> > there is no obvious need to change it.

I was planning on having drmcon maintain a complete "compatability" API for 
the fb* device nodes. 

> > 9) there needs to be a way to control the mode on each head, merged fb
> > should also work. Monitor hotplug should work. Video card hot plug
> > should work. These should all work for console and the display
> > servers.

With drmcon this should be possible. I haven't finished working out the 
problems with the drmcon implementation yet (in other words: I'm still trying 
to figure out a decent method of giving the kernel the minimal DRI stuff 
it'll need to make drmcon a reality)

> > 10) Console support for complex scripts should get consideration.

If drmcon works then using FreeType or the X Font server for providing console 
fonts shouldn't be too hard.

> > 11) VGA is x86 specific. Solutions have to work on all architectures.
> > That implies that the code needed to get a basic console up needs to
> > fit on initramfs. Use PPC machines as an example.

After a lot of discussion with Dave and Tony about this we've decided that 
fbcon (for those systems that need it) will be the default boot display and 
DRM will take over and unload it when it's capable of taking over.

> > 12) If a driver system is loaded is has to inform the kernel of what
> > resources it is using.

This is one of my goals.

> 13) for hardware that supports it a text mode should be supported

This is a given :)

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > 5) The system needs to be robust. Daemons can be killed by the OOM
> > > mechanism, you don't want to lose your console in the middle of trying
> > > to fix a problem. This also means that you have to be able to display
> > > printk's from inside interrupt handles.
>
> Point of disagreement. Tons of userspace helpers isn't a good choice.

Where do you get 'tons'? There will probably be one for initial reset,
one for VESA based mode setting and a few more if there is device
specific code needed for a specific card.

Making console rely on a permanent daemon that is subject to getting
killed by the OOM mechanism is not a workable solution.

You also need to think about how cursors are handled. A non-root app
needs to be able to move the cursor. Actually moving the cursor
requires root. The in-kernel console system needs a cursor. It would
be much better if cursor control was implemented in the device
drivers.

> I don't know about doing a printk from inside interrupt context - the current
> architecture doesn't, IIRC, support printk from inside interrupt context for
> certain drivers for various reasons.

Printk works from inside interrupt handlers currently. This is an
absolute requirement for kernel debugging that can't be removed.
Because of this requirement there has to be a way for all drivers to
draw the console entirely inside the kernel. You can not make calls to
user space from inside interrupt handlers.

> > > 6) Things like panics should be visible no matter what is running. No
> > > more silent deaths.

Panics can occur inside interrupt handlers. You can't queue up printks
in this context and they display them later, the kernel just died,
there is no later.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Thursday 01 June 2006 20:35, Jon Smirl wrote:
> On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > > 5) The system needs to be robust. Daemons can be killed by the OOM
> > > > mechanism, you don't want to lose your console in the middle of
> > > > trying to fix a problem. This also means that you have to be able to
> > > > display printk's from inside interrupt handles.
> >
> > Point of disagreement. Tons of userspace helpers isn't a good choice.
>
> Where do you get 'tons'? There will probably be one for initial reset,
> one for VESA based mode setting and a few more if there is device
> specific code needed for a specific card.
>
> Making console rely on a permanent daemon that is subject to getting
> killed by the OOM mechanism is not a workable solution.
>
> You also need to think about how cursors are handled. A non-root app
> needs to be able to move the cursor. Actually moving the cursor
> requires root. The in-kernel console system needs a cursor. It would
> be much better if cursor control was implemented in the device
> drivers.

Yes, the basic console will only require a few helpers. I get "tons" because 
that's what it would take to provide all the acceleration features to 
userspace. The daemon is *only* there to provide those acceleration features. 
The kernel itself has it's own minimal interface to drmcon that lets it work 
without userspace. The userspace side is for userspace. (Though the kernel 
will only work in a specific set mode without the userspace helpers for 
setting the mode)

Cursor control will be entirely within the driver :)

> > I don't know about doing a printk from inside interrupt context - the
> > current architecture doesn't, IIRC, support printk from inside interrupt
> > context for certain drivers for various reasons.
>
> Printk works from inside interrupt handlers currently. This is an
> absolute requirement for kernel debugging that can't be removed.
> Because of this requirement there has to be a way for all drivers to
> draw the console entirely inside the kernel. You can not make calls to
> user space from inside interrupt handlers.

Hrm... I was thinking that it didn't work for sending to net and serial 
consoles because doing such might generate an interrupt.

> > > > 6) Things like panics should be visible no matter what is running. No
> > > > more silent deaths.
>
> Panics can occur inside interrupt handlers. You can't queue up printks
> in this context and they display them later, the kernel just died,
> there is no later.

Of course. It is one of my goals to keep those silent deaths from occuring. 
AAMOF, that was one of my reasons for this project.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> On Thursday 01 June 2006 20:35, Jon Smirl wrote:
> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > > > 5) The system needs to be robust. Daemons can be killed by the OOM
> > > > > mechanism, you don't want to lose your console in the middle of
> > > > > trying to fix a problem. This also means that you have to be able to
> > > > > display printk's from inside interrupt handles.
> > >
> > > Point of disagreement. Tons of userspace helpers isn't a good choice.
> >
> > Where do you get 'tons'? There will probably be one for initial reset,
> > one for VESA based mode setting and a few more if there is device
> > specific code needed for a specific card.
> >
> > Making console rely on a permanent daemon that is subject to getting
> > killed by the OOM mechanism is not a workable solution.
> >
> > You also need to think about how cursors are handled. A non-root app
> > needs to be able to move the cursor. Actually moving the cursor
> > requires root. The in-kernel console system needs a cursor. It would
> > be much better if cursor control was implemented in the device
> > drivers.
>
> Yes, the basic console will only require a few helpers. I get "tons" because
> that's what it would take to provide all the acceleration features to
> userspace. The daemon is *only* there to provide those acceleration features.
> The kernel itself has it's own minimal interface to drmcon that lets it work
> without userspace. The userspace side is for userspace. (Though the kernel
> will only work in a specific set mode without the userspace helpers for
> setting the mode)

You don't need a ton of helpers for acceleration, Mesa already supports this.

Handling accelerated console is discussed in my paper, but here are
the highlights.

If you examine console you will see that there are two kinds of users,
normal people running emacs/etc and system management needs like
panics and single user mode. Normal users want acceleration, system
management needs absolute robustness. Currently these two uses are
mixed up into a single console,. I think they should be separated
since they clearly have different requirements.

One solution to this split is to build the system management console
in-kernel using the existing fbdev code. A hot key can be used to
access it or it will appear automatically on a panic. The system
management console does not need acceleration, but it always has to
work and work in any context (like interrupt context). Working in any
context forces an implementation that is entirely contained in the
kernel.

For a normal user's accelerated console, build one in user space, use
Mesa or whatever. I'm not going to start a debate on this point. Once
you are in user space you can add Asian language support too.

For people that refuse to use the user space console they can use the
system management mode. If you really want to accelerate this console
you will have to add entry points to the DRM driver; the
implementation of the system management console has to stay entirely
inside the kernel. Since there is only going to be one set of
acceleration code, the entry points have to go in the DRM driver. I
would not recommend doing this because it won't be safe to use the
acceleration hardware in all cases where the system management console
may need to print.

If people are going to whine about the size of Mesa they can implement
OpenGL/ES on top of DRM. Since there is a commercial OpenGL/ES
implementation that is 100K it is proven that this can be done with a
tiny library. All that has to happen is for someone to write the
library. If you really want to whine build a 2D only library on top of
DRM.

Since the system management console can pop up at anytime and in the
context of an unstable system, I really think it should be designed to
use the currently active mode instead of trying to change the mode.
Changing the mode may require a trip to user space and user space may
be dead. The fbdev code already knows how to draw into any framebuffer
format from kernel context.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

> One solution to this split is to build the system management console
> in-kernel using the existing fbdev code. A hot key can be used to
> access it or it will appear automatically on a panic. The system
> management console does not need acceleration, but it always has to
> work and work in any context (like interrupt context). Working in any
> context forces an implementation that is entirely contained in the
> kernel.

And what happens if that console data has been damaged by a wild pointer write 
in kernel?

This does have a practicle use, and the console data for the "System Console" 
is unlikely to get screwed with. I am just pointing out that there are 
problems even with your suggestions. I had already planned on something 
similar to this when I began working on a method to have the video drivers 
able to be added and removed at runtime. What I was planning on was using 
vgacon (for those systems that support it) as the system console and having 
tthe system default back to that should *anything* go wrong in the kernel. 
For the systems that don't support vgacon there is going to be a very minimal 
fbcon that will serve the same purpose.

Userspace helpers for modesetting and other simple tasks is no problem. When 
it comes to handling the acceleration, the DRI part  of the DRM 
infrastructure (the Userspace side of it, in other words) needs to be running 
and available. This is why X has to load the module. Providing that to 
userspace then become a concern, and the easiest way to do this is to have 
the DRI portion loaded and running inside a userspace daemon, either pinned 
into memory so that the OOM killer can't touch it, or running as a special 
process under init that will *always* get restarted if it dies.

Using a mass of userspace helpers, or requiring the applications to provide 
and load their own userspace drivers for the DRM/DRI system is, IMHO, not an 
option.

DRH

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> 
> Printk works from inside interrupt handlers currently. This is an
> absolute requirement for kernel debugging that can't be removed.
> Because of this requirement there has to be a way for all drivers to
> draw the console entirely inside the kernel. You can not make calls to
> user space from inside interrupt handlers.
> 
>> > > 6) Things like panics should be visible no matter what is running. No
>> > > more silent deaths.
> 
> Panics can occur inside interrupt handlers. You can't queue up printks
> in this context and they display them later, the kernel just died,
> there is no later.
> 

Console writes are done with the console semaphore held. printk will also
just write to the log buffer and defer the actual console printing
for later, by the next or current process that will grab the semaphore.

Tony

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> >
> > Printk works from inside interrupt handlers currently. This is an
> > absolute requirement for kernel debugging that can't be removed.
> > Because of this requirement there has to be a way for all drivers to
> > draw the console entirely inside the kernel. You can not make calls to
> > user space from inside interrupt handlers.
> >
> >> > > 6) Things like panics should be visible no matter what is running. No
> >> > > more silent deaths.
> >
> > Panics can occur inside interrupt handlers. You can't queue up printks
> > in this context and they display them later, the kernel just died,
> > there is no later.
> >
>
> Console writes are done with the console semaphore held. printk will also
> just write to the log buffer and defer the actual console printing
> for later, by the next or current process that will grab the semaphore.

That was my original position too. But Alan Cox has drilled it into me
that this is not acceptable for printks in interrupt context, they
need to print there and not be deferred.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
>> >
>>
>> Console writes are done with the console semaphore held. printk will also
>> just write to the log buffer and defer the actual console printing
>> for later, by the next or current process that will grab the semaphore.
> 
> That was my original position too. But Alan Cox has drilled it into me
> that this is not acceptable for printks in interrupt context, they
> need to print there and not be deferred.
> 

Just to clarify, it's not my position, that's how the current printk code
works.

Tony

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> Jon Smirl wrote:
> >> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> >> >
> >>
> >> Console writes are done with the console semaphore held. printk will also
> >> just write to the log buffer and defer the actual console printing
> >> for later, by the next or current process that will grab the semaphore.
> >
> > That was my original position too. But Alan Cox has drilled it into me
> > that this is not acceptable for printks in interrupt context, they
> > need to print there and not be deferred.
> >
>
> Just to clarify, it's not my position, that's how the current printk code
> works.

I haven't looked at the code, but if there is just normal console
running and nothing like X is around, doesn't the console system
always have the semaphore? If it always has the semaphore then
interupt context printk's aren't blocked.

I think that interrupt context printk's work today, I have definitely
seen one printk get inserted into the middle of another on my console.
How else could you achieve that?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Čt 01-06-06 17:48:57, Jon Smirl wrote:
> On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >Jon Smirl wrote:
> >> On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >>> Jon Smirl wrote:
> >>> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> >>> >
> >>>
> >>> Console writes are done with the console semaphore held. printk will 
> >also
> >>> just write to the log buffer and defer the actual console printing
> >>> for later, by the next or current process that will grab the semaphore.
> >>
> >> That was my original position too. But Alan Cox has drilled it into me
> >> that this is not acceptable for printks in interrupt context, they
> >> need to print there and not be deferred.
> >>
> >
> >Just to clarify, it's not my position, that's how the current printk code
> >works.
> 
> I haven't looked at the code, but if there is just normal console
> running and nothing like X is around, doesn't the console system
> always have the semaphore? 

Not if foreground code is already printing something. Fortunately we
do not spend most of time printing text; that's why printk from
interrupt usually works.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/1/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> Jon Smirl wrote:
>> >> > On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
>> >> >
>> >>
>> >> Console writes are done with the console semaphore held. printk
>> will also
>> >> just write to the log buffer and defer the actual console printing
>> >> for later, by the next or current process that will grab the
>> semaphore.
>> >
>> > That was my original position too. But Alan Cox has drilled it into me
>> > that this is not acceptable for printks in interrupt context, they
>> > need to print there and not be deferred.
>> >
>>
>> Just to clarify, it's not my position, that's how the current printk code
>> works.
> 
> I haven't looked at the code, but if there is just normal console
> running and nothing like X is around, doesn't the console system
> always have the semaphore? If it always has the semaphore then
> interupt context printk's aren't blocked.
> 
> I think that interrupt context printk's work today, I have definitely
> seen one printk get inserted into the middle of another on my console.
> How else could you achieve that?
> 

foreground calls acquire_console_sem()
foreground process does a printk, printk writes to log buffer
interrupt-> does a printk -> message inserted to log buffer
foreground process calls release_console_sem
release_console_sem() dumps log buffer contents to console driver

Tony

Re: OpenGL-based framebuffer concepts

[Andrew Morton]

"Antonino A. Daplas" <adaplas@gmail.com> wrote:
>
> Console writes are done with the console semaphore held. printk will also
> just write to the log buffer and defer the actual console printing
> for later, by the next or current process that will grab the semaphore.

Always by the current process which holds console_sem.  Leaving the printing
for the next process would be unacceptably too late for printk.

If printk sees that someone holds console_sem, printk will leave the data
in the log buffer for the current holder of console_sem to print, prior to
that caller releasing console_sem.  logbuf_log is used in tricky ways
around console_sem to prevent races in this logic.

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Andrew Morton wrote:
> "Antonino A. Daplas" <adaplas@gmail.com> wrote:
>> Console writes are done with the console semaphore held. printk will also
>> just write to the log buffer and defer the actual console printing
>> for later, by the next or current process that will grab the semaphore.
> 
> Always by the current process which holds console_sem.  Leaving the printing
> for the next process would be unacceptably too late for printk.

I stand corrected. Thank you.

Tony

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

\
> Where do you get 'tons'? There will probably be one for initial reset,
> one for VESA based mode setting and a few more if there is device
> specific code needed for a specific card.
>
> Making console rely on a permanent daemon that is subject to getting
> killed by the OOM mechanism is not a workable solution.

Jon stop trying to hammer everyone by repeating ad-nauseum statements
of little importance...

We can stop the OOM killer from killing the daemon if necessary.
running device drivers in userspace would sort of require this, we can
run the daemon from init and if it dies, have it respawn, it could put
persistent info in a shared memory segment provided by the DRM, just
because you can't think of any way around things, doesn't mean the
rest of us can't..

The same things apples to a lot of your other "issues" a /dev/ with
permissions is no more or less useful than a /tmp/.grphs_socket1 and 2
with permissions, you insistence that everything be controlled via the
kernel is another thing you've just failed to think about rather than
hammer on about it *must* do this.

I'm spending more time rebutting points you repeatedly make, please
accept that there are other solutions, and everytime you post a list
of things *YOU* believe *MUST* be done, remove the things we've shown
are possible to be done other ways...

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> Jon stop trying to hammer everyone by repeating ad-nauseum statements
> of little importance...

If you can not restraint yourself to making technical arguments,
please stop posing to LKML.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> > Jon stop trying to hammer everyone by repeating ad-nauseum statements
> > of little importance...
>
> If you can not restraint yourself to making technical arguments,
> please stop posing to LKML.

Jon,

you have over the past 2 or so years, posted over and over the same
list of technical points that you consider necessary, numerous times I
and others have pointed alternative methods to achieve what you wanted
that would be equally or more acceptable, you return to the list and
others repeating your list of points without editing, you then force
me to repeat things I've stated numerous times previously, I for one
get very bored of this and it really doesn't help anyone, I feel like
NASA refuting the people who say man never walked on the moon,

You snipped my technical arguments by the way so I'll yet again repeat them:

We can stop the OOM killer from killing the daemon if necessary.
running device drivers in userspace would sort of require this, we can
run the daemon from init and if it dies, have it respawn, it could put
persistent info in a shared memory segment provided by the DRM, just
because you can't think of any way around things, doesn't mean the
rest of us can't..

a /dev/ with permissions is no more or less useful than a
/tmp/.grphs_socket1 and 2
with permissions,

Please discuss,
Dave.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> We can stop the OOM killer from killing the daemon if necessary.
> running device drivers in userspace would sort of require this, we can
> run the daemon from init and if it dies, have it respawn, it could put
> persistent info in a shared memory segment provided by the DRM, just
> because you can't think of any way around things, doesn't mean the
> rest of us can't..
>
> a /dev/ with permissions is no more or less useful than a
> /tmp/.grphs_socket1 and 2
> with permissions,

/dev/devices have a standard system design in the kernel with h files
and ioctls. Why create a new communication protocol when a standard
one exists? How is a printk generated in the kernel going to find this
socket and get the printk message into it?

You have a panic in an interrupt handler. User space is messed up
because of wild pointer writes in the kernel. Your display process has
been swapped out. How are you going to display the panic message?

How does a process protected from the OOM killer that is also pinned
into memory differ from just being part of the kernel? Is creating a
process like this and building a communication system worth it just to
get address space separation?

Why don't you write up a comprehensive design for your system and post
it for all to read. It is difficult to piece together an overall
picture from 100s of emails talking about specific features. To do
this right  you have to address everything from fbdev to X to SDL to
i8n. There were 13 design requirements posted earlier, can your system
satisfy all of those?

Any designs you propose have to be able to stand up to questioning
like this. It is much better to deal with the problems as questions
rather than to find them after the code is written.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Čt 01-06-06 20:45:20, Jon Smirl wrote:
> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> >We can stop the OOM killer from killing the daemon if necessary.
> >running device drivers in userspace would sort of require this, we can
> >run the daemon from init and if it dies, have it respawn, it could put
> >persistent info in a shared memory segment provided by the DRM, just
> >because you can't think of any way around things, doesn't mean the
> >rest of us can't..
> >
> >a /dev/ with permissions is no more or less useful than a
> >/tmp/.grphs_socket1 and 2
> >with permissions,
> 
> /dev/devices have a standard system design in the kernel with h files
> and ioctls. Why create a new communication protocol when a standard
> one exists? How is a printk generated in the kernel going to find this
> socket and get the printk message into it?
> 
> You have a panic in an interrupt handler. User space is messed up
> because of wild pointer writes in the kernel. Your display process has
> been swapped out. How are you going to display the panic message?

Well, daemon vs. standalone binaries make no difference here.

> How does a process protected from the OOM killer that is also pinned
> into memory differ from just being part of the kernel? Is creating a
> process like this and building a communication system worth it just to
> get address space separation?

Yes, certainly it is worth it. And remember you'd have to protect your
small helpers, too, OOM can happen there.

Daemon is the way to go, sorry.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On Čt 01-06-06 16:35:12, Jon Smirl wrote:
> On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> >> > 5) The system needs to be robust. Daemons can be killed by the OOM
> >> > mechanism, you don't want to lose your console in the middle of trying
> >> > to fix a problem. This also means that you have to be able to display
> >> > printk's from inside interrupt handles.
> >
> >Point of disagreement. Tons of userspace helpers isn't a good choice.
> 
> Where do you get 'tons'? There will probably be one for initial reset,
> one for VESA based mode setting and a few more if there is device
> specific code needed for a specific card.
> 
> Making console rely on a permanent daemon that is subject to getting
> killed by the OOM mechanism is not a workable solution.

Well, you keep forgetting that temporary programs are _also_ subject
to OOM, and that -- in case of problems -- exec() is less likely to
work than most other things.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> Without specifying a design here are a few requirements I would have:
>
> 1) The kernel subsystem should be agnostic of the display server. The
> solution should not be X specific. Any display system should be able
> to use it, SDL, Y Windows, Fresco, etc...

of course, but that doesn't mean it can't re-use X's code, they are
the best drivers we have. you forget everytime that the kernel fbdev
drivers aren't even close, I mean not by a long long way apart from
maybe radeon.

> 2) State inside the hardware is maintained by a single driver. No
> hooks for state swapping (ie, save your state, now I'll load mine,
> ...).

We still have to do state swapping, we just don't expose it,
suspend/resume places state swapping as a requirement.

> 3) A non-root user can control their graphics device.

Of course, how we decide their device is another story best left to a
permissions model, either  /dev or sockets will cover this.

> 4) Multiple independent users should work

Multiple independent users on one card is always nasty but I can't see
anything to stop this from working.

> 5) The system needs to be robust. Daemons can be killed by the OOM
> mechanism, you don't want to lose your console in the middle of trying
> to fix a problem. This also means that you have to be able to display
> printk's from inside interrupt handles.

I've already pointed out the first of these is crap, a protected
daemon is better. displaying printks inside interrupt handlers on a
graphics console is always nasty, especially if the engine waits for
idle space etc.. so ideally this should involve just blasting to the
fb using info we know about like framebuffer/font etc..

> 6) Things like panics should be visible no matter what is running. No
> more silent deaths.

Same as 5 really..

> 7) Obviously part of this is going to exist in user space since some
> cards can only be controlled by VBIOS calls. Has anyone explored using
> the in-kernel protected mode VESA hooks for this?

Obviously as part of replacing X we must implement all features that X has.

> 8) The user space fbdev API has to be maintained for legacy apps. DRM
> can be changed if needed since there is only a single user of it, but
> there is no obvious need to change it.

DRM is designed to be incrementally changed, we cannot just break it
however, we can add new features that are enabled for a new userspcae,
but old X servers should continue to work with the new DRMs, this is a
hard requirement that is missing and will be missing every time you
post these lists.

> 9) there needs to be a way to control the mode on each head, merged fb
> should also work. Monitor hotplug should work. Video card hot plug
> should work. These should all work for console and the display
> servers.

Of course, have you got drivers for these written? this is mostly in
the realms of the driver developer, the modesetting API is going to
have to deal with all these concepts.

> 10) Console support for complex scripts should get consideration.

not really necessary.. nor should it be... fbset works, something like
it would be good enough..

> 11) VGA is x86 specific. Solutions have to work on all architectures.
> That implies that the code needed to get a basic console up needs to
> fit on initramfs. Use PPC machines as an example.

or other arches can have initial fbdev drivers that get disabled at
run time, stated a few times previously

> 12) If a driver system is loaded is has to inform the kernel of what
> resources it is using.

of coursee again this obvious.

13) text mode
Yes should always be an option.

Some simple ones from me:

14) backwards compatible, an old X server should still run on a new
kernel. I will allow for new options to be enabled at run-time so that
this isn't possible, but just booting a kernel and starting X should
work.

15) re-use as much of the X drivers as possible, otherwise it will KGI.

16) secure - no direct IO or MMIO access, modesetting is slow anyways
having the kernel checking the mmio access won't make it much slower.

17) incremental implementation - so it won't KGI.

Dave.

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> > Without specifying a design here are a few requirements I would have:
> >
> > 1) The kernel subsystem should be agnostic of the display server. The
> > solution should not be X specific. Any display system should be able
> > to use it, SDL, Y Windows, Fresco, etc...
>
> of course, but that doesn't mean it can't re-use X's code, they are
> the best drivers we have. you forget everytime that the kernel fbdev
> drivers aren't even close, I mean not by a long long way apart from
> maybe radeon.

This requirement means that stuff like mode setting has to be broken
out into an independent library. For example it would not be ok to say
that Fresco has to install X to get mode setting. No comment was made
on where the code comes from, you are reading in something that isn't
in the requirement.. I am aware that X has the best mode setting code
and it would be foolish to ignore it.

Both you and I both know what a pain it is to extract this type of
code from X. Let's not repeat X's problems in this area. Let's make
the new library standalone and easy to work with in any environment.
No all encompassing typedef systems this time.

> > 2) State inside the hardware is maintained by a single driver. No
> > hooks for state swapping (ie, save your state, now I'll load mine,
> > ...).
>
> We still have to do state swapping, we just don't expose it,
> suspend/resume places state swapping as a requirement.

I don't consider suspend/resume state swapping, it is state save and
restore. The same state is loaded back in.

Other than suspend/resume why would the driver need to do state swapping?

> > 9) there needs to be a way to control the mode on each head, merged fb
> > should also work. Monitor hotplug should work. Video card hot plug
> > should work. These should all work for console and the display
> > servers.
>
> Of course, have you got drivers for these written? this is mostly in
> the realms of the driver developer, the modesetting API is going to
> have to deal with all these concepts.

This needs to be considered in the design stage. For example, if both
heads are mapped through a single device node they can't be
independently controlled by two different user IDs. We need to make
sure we leave the path open to building this.


> > 10) Console support for complex scripts should get consideration.
>
> not really necessary.. nor should it be... fbset works, something like
> it would be good enough..

I meant support for Korean, Chinese, etc. You can't draw some of the
complex scripts without using something like Pango. Do we want to
build a system where people can use console in their native language?
You can use these languages from xterm but not console today. I have
no strong opinion on this point other that I believe it should be
discussed and input from non-English speakers should be considered. No
one on this list has a problem with this area since we all speak
English.

> 14) backwards compatible, an old X server should still run on a new
> kernel. I will allow for new options to be enabled at run-time so that
> this isn't possible, but just booting a kernel and starting X should
> work.

I'm not sure we want to continue supporting every X server released in
the last 25 years. But we should definitely support any X server
released in a 2.6 based kernel distribution. What are reasonable
limits?

> 15) re-use as much of the X drivers as possible, otherwise it will KGI.

I would broaden this to use the best code where ever it is found. Of
course X is a major source.

> 16) secure - no direct IO or MMIO access, modesetting is slow anyways
> having the kernel checking the mmio access won't make it much slower.

This needs some expansion. Secure is good, but it's not clear what you
are requiring with this point.

For me security means reducing the privileged code to an absolute
minimum and then inspecting it closely to make sure there are no
holes. Everything that is passed in needs to be checked and regarded
with suspicion. But you can go too far with the reduction, if you
provide a generic IOCTL to poke an IO port with an arbitrary value you
now have to verify that it is safe to pass in every possible value.
Instead if the IOCTL implements a specific function that pokes the
port with a single fixed value it is easier to say that it is secure.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 02 June 2006 02:18, Jon Smirl wrote:
> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> > > Without specifying a design here are a few requirements I would have:
> > >
> > > 1) The kernel subsystem should be agnostic of the display server. The
> > > solution should not be X specific. Any display system should be able
> > > to use it, SDL, Y Windows, Fresco, etc...
> >
> > of course, but that doesn't mean it can't re-use X's code, they are
> > the best drivers we have. you forget everytime that the kernel fbdev
> > drivers aren't even close, I mean not by a long long way apart from
> > maybe radeon.
>
> This requirement means that stuff like mode setting has to be broken
> out into an independent library. For example it would not be ok to say
> that Fresco has to install X to get mode setting. No comment was made
> on where the code comes from, you are reading in something that isn't
> in the requirement.. I am aware that X has the best mode setting code
> and it would be foolish to ignore it.
>
> Both you and I both know what a pain it is to extract this type of
> code from X. Let's not repeat X's problems in this area. Let's make
> the new library standalone and easy to work with in any environment.
> No all encompassing typedef systems this time.

Jon, I've already discussed this with Dave. Part of providing a "drmcon" will 
involve having libraries that currently almost always rely on X being loaded 
modified to allow for use whether or not X is running. To this end I plan on 
working on the current set of userspace drivers (the DRI side of the DRM/DRI 
pair) in X to make them usable by the drmcon system.

> > > 2) State inside the hardware is maintained by a single driver. No
> > > hooks for state swapping (ie, save your state, now I'll load mine,
> > > ...).
> >
> > We still have to do state swapping, we just don't expose it,
> > suspend/resume places state swapping as a requirement.
>
> I don't consider suspend/resume state swapping, it is state save and
> restore. The same state is loaded back in.
>
> Other than suspend/resume why would the driver need to do state swapping?

VT switch to a VT where X is running. X will still require a VT and assume it 
has good access to the graphics system. While currently it has no problems, 
when drmcon becomes a reality there will have to be a state switch between 
the consoles settings and the setting for the VT running X.

> > > 9) there needs to be a way to control the mode on each head, merged fb
> > > should also work. Monitor hotplug should work. Video card hot plug
> > > should work. These should all work for console and the display
> > > servers.
> >
> > Of course, have you got drivers for these written? this is mostly in
> > the realms of the driver developer, the modesetting API is going to
> > have to deal with all these concepts.
>
> This needs to be considered in the design stage. For example, if both
> heads are mapped through a single device node they can't be
> independently controlled by two different user IDs. We need to make
> sure we leave the path open to building this.

Exactly. This is part of keeping the kernel as secure as possible.

> > > 10) Console support for complex scripts should get consideration.
> >
> > not really necessary.. nor should it be... fbset works, something like
> > it would be good enough..
>
> I meant support for Korean, Chinese, etc. You can't draw some of the
> complex scripts without using something like Pango. Do we want to
> build a system where people can use console in their native language?
> You can use these languages from xterm but not console today. I have
> no strong opinion on this point other that I believe it should be
> discussed and input from non-English speakers should be considered. No
> one on this list has a problem with this area since we all speak
> English.

At current the best direction forward would be to just use the code from 
directfb-gtk to get Pango running for drmcon. Once that happens there is time 
for the coders to work out a complete solution that is seperate from PANGO 
and all other libraries if it's felt that it's still needed.

> > 14) backwards compatible, an old X server should still run on a new
> > kernel. I will allow for new options to be enabled at run-time so that
> > this isn't possible, but just booting a kernel and starting X should
> > work.
>
> I'm not sure we want to continue supporting every X server released in
> the last 25 years. But we should definitely support any X server
> released in a 2.6 based kernel distribution. What are reasonable
> limits?

This is not a supportable position, Jon. I haven't seen it myself, but I'm 
willing to bet there are still a few systems out there running X5 but have a 
recent kernel. Since X version prior to 6 are no longer in wide use, however, 
this is something that could be done with little damage to anyone.

But it still breaks the spirit of Linus' directive to "break nothing"

> > 15) re-use as much of the X drivers as possible, otherwise it will KGI.
>
> I would broaden this to use the best code where ever it is found. Of
> course X is a major source.
>
> > 16) secure - no direct IO or MMIO access, modesetting is slow anyways
> > having the kernel checking the mmio access won't make it much slower.
>
> This needs some expansion. Secure is good, but it's not clear what you
> are requiring with this point.
>
> For me security means reducing the privileged code to an absolute
> minimum and then inspecting it closely to make sure there are no
> holes. Everything that is passed in needs to be checked and regarded
> with suspicion. But you can go too far with the reduction, if you
> provide a generic IOCTL to poke an IO port with an arbitrary value you
> now have to verify that it is safe to pass in every possible value.
> Instead if the IOCTL implements a specific function that pokes the
> port with a single fixed value it is easier to say that it is secure.

At this poitn Dave has done a good job of keeping the DRM thats in kernel 
secure. I'll be working on the same with him as work on drmcon progresses. 
Doing the type of bounds-checking you mention at the end isn't really 
necessary, as there are only a few valid values - the code can and will check 
for those and reject ones that are invalid.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> VT switch to a VT where X is running. X will still require a VT and assume it
> has good access to the graphics system. While currently it has no problems,
> when drmcon becomes a reality there will have to be a state switch between
> the consoles settings and the setting for the VT running X.


> > > 14) backwards compatible, an old X server should still run on a new
> > > kernel. I will allow for new options to be enabled at run-time so that
> > > this isn't possible, but just booting a kernel and starting X should
> > > work.
> >
> > I'm not sure we want to continue supporting every X server released in
> > the last 25 years. But we should definitely support any X server
> > released in a 2.6 based kernel distribution. What are reasonable
> > limits?
>
> This is not a supportable position, Jon. I haven't seen it myself, but I'm
> willing to bet there are still a few systems out there running X5 but have a
> recent kernel. Since X version prior to 6 are no longer in wide use, however,
> this is something that could be done with little damage to anyone.
>
> But it still breaks the spirit of Linus' directive to "break nothing"

I don't know if break nothing applies to operating systems
masquerading as applications. "Break nothing" works both ways. Old X
servers are doing things like messing with the PCI bus that breaks new
kernels.

Use some common sense here, who would update to a 2006 kernel and keep
running an X server from 1989? Pick a reasonable limit and say the
rest are unsupported. Why make a pile of work for yourself that no
sane person is ever going to make use of.

Remember, an X server from 1989 only contains drivers for hardware
from 1989 and earlier. Can 2.6 Linux boot on a 1989 PC with an 8514
graphics card? Does it support running in 640K with an AboveBoard?
Does anyone even remember what an AboveBoard did?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 02 June 2006 02:58, Jon Smirl wrote:
> On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > VT switch to a VT where X is running. X will still require a VT and
> > assume it has good access to the graphics system. While currently it has
> > no problems, when drmcon becomes a reality there will have to be a state
> > switch between the consoles settings and the setting for the VT running
> > X.
> >
> > > > 14) backwards compatible, an old X server should still run on a new
> > > > kernel. I will allow for new options to be enabled at run-time so
> > > > that this isn't possible, but just booting a kernel and starting X
> > > > should work.
> > >
> > > I'm not sure we want to continue supporting every X server released in
> > > the last 25 years. But we should definitely support any X server
> > > released in a 2.6 based kernel distribution. What are reasonable
> > > limits?
> >
> > This is not a supportable position, Jon. I haven't seen it myself, but
> > I'm willing to bet there are still a few systems out there running X5 but
> > have a recent kernel. Since X version prior to 6 are no longer in wide
> > use, however, this is something that could be done with little damage to
> > anyone.
> >
> > But it still breaks the spirit of Linus' directive to "break nothing"
>
> I don't know if break nothing applies to operating systems
> masquerading as applications. "Break nothing" works both ways. Old X
> servers are doing things like messing with the PCI bus that breaks new
> kernels.
>
> Use some common sense here, who would update to a 2006 kernel and keep
> running an X server from 1989? Pick a reasonable limit and say the
> rest are unsupported. Why make a pile of work for yourself that no
> sane person is ever going to make use of.
>
> Remember, an X server from 1989 only contains drivers for hardware
> from 1989 and earlier. Can 2.6 Linux boot on a 1989 PC with an 8514
> graphics card? Does it support running in 640K with an AboveBoard?
> Does anyone even remember what an AboveBoard did?

Okay, okay. Point taken. And note that I did state that X versions prior to 6 
(hell, AFAIK, prior to 6.5) aren't in any widespread use. And the Elks 
version of Linux could run a 1989 system. Not that I think these changes will 
make it into Elks, but...

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> VT switch to a VT where X is running. X will still require a VT and assume it
> has good access to the graphics system. While currently it has no problems,
> when drmcon becomes a reality there will have to be a state switch between
> the consoles settings and the setting for the VT running X.

I forgot to include comments on VT's.

We need to reconsider how VT's are implemented. I would like to remove
them from the kernel. Now don't get too excited, I also want to
replace them with a system that would function the same for a normal
user.

There is only one VT system in the kernel. Making it support more that
one user requires a gigantic patch (18,000 lines). That patch has been
floating around for years and has never been merged. I don't think it
makes sense to extend the existing VT code even further to support
multiuser.

My proposal would be to switch to the concept of splitting console as
I described earlier. There would only be one in-kernel system
management console and it wouldn't support VT's. The system management
console is not meant for normal use.

Normal consoles would be implemented via user space processes. These
processes would provide the VT swap feature that people are used to.
They would also be accelerated via DRM. Since they are user space apps
it is easy to support multiuser by having multiple processes.

Getting rid of the VT implementation inside of the kernel lets us move
towards the single state in the hardware goal. The current in-kernel
VT design forces the "save your state, now I'll load mine" behavior.
That behavior is evil and it is the source of a lot of problems and it
should be removed. VT's were a good idea on VGA cards with 14
registers, now cards have 300 registers, a coprocessor, 512MB, etc.
There is simply too much state to swap.

In this model there would be no change at the normal user level,
Ctrl-Atl-num at a normal user console will still get you another
session. A hot key would display the system management console,
another would make it disappear.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 02 June 2006 03:16, Jon Smirl wrote:
> On 6/1/06, D. Hazelton <dhazelton@enter.net> wrote:
> > VT switch to a VT where X is running. X will still require a VT and
> > assume it has good access to the graphics system. While currently it has
> > no problems, when drmcon becomes a reality there will have to be a state
> > switch between the consoles settings and the setting for the VT running
> > X.
>
> I forgot to include comments on VT's.
>
> We need to reconsider how VT's are implemented. I would like to remove
> them from the kernel. Now don't get too excited, I also want to
> replace them with a system that would function the same for a normal
> user.
>
> There is only one VT system in the kernel. Making it support more that
> one user requires a gigantic patch (18,000 lines). That patch has been
> floating around for years and has never been merged. I don't think it
> makes sense to extend the existing VT code even further to support
> multiuser.
>
> My proposal would be to switch to the concept of splitting console as
> I described earlier. There would only be one in-kernel system
> management console and it wouldn't support VT's. The system management
> console is not meant for normal use.
>
> Normal consoles would be implemented via user space processes. These
> processes would provide the VT swap feature that people are used to.
> They would also be accelerated via DRM. Since they are user space apps
> it is easy to support multiuser by having multiple processes.
>
> Getting rid of the VT implementation inside of the kernel lets us move
> towards the single state in the hardware goal. The current in-kernel
> VT design forces the "save your state, now I'll load mine" behavior.
> That behavior is evil and it is the source of a lot of problems and it
> should be removed. VT's were a good idea on VGA cards with 14
> registers, now cards have 300 registers, a coprocessor, 512MB, etc.
> There is simply too much state to swap.
>
> In this model there would be no change at the normal user level,
> Ctrl-Atl-num at a normal user console will still get you another
> session. A hot key would display the system management console,
> another would make it disappear.

Okay, and have the kernel trap the hotkey and call out to a usermode helper? 
Good idea, but I'm going to stick it way down on my TODO list, since it's 
something that would better be implemented after the framework for drmcon is 
in place.

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> >
> > not really necessary.. nor should it be... fbset works, something like
> > it would be good enough..
>
> I meant support for Korean, Chinese, etc. You can't draw some of the
> complex scripts without using something like Pango. Do we want to
> build a system where people can use console in their native language?
> You can use these languages from xterm but not console today. I have
> no strong opinion on this point other that I believe it should be
> discussed and input from non-English speakers should be considered. No
> one on this list has a problem with this area since we all speak
> English.

Sorry misinterpreted, a userspace console would be possible now, if
someone implements it we can use it, but I'm not sure a freetype
accelrated console is necessary for us to do everything else.

> > 14) backwards compatible, an old X server should still run on a new
> > kernel. I will allow for new options to be enabled at run-time so that
> > this isn't possible, but just booting a kernel and starting X should
> > work.
>
> I'm not sure we want to continue supporting every X server released in
> the last 25 years. But we should definitely support any X server
> released in a 2.6 based kernel distribution. What are reasonable
> limits?

Yes at least a 2.6 distro based X should always work, I'm sure 2.4 DRM
doesn't work with new X in a lot of cases anyways as no-one tested it
at the time and it just got broken...

> > 15) re-use as much of the X drivers as possible, otherwise it will KGI.
>
> I would broaden this to use the best code where ever it is found. Of
> course X is a major source.

I'm not considering using knowledge from X drivers, I'm considering
using the X drivers, I don't personally care about things like X's
over use of typedefs and that sort of stuff, that is what I term
semantic, people who work on X drivers know X drivers, and writing the
drivers is the biggest part of any graphic systems.

> > 16) secure - no direct IO or MMIO access, modesetting is slow anyways
> > having the kernel checking the mmio access won't make it much slower.
>
> This needs some expansion. Secure is good, but it's not clear what you
> are requiring with this point.

I'm talking the recent secure thread that came from OpenBSD, we should
have no unchecked access to the I/O ports from userspace, even for
root or special graphics processes, MMIO needs to be mapped R/O to
userspace and accessed via either real DMA or pseudo-DMA mechanism in
the kernel. I don't think putting modesetting into the kernel is
sufficent to fix all needed uses for MMIO so I'd rather add a checking
mechanism ala what the DRM does now.

Dave.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> > > 15) re-use as much of the X drivers as possible, otherwise it will KGI.
> >
> > I would broaden this to use the best code where ever it is found. Of
> > course X is a major source.
>
> I'm not considering using knowledge from X drivers, I'm considering
> using the X drivers, I don't personally care about things like X's
> over use of typedefs and that sort of stuff, that is what I term
> semantic, people who work on X drivers know X drivers, and writing the
> drivers is the biggest part of any graphic systems.

I have considered that option too. It is a good place for a quick
start but it is not maintainable in the long run. The driver code has
to be divorced from X and not require having the entire X system
around to build a new driver.

Have you checked the dependencies needed for loading X drivers?
Modularization may have helped but loading an X driver used to
effectively suck in the entire X server due to dependencies. Sucking
in all of X is not fair to alternative windowing systems.

I do agree that this is a workable starting point but it can't be the
long term solution.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> > > > 15) re-use as much of the X drivers as possible, otherwise it will KGI.
> > >
> > > I would broaden this to use the best code where ever it is found. Of
> > > course X is a major source.
> >
> > I'm not considering using knowledge from X drivers, I'm considering
> > using the X drivers, I don't personally care about things like X's
> > over use of typedefs and that sort of stuff, that is what I term
> > semantic, people who work on X drivers know X drivers, and writing the
> > drivers is the biggest part of any graphic systems.
>
> I have considered that option too. It is a good place for a quick
> start but it is not maintainable in the long run. The driver code has
> to be divorced from X and not require having the entire X system
> around to build a new driver.
>
> Have you checked the dependencies needed for loading X drivers?
> Modularization may have helped but loading an X driver used to
> effectively suck in the entire X server due to dependencies. Sucking
> in all of X is not fair to alternative windowing systems.
>
> I do agree that this is a workable starting point but it can't be the
> long term solution.

I just checked the Xorg R7 drivers. The ones I checked are statically
linked to their X components so there are no big X dependencies. That
makes them usable as standalone drivers.

What do you think about wrapping them with EGL instead of using their
entry points directly? That would remove the temptation to use
acceleration code in the X drivers and encourage use of DRM instead.

Wrapping them with EGL was my plan for getting Xegl up last summer
when Nvidia wouldn't implement the API. Using the X driver was the
only solution available for Nvidia/ATI hardware.

This still needs to be classified as a temporary solution. Long term
the code needs to be extracted from X and converted to a standalone
build system. They could be turned in to real EGL drivers at that
point.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 02 June 2006 04:28, Jon Smirl wrote:
> On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> > > > > 15) re-use as much of the X drivers as possible, otherwise it will
> > > > > KGI.
> > > >
> > > > I would broaden this to use the best code where ever it is found. Of
> > > > course X is a major source.
> > >
> > > I'm not considering using knowledge from X drivers, I'm considering
> > > using the X drivers, I don't personally care about things like X's
> > > over use of typedefs and that sort of stuff, that is what I term
> > > semantic, people who work on X drivers know X drivers, and writing the
> > > drivers is the biggest part of any graphic systems.
> >
> > I have considered that option too. It is a good place for a quick
> > start but it is not maintainable in the long run. The driver code has
> > to be divorced from X and not require having the entire X system
> > around to build a new driver.
> >
> > Have you checked the dependencies needed for loading X drivers?
> > Modularization may have helped but loading an X driver used to
> > effectively suck in the entire X server due to dependencies. Sucking
> > in all of X is not fair to alternative windowing systems.
> >
> > I do agree that this is a workable starting point but it can't be the
> > long term solution.
>
> I just checked the Xorg R7 drivers. The ones I checked are statically
> linked to their X components so there are no big X dependencies. That
> makes them usable as standalone drivers.
>
> What do you think about wrapping them with EGL instead of using their
> entry points directly? That would remove the temptation to use
> acceleration code in the X drivers and encourage use of DRM instead.
>
> Wrapping them with EGL was my plan for getting Xegl up last summer
> when Nvidia wouldn't implement the API. Using the X driver was the
> only solution available for Nvidia/ATI hardware.
>
> This still needs to be classified as a temporary solution. Long term
> the code needs to be extracted from X and converted to a standalone
> build system. They could be turned in to real EGL drivers at that
> point.

Exactly. Using the X7 drivers would be a good starting point for the userspace 
side of things. I've always planned on this. Moving away from using the X7 
drivers towards ones built specific for the purpose is also in the plans I 
have.

DRH

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >> > 15) re-use as much of the X drivers as possible, otherwise it will KGI.
> >>
> >> I would broaden this to use the best code where ever it is found. Of
> >> course X is a major source.
> >
> >I'm not considering using knowledge from X drivers, I'm considering
> >using the X drivers, I don't personally care about things like X's
> >over use of typedefs and that sort of stuff, that is what I term
> >semantic, people who work on X drivers know X drivers, and writing the
> >drivers is the biggest part of any graphic systems.
> 
> I have considered that option too. It is a good place for a quick
> start but it is not maintainable in the long run. The driver code has
> to be divorced from X and not require having the entire X system
> around to build a new driver.
> 
> Have you checked the dependencies needed for loading X drivers?
> Modularization may have helped but loading an X driver used to
> effectively suck in the entire X server due to dependencies. Sucking
> in all of X is not fair to alternative windowing systems.

Why not? For now we can have something that works, and alternative
windowing systems can strip it down if they wish to.

> I do agree that this is a workable starting point but it can't be the
> long term solution.

Long term, someone is definitely going to clean up that userspace
code...

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Kyle Moffett]

On Jun 1, 2006, at 22:18:07, Jon Smirl wrote:
> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
>> of course, but that doesn't mean it can't re-use X's code, they  
>> are the best drivers we have. you forget everytime that the kernel  
>> fbdev drivers aren't even close, I mean not by a long long way  
>> apart from maybe radeon.
>
> I am aware that X has the best mode setting code and it would be  
> foolish to ignore it.

You're kidding, right?  I've never been able to get X to get the  
modes right on my damn flatpanel.  Hell, it can't even match DDC  
channels to VGA ports without hand-holding in the config file.  To  
contrast, the fbdev layer gets it right every time on the whole  
variety of hardware that I've got.  Likewise the only way that I've  
ever gotten X to even set a vaguely functional mode on another card  
is by loading the framebuffer module first and specifying Option  
"UseFBDev" "true".  Anything else and the monitor goes off mode and  
there's no getting it back.

>>> 9) there needs to be a way to control the mode on each head,  
>>> merged fb should also work. Monitor hotplug should work. Video  
>>> card hot plug should work. These should all work for console and  
>>> the display servers.
>>
>> Of course, have you got drivers for these written? this is mostly  
>> in the realms of the driver developer, the modesetting API is  
>> going to have to deal with all these concepts.
>
> This needs to be considered in the design stage. For example, if  
> both heads are mapped through a single device node they can't be  
> independently controlled by two different user IDs. We need to make  
> sure we leave the path open to building this.

I kind of agree, but on the other hand there needs to be a way to  
specify multiple viewports in a single framebuffer like MergedFB on  
my radeon.  I would be quite happy to tinker with my little C-based  
framebuffer graphics apps in the console except that I can't  
manipulate the second display's view in the same framebuffer with fbset.

> I meant support for Korean, Chinese, etc. You can't draw some of  
> the complex scripts without using something like Pango. Do we want  
> to build a system where people can use console in their native  
> language?  You can use these languages from xterm but not console  
> today. I have no strong opinion on this point other that I believe  
> it should be discussed and input from non-English speakers should  
> be considered. No one on this list has a problem with this area  
> since we all speak English.

IMHO the best way to do this is leave basic 7-bit or 8-bit fonts in  
the kernel where they are now and do the rest from a little userspace  
framebuffer console.  With a secure-attention-key to revert to the  
native console for emergency debugging and such, set up so it can  
display panics, I think the rest would be much better handled with  
the flexibility and locale support of userspace.

>> 14) backwards compatible, an old X server should still run on a  
>> new kernel. I will allow for new options to be enabled at run-time  
>> so that this isn't possible, but just booting a kernel and  
>> starting X should work.
>
> I'm not sure we want to continue supporting every X server released  
> in the last 25 years. But we should definitely support any X server  
> released in a 2.6 based kernel distribution. What are reasonable  
> limits?

IMHO X is currently broken enough on much of my hardware that I'd be  
completely happy to be forced to upgrade.  My LCD has diagonal red  
scrolling when in X (works fine on the kernel console though) and X  
can't seem to hardware accelerate at all, even on this RV200 chip.

>> 16) secure - no direct IO or MMIO access, modesetting is slow  
>> anyways having the kernel checking the mmio access won't make it  
>> much slower.
>
> This needs some expansion. Secure is good, but it's not clear what  
> you are requiring with this point.
>
> For me security means reducing the privileged code to an absolute  
> minimum and then inspecting it closely to make sure there are no  
> holes. Everything that is passed in needs to be checked and  
> regarded with suspicion. But you can go too far with the reduction,  
> if you provide a generic IOCTL to poke an IO port with an arbitrary  
> value you now have to verify that it is safe to pass in every  
> possible value. Instead if the IOCTL implements a specific function  
> that pokes the port with a single fixed value it is easier to say  
> that it is secure.

I'd personally rather not see any IOCTLs for poking of ports, I kinda  
like being able to script framebuffer drawing with a little bit of  
Perl or some hastily written C.  Calling FBIOGET_VSCREENINFO is fine,  
calling FBIO_POKE_OBSCURE_PORT is kinda iffy.  I realize there's no  
black and white but it would be nice to maintain some clarity of  
interface; make simple things simple and hard things possible.

Cheers,
Kyle Moffett

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Saturday 03 June 2006 03:21, Kyle Moffett wrote:
> On Jun 1, 2006, at 22:18:07, Jon Smirl wrote:
> > On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> >> of course, but that doesn't mean it can't re-use X's code, they
> >> are the best drivers we have. you forget everytime that the kernel
> >> fbdev drivers aren't even close, I mean not by a long long way
> >> apart from maybe radeon.
> >
> > I am aware that X has the best mode setting code and it would be
> > foolish to ignore it.
>
> You're kidding, right?  I've never been able to get X to get the
> modes right on my damn flatpanel.  Hell, it can't even match DDC
> channels to VGA ports without hand-holding in the config file.  To
> contrast, the fbdev layer gets it right every time on the whole
> variety of hardware that I've got.  Likewise the only way that I've
> ever gotten X to even set a vaguely functional mode on another card
> is by loading the framebuffer module first and specifying Option
> "UseFBDev" "true".  Anything else and the monitor goes off mode and
> there's no getting it back.

We'll use the best modesetting code we can find. Currently X refuses to do DDC 
via VESA on any modern card - I've seen this problem myself. The solution for 
the kernel graphics side of things would be to have it do all the probing in 
the userspace side (save where drmcon is concerned) and not limit that 
probing to just the EDID and i2c probing like X does.

As for the acceleration side of things... I'm not familiar enough with the X 
code to be able to pinpoint what the problem is, but part of it is definately 
the way DRM accesses the hardware. Apparently with any framebuffer driver 
loaded DRM can't give X full acceleration.

> >>> 9) there needs to be a way to control the mode on each head,
> >>> merged fb should also work. Monitor hotplug should work. Video
> >>> card hot plug should work. These should all work for console and
> >>> the display servers.
> >>
> >> Of course, have you got drivers for these written? this is mostly
> >> in the realms of the driver developer, the modesetting API is
> >> going to have to deal with all these concepts.
> >
> > This needs to be considered in the design stage. For example, if
> > both heads are mapped through a single device node they can't be
> > independently controlled by two different user IDs. We need to make
> > sure we leave the path open to building this.
>
> I kind of agree, but on the other hand there needs to be a way to
> specify multiple viewports in a single framebuffer like MergedFB on
> my radeon.  I would be quite happy to tinker with my little C-based
> framebuffer graphics apps in the console except that I can't
> manipulate the second display's view in the same framebuffer with fbset.

This is something that has been considered and marked as "TODO" on my list. 
It's not high up on that list because it's better to get the foundation for 
the system layed out before adding all the bells and whistles.

> > I meant support for Korean, Chinese, etc. You can't draw some of
> > the complex scripts without using something like Pango. Do we want
> > to build a system where people can use console in their native
> > language?  You can use these languages from xterm but not console
> > today. I have no strong opinion on this point other that I believe
> > it should be discussed and input from non-English speakers should
> > be considered. No one on this list has a problem with this area
> > since we all speak English.
>
> IMHO the best way to do this is leave basic 7-bit or 8-bit fonts in
> the kernel where they are now and do the rest from a little userspace
> framebuffer console.  With a secure-attention-key to revert to the
> native console for emergency debugging and such, set up so it can
> display panics, I think the rest would be much better handled with
> the flexibility and locale support of userspace.

I hadn't thought of using the SAK to pull up a "crash" console. Should be 
possible if we implement a safe console system like Jon has talked about, 
where all VT switching and such is handled totally in userspace. (I don't 
think it can be completely handled in userspace, just because of a few minor 
issues, but...)

> >> 14) backwards compatible, an old X server should still run on a
> >> new kernel. I will allow for new options to be enabled at run-time
> >> so that this isn't possible, but just booting a kernel and
> >> starting X should work.
> >
> > I'm not sure we want to continue supporting every X server released
> > in the last 25 years. But we should definitely support any X server
> > released in a 2.6 based kernel distribution. What are reasonable
> > limits?
>
> IMHO X is currently broken enough on much of my hardware that I'd be
> completely happy to be forced to upgrade.  My LCD has diagonal red
> scrolling when in X (works fine on the kernel console though) and X
> can't seem to hardware accelerate at all, even on this RV200 chip.

If only everyone felt like that. I know quite a few people that refuse to 
upgrade until there is something they want to do that the software or 
hardware doesn't allow.

> >> 16) secure - no direct IO or MMIO access, modesetting is slow
> >> anyways having the kernel checking the mmio access won't make it
> >> much slower.
> >
> > This needs some expansion. Secure is good, but it's not clear what
> > you are requiring with this point.
> >
> > For me security means reducing the privileged code to an absolute
> > minimum and then inspecting it closely to make sure there are no
> > holes. Everything that is passed in needs to be checked and
> > regarded with suspicion. But you can go too far with the reduction,
> > if you provide a generic IOCTL to poke an IO port with an arbitrary
> > value you now have to verify that it is safe to pass in every
> > possible value. Instead if the IOCTL implements a specific function
> > that pokes the port with a single fixed value it is easier to say
> > that it is secure.
>
> I'd personally rather not see any IOCTLs for poking of ports, I kinda
> like being able to script framebuffer drawing with a little bit of
> Perl or some hastily written C.  Calling FBIOGET_VSCREENINFO is fine,
> calling FBIO_POKE_OBSCURE_PORT is kinda iffy.  I realize there's no
> black and white but it would be nice to maintain some clarity of
> interface; make simple things simple and hard things possible.
>
> Cheers,
> Kyle Moffett

I feel the same way Kyle. I don't think direct access to the hardware should 
be allowed from outside the drm daemon. Route all acceleration through the 
drm daemon and it handles the tough stuff. Yes there will be a very minor 
performance hit, but it should be fine.

The reason Jon is so hot on having direct access like that is he feels that 
modesetting and a few other simple tasks should be handled by helpers and 
acceleration itself should be handled by userspace libraries, without the drm 
daemon at all.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote:
> The reason Jon is so hot on having direct access like that is he feels that
> modesetting and a few other simple tasks should be handled by helpers and
> acceleration itself should be handled by userspace libraries, without the drm
> daemon at all.

Jon thinks all of the HW level acceleration should be handled in the
DRM device drivers where it already exists. The acceleration code in
fbdev and XAA/EXA needs to die. DRM is the only choice since it is
possible to eliminate the other two and it is not possible to
eliminate DRM. Dave is in agreement with this design.

I think you are mixing up my comments about DRI vs DRM. DRI is the
user space acceleration code but it doesn't actually touch the
hardware. DRM actually touches it. I have never wanted user space
acceleration code for the low level hardware access.

Dave and I are only in disagreement on how to handle mode setting. In
his model there is a mode setting daemon that has a socket interface.
The libraries implementing xlib/OpenGL then talk to both this socket
and to the DRM device.

My desire is to have a single point of interface, DRM. Since mode
setting is not done very often I would use call_userhelper from the
DRM device driver to invoke it when necessary. To set a mode you IOCTL
DRM, which then bounces to a transient user space app.

Neither model forces mode setting exclusively into user space or the
kernel, each driver can chose to put it where ever is more efficient.
By initially reusing the existing X drivers it will probably all end
up in user space but people may rewrite that over time.

Two other things that probably have to go into user space are initial
reset and attached device (monitors) discovery.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Saturday 03 June 2006 05:55, Jon Smirl wrote:
> On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote:
> > The reason Jon is so hot on having direct access like that is he feels
> > that modesetting and a few other simple tasks should be handled by
> > helpers and acceleration itself should be handled by userspace libraries,
> > without the drm daemon at all.
>
> Jon thinks all of the HW level acceleration should be handled in the
> DRM device drivers where it already exists. The acceleration code in
> fbdev and XAA/EXA needs to die. DRM is the only choice since it is
> possible to eliminate the other two and it is not possible to
> eliminate DRM. Dave is in agreement with this design.
>
> I think you are mixing up my comments about DRI vs DRM. DRI is the
> user space acceleration code but it doesn't actually touch the
> hardware. DRM actually touches it. I have never wanted user space
> acceleration code for the low level hardware access.
>
> Dave and I are only in disagreement on how to handle mode setting. In
> his model there is a mode setting daemon that has a socket interface.
> The libraries implementing xlib/OpenGL then talk to both this socket
> and to the DRM device.
>
> My desire is to have a single point of interface, DRM. Since mode
> setting is not done very often I would use call_userhelper from the
> DRM device driver to invoke it when necessary. To set a mode you IOCTL
> DRM, which then bounces to a transient user space app.
>
> Neither model forces mode setting exclusively into user space or the
> kernel, each driver can chose to put it where ever is more efficient.
> By initially reusing the existing X drivers it will probably all end
> up in user space but people may rewrite that over time.
>
> Two other things that probably have to go into user space are initial
> reset and attached device (monitors) discovery.

Actually, Jon, Dave is thinking like I am in that the DRI drivers needs to be 
loaded for use. Rather than forcing applications to include all that code the 
userspace daemon can be configured to load the DRI driver and provides the 
userspace interface to the system. Using a daemon for a simple task, like 
modesetting, is idiotic - but using the daemon to provide userspace with full 
access to acceleration (the Kernel drivers only provide the backend for the 
acceleration. The userspace side actually provides the code that manages it 
all) without needing to have to worry about loading and initializing the dri 
drivers provides a method for anything from a scripting language to a full 
compiled application easy access to the acceleration.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote:
> Actually, Jon, Dave is thinking like I am in that the DRI drivers needs to be
> loaded for use. Rather than forcing applications to include all that code the
> userspace daemon can be configured to load the DRI driver and provides the
> userspace interface to the system. Using a daemon for a simple task, like
> modesetting, is idiotic - but using the daemon to provide userspace with full
> access to acceleration (the Kernel drivers only provide the backend for the
> acceleration. The userspace side actually provides the code that manages it
> all) without needing to have to worry about loading and initializing the dri
> drivers provides a method for anything from a scripting language to a full
> compiled application easy access to the acceleration.

You are confused about this. Nobody wants to change the way DRI and
DRM work, it would take years of effort to change it. These are shared
libraries, it doesn't matter how many people have them open, there is
only one copy in memory.

Applications don't 'include' all of the DRI/DRM code they dynamically
link to the OpenGL shared object library which in turns loads the
correct DRI shared library. The correct DRM module should be loaded by
the kernel at boot. You can write a 10 line OpenGL program that will
make use of all of this, it is not hard to do. User space has always
had access to hardware acceleration from these libraries.

We have not been discussing DIrect Rendering vs indirect (AIGLX). It
will be up to the windowing system to chose which (or both) of those
model to use. The lower layers are designed not to force that choice
one way ot the other.

Dave wants to load the existing X drivers into the daemon, not the DRI
libraries. Other than using them for mode setting there isn't much use
for them. I have asked him where he wants things like blanking, cmap,
cursor and he hasn't said yet. Those functions are tiny, ~100 lines of
code.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Saturday 03 June 2006 06:31, Jon Smirl wrote:
> On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote:
> > Actually, Jon, Dave is thinking like I am in that the DRI drivers needs
> > to be loaded for use. Rather than forcing applications to include all
> > that code the userspace daemon can be configured to load the DRI driver
> > and provides the userspace interface to the system. Using a daemon for a
> > simple task, like modesetting, is idiotic - but using the daemon to
> > provide userspace with full access to acceleration (the Kernel drivers
> > only provide the backend for the acceleration. The userspace side
> > actually provides the code that manages it all) without needing to have
> > to worry about loading and initializing the dri drivers provides a method
> > for anything from a scripting language to a full compiled application
> > easy access to the acceleration.
>
> You are confused about this. Nobody wants to change the way DRI and
> DRM work, it would take years of effort to change it. These are shared
> libraries, it doesn't matter how many people have them open, there is
> only one copy in memory.

Exactly.

> Applications don't 'include' all of the DRI/DRM code they dynamically
> link to the OpenGL shared object library which in turns loads the
> correct DRI shared library. The correct DRM module should be loaded by
> the kernel at boot. You can write a 10 line OpenGL program that will
> make use of all of this, it is not hard to do. User space has always
> had access to hardware acceleration from these libraries.

Yes, but there are userspace *drivers* that have to be loaded for that code to 
work properly. By providing the daemon no program needs to worry about 
loading those drivers.

> We have not been discussing DIrect Rendering vs indirect (AIGLX). It
> will be up to the windowing system to chose which (or both) of those
> model to use. The lower layers are designed not to force that choice
> one way ot the other.
>
> Dave wants to load the existing X drivers into the daemon, not the DRI
> libraries. Other than using them for mode setting there isn't much use
> for them. I have asked him where he wants things like blanking, cmap,
> cursor and he hasn't said yet. Those functions are tiny, ~100 lines of
> code.

Stuff like that would probably be best left to small userspace helpers, or 
potentially 1 userspace helper that figures out what to do based on what the 
name is that's given to the link.

DRH

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/2/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On Jun 1, 2006, at 22:18:07, Jon Smirl wrote:
> > On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> >> of course, but that doesn't mean it can't re-use X's code, they
> >> are the best drivers we have. you forget everytime that the kernel
> >> fbdev drivers aren't even close, I mean not by a long long way
> >> apart from maybe radeon.
> >
> > I am aware that X has the best mode setting code and it would be
> > foolish to ignore it.
>
> You're kidding, right?  I've never been able to get X to get the
> modes right on my damn flatpanel.  Hell, it can't even match DDC
> channels to VGA ports without hand-holding in the config file.  To
> contrast, the fbdev layer gets it right every time on the whole
> variety of hardware that I've got.  Likewise the only way that I've
> ever gotten X to even set a vaguely functional mode on another card
> is by loading the framebuffer module first and specifying Option
> "UseFBDev" "true".  Anything else and the monitor goes off mode and
> there's no getting it back.

I don't care where the mode setting code comes from. I don't care if
it runs in the kernel or in user space. This argument has been going
on for two years without resolution so I've started working on Mozilla
instead of graphics while I wait for it to resolve.

For a while I didn't understand why 10K of code per adapter had to be
such a controversial subject. Now I understand that this code is a
lighting rod for the causes of microkernel vs monolithic and platform
independence vs Linux specific.

I've posted my requirement for a design. I'll be happy with anything
that satisfies those requirements and works.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Helge Hafting]

Jon Smirl wrote:
> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
>> > Without specifying a design here are a few requirements I would have:
>> >
>> > 1) The kernel subsystem should be agnostic of the display server. The
>> > solution should not be X specific. Any display system should be able
>> > to use it, SDL, Y Windows, Fresco, etc...
>>
>> of course, but that doesn't mean it can't re-use X's code, they are
>> the best drivers we have. you forget everytime that the kernel fbdev
>> drivers aren't even close, I mean not by a long long way apart from
>> maybe radeon.
>
> This requirement means that stuff like mode setting has to be broken
> out into an independent library. For example it would not be ok to say
> that Fresco has to install X to get mode setting. No comment was made
> on where the code comes from, you are reading in something that isn't
> in the requirement.. I am aware that X has the best mode setting code
> and it would be foolish to ignore it.
>
> Both you and I both know what a pain it is to extract this type of
> code from X. Let's not repeat X's problems in this area. Let's make
> the new library standalone and easy to work with in any environment.
> No all encompassing typedef systems this time.
>
>> > 2) State inside the hardware is maintained by a single driver. No
>> > hooks for state swapping (ie, save your state, now I'll load mine,
>> > ...).
>>
>> We still have to do state swapping, we just don't expose it,
>> suspend/resume places state swapping as a requirement.
>
> I don't consider suspend/resume state swapping, it is state save and
> restore. The same state is loaded back in.
>
> Other than suspend/resume why would the driver need to do state swapping?
>
>> > 9) there needs to be a way to control the mode on each head, merged fb
>> > should also work. Monitor hotplug should work. Video card hot plug
>> > should work. These should all work for console and the display
>> > servers.
>>
>> Of course, have you got drivers for these written? this is mostly in
>> the realms of the driver developer, the modesetting API is going to
>> have to deal with all these concepts.
>
> This needs to be considered in the design stage. For example, if both
> heads are mapped through a single device node they can't be
> independently controlled by two different user IDs. We need to make
> sure we leave the path open to building this.
Yes.  Having two nodes should fix this one though.  The two nodes
can of course be managed by the same driver, so as to deal with
issues when there are some shared resources like memory
and a single graphichs accelerator.
>
>
>> > 10) Console support for complex scripts should get consideration.
>>
>> not really necessary.. nor should it be... fbset works, something like
>> it would be good enough..
>
> I meant support for Korean, Chinese, etc. You can't draw some of the
> complex scripts without using something like Pango. Do we want to
> build a system where people can use console in their native language?
That is very nice to have.  Of course, it is acceptable to say that
those who want a Korean/Chinese console are the ones who have to
program that part themselves too, but the console design should not 
prevent this.


Helge Hafting

Re: OpenGL-based framebuffer concepts

[Daniel Hazelton]

On Thursday 08 June 2006 03:02 am, Helge Hafting wrote:
> Jon Smirl wrote:
> > On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> >> > Without specifying a design here are a few requirements I would have:
> >> >
> >> > 1) The kernel subsystem should be agnostic of the display server. The
> >> > solution should not be X specific. Any display system should be able
> >> > to use it, SDL, Y Windows, Fresco, etc...
> >>
> >> of course, but that doesn't mean it can't re-use X's code, they are
> >> the best drivers we have. you forget everytime that the kernel fbdev
> >> drivers aren't even close, I mean not by a long long way apart from
> >> maybe radeon.
> >
> > This requirement means that stuff like mode setting has to be broken
> > out into an independent library. For example it would not be ok to say
> > that Fresco has to install X to get mode setting. No comment was made
> > on where the code comes from, you are reading in something that isn't
> > in the requirement.. I am aware that X has the best mode setting code
> > and it would be foolish to ignore it.
> >
> > Both you and I both know what a pain it is to extract this type of
> > code from X. Let's not repeat X's problems in this area. Let's make
> > the new library standalone and easy to work with in any environment.
> > No all encompassing typedef systems this time.
> >
> >> > 2) State inside the hardware is maintained by a single driver. No
> >> > hooks for state swapping (ie, save your state, now I'll load mine,
> >> > ...).
> >>
> >> We still have to do state swapping, we just don't expose it,
> >> suspend/resume places state swapping as a requirement.
> >
> > I don't consider suspend/resume state swapping, it is state save and
> > restore. The same state is loaded back in.
> >
> > Other than suspend/resume why would the driver need to do state swapping?
> >
> >> > 9) there needs to be a way to control the mode on each head, merged fb
> >> > should also work. Monitor hotplug should work. Video card hot plug
> >> > should work. These should all work for console and the display
> >> > servers.
> >>
> >> Of course, have you got drivers for these written? this is mostly in
> >> the realms of the driver developer, the modesetting API is going to
> >> have to deal with all these concepts.
> >
> > This needs to be considered in the design stage. For example, if both
> > heads are mapped through a single device node they can't be
> > independently controlled by two different user IDs. We need to make
> > sure we leave the path open to building this.
>
> Yes.  Having two nodes should fix this one though.  The two nodes
> can of course be managed by the same driver, so as to deal with
> issues when there are some shared resources like memory
> and a single graphichs accelerator.

Okay. I'll stick this on my list. Shouldn't be too hard to get to, provided I 
can finish up my work on drmcon. (Tony, I'm still waiting on that unloadable 
fbcon/fbdev bit and the userspace fbdev driver you mentioned)

> >> > 10) Console support for complex scripts should get consideration.
> >>
> >> not really necessary.. nor should it be... fbset works, something like
> >> it would be good enough..
> >
> > I meant support for Korean, Chinese, etc. You can't draw some of the
> > complex scripts without using something like Pango. Do we want to
> > build a system where people can use console in their native language?
>
> That is very nice to have.  Of course, it is acceptable to say that
> those who want a Korean/Chinese console are the ones who have to
> program that part themselves too, but the console design should not
> prevent this.
>
>
> Helge Hafting

Actually, if drmcon works out right all that would be needed is a program that 
can use FreeType to load the font into the driver.

DRH

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Daniel Hazelton wrote:
> On Thursday 08 June 2006 03:02 am, Helge Hafting wrote:
>> Jon Smirl wrote:
>>> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> Okay. I'll stick this on my list. Shouldn't be too hard to get to, provided I 
> can finish up my work on drmcon. (Tony, I'm still waiting on that unloadable 
> fbcon/fbdev bit and the userspace fbdev driver you mentioned)

I already have a preliminary patch that allows the binding and unbinding
of fbcon which I sent to lkml and fbdev-devel.  Jon and Andrew are against
having the control in fbcon, so I'm  currently working on another patch that
will transfer the control to the console layer.  It was a bit more complicated
that what I thought, but I'm almost done. I'm just in  debugging mode, and so
far I haven't encountered any major problems.

The nice thing about this change is that it's not restricted to fbcon. Other
console drivers can explicitly bind or unbind, ie, your future drmcon.

I may send out the patch within a day or 2. After this, I'll start work on
the userland driver.

Tony

Re: OpenGL-based framebuffer concepts

[Daniel Hazelton]

On Thursday 08 June 2006 04:30 am, Antonino A. Daplas wrote:
> Daniel Hazelton wrote:
> > On Thursday 08 June 2006 03:02 am, Helge Hafting wrote:
> >> Jon Smirl wrote:
> >>> On 6/1/06, Dave Airlie <airlied@gmail.com> wrote:
> >
> > Okay. I'll stick this on my list. Shouldn't be too hard to get to,
> > provided I can finish up my work on drmcon. (Tony, I'm still waiting on
> > that unloadable fbcon/fbdev bit and the userspace fbdev driver you
> > mentioned)
>
> I already have a preliminary patch that allows the binding and unbinding
> of fbcon which I sent to lkml and fbdev-devel.  Jon and Andrew are against
> having the control in fbcon, so I'm  currently working on another patch
> that will transfer the control to the console layer.  It was a bit more
> complicated that what I thought, but I'm almost done. I'm just in 
> debugging mode, and so far I haven't encountered any major problems.

Gotcha. Not having control in fbcon? Understandable. I don't think vgacon has 
that control in it, and see no reason for it to be in fbcon either.

> The nice thing about this change is that it's not restricted to fbcon.
> Other console drivers can explicitly bind or unbind, ie, your future
> drmcon.

Now this is a good reason to put the binding/unbinding control in another 
place. I had already thought that re-initializing vgacon on an error 
condition would be the best way to get the message to the screen. Having the 
console binding/unbinding code in a generic layer will make this very easy.

> I may send out the patch within a day or 2. After this, I'll start work on
> the userland driver.
>
> Tony

Thanks Tony. I'll get my nose back into drmcon and see if I can't get it into 
shape soon myself.

DRH

Re: OpenGL-based framebuffer concepts

[Ville Syrjälä]

On Fri, 02 Jun 2006 11:15:47 +1000, Dave Airlie wrote:

>> Without specifying a design here are a few requirements I would have:
>>
>> 1) The kernel subsystem should be agnostic of the display server. The
>> solution should not be X specific. Any display system should be able
>> to use it, SDL, Y Windows, Fresco, etc...
> 
> of course, but that doesn't mean it can't re-use X's code, they are
> the best drivers we have. you forget everytime that the kernel fbdev
> drivers aren't even close, I mean not by a long long way apart from
> maybe radeon.

matroxfb is clearly better than the X driver. atyfb too IMO.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

Re: OpenGL-based framebuffer concepts

[D. Hazelton]

On Friday 02 June 2006 04:34, Ville Syrjälä wrote:
> On Fri, 02 Jun 2006 11:15:47 +1000, Dave Airlie wrote:
> >> Without specifying a design here are a few requirements I would have:
> >>
> >> 1) The kernel subsystem should be agnostic of the display server. The
> >> solution should not be X specific. Any display system should be able
> >> to use it, SDL, Y Windows, Fresco, etc...
> >
> > of course, but that doesn't mean it can't re-use X's code, they are
> > the best drivers we have. you forget everytime that the kernel fbdev
> > drivers aren't even close, I mean not by a long long way apart from
> > maybe radeon.
>
> matroxfb is clearly better than the X driver. atyfb too IMO.

Hopefully the work me, Dave and Tony are doing is going to make it a level 
field. If it still doesn't improve things you are still free to use the fbcon 
system. THat's one part of the design that will not change.

DRH

Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> >> Without specifying a design here are a few requirements I would have:
> >>
> >> 1) The kernel subsystem should be agnostic of the display server. The
> >> solution should not be X specific. Any display system should be able
> >> to use it, SDL, Y Windows, Fresco, etc...
> >
> > of course, but that doesn't mean it can't re-use X's code, they are
> > the best drivers we have. you forget everytime that the kernel fbdev
> > drivers aren't even close, I mean not by a long long way apart from
> > maybe radeon.
>
> matroxfb is clearly better than the X driver. atyfb too IMO.

Okay maybe matroxfb, but if atyfb is the mach64, it really isn't as
good, the last few times I tried it, it just made my LCD bloom, X
worked, mach64 is probably the most complex thing as there must be at
least 15 variations on the theme.... mach64 isn't a chip family so
much as a chip tribe... I've since burned my mach64 as a sacrifice....

Dave.
>
> --
> Ville Syrjälä
> syrjala@sci.fi
> http://www.sci.fi/~syrjala/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: OpenGL-based framebuffer concepts

[Ville Syrjälä]

On Fri, Jun 02, 2006 at 04:19:55PM +1000, Dave Airlie wrote:
> >>> Without specifying a design here are a few requirements I would have:
> >>>
> >>> 1) The kernel subsystem should be agnostic of the display server. The
> >>> solution should not be X specific. Any display system should be able
> >>> to use it, SDL, Y Windows, Fresco, etc...
> >>
> >> of course, but that doesn't mean it can't re-use X's code, they are
> >> the best drivers we have. you forget everytime that the kernel fbdev
> >> drivers aren't even close, I mean not by a long long way apart from
> >> maybe radeon.
> >
> >matroxfb is clearly better than the X driver. atyfb too IMO.
> 
> Okay maybe matroxfb, but if atyfb is the mach64, it really isn't as
> good, the last few times I tried it,

When was that exactly, and what kernel? I've been using atyfb+DirectFB 
exclusively for a few years with chips ranging from VT2 to Rage 
Mobility.

> it just made my LCD bloom, X
> worked,

The X driver probably doesn't touch as much of the hardware as atyfb.

> mach64 is probably the most complex thing as there must be at
> least 15 variations on the theme.... mach64 isn't a chip family so
> much as a chip tribe... I've since burned my mach64 as a sacrifice....

If you ignore the pre-CT chps it isn't too bad.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/1/06, Ondrej Zajicek <santiago@mail.cz> wrote:
>> On Wed, May 31, 2006 at 12:39:19AM -0400, Jon Smirl wrote:
> 
> 7) Obviously part of this is going to exist in user space since some
> cards can only be controlled by VBIOS calls. Has anyone explored using
> the in-kernel protected mode VESA hooks for this?
> 

The protected mode interface provided by the VESA BIOS is only available
for setting the CLUT registers and setting the start address of the
frontbuffer. And this is only available in x86-32.

For the other functions such as mode setting, you need to call the BIOS
in real-mode.  And unless you can persuade Linus to allow this, the
only way to do it is in userspace.

Tony

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> > > Actually the suspend/resume has to be in userspace, X just re-posts
> > > the video ROM and reloads the registers... so the repost on resume has
> > > to happen... so some component needs to be in userspace..
> >
> > I'd like to see the simple video POST program get finished. All of the
> > pieces are lying around. A key step missing is to getting klibc added
> > to the kernel tree which is being worked on.
> 
> True. But how long is it going to be before klibc is merged?

It is in -mm tree just now. Just work against -mm tree, it is tree
you'll need to merge against, anyway.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Tue, May 30, 2006 at 07:27:25PM -0400, Jon Smirl wrote:
> On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> >Actually the suspend/resume has to be in userspace, X just re-posts
> >the video ROM and reloads the registers... so the repost on resume has
> >to happen... so some component needs to be in userspace..
> 
> I'd like to see the simple video POST program get finished.

http://archive.ubuntu.com/ubuntu/pool/main/v/vbetool/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

On St 31-05-06 02:38:13, Daniel Stone wrote:
> On Tue, May 30, 2006 at 07:27:25PM -0400, Jon Smirl wrote:
> > On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> > >Actually the suspend/resume has to be in userspace, X just re-posts
> > >the video ROM and reloads the registers... so the repost on resume has
> > >to happen... so some component needs to be in userspace..
> > 
> > I'd like to see the simple video POST program get finished.
> 
> http://archive.ubuntu.com/ubuntu/pool/main/v/vbetool/

also integreted into cvs at suspend.sf.net, along with dmi-based
whitelist.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Daniel Stone <daniel@fooishbar.org> wrote:
> On Tue, May 30, 2006 at 07:27:25PM -0400, Jon Smirl wrote:
> > On 5/30/06, Dave Airlie <airlied@gmail.com> wrote:
> > >Actually the suspend/resume has to be in userspace, X just re-posts
> > >the video ROM and reloads the registers... so the repost on resume has
> > >to happen... so some component needs to be in userspace..
> >
> > I'd like to see the simple video POST program get finished.
>
> http://archive.ubuntu.com/ubuntu/pool/main/v/vbetool/

I am aware of that tool and I have looked at the source. The new
program being discussed is very similar with adjustments for using the
klibc, emu86, kernel ROM support, etc. Switching to emu86 is important
to making the tool work on PPC machines. I don't know if BenH started
with vbetool source or source from another similar tool from Scitech.
I know he was looking at both of them.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Pavel Machek]

Hi!

> >Actually the suspend/resume has to be in userspace, X just re-posts
> >the video ROM and reloads the registers... so the repost on resume has
> >to happen... so some component needs to be in userspace..
> 
> I'd like to see the simple video POST program get finished. All of the
> pieces are lying around. A key step missing is to getting klibc added
> to the kernel tree which is being worked on.
> 
> BenH has the emu86 code. I agree that is simpler to always use emu86
> and not bother with vm86. He also pointed out that we need to copy the
> image back into the kernel after the ROM runs. Right now you can only
> read the ROM image from the sysfs attribute. The ROM code has support
> for keeping an image in RAM, it just isn't hooked up to the sysfs
> attribute for writing it.

Actually, vbetool is the piece of puzzle we currently use to
reinitialize graphics cards after resume. (suspend.sf.net).

We currently do it all in userspace; it would be cleaner to do it as
call_usermodehelper() from kernel.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Pavel Machek wrote:
> Hi!
> 
>>> Actually the suspend/resume has to be in userspace, X just re-posts
>>> the video ROM and reloads the registers... so the repost on resume has
>>> to happen... so some component needs to be in userspace..
>> I'd like to see the simple video POST program get finished. All of the
>> pieces are lying around. A key step missing is to getting klibc added
>> to the kernel tree which is being worked on.
>>
>> BenH has the emu86 code. I agree that is simpler to always use emu86
>> and not bother with vm86. He also pointed out that we need to copy the
>> image back into the kernel after the ROM runs. Right now you can only
>> read the ROM image from the sysfs attribute. The ROM code has support
>> for keeping an image in RAM, it just isn't hooked up to the sysfs
>> attribute for writing it.
> 
> Actually, vbetool is the piece of puzzle we currently use to
> reinitialize graphics cards after resume. (suspend.sf.net).

But vbetool can only handle primary cards, can't it?

> 
> We currently do it all in userspace; it would be cleaner to do it as
> call_usermodehelper() from kernel.

I had a patch sometime before, vm86d.  It's a daemon in userspace that
accepts requests from the kernel which executes x86 instructions using
lrmi, then pushes the result back to the kernel.  I modified vesafb
so that it uses this daemon which makes vesafb acquire the capability
to do on the fly mode switching (similar in functionality with
vesafb-tng which uses a different method).

I abandoned this patch, but it seems there's might be at least one user.

spblinux (http://spblinux.sourceforge.net/)

Tony

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > Actually, vbetool is the piece of puzzle we currently use to
> > reinitialize graphics cards after resume. (suspend.sf.net).
>
> But vbetool can only handle primary cards, can't it?

That is correct, but you can get the ROM image for all adapters out of
sysfs now so it is not really hard to change it.  Handling secondary
cards is another feature of the new tools that isn't finished yet.

The tool should also put the image back into the kernel after the ROM
is run. A lot of these ROM assume they are running out of shadow RAM
and make changes to the image.

> > We currently do it all in userspace; it would be cleaner to do it as
> > call_usermodehelper() from kernel.
>
> I had a patch sometime before, vm86d.  It's a daemon in userspace that
> accepts requests from the kernel which executes x86 instructions using
> lrmi, then pushes the result back to the kernel.  I modified vesafb
> so that it uses this daemon which makes vesafb acquire the capability
> to do on the fly mode switching (similar in functionality with
> vesafb-tng which uses a different method).
>
> I abandoned this patch, but it seems there's might be at least one user.
>
> spblinux (http://spblinux.sourceforge.net/)

This is very similar to what I am proposing. I would just spawn the
app off each time instead of using a daemon; it's not like you are
changing mode every few seconds. By spawning each time you can avoid
the problem of the kernel trying to figure out if the daemon has died.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: OpenGL-based framebuffer concepts

[Antonino A. Daplas]

Jon Smirl wrote:
> On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > Actually, vbetool is the piece of puzzle we currently use to
>> > reinitialize graphics cards after resume. (suspend.sf.net).
>>
>>
>> I had a patch sometime before, vm86d.  It's a daemon in userspace that
>> accepts requests from the kernel which executes x86 instructions using
>> lrmi, then pushes the result back to the kernel.  I modified vesafb
>> so that it uses this daemon which makes vesafb acquire the capability
>> to do on the fly mode switching (similar in functionality with
>> vesafb-tng which uses a different method).
>>
>> I abandoned this patch, but it seems there's might be at least one user.
>>
>> spblinux (http://spblinux.sourceforge.net/)
> 
> This is very similar to what I am proposing. I would just spawn the
> app off each time instead of using a daemon; it's not like you are
> changing mode every few seconds. By spawning each time you can avoid
> the problem of the kernel trying to figure out if the daemon has died.

I was thinking of reviving this patch, because of problems with suspend/
resume and mode setting. But if there is a plan to put an emulator as part
of the kernel library, I'll hold off.

I'm also thinking of using a different user-kernel interface.  The old
patch creates a misc device which the daemon opens, but can the kernel
connector do the job? I don't know anything about this.

Tony

PS: This user helper need not just do x86 calls, it might use OF or even
X. (I believe the Xen people have something similar). A userspace
framebuffer driver usable by the kernel console is definitely possible.

Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> I was thinking of reviving this patch, because of problems with suspend/
> resume and mode setting. But if there is a plan to put an emulator as part
> of the kernel library, I'll hold off.

There's a plan but nobody is working on it right now. The first step
is to get klibc in and that seems to be taking forever. klibc is
making progress, there is a merged kernel/klibc git tree available,
I'm just not sure when it will get merged for real.

> I'm also thinking of using a different user-kernel interface.  The old
> patch creates a misc device which the daemon opens, but can the kernel
> connector do the job? I don't know anything about this.

My app wrote its results and signaled it was finished by writing to a
sysfs attribute. I'm sure one of the experts on the list will tell us
the right way to do this.

The flow is like this:
normal user ioctls device
kernel driver calls usermodehelper
what's the right way for the kernel driver to sleep here?
user space run the helper app as root
app writes to sysfs attribute
kernel driver wakes
returns out to normal user

If you look at the code for /sys/class/firmware it does most of what is needed.
Check out drivers/base/firmware_class.c

This code can be generalized to support calling out to arbitrary user
mode helpers instead of the specific firmware helper. I think I posted
a patch to do this, I don't have it locally but it may be in the
archives.

> PS: This user helper need not just do x86 calls, it might use OF or even
> X. (I believe the Xen people have something similar). A userspace
> framebuffer driver usable by the kernel console is definitely possible.

I have never been against having the driver call out into user mode,
in fact it is required for some hardware. The model I would like to
see is for everything to be controlled via a device node. Having the
device node lets you control it as a normal user and then use the
device driver to gain root when you have to have it.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: replacing X Window System !

[D. Hazelton]

Linux does provide a system in kernel for accessing the graphics cards. This 
includes both the DRM system and the framebuffer drivers. If the hardware 
drivers, such as the DRM drivers and system and the framebuffer drivers, were 
extended to allow a bit more utility, perhaps by providing a documented API 
(in the framebuffer case) it should be a simple matter to rewrite X so that 
it doesn't require root access. That this *hasn't* been done is both a 
problem with the kernel documentation and the X developers - more the X 
developers than anything.

In the case of the DRM drivers, I, personally, feel they should implement the 
accelerated drawing commands, or perhaps have a passthrough method similar to 
the SG system, then X and Mesa could easily access all features of the 
hardware through the userspace side of the DRM driver, which itself could 
provide the API as a wrapper around an IOCTL interface, or perhaps a sysfs 
interface.

For the Framebuffer drivers I, personally, would like to see its userspace 
accessable bits documented. This is, of course, assuming that there is more 
to it than an interface for setting the video mode and writing the graphics 
data to the device file. Now, if the framebuffer device was extended to 
provide some sort of interface, either via IOCTL or via a set of sysfs files, 
to the full capabilities of the device, then all problems of X needing to be 
root once more disappear.

Note that I am not advocating putting the windowing system in-kernel, just 
expanding the kernel interface to the various graphics devices so that future 
versions of X will not be required to have direct access to the hardware. 

I have no experience with kernel-level programming and no experience in 
graphics programming beyond some simple DOS applications I wrote in the days 
of just using a pointer to 0xB000 and 0xC000. Despite that I would be willing 
to set aside all my private projects and lend any assistance required to make 
any of these suggestions happen if anyone wishes to pick them up.

DRH

Re: replacing X Window System !

[Lennart Sorensen]

On Wed, May 17, 2006 at 01:47:22PM +0200, linux cbon wrote:
> X Window System has many problems affecting directly
> the kernel.
> 
> http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
> -Many current implementations of X manipulate the
> video hardware directly.

Not a problem with X, just with some implementations.

> -X deliberately contains no specification as to user
> interface or most inter-application communication.

Why should it?  Let someone else deal with that.  X has no business
getting involved in applications talking to each other.

> -The X protocol provides no facilities for handling
> sound,

True.  It is a display/input protocol.  There are other protocols
that handle remote sound.  There isn't really a reason they need to
be combined.  X is event driven.  Audio tends to require streams.  Very
different tasks.

> -Until recently, X did not include a good solution to
> print screen-displays. 

Hmm, I guess I never noticed.  Was this missed by anyone?  Screen
captures were just fine as far as I can tell.

> -One cannot currently detach an X client or session
> from one server and reattach it to another.

Some people have worked on ways to do that.  Given things like DGA and
shared memory and such, some applications simply can't be detached
unless the application was written to support some kind of shutdown the
gui and then go connect to another X server and start the gui again.

> I would add :
> -X needs to be root so it opens many security holes.

Some implementations need to be root.  I think it may be possible to run
a framebuffer based X without root, although you would also have to do
something about the keyboard and mouse drivers I imagine.

> -X has more code than the kernel and it is almost an
> OS in itself.

So?  That doesn't make it bad, it just has a lot of features and
includes a lot of utilities.

> -if a "closed-source" graphical card driver has
> security holes, what do you do ?
> etc.

Same as with anything else closed source.  This is not a flaw in X.

> Some people are working on replacement like Y windows
> :
> http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf
> http://www.y-windows.org/
> 
> There are some questions like :
> - should the next generation window versions Y,Z etc.
> remain backward compatible with X ?
> I think they should start something better and simpler
> from scratch and not backward compatible.

Lack of application support (which requires backwards compatibility) is
what dooms projects.  If you don't want to be backwards compatible (just
through emulation is fine) then don't bother.  Other than a fun hobby it
won't go anywhere ever.  I think ALSA might have been doomed had it not
emulated OSS.  By allowing emulation it slowly has gained support from
applications as they were ready to start taking advantages of the new
and improved interface.  Linux evolves, which is why it's still here.
Starting from scratch almost never succeeds.

> - should the kernel remain pure "shell" or include
> some basic universal graphical universal window system
> ?
> I think second answer.

It should very much stay purely text based.  Lots of systems have no
graphics abilities at all, and run linux very well.  The simpler the
better for the kernel interface.  The less special hardware support it
needs to show stuff to the user the easier it is to fix problems.

Windows is majorly annoying and broken that way.  You can't really fix
anything if you can't boot as far as starting the GUI.

Len Sorensen

Re: replacing X Window System !

[Jan Engelhardt]

>> hi,
>> 
>> I know it may not be the best place, sorry for that.
>> 
>> X Window System is old, not optimized, slow, not
>> secure (uses root much), accesses the video hardware
>> directly (thats the kernel's job !), it cannot do VNC,
>> etc.
>> 
>> The question is : what are your ideas to make a system
>> remplacing X Window System ?
>> 

For great justice, a cookie quote:

On Sat, 13 May 2006 22:43:57 -0400, Theodore Tso wrote:

     +----------+
     |  PLEASE  |
     |  DO NOT  |
     | FEED THE |
     |  TROLLS  |
     +----------+
         |  |    
         |  |    
       .\|.||/..



Jan Engelhardt
-- 

Re: replacing X Window System !

[Felipe Alfaro Solana]

> X Window System is old

Yep, but works pretty good. It allows for very smart and useful
things, like separating execution from presentation.

> not optimized

I wouldn't say so.

> slow

Slow? Have you ever seen Xgl?

> not secure (uses root much), accesses the video hardware
> directly (thats the kernel's job !)

> it cannot do VNC, etc.

What? You must be kidding. There's an X.org module which adds support
for VNC. It's built-in an I haved used it in the past to remotely
control some of my machines.

Re: replacing X Window System !

[Ondrej Zary]

Felipe Alfaro Solana wrote:
 >> slow
 >
 > Slow? Have you ever seen Xgl?

It is slow. Just take any older machine (Pentium class), open any longer 
web page in Firefox and scroll it up and down. Or open some other 
window, move it around the screen on top of the Firefox window and see 
how "fast" it really is. Then repeat the same in Windows.
How can Xgl help here?

-- 
Ondrej Zary

Re: replacing X Window System !

[Carlos Silva]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Wed, 2006-05-17 at 10:46 +0200, Ondrej Zary wrote:
> Felipe Alfaro Solana wrote:
>  >> slow
>  >
>  > Slow? Have you ever seen Xgl?
> 
> It is slow. Just take any older machine (Pentium class), open any longer 
> web page in Firefox and scroll it up and down. Or open some other 
> window, move it around the screen on top of the Firefox window and see 
> how "fast" it really is. Then repeat the same in Windows.
> How can Xgl help here?

It helps! I hope that by "Windows" you ment Windows XP, cause Windows XP
on a pentium class machine, the box hardly boots, so i guess comparing
XGL and Windows XP on a current machine with a decent graphics card,
it's a good comparison. But not on a old machine, neither for windows or
Xgl.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: replacing X Window System !

[Lennart Sorensen]

On Wed, May 17, 2006 at 10:46:57AM +0200, Ondrej Zary wrote:
> It is slow. Just take any older machine (Pentium class), open any longer 
> web page in Firefox and scroll it up and down. Or open some other 
> window, move it around the screen on top of the Firefox window and see 
> how "fast" it really is. Then repeat the same in Windows.
> How can Xgl help here?

Would a pentium class machine even run firefox on windows?

I think there is something very wrong with how firefox manages it's page
rendering and scrolling.  It certainly eats a ton of ram with whatever
it is doing.

Len Sorensen

RE: replacing X Window System !

[David Schwartz]

> Would a pentium class machine even run firefox on windows?
>
> I think there is something very wrong with how firefox manages it's page
> rendering and scrolling.  It certainly eats a ton of ram with whatever
> it is doing.

	My sister can testify that it's possible but there's really no point. She
has a P60 with 128MB of RAM (the max her mobo can take) and it takes about 2
minutes to launch firefox. She uses gmail, and it's basically unusable on
her machine. Almost once every day I send her another configuration for a
machine I recommend she should buy to end her suffering. She says she uses
her machine so little it's not worth it. I point out that she uses it so
little because it is useful for so little.

	DS

RE: replacing X Window System !

[alan]

On Wed, 17 May 2006, David Schwartz wrote:

>
>> Would a pentium class machine even run firefox on windows?
>>
>> I think there is something very wrong with how firefox manages it's page
>> rendering and scrolling.  It certainly eats a ton of ram with whatever
>> it is doing.
>
> 	My sister can testify that it's possible but there's really no point. She
> has a P60 with 128MB of RAM (the max her mobo can take) and it takes about 2
> minutes to launch firefox. She uses gmail, and it's basically unusable on
> her machine. Almost once every day I send her another configuration for a
> machine I recommend she should buy to end her suffering. She says she uses
> her machine so little it's not worth it. I point out that she uses it so
> little because it is useful for so little.

The P60s are just bad to begin with.  That is the one where the floating 
point error appeared.

Gmail requires a current browser.  To support it you need a machine made 
in this century, not the last.

Just because Linux will run on that machine does not mean it is a good 
idea.

But we have gone WAY off topic for the kernel list.

-- 
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis

Re: replacing X Window System !

[Gábor Lénárt]

On Wed, May 17, 2006 at 10:46:29AM -0700, alan wrote:
> The P60s are just bad to begin with.  That is the one where the floating 
> point error appeared.
> 
> Gmail requires a current browser.  To support it you need a machine made 
> in this century, not the last.

Hmm, I'm using Gmail with Elinks which is a text based browser and it works
(OK, ugly and sometimes buggy). So the problem is not the content itself in
general but the browser (sure, I can't browse flash or AJAX powered site
with Elinks very well though :). I may try to use Gmail on a real Commodore
64 with Contiki it would be a very interesting experiment :)


-- 
- Gábor

Re: replacing X Window System !

[Felipe Alfaro Solana]

>  > Slow? Have you ever seen Xgl?
>
> It is slow. Just take any older machine (Pentium class), open any longer
> web page in Firefox and scroll it up and down. Or open some other
> window, move it around the screen on top of the Firefox window and see
> how "fast" it really is. Then repeat the same in Windows.
> How can Xgl help here?

Yeah! Windows 3.0 is lightning fast on a Pentium-class machine.
However, Windows XP is dog slow. However, XFCE on the same machine is
much more usable. I don't see the problem, then.

Re: [OT] replacing X Window System !

[Jan Knutar]

> It is slow. Just take any older machine (Pentium class), open any longer 
> web page in Firefox and scroll it up and down. Or open some other 
> window, move it around the screen on top of the Firefox window and see 
> how "fast" it really is. Then repeat the same in Windows.
> How can Xgl help here?

I wonder if firefox window gets redrawn when you scroll or move stuff over
it. I fondly remember GTK1 overdrawing the scrollbar with grey rectangles,
then putting the scrollbar pixmaps on top, repeated about 6 times, and this
all done a few times per second for a nice flickering effect on your scollbar..

Do the widget toolkits still only push pixels to the screen, or do they actually
take advantage of any acceleration features that X provides?