On Monday 26 March 2007 15:58, Artur Skawina wrote:
Please subscribe to the list. For some reason there is no separate
request for approval.
> Stefan Lucke wrote:
> > On Friday 23 March 2007 13:37, Artur Skawina wrote:
> >> Turns off the decoder when the video window isn't visible (when you switch
> >> to another
> >> (virtual) desktop, other windows cover it or screensaver kicks in etc).
> >>
> >> Note this will unsuspend on vdr startup when using XV even when the
> >> previously saved
> >> config value was 0 - this is probably the desired behaviour; to start XV
> >> in suspended
> >> mode make sure the window isn't visible by placing it appropriately (using
> >> geometry/WM).
> >>
> >
> > Thanks for your patch.
> >
> > We should be prepared to act on VisibilityNotify, but I don't think this
> > should
> > be done automagically mapped to suspend/resume action.
> > Comments welcome.
>
> I've now used it for a few days, some thoughts:
>
> - it does the right thing wrt video, but turning off the audio is not always
> desirable;
> examples would be listening to radio or some kind of music/talk channel.
> While the
> former could be auto detected (don't suspend if no video) the latter does
> require
> a user defined preference.
> - When not live viewing but playing back recordings, suspending the playback
> completely
> when the window is hidden actually turns out to be a feature -- you can
> switch to
> another desktop (or otherwise hide the window) and playback will pause;
> switch back
> and the playback resumes. This turns out to be very convenient, but makes
> the user
> pref mentioned above a bit more complicated. Is there a simple way to
> distinguish live
> viewing from playback?
> - When live viewing, suspending does not stop av stream, using bw and/or
> keeping a dvb device
> unnecessarily busy.
> - (un)suspending does a bit too much x/xv (de)init.
>
> > Example:
> > - 'r' did a suspend action (video and audio stopped).
> > - touching the window will bring back both.
>
> I'm not using 'r' so i didn't notice this. Yes, moving anything over the
> window or just
> moving the video window itself does unsuspend. I've always considered the 'r'
> key a hack
> (the reason I sent the patch enabling it w/ configure is that it is a
> regression); it should
> be done via normal vdr input processing so that it it is accessible from
> remotes too.
> Making 'r' work independently from autosuspend would be easy (eg using a
> bitmask instead of int),
> but a more complex approach is needed anyway to handle the above mentioned
> cases...
>
> > and switching to another desktop with kde does not deliver
> > VisibilityFullyObscured :-( .
>
> It works with fvwm2; this probably depends on the window manager. Switching
> away from X
> (eg ctrl-alt-f1) seems to work too.
>
> I'll take a look at fixing some of the above issues in the next few days.
>
> artur
>
> >> diff -urp softdevice-cvs.org/video-xv.c softdevice-cvs/video-xv.c
> >> --- softdevice-cvs.org/video-xv.c 2006-12-18 00:03:46.000000000 +0100
> >> +++ softdevice-cvs/video-xv.c 2007-03-23 11:09:48.000000000 +0100
> >> @@ -579,7 +579,8 @@ void cXvVideoOut::ProcessEvents ()
> >> KeyPressMask |
> >> ExposureMask |
> >> ConfigureNotify |
> >> - StructureNotifyMask,
> >> + StructureNotifyMask |
> >> + VisibilityChangeMask,
> >> &event))
> >> {
> >> switch (event.type)
> >> @@ -703,6 +704,11 @@ void cXvVideoOut::ProcessEvents ()
> >> }
> >> break;
> >>
> >> + case VisibilityNotify:
> >> + EVDEB("VisibilityNotify\n");
> >> + setupStore->shouldSuspend =
> >> event.xvisibility.state==VisibilityFullyObscured;
> >> + break;
> >> +
> >> case MapNotify:
> >> EVDEB("MapNotify\n");
> >> map_count++;
> >> @@ -920,7 +926,8 @@ bool cXvVideoOut::Initialize (void)
> >>
> >> XSelectInput(dpy, win, KeyPressMask | ExposureMask |
> >> ConfigureNotify | StructureNotifyMask |
> >> - PointerMotionMask | ButtonPressMask);
> >> + PointerMotionMask | ButtonPressMask |
> >> + VisibilityChangeMask);
> >>
> >> XMapRaised(dpy, win);
> >> //XNextEvent(dpy, &event);
> >>
> >>
>
>
--
Stefan Lucke
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
