[plug] Display control

[Kevin Shackleton]

Thanks for the comments gents.

I'm trying to keep it really simple from the contributor end, since at
least 2 of these will be updating the central display through screen shots
or perhaps batch files - I'm not going to reverse-engineer complex
applications.

The project doesn't need anything fancy in terms of frame rate or rendering
cleverness, I just need to be able to handle multiple sources of
displayable info, perhaps 1 minute updates.

I could create multiple frames in a web page, but that lends itself to
putting just an image in each (unless I commit to a horrific amount of more
clever code) - an evolutionary dead end perhaps.  I didn't find a
pane-managing part of pyopengl - it seems more bent on what you can do in
one canvas.

Terminal Multiplexer is sort of what I want except it's terminals.

Going right back to the window manager, xmonad looks interesting.  Don't
know if I can automate all I want across the tiles though.  Will play . .

Regards,

Kevin.

On 22 December 2014 at 23:58, Bernd Felsche <bernie at innovative.iinet.net.au>
wrote:

> 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
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20141223/c04e5711/attachment.html>