<div dir="ltr"><div><div><div>Thanks for the comments gents.<br><br></div>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.<br><br></div>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.<br><br>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.<br><br></div><div>Terminal Multiplexer is sort of what I want except it's terminals.<br></div><div><br></div><div>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 . .<br><br></div><div>Regards,<br><br>Kevin.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 December 2014 at 23:58, Bernd Felsche <span dir="ltr"><<a href="mailto:bernie@innovative.iinet.net.au" target="_blank">bernie@innovative.iinet.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 22 Dec 2014 23:07:09 Tim Bowden wrote:<br>
> On Mon, 2014-12-22 at 18:52 +0800, Kevin Shackleton wrote:<br>
<br>
</span><span class="">> > Here's a fairly abstract problem.  I would demonstrate a solution on<br>
> > e.g. a Raspberry Pi, and transition to some tougher industrial PC.<br>
> > It could be described as a "business situational awareness display"<br>
> ><br>
> > This PC is to be set up in a central area of a business, driving a<br>
> > fairly good display.  It will share a folder (or tree if you like).<br>
> ><br>
> > Other PCs can feed various files onto this central display PC's<br>
> > shared folders.  The PC then draws these appropriately, switching<br>
> > from single-pane to 2-pane, 4 pane, maybe 6 or 8 pane to<br>
> > accommodate displaying the data.  The contributor PCs would delete<br>
> > the data to cancel their display.<br>
> ><br>
> > In the simplest form, the data would be images (screen shots maybe).<br>
> > More sophistication could include:<br>
> >  - some consistency in which pane each contributor is displayed.<br>
> >  - maybe a rolling sequence could be used instead of, or as well as,<br>
> ><br>
> > multiple panes.<br>
> >  - handling other file formats including Office formats.<br>
> >  - labelling each panel with some text identifying the source.<br>
> >  - probably lots of other things I have not thought about<br>
<br>
> > I don't really want to get into the capabilities of X, because the<br>
> > contributors will be dumb to X (i.e. Windows)<br>
<br>
</span><span class="">> I take it the 'central display PC' will be non-interactive (ie, no<br>
> keyboard or mouse)?  Can't you just set it up to display a web page<br>
> that gets updates with a bit of javascript?  Central web server<br>
> somewhere else holds the 'folders' and generates the content based on<br>
> that to be served on the next poll by the web page.<br>
<br>
</span>For the underlying display technology, one can adopt OpenGL for<br>
embedded system as in e.g.  <a href="https://www.khronos.org/egl/" target="_blank">https://www.khronos.org/egl/</a><br>
<br>
There are *many* OpenGL libraries/bindings in convenient languages<br>
such as Python. <a href="http://pyopengl.sourceforge.net/" target="_blank">http://pyopengl.sourceforge.net/</a><br>
<br>
Here's an antique example of direct framebuffer access<br>
<a href="https://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-
raspberry-pi-without-x-windows/" target="_blank">https://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-<br>
raspberry-pi-without-x-windows/</a><br>
<br>
I mentioned Python because that also has a trove of rendering<br>
libraries for different types of source data.<br>
<br>
In terms of operational resilience, you might like to consider<br>
deploying a cluster of RPi with a "despatcher" doing the "data<br>
collection" and controlling which RPi in the cluster will be<br>
displaying the data on its own display.<br>
<br>
You may need something with more grunt to pre-process complex data<br>
for display. Separation of the despatch and display roles provides<br>
flexibility in implementation while allowing robust elements to be<br>
developed independently.<br>
<br>
A WebUI can be provided by the despatcher, providing a convenient<br>
interface to upload data to be displayed and a convenient on/off<br>
button to make the data go away.<br>
<br>
Authentication will definitely be an issue in such a situation, as<br>
will encryption and otherwise securing the dat to be displayed.<br>
Letting just anybody to upload and control the "situational<br>
awareness" displays is asking for trouble.<br>
<br>
Unfortunately, I ran out of time to play enough with OpenGL to get<br>
to the point where it "clicked". I was just "kicking the tyres", not<br>
driving.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
/"\ Bernd Felsche - Somewhere in Western Australia<br>
\ /  ASCII ribbon campaign | For every complex problem there is an<br>
 X   against HTML mail     | answer that is clear, simple, and wrong.<br>
/ \  and postings          |  --HL Mencken<br>
<br>
_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
</font></span></blockquote></div><br></div>