Sorry. I have been away for awhile. Busy with other projects.
> This is one of the reasons why DRI is a Bad Thing. Security and stability
> should be the preferences of an OS. Even if it sacrifices some speed.
> Arguments? :)
I completely agree, In fact DRI boils down to a attempt to make userland
access to video hardware SMP safe. I had a talk with Darlly Strauss about
fbdev and DRI. He uses fbcon. Basically it boiled down to fbcon is nice
for a graphical console but when we start talking about locking and fbdev
needing locks. What I discovered was DRI X servers ignore that fact fbdev
exist and does mode setting and mapping the framebuffer from userspace.
Once the X server exits it then allows fbcon to take over. So it looks
like the goal is to allow fbcon and let the /dev/fb interface die
away. Where DRI will do the old fashion userland setting of the
video mode and accel hardware access.
> Q: How does one talk to an accelerator?
>
> A: Depends on the card. Possible routes:
> (/Aside: Anyone know how the SGI direct rendering system works? /Aside end)
Sort of thanks to Mike Macovitch . I was working with Mike Macovitch from
SGI to make a open source direct rendering engine. He left SGI several
weeks ago and I haven't heard from him since. I hope to hear from him
soon.
> X works this way too currently but is farely well tested so doesn't
> tend to make your display unusable when it dies... (I do mean -when-
> for me anyways. Most other people have never seen X crash :)
I wish that was the case for me :( When my X server dies it takes my
system with it.
> ! you can't share the accelerator with another program
DRI tries to solve that. Just in a very poor way.
[security and other problems]
[snip ...]
Its in the thread I had with linus. Linus will not move his postion on
this topic. He supports userland locking. Even tho I proved to him its not
safe. You can tell by his lame response toward the end of the end of the
thread. He wants maximum pefformace even if its means giving up security
and stability :(
> (ggi doesn't support DRI. Why not?)
Because DRI authorization to use the accel engine is built into the X
server. Thus DRI can be only used with X. I have spoken already with
DRI on this. They seemed interested but nothing came of this. They kind
of brushed it under teh carpet. This is teh second time I have spoken
with them. The first time I asked them if tehy would support the fbdev
project by writing fbdev driver. They just ignored me. Oh wells. See the
thread I had with Linus on this.
> incidentally, I like this proposal for features...
>
> Could use some rearranging but I can't think straight anymore.
> Could use a real explanation other than the occasional blurb on why some
> situations are Bad Things. Such as DRI, FBdev, ... (afaik the only
> problem that fbdev has is no 'testmode' feature to see if a mode's
> possible - just a way of setting the mode and then testing if it
> succeeded)
I have been sending patches for 2.3.x for fbdev to clean this up. Their
are protocols for fbdev to test if a mode is valid. Unfortunely most
drivers are broken in this case. So I have been going around and cleaning
this up. Hopefully when 2.4.x comes out all drivers will work properly.
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
