[MPlayer-dev-eng] Re: mplayer and xscreensaver problems

[Andriy Gapon]

To Arpi:
> you mean "his method", so executing a shell command every second?
> it's simply dumb & nonsense and makes playback jerky

I see you both have a lot of mutual affection :)
As a matter of fact I made a suggestion to him once that IMHO it was a
good idea to have a client library that would allow application to
commmunicate to xss via X protocol instead of running shell commands (his
own client talks to the saver via it), but he disagreed...

I'd create such a lib myself but I don't want to be intrusive, especially
in view of his disliking .

> it may work for multithreaded players but won't for mplayer...

I didn't get this part... What makes mplayer non-multithreaded ?
In my patch I start a new pthread from saver_on() and signal it to quit in
saver_off(), the thread periodically (once in a minute by default)
executes the shell command in background.
It doesn't have to be 1 second, does it ?


I agree that there should be a more general approach, and neither what
currently is nor what Jamie proposes is good enough.

At least, let's fix two problems I mentioned initially -- descriptors
inherited by xss, and the fact that xss is re-started regardless of
whether it was running or not when -stop_xscreensaver option is used.
And maybe, that xss is not re-activated when mplayer is paused.

To Rich:

the situation is sort of symmetrical here, screensaver developers might
(and do) argue as well that it's not their business to know about each
program that wants screensaver paused/disabled. It may not be as easy as
list of clients, because the same client may be used diffrently, may
have different states etc.
As I mentioned before, there should be a general solution, common API.
Until then you can do (or not do) only what you can do.
May be such an API already exists, I don't know.

Btw, what 'awful hacks' did you refer to ?

-- 
Andriy Gapon
*
Hang on tightly, let go lightly.