Hi!
I have written this patch for the softdevice xv-output method to stop it from changing all my xv output settings (contrast brightness hue saturation). I mainly use the new shm-output communication with xv.
I know that it is in some parts a hack, but I hope that a similar patch will be incorporated into the official version.
The other problem I could not solve myself is that the colorkey setting of xv gets modified to colorkey=black, which makes every window containing black areas transparent, this is just annoying.
Matthias
Matthias Schwarzott schrieb:
Hi!
I have written this patch for the softdevice xv-output method to stop it from changing all my xv output settings (contrast brightness hue saturation). I mainly use the new shm-output communication with xv.
I know that it is in some parts a hack, but I hope that a similar patch will be incorporated into the official version.
I see your problem, this really should be solved soon. Your patch disables the use of saved values for contrast, hue etc. for Xv-out as well as shm-out, which is quite a nice feature if one doesn't want to use the default values. I would propose just to switch off the settings as long as one can't change them from shm-out. My following, untestet patch should do that, I will apply it if it works for you.
The other problem I could not solve myself is that the colorkey setting of xv gets modified to colorkey=black, which makes every window containing black areas transparent, this is just annoying.
On the long term I planned to make the colorkey adjustable. The osd system is already prepared for it, only video-xv needs to be tweaked. If you want to work on this, look for "color key" comment inside SoftOsd.c, and the COLOR_KEY constant in SoftOsd.h. In video-xv you obviously also have to adjust the color key and either manualy draw a rectangle with the color key where the video is to be displayed or switch on the auto paint color key (which may collide with the osd drawing). The only problem is to get it running for the different colour depth, the easiest is 32bit, so you may want to start with that. For the other color depth the color key has to be converted to the corresponding color depth.
Bye, Martin
Index: video-xv.c =================================================================== RCS file: /cvsroot/softdevice/softdevice/video-xv.c,v retrieving revision 1.54 diff -u -r1.54 video-xv.c --- video-xv.c 24 Apr 2006 22:56:47 -0000 1.54 +++ video-xv.c 15 May 2006 20:32:17 -0000 @@ -705,7 +705,9 @@ PutXvImage(); XSync(dpy, False); } +#ifndef STAND_ALONE attributeStore.CheckVideoParmChange(); +#endif }
if(cursor_visible == True) {
On Montag 15 Mai 2006 22:47, Martin Wache wrote:
Matthias Schwarzott schrieb:
Hi!
I have written this patch for the softdevice xv-output method to stop it from changing all my xv output settings (contrast brightness hue saturation). I mainly use the new shm-output communication with xv.
I know that it is in some parts a hack, but I hope that a similar patch will be incorporated into the official version.
I see your problem, this really should be solved soon. Your patch disables the use of saved values for contrast, hue etc. for Xv-out as well as shm-out, which is quite a nice feature if one doesn't want to use the default values.
Another additional argument for xv-out (dfb-out) could be: leave settings as is.
I would propose just to switch off the settings as long as one can't change them from shm-out. My following, untestet patch should do that, I will apply it if it works for you.
The other problem I could not solve myself is that the colorkey setting of xv gets modified to colorkey=black, which makes every window containing black areas transparent, this is just annoying.
But this happens only for windows which overlap video window.
On the long term I planned to make the colorkey adjustable. The osd system is already prepared for it, only video-xv needs to be tweaked.
You could set color key to an arbitrary OSD color which has a alpha value of 0 (full transparent), but then you'll get perhaps red, green or something else colored stripes above and below during letterboxing (left/right during pillar boxing).
If you want to work on this, look for "color key" comment inside SoftOsd.c, and the COLOR_KEY constant in SoftOsd.h. In video-xv you obviously also have to adjust the color key and either manualy draw a rectangle with the color key where the video is to be displayed or switch on the auto paint color key (which may collide with the osd drawing). The only problem is to get it running for the different colour depth, the easiest is 32bit, so you may want to start with that. For the other color depth the color key has to be converted to the corresponding color depth.
Bye, Martin
On Tuesday 16 May 2006 00:26, Stefan Lucke wrote:
On Montag 15 Mai 2006 22:47, Martin Wache wrote:
Matthias Schwarzott schrieb:
Hi!
I have written this patch for the softdevice xv-output method to stop it from changing all my xv output settings (contrast brightness hue saturation). I mainly use the new shm-output communication with xv.
I know that it is in some parts a hack, but I hope that a similar patch will be incorporated into the official version.
I see your problem, this really should be solved soon. Your patch disables the use of saved values for contrast, hue etc. for Xv-out as well as shm-out, which is quite a nice feature if one doesn't want to use the default values.
Another additional argument for xv-out (dfb-out) could be: leave settings as is.
Yeah, this would be good. For my card (nvidia) the init-values of 50% are not the default-picture settings.
Another thing I discovered is that the key-handling of the shm-module is sub-optimal. First point (tested at a friend of mine): It does not work on amd64 at the moment.
Second point: The SHM-Area for the key is initialized with kNone, and not with NO_KEY which would be correct. For me this resulted in vdr switching to channel 5 at every start - the kNone was mapped to 5 for me. Patch is attached.
Third point: softdevice crashes sometimes because of a wrong initialization order. Means: Some threads are started before the data they access is initialized. As I understood vdr-plugin interface, only in Plugin::Start() threads should be started, not before. If I find time, I try to trace the error a bit further.
Matthias
-
Martin Wache -
Matthias Schwarzott -
Stefan Lucke