mpv on weston allows display timeout

[wwalexander]

When watching videos on the Weston Wayland compositor, the display timeout occurs at the default interval (300 seconds of inactivity), and requires pressing a key or moving the mouse to wake the display.

I'm not sure if this is a problem inherent to Weston or whether there's some way for mpv to disable the timeout when videos are open.

Distro: Arch Linux
linux 3.13.5
mpv 0.3.5
xf86-video-intel 2.99.910
wayland 1.4.0
weston 1.4.0

[kevmitch]

I believe this only happens with --vo=opengl, --vo=weston seems to have a way of inhibiting it.

[wwalexander]

Do you mean --vo=wayland? I don't seem to have --vo=weston as an option.

--vo=wayland still has the issue.

[giselher]

Sorry for the late response.

There is currently no way for inhibiting in mpv under wayland.
The only way to do it is to use dbus, but I didn't want to introduce another dependency just for wayland outputs.

If I add inhibiting via dbus we also could use this on x11 too.

[ghost]

x11 has its own X-level screensaver protocol, and mpv uses it. That gnome often breaks this protocol is separate problem.

Requiring dbus just just for this instead of having it in the wayland protocol sounds like complete non-sense. I hope they fix this. Until then, we can't fix this issue.

[maletor]

If you start weston with weston-launch -- -i0 you effectively disable the timeout. In regards to the mpv option "stop-screensaver", there are probably issues with its efficacy on weston.

[ghost]

Adding the label not our bug since there is no reasonable protocol to do this yet.

[fxthomas]

As a workaround, I wrote a script that can be used to temporarily disable the screensaver on Gnome/Wayland 3.22.

[ppaalanen]

There is already:
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/idle-inhibit
It has been there for a few months by now. So yes, there is protocol, but I am not aware of an implementation landing in any compositor yet. And protocol is all that Wayland cares about. This is out of "Wayland's hands" now and up to the individual display server projects.

If you want a solution based on Wayland, aim for getting that implemented in compositors and your app. Review and evaluate that protocol proposal, help with the implementations, provide testing, comments and praise, so that it can eventually be declared stable. It will not be declared stable without testing, which requires implementations.

The reality is that no-one can force all compositor projects to implement the thing you want. You need to make it more attractive for them to implement it rather than not implement it.

I have not seen much any discussion outside of few Wayland core protocol regular contributors, which makes it look like the protocol proposal does not raise any interest. If it does not raise any interest, why would anyone bother working on it. Ranting about the lack of a way is not expressing interest in a potential solution.

You can keep on adding window system specific ways, or you can promote the DBus interface if it is sufficient so that you do not need to have a different implementation for every single window system protocol. Whether Wayland or DBus is better in this particular case is a little bit of an open question, AFAIK the two differ in features, not just the protocol details. If you like the features of the Wayland proposal better, do come forward with it.

Have you at least filed bugs with the display server projects to implement the feature you want?

[ghost]

From what I know, a screensaver inhibition protocol was always on the Wayland TODO list, so it's great that there's finally one.

From a quick look, the one you linked looks ok.

@atomnuker (who currently maintains the mpv wayland code) should take a look at it, if he isn't already aware of it.

I have not seen much any discussion outside of few Wayland core protocol regular contributors, which makes it look like the protocol proposal does not raise any interest. If it does not raise any interest, why would anyone bother working on it.

Downstream applications won't like to use "unstable" protocols, because, well, they're unstable, can change any time, and there is a risk that it won't be broadly adopted or that you have to support multiple protocols until a standard emerges. But I guess I can understand that it's hard to standardize a protocol that nobody uses and for which it's unknown whether it's adequate in real-world situations or not. So it's a bit of a chicken-and-egg problem. Also a bit of a X11-like situation.

It's made worse by desktop environment using their own non-standard stuff anyway (to the point where I wonder why there are standard protocols at all).

Ranting about the lack of a way is not expressing interest in a potential solution.

Actually it is, just not in a constructive way.

You can keep on adding window system specific ways, or you can promote the DBus interface if it is sufficient so that you do not need to have a different implementation for every single window system protocol. Whether Wayland or DBus is better in this particular case is a little bit of an open question, AFAIK the two differ in features, not just the protocol details. If you like the features of the Wayland proposal better, do come forward with it.

