Re: Proposal for a low-level Linux display framework

[Enrico Weigelt <weigelt@metux.de>]

* Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

Hi folks,


just some *naive* thoughts (actually, I dont really understand much
of the hardware and the APIs ;-o).

> So we may have something like this, when all overlays read pixels from
> separate areas in the memory, and all overlays are on LCD display:
> 
>  .-----.         .------.           .------.
>  | mem |-------->| ovl0 |-----.---->| LCD  |
>  '-----'         '------'     |     '------'
>  .-----.         .------.     |
>  | mem |-------->| ovl1 |-----|
>  '-----'         '------'     |
>  .-----.         .------.     |     .------.
>  | mem |-------->| ovl2 |-----'     |  TV  |
>  '-----'         '------'           '------'

This somehow reminds me on the spire concept on C64 ;-)

Wouldn't this call for an model and API which understands the
concept of windows or sprites ?

Lets say: we have some (virtual?) image (that's in the end seen
by the user in front) that's made of certain visual objects.
These objects all have their datasource (might be some in-memory
framebuffer or even some external input). Somethings in the middle,
lets call it compositor, somehow attached to these objects puts
them together and generate the output for the physical output
device (end the end of the pipeline, we'll have somehing like analog
VGA or digital HDMI signal, or whatever).

Ah, of course, the connections between these (sub)devices are not
arbitrary, they might be switchable between a certain set of endpoints
and might support different formats or transformation types
(just like a amplifier in a HiFi could switch between several inputs
where other devices are cabled-onto, but it wouldn't be able to
connect directly to a video recorder that's just plugged to the 
TV by SCART cabling).

In the end this IMHO looks like its all about routing and transformation.
Not as simple as IP routing, more like carrier or phone networks
w/ different media types, encodings, in- vs. outbound-signaling, etc.
(hmm, welcome to the world of traffic engineering ;-))

Things like power management could go the opposite direction by an
dependency graph: switching off the monitor could tell the output
hardware that it's not needed now, and this one could tell its inputs
that they're also currently not needed, and so on, and so on. All of
them could tell their power supplies that they're not needed, and if
no active users are left in a subgraph, the power is cut.


No idea, if this all makes sense in that area, so feel free to
correct me if I'm wrong ;-O


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------