On Fri, 26 February 2010 Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
quoted text
> On Fri, Feb 26, 2010 at 6:53 PM, Bruno Prémont wrote:
> > For me the driver would start with a default delay that matches the
> > full-redraw throughput of the device but userspace could reduce the
> > delay when it knows it will mostly just refresh small parts of the
> > display (one or two tiles) and would like those done at a higher
> > rate.
> 
> Who in userspace will know to reduce the delay? How will it know that
> the delay should be reduced?

The default (maybe even the largest) period would indicate what the
hardware can do in worst case and the smallest period what the hardware
can do in best/special cases (like single-tile update for PicoLCD)

Any application that wants to output information might want to know
how often the information can be displayed (what's the need to
calculate 1000 frames per second if only 2 of them will ever be seen
on display?). When possible and they know their display needs they
might benefit from ability to tune the result.

quoted text
> > A sample application would be displaying a media player interface
> > like the one of XMMS and clones where Umeter (the part displaying
> > volume per frequency range) could be refreshed ten times a second,
> > the current position once a second and all the rest only on song
> > change.
> 
> xmms/umeter will talk to this sysfs entry?

Probably not XMMS itself but either a plugin for it or a human
interface to player that takes input from a remote control and
displays status to LCD (instead of/in addition to OSD)

quoted text
> > Knowing the size of the display, probability that it's being used
> > directly by X server is very small, it would rather be some
> > application using it as a sideport display.
> >
> 
> Yes, I'd like to know which applications these are.

I don't have an example at hand. I would rather see plugins for media
players (like those that use LCD4Linux or LCDproc) benefit from such
a feature.

Thanks,
Bruno
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/