Switching between virtual desktops

[Luca Bezerra]

Hello, world!
I've decided to give a return to you all about the closure of this chapter
of my project.
After months talking to my boss and trying to convince him that this idea of
fast-switching between monitors with a single graphics board was no good, he
finally accepted the idea - at least for a while.
Since he has requested a lot of funds for internships lately, he's under
pressure for results on the projects, so, at least for a short-term solution
on this matter, he agreed to use LTSP, and 'postpone' the switching idea to
the next year (in which Im pretty sure I wont be working there anymore, so
it's not going to be my problem to deal with :).

After this brief explanation, I'd like to thank all of you who tried to help
me on this crusade :P Im trully sorry I couldn't manage to make this work,
'cause if I had, it'd really be an awesome thing. But, at the same time, I'm
glad I got rid of this huge responsability, because there was no way I
could, just by myself, develop such solution in so short time, with my
current knowledge.

Once again, thanks for all the help, and I should be unjoining the list soon
(I'd stay around, but you guys write too much, and I'm a clean-inbox-freak!
:P). If anyone has any questions about the project, or want something I
might have found during the time I took researching (which I can assure is
nearly nothing), just talk to me, through here or directly to my e-mail
address.

Trully thankful,
Luca

On Thu, Jun 11, 2009 at 5:41 PM, Luca Bezerra <lucabezerra at gmail.com> wrote:

> First of all, sorry for the time I took to answer, Ive forwarded all these
> messages to my boss so he could see what other people were thinking about
> this project, and had to wait for his answer.
>
> The main loop you've sent me is indeed sort of what I need, thanks for the
> tip and for the explanations about mapping and unmapping.
>
>
> On Wed, Jun 3, 2009 at 1:28 PM, McDonald, Michael-p7438c <
> Michael.McDonald at gdc4s.com> wrote:
>
>>
>>
>>  ------------------------------
>> *From:* Luca Bezerra [mailto:lucabezerra at gmail.com]
>> *Sent:* Tuesday, June 02, 2009 1:48 PM
>> *To:* McDonald, Michael-p7438c
>> *Cc:* xorg at lists.freedesktop.org
>> *Subject:* Re: Switching between virtual desktops
>>
>>
>>
>>  If you wait to switch monitors until after the virtual desktop has been
>>> switched, the the new virtual desktop will be displayed on the old monitor!
>>> You have to do do something more like this:
>>> while (1) {
>>>     tell video demux to ignore new input
>>>     switch virtual desktops
>>>     tell video demux to output to new monitor
>>>     sleep
>>>  }
>>>
>> A: True, hadnt thought of that, thanks for the heads up! Anyway, it was
>> just a sketch of what will really be done, implementation phase still's far
>> from where I am now :P
>>
>>  Uh, one of the most fundamental skills an engineer needs to learn, and
>>> learn early, is how to tell his managers their latest "solution" won't work.
>>> It's easier to get away with telling them that if you do have a working
>>> solution. Therefore, let's make this whole problem rest on the HW guys
>>> shoulders:
>>>
>>> Tell him that his hardware needs to capture the video signal into one of
>>> six separate frame buffers. Your parallel port interface will tell him which
>>> one or none. His hardware will then provide a continuous video signal out to
>>> each of the six monitors connected to it. Users get nice stable video, you
>>> get easy SW task, and boss gets to prove he's a wiz HW designer.
>>>
>> A: Let me see if I got this straight: The framebuffers at the HW part will
>> hold the image sent to that specific monitor while it switchs the virtual
>> desktops between the other monitors, until its monitor 1's turn again, is
>> that right? During like 0.1 second, that image will be frozen on that
>> monitor, waiting for its turn to receive new data? Is this possible to be
>> done with HW (Ive heard that you can do everything you do with software on
>> hardware, but at higher costs, but I dont know how true is that :P)?
>>
>>
>> Yes, this is pretty straight forward and a fairly common thing to do in
>> HW (FPGA).
>>
>>
>>> Why do users have to log in if all they are going to do is use a single
>>> PDF reader? I assume the student don't have to log in before the can read a
>>> book off the shelves. Instead of using virtual desktops, have your app
>>> map/unmap the N copies of acroread/xpdf/... in sync with you parallel port
>>> output. There's no reason to have a window manager or virtual desktops at
>>> all.
>>>
>>>   BTW, what are you doing about input? How are you planning on handling
>>> N keyboards and N mice?
>>>
>>> Mike McDonald
>>>
>> A: Im not sure if I understood what you meant about the map/unmap thing,
>> but anyway..
>>
>>
>> Map/unmap are the X terms for hiding/showing windows.  When top level
>> windows are unmapped, they can't be seen by the user and they don't receive
>> any input events. The windows still exist so the app is happy. Most window
>> managers implement "iconify/minimize" using unmap.
>>
>> So your main loop would become something like:
>>
>>  while (1) {
>>     tell video demux to ignore new input
>>      XUnmap(xpdf[n])
>>      XMap(xpdf[n+1])
>>      tell video demux to output to monitor[n+1]
>>       n = n+1
>>     sleep
>>  }
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20090716/ef32f0ac/attachment.html>