Switching between virtual desktops

[Luca Bezerra]

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)?

>
> Now, having said all of that, I'd have questioned the whole approach from
> the beginning:
>
> Where are the monitors coming from? If you're buying them, then there is
> money to buy cheap, modern PCs to run each station. If the monitors are
> surplus, then check with you university's surplus property department about
> getting ahold of discarded computers.
>
A: Thats a good point. Even though the project is meant to be "zero cost",
there will be monitor purchasing. Since the monitors will be embedded in the
tables (like coming from underneath it), they must be LCD monitors, because
they're thin, so we couldnt just use old CRT monitors. The "paying for
monitors but not paying for graphic cards" thing doesnt make that much sense
to me either, but I gotta work with what's given to me :P Besides, my main
goal right now is to make this system work through any solution. How is my
boss going to manage the costs, its up to him.

>
> 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.. I must correct something I said earlier, and maybe make things
clearer. Now users won't login into a specific virtual desktop anymore. The
machines [by "machine" I really mean the cpu, not the monitors] will be
turned on, all of them logged with a standard login. Each one of the 6
monitors will be assigned with a individual virtual desktop from that
machine. The only application they'll be able to start will be a browser,
and the computers will be connected to an intranet only, accessing an
internal server, no internet/external access involved. On this browser,
they'll access some page hosted on the university's server, log in with
their data and then search for and read books.
This change on the library's system is due to the complicated system that
exists currently. Students cant go the book shelves, they must check a book
list (paper-made), see if the book they want exists in there, write down its
reference number, go to a balcony and ask the lady if there's any book left.
She checks out, types your registration number (similar to the login part)
on the library's system and lends you the book. Since sometimes the ammount
of books isnt enough for all the students (dont even ask me why not just buy
more books instead of all of this), this new system would allow students to
read pdf versions of those books, in cases of urgent need. My boss also
wants this system to gather statistics about students, such as 'most read
books', 'most read books by students of that class', 'most read chapters of
those books', etc. That's why individual logins are required. But since now
they'll log into a service hosted on server, thats not a problem anymore.
The main problem now is to make the screen switching possible.
Finally, about the inputs... I'm still now sure how would that be done.
Multiterminal systems implement this feature pretty well, as far as I know,
so I think I can get something from there.

>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20090602/bea2c8dd/attachment.html>