Graphics on graphical displays (was Re: [Lcdproc] Hi - and a question)

[Piotr Chmura]

This is a multi-part message in MIME format.

--_Part_1o2z5t.7f4x5s=_992107.cqqzlb
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

Uzytkownik Jason Ball <jason@ball.net> napisał:
>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.

What about client, which listens on several ports (one port per 'window'), with LCDd compatible protocol and composes final screen.

for example (on 20*2 display):
LCDd <->
virtualWindows client:
 - window1 (20*1 starting at 1,1) <-> currentClient1 ; currentClient2 
 - window2 (10*1 starting at 1,2) <-> currentClient3
 - window3 (10*1 starting at 11,2) <-> currentClient4



--_Part_1o2z5t.7f4x5s=_992107.cqqzlb
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="załacznik_1"

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_1o2z5t.7f4x5s=_992107.cqqzlb--