[plug] Display control
bernie at innovative.iinet.net.au
Mon Dec 22 15:58:15 UTC 2014
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
> 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
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
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
/"\ 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
More information about the plug