DBus is entirely disconnected from the windowing system, so I do not see how it could possibly adequately handle the screensaver, which is very related to the windowing system. How is the other end on a dbus screensaver protocol supposed to know whether the client has an active window (or whether it's obscured or was removed)?

If it has to be the DBus way (for things like system power states too), I'd rather prefer a kernel API or an otherwise low level small interface, like e.g. MS Windows provides it. Because DBus is still a pain to use. I know, it's no argument for desktop environment and toolkit people, for which the additional complexity and maintenance load of having to support dbus interaction is very small compared to the other stuff they're dealing with.

Anyway, thank you for reaching out to us.

[ppaalanen]

Hi @wm4 ,

first an apology if my comment came out heated - this thread was brought to my attention by a user who was extremely rude and hostile down to a personal level.

Chicken-and-egg problem indeed, we have that all over every protocol extension that is not just low-level plumbing but touches concepts that desktops care about. There aren't many actual desktop people in the regular Wayland protocol contributors, and outsiders like myself cannot design good desktop protocols (I've proved that personally). That is also a reason why we (Wayland developers) desired from the beginning that desktop projects should come forward with their own protocol proposals instead of design-by(-amateur?)-committee - and we had and still have much to do with just the plumbing too.

Yes, DBus is disconnected from the window system. That is why the Wayland protocol proposal for idle-inhibit makes more sense, because it can directly make an association with a window. That would be quite painful over DBus. There are other topics, however, where DBus might make more sense, e.g. display server configuration interface (think of xrandr tool and friends) which is not about specific clients or windows. It depends on the case, really.

If you see only GTK+, Qt, etc. "big toolkits" as toolkits, then yes, I can understand the desire to avoid toolkits. However, I would consider also things like libSDL to be a toolkit. Once more desktop stuff becomes generally supported and common ways emerge, maybe there will also be lightweight toolkits.

[ghost]

first an apology if my comment came out heated - this thread was brought to my attention by a user who was extremely rude and hostile down to a personal level.

Not needed, I'm sure there was plenty of rudeness from some of our users, developers, and myself, to compensate. So I should apologize. I think that's just show it goes in heated internet arguments.

There aren't many actual desktop people in the regular Wayland protocol contributors, and outsiders like myself cannot design good desktop protocols (I've proved that personally).

I suspect the problem with desktop things is that they often have requirements coming from user interface concerns (i.e. "humans"), which tend not to map to technically clean API designs. Anyway, this stance is probably way too theoretical, and we saw where the X11 "mechanism not policy" ideology lead to. So I'm not sure either what to suggest.

There are other topics, however, where DBus might make more sense, e.g. display server configuration interface (think of xrandr tool and friends) which is not about specific clients or windows.

But in this case I'd definitely say that should be a wayland protocol, or otherwise you'd end up with a lot of similar protocols, one for each desktop environment. This is an example where a protocol would likely be very closely bound to GUIs: the GUIs which the DEs want to present to the user to configure these things. But it's possible to create an API that handles the the underlying task, display configuration, cleanly. There's not much doubt how it should work - just mirror the kernel APIs. (Probably.)

One might argue that display configuration is not the business of normal applications, so there's no need for a standard protocol. But there are still plenty of cases where an application has to take this into its own hands, especially multimedia applications. (Maybe not mpv, but for example media center applications.) The most commonly needed thing is probably display mode switching.

If you see only GTK+, Qt, etc. "big toolkits" as toolkits, then yes, I can understand the desire to avoid toolkits. However, I would consider also things like libSDL to be a toolkit. Once more desktop stuff becomes generally supported and common ways emerge, maybe there will also be lightweight toolkits.

Indeed, I can't see libsdl using GTK or Qt. Another thing comes to mind: the lack of server side decorations. This is a problem for applications like mpv, which don't want to pull in entire GUI applications (or dozens of libs) just to draw some borders. Wayland has firmly rejected them, which is why I recently changed mpv's preferred backend back to X11.

[teohhanhui]

So what's the recommended way for users to work around this issue? To use a frontend like gnome-mpv?

[ghost]

Complain to the weston devs to implement the screensaver protocol that mpv supports. There's even a patch for weston to do it but they kept arguing about it and didn't merge it after half a year. Even kde supports it.

[crazygolem]

@teohhanhui as a pragmatic solution for gnome users, I have found that the caffeine extension does the job: it can detect full-screen applications and trigger inhibition, and you can specify a list of applications that trigger inhibition as well. The readme on its repo mentions however that the extension is no longer maintained and suffers from a severe bug.

This is not a very good solution (it would be nicer to have proper support for inhibition at whatever level is needed to make it work), but works better than the recommended "wish upon a well" for now... and is quite user-friendly IMO.

[teohhanhui]

I'm using gnome-session-inhibit to launch mpv. It seems to work well. Is it possible for mpv to call that?

[kevmitch]

I notice that the xdg-screensaver calling is done only in x11_common.c. Does the xdg-screensaver script work in gnome-wayland?