Graphics on graphical displays (was Re: [Lcdproc] Hi - and a question)
Jason Ball
jason@ball.net
Fri Jan 12 06:34:02 2007
------=_Part_23925_1277026.1168583576856
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Similar to what I was thinking, just curious what people may have done.
One idea would be to 'partition' the display into 'virtual' devices,
i.e.
for a 40*2 display:
Dev A: 2*20, position 1->20.
Dev B: 2*20, position 21-40.
using a user mode driver to facilitate the 'windows'. LCDProc could be
configured as you would for multiple displays on a single system (two
daemons perhaps) communicating with the user mode driver. The 'window'
driver would merge the input streams and render accordingly.
In my situation there would be 3 to 4 windows. Ideally this 'windowing'
would be built in to LCDProc, but I would want to demonstrate the idea
before committing to that work.
This option would achieve the goals although changing the number, size and
locations of the 'windows' on the fly would be an issue.
So much to do and so little time!
Cheers
Jason.
On 1/12/07, Ethan Dicks <ethan.dicks@gmail.com > wrote:
>
> On 1/11/07, Jason Ball <jason@ball.net > wrote:
> >
> > Hi all,
>
> Hi, Jason,
>
>
> >Perhaps you could work with a different low-level driver that would
> >handle your windowing, then write a new LCDd "driver" interface
> >like the glue logic between glcdlib and LCDproc - then your running
> >LCDd daemon would _think_ it owns a patch of screen and change
> >the renderings, but your new low-level driver would _really_ be
> >managing the pixels.
>
> Does this sound like an idea worth further discussion?
I'm curious on that one. :)
Cheers
Jason.
--
The era of procrastination, of half measures of soothing and baffling
expedients, of delays, is coming to an end. In it's place we are entering a
period of consequences. - Winston Churchill
<a href=http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html>An
Inconvenient Truth</a>
--
The era of procrastination, of half measures of soothing and baffling
expedients, of delays, is coming to an end. In it's place we are entering a
period of consequences. - Winston Churchill
<a href=http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html>An
Inconvenient Truth</a>
------=_Part_23925_1277026.1168583576856
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<span class="gmail_quote"><br><br></span>Similar to what I was thinking, just curious what people may have done.<br><br>One idea would be to 'partition' the display into 'virtual' devices, <br><br>i.e. <br>
<br>for a 40*2 display: <br><br> Dev A: 2*20, position 1->20.
<br> Dev B: 2*20, position 21-40.<br><br>using a user mode driver to facilitate the 'windows'. LCDProc could be configured as you would for multiple displays on a single system (two daemons perhaps) communicating with the user mode driver. The 'window' driver would merge the input streams and render accordingly.
<br><br>In my situation there would be 3 to 4 windows. Ideally this 'windowing' would be built in to LCDProc, but I would want to demonstrate the idea before committing to that work.<br><br>This option would achieve the goals although changing the number, size and locations of the 'windows' on the fly would be an issue.
<br><br>So much to do and so little time!<br><br>Cheers<br>Jason.<br><br><div><span class="q"><span class="gmail_quote">On 1/12/07, <b class="gmail_sendername">Ethan Dicks</b> <<a href="mailto:ethan.dicks@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ethan.dicks@gmail.com
</a>> wrote:</span></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="q">On 1/11/07, Jason Ball <<a href="mailto:jason@ball.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
jason@ball.net
</a>> wrote:<br>><br>> Hi all,<br><br>Hi, Jason,<br><br><br></span><span class="q">>Perhaps you could work with a different low-level driver that would<br>>handle your windowing, then write a new LCDd "driver" interface
<br>>like the glue logic between glcdlib and LCDproc - then your running<br>>LCDd daemon would _think_ it owns a patch of screen and change<br>>the renderings, but your new low-level driver would _really_ be<br>
>managing the pixels.
<br><br></span><span class="q">Does this sound like an idea worth further discussion?</span></blockquote><div><br>I'm curious on that one. :)<br></div><br>Cheers<br>Jason.<br></div><span class="sg"><br clear="all"><br>
-- <br>The era of procrastination, of half measures of soothing and baffling expedients, of delays, is coming to an end. In it's place we are entering a period of consequences. - Winston Churchill
<br><a href=<a href="http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html
</a>>An Inconvenient Truth</a>
</span><br clear="all"><br>-- <br>The era of procrastination, of half measures of soothing and baffling expedients, of delays, is coming to an end. In it's place we are entering a period of consequences. - Winston Churchill
<br><a href=<a href="http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html">http://www.climatecrisis.net/downloads/ecards/preview-glacier1.html</a>>An Inconvenient Truth</a>
------=_Part_23925_1277026.1168583576856--