Subject: Re: [linux-audio-dev] framebuffer devices
From: David Olofson (david_AT_gardena.net)
Date: Fri Jan 19 2001 - 18:26:11 EET
On Thursday 18 January 2001 17:01, Benno Senoner wrote:
> On Mon, 15 Jan 2001, Andrew Morton wrote:
> > How serious an issue is the latency introduced by fbdevs?
> >
> > I've taken a look at what's going on in there and it seems
> > that it's fairly straightforward to fix (*). It definitely
> > _needs_ fixing - it's putrid.
> >
> > The one drawback of the approach I'm thinking about is that
> > kernel printk's from interrupt context wouldn't appear
> > on the console (but they would make it to the logfile). Or
> > maybe they will, but delayed a bit.
> >
> > Question is: is this worth the effort, or are people
> > OK with just running X or vgacon all the time?
>
> If latencies can be fixed, it would be nice.
> Perhaps someone would want to use a Linux box in fbdev mode as a
> realtime video processing box. (30-60fps without frame losses).
I just browsed some site on the history of trackers, and remembered
what made these programs feel a lot more solid than anything I've
ever seen in windowed environments: The panel oriented user
interfaces (no window fiddling) and the lightning fast and smooth
animation. :-)
Of course, it's possible to write full screen X applications, but I
still think fbdev is more appropriate for that, especially
considering it's footprint compared to X. It also allows some neat
software rendering tricks that cannot be done efficiently on X, and
seems to fit a lot better into real time systems... (Remember the
fancy visualization panels of the Amiga trackers? Not essential for
the functionality or technically impressive, but I still haven't seen
any windowed application do similar things as smoothly. That kind of
stuff does affect the feel of the GUI a great deal, IMHO.)
> With X it is currently not easy (or impossible ?) to achieve zero
> frame losses, due to the X process running as a normal user
> process.
Well, you can promote it to SCHED_FIFO, it seems, but it's kind of
flaky, to say the least. The X server shows all kinds of nasty signs
of not being a real time program! *hehe*
> Perhaps this can be achieved using DRI, but I'm not an expert in
> that field.
It still seems that the X server process will get in the way in some
cases anyway, but hopefully, I'm wrong. I've only looked more
carefully at the Utah-GLX code, and just read some articles on DRI.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Fri Jan 19 2001 - 18:54:04 EET