Dear freevo community, I am posting this in order to see whether somebody has already solved the same problem or has some helpful hint that will save me long hours of re-engineering the details of freevo. I am currently using freevo 1.8.0rc1.
I bought a sleek Zalman case with a built-in 800x600 LCD touch screen. My plan is to use this display as a secondary display in addition to my 1920x1080 Full-HD LCD TV: - TV does not need to be turned on when playing audio - Secondary display should basically show the same menus as the primary screen - Optional: when playing video on the primary screen, the seondary display shows additional info (e.g., title, elapsed time) I hacked a driver for the touchscreen and can use the secondary display in dual head mode under the same X server - so far, so good. The easiest option would be to show the same information on both displays - this would not look good due to the different aspect ratio, and would not allow me to show additional information on the secondary display. I also looked at the lcd plugin, but that produces only very simplistic outputs that does not come close to the info on a standard freevo screen. The third option I tried is the following: the freevo screen display is based on pygame. Unfortunately, pygame seems to support only one screen per process. So I used rpyc in order to run a second process which outputs a pygame screen on the secondary display. For each call to one of the methods to an OSD object (in osd.py - these are only four main calls, i.e. screenblit(), update(), drawroundbox() and drawstringframed() ), I call the same method in the second process via rpyc. This solution works in principle, i.e. I can create a second, independent display and go through the main menu quite well. The disadvantage is that transferring the parameters (which are large pygame surface objects in many cases) and converting them to the format of the secondary display is too slow. As an alternative, I also tried not to pass full pygame surfaces to the second process, but rather use the text strings and positions where strings/boxes are to be positioned on the screen this did not work too well either as it does not seem to be to determine when a new screen needs to be built (explicit clear screen function is not used). To cut a long story short, I believe that the general principle of communicating with a second process via rpyc works, but the communication between the two processes should not be done at the level of OSD objects, but rather at objects of a higher abstraction level (Screen objects? Skin objects?). Does anybody have a helpful hint on the best level? Has anybody found a better solution to drive a secondary, full-featured display in freevo? I am very grateful for any hints. Cheers -holger ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freevo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-users
