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
Hi,
On 16/05/06, linux cbon <[email protected]> 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/)
linux cbon <[email protected]> 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
[email protected]
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
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*.....
On Tue, 16 May 2006, [email protected] 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
> 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.
> > 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? :)
[...]
Although one has to admit that working with remote X terminals over a
SSH/WAN/VPN-connection is far from usefull, Microsoft?s RDP protocol does a
much better job there. However, there?s NX (http://www.nomachine.com/) and
other products but out of the box X11 it?s quite slow over higher latency
connections.
Just my EUR 0.02
SIEGENIA-AUBI KG
Informationswesen
i.A.
Markus D?hr
SAP-CC/BC, SAPDB-DBA
Tel.: +49 6503 917-152
Fax: +49 6503 917-7152
E-Mail: [email protected]
Internet: http://www.siegenia-aubi.com
On Tuesday 16 May 2006 22:57, M?ns Rullg?rd wrote:
> linux cbon <[email protected]> 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.
"D?hr, Markus ICC-H" <[email protected]> writes:
>> > 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? :)
> [...]
>
> Although one has to admit that working with remote X terminals over
> a SSH/WAN/VPN-connection is far from usefull,
It depends on what programs you run. Emacs runs perfectly fine over a
slow modem. Firefox is usually very unhappy even on a fast LAN. In
general, applications that render an image locally and send that to
the X server for display will run badly over a remove connection.
Apps that send text and drawing commands to the server, and let it
take care of rendering run quite well.
> Microsoft?s RDP protocol does a much better job there. However,
> there?s NX (http://www.nomachine.com/) and other products but out of
> the box X11 it?s quite slow over higher latency connections.
RDP is more like VNC, AFAIK. It serves a different purpose.
--
M?ns Rullg?rd
[email protected]
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
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.
> > Microsoft?s RDP protocol does a much better job there. However,
> > there?s NX (http://www.nomachine.com/) and other products
> but out of
> > the box X11 it?s quite slow over higher latency connections.
>
> RDP is more like VNC, AFAIK. It serves a different purpose.
No, not necessarily. It?s very possible to run only a single application
from an RDP serving system (as you do with X), the application gets executed
on the server and the display is pushed to the client.
Greetz,
SIEGENIA-AUBI KG
Informationswesen
i.A.
Markus D?hr
SAP-CC/BC, SAPDB-DBA
Tel.: +49 6503 917-152
Fax: +49 6503 917-7152
E-Mail: [email protected]
Internet: http://www.siegenia-aubi.com
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
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.
--- [email protected] 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
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....)
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
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
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
On 17/05/06, linux cbon <[email protected]> wrote:
> --- [email protected] 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 <[email protected]>
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
On 5/17/06, Lennart Sorensen <[email protected]> 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
Hi,
On 17/05/06, Bob Copeland <[email protected]> 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/)
[email protected] 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
Panagiotis Issaris wrote:
> [email protected] 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
On Wed, May 17, 2006 at 04:10:38PM +0200, Panagiotis Issaris wrote:
> [email protected] 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.
On 5/17/06, Olivier Galibert <[email protected]> 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
--- Jesper Juhl <[email protected]> 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
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
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...
On Wed, 17 May 2006 11:09:38 EDT, [email protected] 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...
On Wed, 17 May 2006 [email protected] wrote:
> On Wed, 17 May 2006 11:09:38 EDT, [email protected] 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/
_
****************************************************************
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
--- Alan Cox <[email protected]> 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
--- [email protected] a ?crit :
> On Wed, 17 May 2006 11:09:38 EDT,
> [email protected] 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
On Wed, 17 May 2006 17:53:25 +0200 (CEST) linux cbon wrote:
> --- [email protected] a ?crit :
> > On Wed, 17 May 2006 11:09:38 EDT,
> > [email protected] 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
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
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
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.
> > 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.
> > RDP is more like VNC, AFAIK. It serves a different purpose.
>
> No, not necessarily. It?s very possible to run only a single application
> from an RDP serving system (as you do with X), the application gets executed
> on the server and the display is pushed to the client.
AFAIK, only ICA allows running single applications (publishing), not
RDP. And, BTW, they _do_ consume a complete user session, so they're
pretty a resource hog.
> > 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.
> 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
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
On Wed, May 17, 2006 at 04:53:35PM +0200, linux cbon wrote:
> --- Jesper Juhl <[email protected]> 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
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
>> 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
--
> > No, not necessarily. It?s very possible to run only a single
> > application from an RDP serving system (as you do with X), the
> > application gets executed on the server and the display is
> pushed to the client.
>
> AFAIK, only ICA allows running single applications
> (publishing), not RDP. And, BTW, they _do_ consume a complete
> user session, so they're pretty a resource hog.
No - with RDP 5.2 this is possible as it is with Citrix.
Doing this creates three processes on the system, a login process, a "shell"
(explorer) - and the process I'm executing/calling.
The main difference is - you can't "publish" applications, you need to know
how to call them (path). Everything else is pretty much the same as in
Citrix.
We make heavily use of this with the "Sun Global Desktop" software. That
software acts as middleware between the client and the server, they use
either Java or an AIP protocol to get the application to the desktop.
Working over that in X is as if you were sitting right in front of the
console.
--
Markus
El Wed, 17 May 2006 19:17:12 +0200,
"Felipe Alfaro Solana" <[email protected]> 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.
linux cbon wrote:
> --- [email protected] 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
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
--- Helge Hafting <[email protected]> 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
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.
El Thu, 18 May 2006 11:42:15 -0400,
[email protected] (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.
linux cbon <[email protected]> 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?
--- Thierry Vignaud <[email protected]> a ?crit :
> linux cbon <[email protected]> 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
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
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 <[email protected]>
> To: Thierry Vignaud <[email protected]>
> Cc: [email protected], [email protected],
> [email protected]
> Subject: Re: replacing X Window System !
>
> --- Thierry Vignaud <[email protected]> a ?crit :
>
> > linux cbon <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
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
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.
--- [email protected] 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
--- Gerhard Mack <[email protected]> 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
> 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...
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
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 <[email protected]> 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.
linux cbon wrote:
> --- Helge Hafting <[email protected]> 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
> 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?
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
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
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!)
--
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
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
--- Xavier Bestel <[email protected]> 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
On Fri, 2006-05-19 at 17:13, linux cbon wrote:
> --- Xavier Bestel <[email protected]> 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
--- Xavier Bestel <[email protected]> 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
>> 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
--
>
>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
--
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
--- Helge Hafting <[email protected]> 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
> Although one has to admit that working with remote X terminals over a
> SSH/WAN/VPN-connection is far from usefull, [...]
You can tunnel just about anything X11 over SSH/VPN/etc.; even things
like a whole desktop GUI; not just plain X terminals.
> However, there?s NX (http://www.nomachine.com/) and
> other products but out of the box X11 it?s quite slow over higher latency
> connections.
One good way to reduce latency (at least when using X11 over SSH) is
to tell SSH to compress its connection tunnel ("ssh -C ...").
On 5/19/06, linux cbon <[email protected]> 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
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
> > Although one has to admit that working with remote X
> terminals over a
> > SSH/WAN/VPN-connection is far from usefull, [...]
> You can tunnel just about anything X11 over SSH/VPN/etc.; even things
> like a whole desktop GUI; not just plain X terminals.
Did you actually do that? Starting Firefox over a 6 Mbit VPN takes about 3
minutes on a FAST machine. That?s not acceptable - our users want (almost)
immediate response to an application, to clicking and waiting 10 seconds
until the app is doing something.
> > However, there?s NX (http://www.nomachine.com/) and
> > other products but out of the box X11 it?s quite slow over
> higher latency
> > connections.
> One good way to reduce latency (at least when using X11 over SSH) is
> to tell SSH to compress its connection tunnel ("ssh -C ...").
>
Yes, this will start Firefox (as an example) down to 2 minutes 15 seconds
and put additional compression/decompression load on the system. We go for
AIP right now (Sun Secure Global Desktop), there you have the feeling as if
you were sitting in front of the box.
--
Markus
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
Am Samstag, 20. Mai 2006 02:57 schrieb D?hr, Markus ICC-H:
> Did you actually do that? Starting Firefox over a 6 Mbit VPN takes about 3
> minutes on a FAST machine. That?s not acceptable - our users want (almost)
> immediate response to an application, to clicking and waiting 10 seconds
> until the app is doing something.
strange. starting konqueror over my (6Mbit) ADSL Line takes 5 seconds. ping
times to server are 40ms. Of course it's cached on the remote machine. Localy
it takes 2 seconds.
> Yes, this will start Firefox (as an example) down to 2 minutes 15 seconds
> and put additional compression/decompression load on the system. We go for
> AIP right now (Sun Secure Global Desktop), there you have the feeling as if
> you were sitting in front of the box.
No idea what's going on at your machine, but 2.15 minutes for firefox seems to
be seriously broken.
regards
Alex
--
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
On Sat, 20 May 2006, "D?hr, Markus ICC-H" wrote:
> Date: Sat, 20 May 2006 02:57:55 +0200
> From: "\"D?hr, Markus ICC-H\"" <[email protected]>
> To: 'Peter Gordon' <[email protected]>
> Cc: [email protected], [email protected]
> Subject: RE: replacing X Window System !
>
>>> Although one has to admit that working with remote X
>> terminals over a
>>> SSH/WAN/VPN-connection is far from usefull, [...]
>> You can tunnel just about anything X11 over SSH/VPN/etc.; even things
>> like a whole desktop GUI; not just plain X terminals.
>
> Did you actually do that? Starting Firefox over a 6 Mbit VPN takes about 3
> minutes on a FAST machine. That?s not acceptable - our users want (almost)
> immediate response to an application, to clicking and waiting 10 seconds
> until the app is doing something.
this is due to the latency, not the speed (X by default requires many
round-trips to startup). There is an extention that greatly reduces the
number of round-trips nessasary, I'm willing to bet this will make a huge
difference for your startup. Unfortunantly I don't remember what this is.
however the huge delays on startup don't translate into a general slowdown
once the application is started.
yes, this is an add-on, but the way that X evolves is for new
functionality to be initially available as an add-on, and then move into
the core distribution.
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
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.
Implementing an idea before discussing it's feasibility?
Kind of stupid, don't you think?
> Otherwise, you are only wasting your (and our) time since there's
> exactly a 0% probability that someone else will implement your ideas.
Maybe not 0% exactly.
Not that I would agree with the in-Kernel X idea per se, but it does raise
the issue of a stable API once more, as it would allow more freedom to
create a module against a version line w/o fear of being rejected.
Thanks!
--
Al
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
David Lang wrote:
> On Sat, 20 May 2006, "D?hr, Markus ICC-H" wrote:
>
>> Date: Sat, 20 May 2006 02:57:55 +0200
>> From: "\"D?hr, Markus ICC-H\"" <[email protected]>
>> Did you actually do that? Starting Firefox over a 6 Mbit VPN takes
>> about 3
>> minutes on a FAST machine. That?s not acceptable - our users want
>> (almost)
>> immediate response to an application, to clicking and waiting 10 seconds
>> until the app is doing something.
>
> this is due to the latency, not the speed (X by default requires many
> round-trips to startup). There is an extention that greatly reduces the
> number of round-trips nessasary, I'm willing to bet this will make a
> huge difference for your startup. Unfortunantly I don't remember what
> this is.
I think it's called "lbxproxy".
Cheers,
Bart
On Sat, 20 May 2006, Bart Samwel wrote:
> David Lang wrote:
> > On Sat, 20 May 2006, "D?hr, Markus ICC-H" wrote:
> >
> >> Date: Sat, 20 May 2006 02:57:55 +0200
> >> From: "\"D?hr, Markus ICC-H\"" <[email protected]>
> >> Did you actually do that? Starting Firefox over a 6 Mbit VPN takes
> >> about 3
> >> minutes on a FAST machine. That?s not acceptable - our users want
> >> (almost)
> >> immediate response to an application, to clicking and waiting 10 seconds
> >> until the app is doing something.
> >
> > this is due to the latency, not the speed (X by default requires many
> > round-trips to startup). There is an extention that greatly reduces the
> > number of round-trips nessasary, I'm willing to bet this will make a
> > huge difference for your startup. Unfortunantly I don't remember what
> > this is.
>
> I think it's called "lbxproxy".
Description: Low Bandwidth X (LBX) proxy server
Applications that would like to take advantage of the Low Bandwidth
extension
to X (LBX) must make their connections to an lbxproxy. These
applications
need know nothing about LBX, they simply connect to the lbxproxy as if
were a
regular X server. The lbxproxy accepts client connections, multiplexes
them
over a single connection to the X server, and performs various
optimizations
on the X protocol to make it faster over low bandwidth and/or high
latency
connections.
>
> Cheers,
> Bart
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/
> >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
On Sat, May 20, 2006 at 07:33:08AM +0300, Al Boldi wrote:
> 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.
>
> Implementing an idea before discussing it's feasibility?
>
> Kind of stupid, don't you think?
Sure, it does make sense to ask for comments before starting with an
implementation.
But discussing possible patches also becomes kind of stupid if you
aren't willing to implement it yourself.
There have already been more than enough discussions regarding this
issue - if he still considers his idea worth it HE must start with the
implementation NOW.
He seems to be the kind of troll who wants to convince other people of
his "great" ideas without writing a single line of code himself.
> > Otherwise, you are only wasting your (and our) time since there's
> > exactly a 0% probability that someone else will implement your ideas.
>
> Maybe not 0% exactly.
In this case, 0% exactly.
> Not that I would agree with the in-Kernel X idea per se, but it does raise
> the issue of a stable API once more, as it would allow more freedom to
> create a module against a version line w/o fear of being rejected.
It does not raise the issue of a stable kernel API:
The solution is to work on getting the module included into the kernel.
All problems with changing kernel APIs vanish as soon as your module is
included. This is independent from what the module in question is doing.
Documentation/stable_api_nonsense.txt explains the advantages of not
having a stable API.
> Thanks!
> Al
cu
Adrian
BTW: Don't drop people from the Cc.
--
"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
On Saturday 20 May 2006 09:56, Bart Samwel wrote:
> I think it's called "lbxproxy".
NX is probably more useful.
Adrian Bunk wrote:
> On Sat, May 20, 2006 at 07:33:08AM +0300, Al Boldi wrote:
> > Not that I would agree with the in-Kernel X idea per se, but it does
> > raise the issue of a stable API once more, as it would allow more
> > freedom to create a module against a version line w/o fear of being
> > rejected.
>
> It does not raise the issue of a stable kernel API:
>
> The solution is to work on getting the module included into the kernel.
> All problems with changing kernel APIs vanish as soon as your module is
> included. This is independent from what the module in question is doing.
Yes, but the question is:
What's the trick to get the module into the kernel?
It seems that we are currently under the mercy of the few, who have the power
to control this. And forking isn't really a solution.
With a stable API, I can just implement whatever w/o caring whether it is
included into the kernel. Now that's freedom!
Thanks!
--
Al
On Saturday May 20, [email protected] wrote:
> Adrian Bunk wrote:
> > On Sat, May 20, 2006 at 07:33:08AM +0300, Al Boldi wrote:
> > > Not that I would agree with the in-Kernel X idea per se, but it does
> > > raise the issue of a stable API once more, as it would allow more
> > > freedom to create a module against a version line w/o fear of being
> > > rejected.
> >
> > It does not raise the issue of a stable kernel API:
> >
> > The solution is to work on getting the module included into the kernel.
> > All problems with changing kernel APIs vanish as soon as your module is
> > included. This is independent from what the module in question is doing.
>
> Yes, but the question is:
> What's the trick to get the module into the kernel?
The 'trick' is to write well designed, maintainable code, and accept
all criticism with good grace. (It helps if the code works too)
By far the best approach is to incrementally improve what is already
in the kernel. In this case, that probably means fbdev and/or DRI.
If you get them to play nicely together and gradually enhance them to
provide the functionality you need, I think you would make a lot of
people happy.
>
> It seems that we are currently under the mercy of the few, who have the power
> to control this. And forking isn't really a solution.
It is true that a thick skin helps. But if you demonstrate (with
code) that you know what you are talking about, and respond
intelligently to all feedback (even when you don't feel the feedback
itself is intelligent) people will listen to you.
The coin of this realm is very much code. That is one of the reasons
to start with small patches to existing code: it increases your
credibility with less investment than creating a great big slab of
code.
>
> With a stable API, I can just implement whatever w/o caring whether it is
> included into the kernel. Now that's freedom!
>
That's userspace.
Improve what is in the kernel so that it presents to userspace
whatever API you need, and write stuff in userspace to your hearts
content. I'm sure that there is no need for the entire 'X' server to
be in the kernel, and I'm equally sure that there are advantages in
the kernel providing more services for an X server than it currently
does. You need to find that balance. It may be hard, but there are
people here who will help. You add bits of functionality - people
will question them and require you to justify them. Some will make it,
some won't. Bit by bit you will arrive at a workable solution.
As a sort of example: were I to start writing an NFS server for Linux
today, I wouldn't put it all in the kernel. I would figure out the
minimum services I needed from the kernel and add them one at a time,
at each step modifying the userspace NFS server to use this
functionality. Some of it would be quite tricky - particularly
achieving zero-copy reads and single-copy writes. But I'm sure it is
possible, and I'm sure there are people here who would help point me
in the right direction.
NeilBrown
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?
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
--- [email protected] 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
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
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
Hi!
> > With a stable API, I can just implement whatever w/o caring whether it is
> > included into the kernel. Now that's freedom!
> >
>
> That's userspace.
>
> Improve what is in the kernel so that it presents to userspace
> whatever API you need, and write stuff in userspace to your hearts
> content. I'm sure that there is no need for the entire 'X' server to
> be in the kernel, and I'm equally sure that there are advantages in
> the kernel providing more services for an X server than it currently
> does. You need to find that balance. It may be hard, but there are
> people here who will help. You add bits of functionality - people
> will question them and require you to justify them. Some will make it,
> some won't. Bit by bit you will arrive at a workable solution.
>
> As a sort of example: were I to start writing an NFS server for Linux
> today, I wouldn't put it all in the kernel. I would figure out the
> minimum services I needed from the kernel and add them one at a time,
> at each step modifying the userspace NFS server to use this
> functionality. Some of it would be quite tricky - particularly
> achieving zero-copy reads and single-copy writes. But I'm sure it is
> possible, and I'm sure there are people here who would help point me
> in the right direction.
I'm sure it is still possible to rewrite knfsd into userspace
:-). With splice & friends, maybe it is now easier to do 0-copy...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Döhr, Markus ICC-H wrote:
>>>Although one has to admit that working with remote X
>>>
>>>
>>terminals over a
>>
>>
>>>SSH/WAN/VPN-connection is far from usefull, [...]
>>>
>>>
>>You can tunnel just about anything X11 over SSH/VPN/etc.; even things
>>like a whole desktop GUI; not just plain X terminals.
>>
>>
>
>Did you actually do that? Starting Firefox over a 6 Mbit VPN takes about 3
>minutes on a FAST machine. That´s not acceptable - our users want (almost)
>immediate response to an application, to clicking and waiting 10 seconds
>until the app is doing something.
>
>
It is not that bad. I tried starting firefox on a machine 20km away,
using a 5Mbps ADSL link from the "wrong" end. (I ssh'ed into
my home pc from work.)
Firefox started in 55s, not 3min. Still bad, but that is a firefox
problem, not a generic X-tunneling problem. I can start the
lyx word processor in 3s over the same link, and have decent
performance while using it too.
Helge Hafting
[...]
> >Did you actually do that? Starting Firefox over a 6 Mbit VPN takes
> >about 3 minutes on a FAST machine. That?s not acceptable - our users
> >want (almost) immediate response to an application, to clicking and
> >waiting 10 seconds until the app is doing something.
> >
> >
> It is not that bad. I tried starting firefox on a machine
> 20km away, using a 5Mbps ADSL link from the "wrong" end. (I
> ssh'ed into my home pc from work.) Firefox started in 55s,
> not 3min. Still bad, but that is a firefox problem, not a
> generic X-tunneling problem. I can start the lyx word
> processor in 3s over the same link, and have decent
> performance while using it too.
55 seconds to start an application... That?s not acceptable. Why do you
think it?s a Firefox problem? Did you try this with a Java application?
I don?t wanna blame X in general, just saying it is useless if you?re
sitting in Hungary or Poland and want to work remotely - in comparision to
M$?s RDP.
The question for me is not "X or not X" - but how to enable people to start
e. g. "sam" on an HP-UX box without needing to wait minutes before the
application starts. It works - for sure, but the speed is for our needs not
acceptable. Additionally ~ 60 ssh sessions on a single box will but a lot of
CPU load on the system beside the fact, that you need a BIG BIG pipe.
--
Markus
Döhr, Markus ICC-H wrote:
>[...]
>
>
>>>Did you actually do that? Starting Firefox over a 6 Mbit VPN takes
>>>about 3 minutes on a FAST machine. That´s not acceptable - our users
>>>want (almost) immediate response to an application, to clicking and
>>>waiting 10 seconds until the app is doing something.
>>>
>>>
>>>
>>>
>>It is not that bad. I tried starting firefox on a machine
>>20km away, using a 5Mbps ADSL link from the "wrong" end. (I
>>ssh'ed into my home pc from work.) Firefox started in 55s,
>>not 3min. Still bad, but that is a firefox problem, not a
>>generic X-tunneling problem. I can start the lyx word
>>processor in 3s over the same link, and have decent
>>performance while using it too.
>>
>>
>
>55 seconds to start an application... That´s not acceptable. Why do you
>think it´s a Firefox problem? Did you try this with a Java application?
>
>
I say it is a firefox problem because other apps don't have this delay!
So clearly, firefox is doing something stupid here that other apps
doesn't do. Waiting 3 seconds isn't that painful.
I haven't tried with a java app - I don't think I have any of those.
Are they special in any way?
>I don´t wanna blame X in general, just saying it is useless if you´re
>sitting in Hungary or Poland and want to work remotely - in comparision to
>M$´s RDP.
>
>
It all depends on what latency and bandwith you have.
5-6 Mbps is enough to have a decent experience, except for
some stupid apps. Firefox is certainly slow in starting, and
somewhat slow later too. But one doesn't have to run firefox,
there are other browsers. And usually, the webbrowser is
something you _can_ run locally. At least if you're simply
trying to read webpages.
>The question for me is not "X or not X" - but how to enable people to start
>e. g. "sam" on an HP-UX box without needing to wait minutes before the
>application starts. It works - for sure, but the speed is for our needs not
>acceptable. Additionally ~ 60 ssh sessions on a single box will but a lot of
>CPU load on the system beside the fact, that you need a BIG BIG pipe.
>
>
60 sessions - sure. The more users, the more resources you need . . .
Helge Hafting
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
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".)
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
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
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
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
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
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
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.
On 5/22/06, D. Hazelton <[email protected]> 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
[email protected]
---------- Forwarded message ----------
From: Xiong Jiang <[email protected]>
Date: May 23, 2006 10:15 AM
Subject: Re: OpenGL-based framebuffer concepts
To: Alan Cox <[email protected]>
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Jon Smirl <[email protected]> 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 | [email protected]
On 5/23/06, Matthew Garrett <[email protected]> wrote:
> Jon Smirl <[email protected]> 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
[email protected]
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
On 5/23/06, Kyle Moffett <[email protected]> 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
[email protected]
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
On Tuesday 23 May 2006 23:38, Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <[email protected]> wrote:
> > Jon Smirl <[email protected]> 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
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
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
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
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
>
> 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.
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
On 5/23/06, D. Hazelton <[email protected]> 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
[email protected]
On Wednesday 24 May 2006 04:21, Jon Smirl wrote:
> On 5/23/06, D. Hazelton <[email protected]> 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
On 5/23/06, Jeff Garzik <[email protected]> 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
[email protected]
On 5/23/06, D. Hazelton <[email protected]> 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
[email protected]
On Wednesday 24 May 2006 04:57, Jon Smirl wrote:
> On 5/23/06, D. Hazelton <[email protected]> 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
> > 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.
Jon Smirl wrote:
> On 5/23/06, Jeff Garzik <[email protected]> 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
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
> > 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.
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
Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <[email protected]> wrote:
>> Jon Smirl <[email protected]> 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
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
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 | [email protected]
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.
On Tue, May 23, 2006 at 07:38:40PM -0400, Jon Smirl wrote:
> On 5/23/06, Matthew Garrett <[email protected]> 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
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 - http://www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
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
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
On 5/24/06, Alexander E. Patrakov <[email protected]> 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
[email protected]
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
On 5/24/06, Dave Airlie <[email protected]> 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
[email protected]
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 -- [email protected]
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
On 5/24/06, Alexander E. Patrakov <[email protected]> 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.
Matheus Izvekov wrote:
> On 5/24/06, Alexander E. Patrakov <[email protected]> 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
On 5/24/06, Alexander E. Patrakov <[email protected]> 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
[email protected]
On 5/24/06, Alexander E. Patrakov <[email protected]> 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.
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
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 | [email protected]
On 5/24/06, Matthew Garrett <[email protected]> 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
[email protected]
> 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.
On 5/24/06, Dave Airlie <[email protected]> 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
[email protected]
>
> 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.
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
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
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
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
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
On 5/25/06, Jeff Garzik <[email protected]> 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
[email protected]
Jon Smirl wrote:
> On 5/25/06, Jeff Garzik <[email protected]> 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
On 5/25/06, Jeff Garzik <[email protected]> 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
[email protected]
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 - http://www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
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
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
> > 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.
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
Jon Smirl wrote:
> On 5/25/06, Jeff Garzik <[email protected]> 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
> > 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.
On 5/25/06, Jeff Garzik <[email protected]> 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
[email protected]
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
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
Alexander E. Patrakov wrote:
> Matheus Izvekov wrote:
>> On 5/24/06, Alexander E. Patrakov <[email protected]> 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
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
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
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
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
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
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
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
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.
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.
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.
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
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
On 5/27/06, D. Hazelton <[email protected]> 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
[email protected]
On Sunday 28 May 2006 00:03, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <[email protected]> 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
On 5/27/06, D. Hazelton <[email protected]> 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
[email protected]
On Sunday 28 May 2006 02:34, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <[email protected]> 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
On 5/27/06, D. Hazelton <[email protected]> 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
[email protected]
On Sunday 28 May 2006 03:27, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <[email protected]> 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
> > 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.
On 5/28/06, Dave Airlie <[email protected]> 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
[email protected]
On Sun, May 28, 2006 at 08:59:19PM -0400, Jon Smirl wrote:
> On 5/28/06, Dave Airlie <[email protected]> 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.
On 5/28/06, Daniel Stone <[email protected]> wrote:
> On Sun, May 28, 2006 at 08:59:19PM -0400, Jon Smirl wrote:
> > On 5/28/06, Dave Airlie <[email protected]> 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
[email protected]
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.)
> > 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.
On 5/28/06, D. Hazelton <[email protected]> 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
[email protected]
On Monday 29 May 2006 04:05, Jon Smirl wrote:
> On 5/28/06, D. Hazelton <[email protected]> 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
On Monday May 29, [email protected] 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
>
> 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.
On Monday May 29, [email protected] 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
On Monday 29 May 2006 04:58, Neil Brown wrote:
> On Monday May 29, [email protected] 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
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
> >
> > 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.
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
> > 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.
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
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
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
On 5/29/06, Jeff Garzik <[email protected]> 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
[email protected]
> > 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.
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
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
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
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
On Monday 29 May 2006 22:10, Jon Smirl wrote:
> On 5/29/06, Jeff Garzik <[email protected]> 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
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)
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
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
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
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
On 5/30/06, Pavel Machek <[email protected]> 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
[email protected]
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 <[email protected]> wrote:
> On 5/30/06, Pavel Machek <[email protected]> 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
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
On 5/30/06, Antonino A. Daplas <[email protected]> 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
[email protected]
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: [email protected], jabber: [email protected])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
On 5/30/06, Ondrej Zajicek <[email protected]> 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
[email protected]
> >
> > > >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.
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
On 5/30/06, Dave Airlie <[email protected]> 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
[email protected]
On Tue, May 30, 2006 at 07:27:25PM -0400, Jon Smirl wrote:
> On 5/30/06, Dave Airlie <[email protected]> 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/
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
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 <[email protected]> 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
On 5/30/06, Daniel Stone <[email protected]> wrote:
> On Tue, May 30, 2006 at 07:27:25PM -0400, Jon Smirl wrote:
> > On 5/30/06, Dave Airlie <[email protected]> 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
[email protected]
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
On 5/30/06, Antonino A. Daplas <[email protected]> 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
[email protected]
Jon Smirl wrote:
> On 5/30/06, Antonino A. Daplas <[email protected]> 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.
On 5/30/06, Antonino A. Daplas <[email protected]> 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
[email protected]
On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> On 5/30/06, Dave Airlie <[email protected]> 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
On 5/30/06, D. Hazelton <[email protected]> wrote:
> On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> > On 5/30/06, Dave Airlie <[email protected]> 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
[email protected]
On Wednesday 31 May 2006 04:02, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <[email protected]> wrote:
> > On Tuesday 30 May 2006 23:27, Jon Smirl wrote:
> > > On 5/30/06, Dave Airlie <[email protected]> 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
On 5/30/06, D. Hazelton <[email protected]> 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
[email protected]
On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <[email protected]> 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
On 5/30/06, D. Hazelton <[email protected]> wrote:
> On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> > On 5/30/06, D. Hazelton <[email protected]> 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 <[email protected]>) and DRM (Dave Airlie
<[email protected]>) 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
[email protected]
On Wednesday 31 May 2006 04:39, Jon Smirl wrote:
> On 5/30/06, D. Hazelton <[email protected]> wrote:
> > On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
> > > On 5/30/06, D. Hazelton <[email protected]> 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 <[email protected]>) and DRM (Dave Airlie
> <[email protected]>) 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
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 <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Minimalist definition of maximalism: `more!'.
On 5/31/06, Martin Mares <[email protected]> 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
[email protected]
> >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 <[email protected]> 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?
On Wednesday 31 May 2006 07:13, Jon Smirl wrote:
> On 5/31/06, Martin Mares <[email protected]> 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
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
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: [email protected], jabber: [email protected])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
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 <[email protected]> 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: [email protected], jabber: [email protected])
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
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
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 <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.
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 -- [email protected]
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
On 5/31/06, Geert Uytterhoeven <[email protected]> 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
[email protected]
Jon Smirl <[email protected]> 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 | [email protected]
On 5/31/06, Matthew Garrett <[email protected]> wrote:
> Jon Smirl <[email protected]> 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 | [email protected]
>
--
Jon Smirl
[email protected]
>
>> 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
--
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
On Thursday 01 June 2006 02:19, Jon Smirl wrote:
> On 5/31/06, Antonino A. Daplas <[email protected]> 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
Jon Smirl wrote:
> On 5/30/06, D. Hazelton <[email protected]> wrote:
>> On Wednesday 31 May 2006 04:16, Jon Smirl wrote:
>> > On 5/30/06, D. Hazelton <[email protected]> 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 <[email protected]>) and DRM (Dave Airlie
> <[email protected]>) 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
On 5/31/06, Antonino A. Daplas <[email protected]> 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
[email protected]
Jon Smirl wrote:
> On 5/31/06, Antonino A. Daplas <[email protected]> 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
On 5/31/06, Antonino A. Daplas <[email protected]> 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
[email protected]
Jon Smirl wrote:
> On 5/31/06, Geert Uytterhoeven <[email protected]> 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
On 5/31/06, D. Hazelton <[email protected]> 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
[email protected]