If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

They say this kind of protocol should be private and not exposed publicly to regular clients.

I generally agree. One of the biggest reasons I was looking forward to Wayland was because of the "applications which want to fullscreen can only use a resolution-changing API similar to xdg-screensaver which is bound to a window and can't get stuck if the application dies unexpectedly" idea.

Allowing RandR via a public API makes it that much easier for lazy ports of Windows games to do the wrong thing... potentially bringing us back to square one by requiring a hack analogous to "focus-stealing prevention" but for resolution changing.

Comment

Allowing RandR via a public API makes it that much easier for lazy ports of Windows games to do the wrong thing... potentially bringing us back to square one by requiring a hack analogous to "focus-stealing prevention" but for resolution changing.

On the other hand, you'll want to have applications like "KScreen" which help you handle plugging -in and -out screen, selecting different resolution for displays that supports several, etc.
The problems you mention should be handled by granting capabilities and similar.

A regular application shouldn't be able to directly call into RandR APIs (or at least, nothing beyond getting a few basic info about currently plugged in monitors. That wouldn't be disruptive, and might be handy for some specific software: presentation software like LibreOffice Impress might need to know if there's a projector plugged in, so they know on which screen to ask for a fullscreen window (for the actual presentation) and on which screen to keep the user interface (for the presenter's notes).

Only special application (like applets part of the desktop environment, like KDE's KScreen, or a potential "WRandR" for Wayland/Weston) should be granted special rights to manipulate screen settings for the whole compositor (along with a mechanism to revert change to latest "good" setting. So even in the case of a "WRandR"'s crash, the screen reverts if the Wayland server didn't get any confirmation before timeout).
Any other application should be receiving a "request denied" answer.

Comment

They say this kind of protocol should be private and not exposed publicly to regular clients.

This looks like the correct approach to me.
I cannot think of any use case where a client would need to set the display to a specific value that would not be covered by wl_shell_surface.set_fullscreen.