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. 
[lots more real helpful stuff clipped *sigh*]

Well, this explains a lot :)

Anyways, I've been mucking about a bit with DRI+3dfx/glide+X.  I'm going
to attack making it more fbdev-friendly...  (and try to get
Mesa/3dfx-Banshee working under a console :)

Don't know how much luck I'll have but ya never know.

Incidentally, I'm -going- to write a scale-target for GGI.  Any
suggestions on what I should base it on?  Currently I'm looking at palemu
but I don't like it.  Target-writing is a royal pain!
I've got this -beautiful- scaling code and a lot of programs don't work on
my card as 320x200 tends to leave my monitor unusable...   *sigh*  (as
does 640x480x16colour...).  I'd guess a bug in the Diamond Fusion but I
don't know any better yet.

G'day, eh? :)
        - Teunis

Reply via email to