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? :)