Klaus Schmidinger wrote:> Well, tell that to people writing plugins for such output devices.> I don't see where *I* would be involved there?!> Are there enough interfaces to be able to read the and control the OSD for including them seamlessly it into a different front-end? I don´t think that SVDRP and interpreting the returned data is the best way to go. And what about the limitation on one OSD per VDR?I think, these are the real limitations - currently users of media center UIs are exiting them and start xinelib for using VDR and visa verse.A better separation of "back-end" and "front-end" could IMHO solve the problem and end the discussion about hardware related support. Because with a clean and some kind of more standardized interface (which also transmits OSD related information), you could write every "output device connector/plug-in" that you can think and be compatible to more front-ends or devices then before. Even an "evil" Windows front-end with VDR running on Windows (with the help of something like colinux or a VM) would be possible.Currently, xinelib (with original OSD) uses a different protocol than the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in (with OSD tranfered with some kind of VNC IIRC) which also works different from the streamdev approach (without OSD) that is used for hardware streaming clients that use oxyl etc. Unfortunately, I am just a user, not a developer though I am at least able to read and modify simple C and script code ;) - it has been a long time since I was student and was able/had the time to code little projects... With kind regards Joerg Knitter _______________________________________________vdr mailing listvdr@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
