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 <[email protected]> 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 < > [email protected]> wrote: > >> >> >> ------------------------------ >> *From:* Luca Bezerra [mailto:[email protected]] >> *Sent:* Tuesday, June 02, 2009 1:48 PM >> *To:* McDonald, Michael-p7438c >> *Cc:* [email protected] >> *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 >> } >> >> > >
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
