On Sat, 18 Dec 1999, James Simmons wrote:
> 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.
I think to solve this really bad issue, to write a DRI-target for GGI,
which checks if fbcon is already used or not.
If fbcon is used, the DRI-target should redirect to the fbdev-target to
start the XGGI-Server, otherwise...
> > 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
> > 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 :(
OTOH Linus will learn with the time. In the future when DRI is in the
standard kernel and on the linux kernel list comes more and more reports
about security and stability problems, Linus can't no longer ignore that.
Then perhaps there is a chance to get Steffen's KGI into the kernel...
> > (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.
Ooops - may be I am wrong above with my suggestion with a DRI-target
for GGI... :-(
> > 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.
E-Mail: [EMAIL PROTECTED]