lkml.org 
[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SUMMARY: GGI/X : the other way??
Date
Alan Cox said:
> > IIRC, DGA requires root access on the part of the client (the X server
> > simply gives the DGA client an offset into /dev/mem, and the client is
> > responsible for actually mmapping it), since it needs to mmap /dev/mem to
> > get at the framebuffer ... from there, we get back to mostly the same
> > problems as in SVGALib.
>
> Thats simply an implementation flaw with DGA not a design flaw.

An fb device would solve this, but as linux didn't have a revoke syscall I
never sent my DGA compatible /dev/fb to linus. The security issues of a
publically readable /dev/fb are very compicated (I would like to know how
ggi has tried to get round them).

> > Yeah, pretty much, although IIRC, DGA apps really don't have any good way to
> > access acceleration at all anyway.
>
> Yes. That is a -big- issue.

As the XFree96 4.0 drivers will be modular it could link them in, but we get
back to the "must be root" problems. But if you are going to use a lot of
accelarated stuff, it is probably better staying in X and using MIT shmem.
X is already optimized for the cards accelarate features..

DGA was added for the apps (games) that just wanted a lot of framebuffer
bandwidth. To be exact I wrote if for Dave Taylor for xquake...

> fbcon is modular if it needs to be, and it deals with accelerations it needs
> to know about in text mode and exposes the other stuff to the X server. It
> deals with the mode changes too.

Yes I think fbcon has all that is needed.

Jon.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans