XRandR Equivalent Published For Wayland, Weston

[jayrulez]

Yeah, frak you Mir!

Something like XRandR is not something that is desirable for wayland/weston so I'm not sure why you seem so happy about this.

[valeriodean]

I think the wayland's devs have clear in mind that problem, so lets they work on the patch and through next versions to arrive to the right solution, as usual.
For example, the problem is already under discussion:

For the issue with a client dying and leaving the compositor in a weird
resolution. Perhaps the API could change so that clients can specify
that the resolution change is contextual, and the previous resolution
would be set back when the client dies (it would look like the exclusive
part of the screenshooter).

Anyway it is really useful for testing mode_switch() callbacks.

Actually I'm waiting for the PQ's work on subsurface and its refinement, because subsurface implementation will be useful for a lot of features and will help the completion of QtWayland in time for the release of Qt 5.1 I hope.

[varikonniemi]

I for one fully agree that a client should only be able to _ask_ for a resolution, not _set_ it. I had enough of it with crashing games and/or bad drivers on Linux that left me with a crappy desktop at super low/broken res.

People shouldn't confuse the requirements for something like a control panel displays applet or command line mode switcher, for the case that a user wants to switch resolution, from the case where an app wants to switch.

[F i L]

People shouldn't confuse the requirements for something like a control panel displays applet or command line mode switcher, for the case that a user wants to switch resolution, from the case where an app wants to switch.

Just require root permissions. The Control Panel could have both a "basic" (wallpaper, timezone, etc) and "secure" (display, hostname, etc) sections. The Secure section requires the root password.

[Petteri]

Just require root permissions. The Control Panel could have both a "basic" (wallpaper, timezone, etc) and "secure" (display, hostname, etc) sections. The Secure section requires the root password.

That would be bad way to handle this. Users without root password wouldn't be able to change their desktops display settings, usability would be annoying and using root privileges is bad for security.

[przemoli]

"ASKING" for change of resolution will NOT WORK MIRACLES.

Unless display manager can not be notified that app quited, and can not restore previous settings, app that ASKED for change of resolution will F*ck Up your screen resolution same as that who did not asked for permission...

....


It's lack of reliable RESTORATION, that is problem. Its normal that app misbehave. Display manager/server/compositior/ Whole D*** OS can not assume otherwise.

[F i L]

That would be bad way to handle this. Users without root password wouldn't be able to change their desktops display settings, usability would be annoying and using root privileges is bad for security.

No, you're right, that is a bad idea. I think the best solution (and something I believe has been talked about with "asking" vs "setting") is that a "request" for fullscreen means the compositor can remember the previous settings used (before the request), and automatically set things back when that process exits.

[F i L]

"ASKING" for change of resolution will NOT WORK MIRACLES.

Unless display manager can not be notified that app quited, and can not restore previous settings, app that ASKED for change of resolution will F*ck Up your screen resolution same as that who did not asked for permission...

....


It's lack of reliable RESTORATION, that is problem. Its normal that app misbehave. Display manager/server/compositior/ Whole D*** OS can not assume otherwise.

Well, like i said in my post above, I think "asking" (the display server) for a resolution change (and ultimately letting the DS decide if the request is granted) is fundamentally different than clients being able to directly force the screen resolution, in that the DS request can buffer settings about the resolution before it changes for a specific app, and automatically return to those settings when that app exits. Giving the app full direct control over the resolution means there's no guarantee that things get put back if the application dies unexpectedly.

[Micket]

So you guys seem to be talking about very different things here. I was actually hoping that apps would simply ask what the resolution is, and use that.
If unable to comply with that, then letterbox it, or render to a framebuffer and stretch to fullscreen. There simply shouldn't be a way to set or request resolution (without root)

I want to be able to alt+tab out and see the normal desktop. I don't want my second monitor turned black. I don't want to have all my opened applications moved to the first monitor.. oh, and I didn't want to view the game fullscreen on monitor 1.
I always set games to run windowed, and maximize that window in my windowmanager., which always gives a much better experience.

[ChrisXY]

Why would you want to change a resolution anyway? You should rather be able to configure what is the native resolution of each screen and never change that. All fullscreen programs that want a resolution change should just be rescaled to the native resolution automatically. Maybe you should be able to set whether the aspect ratio should be kept (i.e. letterboxing) or whether to stretch. But that's about it.

I believe sdl2 does this on X and I believe I have it already seen with some valve games and it just feels so nice. Finally sane fullscreen and resolution handling.