Re: framebuffer (was As86?)
Heather wrote:
> > Hi,
> >
> > Heather <star@betelgeuse.starshine.org> writes:
> >
> > > ob laptop: framebuffer is driving me nuts. What should be so different
> > > about framebuffer support under Debian (potato/woody mix) and RH 6.1, that
> > > the latter "just works" for framebuffer X, but Debian complains? (the
> > > framebuffer does work for console though)
> >
> > You're using framebuffer X? Why? There's no acceleration in the
> > kernel framebuffer devices. You will almost certainly be faster using
> > the correct Xserver. In fact, the console will be significantly faster
> > if you don't use the framebuffer device.
>
> As an experiment of course. What's the fun in things if you can't understand
> them? Also, if a video chipset is accelerated but imperfect in other ways
> on a brand new server, or merely "slow" on framebuffer, I'll take stability,
> thanks.
>
> When dealing with a completely new critter, the first one that works will
> win. And since I hang out at installfests occasionally, I'd rather be able
> to slap in framebuffer and then say that better exists, than send someone
> away with no X usable at all. Near the end of the run time may matter more
> than whether it plays Quake adequately.
There are other reasons to use the framebuffer, like security: if you have
untrusted users, you only need to audit the small bit of code in the fb, then you
can run X non-suid, instead of counting on all of X to be free of security
holes. The same goes for DRI: untrusted users can send conflicting commands to
accel engines and crash video cards; it's a known problem with a known (though
far-off) solution of abstracting access to accel engines, but not enough people
need/want this to make it a priority now.
Also, a correction: X on framebuffer *is* accelerated for many chipsets,
primarily for those arches which use framebuffers exclusively, like PPC (e.g.
there's atyfb and clgenfb acceleration support in X; Debian uses fb exclusively
though there's also Xpmac).
The two approaches will coexist side-by-side, and the one with better cumulative
performance, ease of use, stability and security over time will eventually get
more users and developers. As with everything Open Source, in the end, the best
code wins. :-)
-Adam P.
Reply to: