[plug] Display control

[Bernd Felsche]

On Mon, 22 Dec 2014 23:07:09 Tim Bowden wrote:
> On Mon, 2014-12-22 at 18:52 +0800, Kevin Shackleton wrote:

> > Here's a fairly abstract problem.  I would demonstrate a solution on
> > e.g. a Raspberry Pi, and transition to some tougher industrial PC. 
> > It could be described as a "business situational awareness display"
> > 
> > This PC is to be set up in a central area of a business, driving a
> > fairly good display.  It will share a folder (or tree if you like).
> > 
> > Other PCs can feed various files onto this central display PC's
> > shared folders.  The PC then draws these appropriately, switching
> > from single-pane to 2-pane, 4 pane, maybe 6 or 8 pane to
> > accommodate displaying the data.  The contributor PCs would delete
> > the data to cancel their display.
> > 
> > In the simplest form, the data would be images (screen shots maybe).
> > More sophistication could include:
> >  - some consistency in which pane each contributor is displayed.
> >  - maybe a rolling sequence could be used instead of, or as well as,
> > 
> > multiple panes.
> >  - handling other file formats including Office formats.
> >  - labelling each panel with some text identifying the source.
> >  - probably lots of other things I have not thought about

> > I don't really want to get into the capabilities of X, because the
> > contributors will be dumb to X (i.e. Windows)

> I take it the 'central display PC' will be non-interactive (ie, no
> keyboard or mouse)?  Can't you just set it up to display a web page
> that gets updates with a bit of javascript?  Central web server
> somewhere else holds the 'folders' and generates the content based on
> that to be served on the next poll by the web page.

For the underlying display technology, one can adopt OpenGL for
embedded system as in e.g.  https://www.khronos.org/egl/

There are *many* OpenGL libraries/bindings in convenient languages
such as Python. http://pyopengl.sourceforge.net/

Here's an antique example of direct framebuffer access
https://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-
raspberry-pi-without-x-windows/

I mentioned Python because that also has a trove of rendering
libraries for different types of source data.

In terms of operational resilience, you might like to consider
deploying a cluster of RPi with a "despatcher" doing the "data
collection" and controlling which RPi in the cluster will be
displaying the data on its own display.

You may need something with more grunt to pre-process complex data
for display. Separation of the despatch and display roles provides
flexibility in implementation while allowing robust elements to be
developed independently.

A WebUI can be provided by the despatcher, providing a convenient
interface to upload data to be displayed and a convenient on/off
button to make the data go away.

Authentication will definitely be an issue in such a situation, as
will encryption and otherwise securing the dat to be displayed.
Letting just anybody to upload and control the "situational
awareness" displays is asking for trouble.

Unfortunately, I ran out of time to play enough with OpenGL to get
to the point where it "clicked". I was just "kicking the tyres", not
driving.

-- 
/"\ Bernd Felsche - Somewhere in Western Australia
\ /  ASCII ribbon campaign | For every complex problem there is an
 X   against HTML mail     | answer that is clear, simple, and wrong.
/ \  and postings          |  --HL Mencken