[PATCH weston 00/17] Follow up from the last xdg-shell series

Thu Apr 9 23:01:39 PDT 2015

On 04/07/2015 11:01 AM, wayland-devel-request at lists.freedesktop.org wrote:
> Date: Tue,  7 Apr 2015 17:01:15 +0800
> From: Jonas Ådahl <jadahl at gmail.com>
> To: wayland-devel at lists.freedesktop.org
> Cc: Jonas Ådahl <jadahl at gmail.com>
> Subject: [PATCH weston 00/17] Follow up from the last xdg-shell series
> Message-ID: <1428397292-8455-1-git-send-email-jadahl at gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
>
> This series is a follow up mostly addressing the issues raised by Pekka
> during the last series as well as some other clarifications.
>
> The patches them self is a better in depth description of the changes, but
> there are a couple of things that I'd like to bring up more explicitly.
>
> 1.
>
> This series again bumps the unstable version and breaks backward
> compatibility (it moves error enums and introduces a new one).
>
> If there are any more breaking changes, I think we should
> push those together and avoiding unstable version 6. This brings me to
> the next point:
>
> 2.
>
> Fullscreen as specified in xdg-shell is more limiting than the one in
> wl_shell_surface, and it might be a good idea to consider make
> fullscreening a bit more powerful in xdg_surface.
>
> The current difference between wl_shell_surface and xdg_surface in regard
> to fullscreening is that while xdg_surface allows for specifying what
> output the surface should be fullscreened on, while wl_shell_surface also
> allows specifying a method (scale, driver, fill) and for the driver method
> a refresh rate.
>
> As of this series, the method of xdg_surface.set_fullscreen is identical to
> t. he wl_shell_surface 'fill' fullscreen method.
>
> The question is whether a 'scale' and/or a 'driver' method should be made
> available.
>
> Such a 'scale' method would more or less overlap completely with the
> wl_scaler protocol, so might be completely unnecessary. Does it provide
> any benefit over using wl_scaler?
>
> The 'driver' method could be good thing to have, assuming it has any
> benefit over scaling (i.e. specify refresh rate, (memory bandwidth?)),
> as I suspect it wouldn't be any compositors policy to change monitor
> resolution for any fullscreen surface where its applicable.
>
> So the question is, how much, if any, of the fullscreen controls should
> be made available via xdg_surface's fullscreen request?
>

Wrt. the "driver" method and being able to request a refresh rate, yes 
please! I assume it would also be good for games and other performance 
hungry apps to avoid wasting gpu cycles / memory bandwidth on scaling 
etc., but my specific use case is visual presentation software for 
neuro-science/medical applications. If one wants to find out how eyes 
and brains work - how we see and perceive and recognize the visual world 
and also what goes wrong if we don't see that well, also how different 
senses work together - one needs fine control over video refresh rates, 
presentation timing and video output resolutions, color reproduction, 
exact location of pixels on the display etc., often on multi-display 
setups. Researchers often use precisely calibrated displays, old CRT 
monitors due to their variable frame rate, or specialized display 
equipment. For that to work we need control over the exact video mode 
and refresh rates, if and how a display uses dithering etc. and just 
rescaling images in the compositor can do rather horrible things to such 
controlled stimuli. Some of the research equipment parses information 
that is color-coded in image pixels to trigger hardware operations which 
are perfectly synchronized to the video stream, so a simple minimal 
change of pixel location, size or color due to running an unexpected 
video mode + rescaling and filtering could completely knock out such 
equipment. Application control over modesetting, at least on displays 
where the application is fullscreen, is essential for these desktop use 
cases.

To port such applications from X11/GLX to Wayland, ideally i'd like to 
have the equivalent of as much as possible of X11's full RandR extension 
- global modesetting, dithering and scaling control, rotation, dynamic 
changes to color gamma tables etc. But unless/until such things become 
available, the ability to set a native video mode is a start. I just 
have started implementing Wayland support for my neuro-science toolkit 
and currently i use wl_shell exactly because it has the 'driver' method 
+ refresh rate selection and xdg_shell doesn't, so i'm stuck on wl_shell 
until xdg_shell would implement that.

It also seems that not many people have tested multi-display fullscreen, 
'driver' method mode setting etc. via wl_shell recently, as i quickly 
discovered a couple of problems in desktop-shell, for which you can find 
a series of patches posted by me a couple of days ago.

thanks,
-mario

>
> Side note: should wl_scaler not specify any kind of scaling filter? For
> example pixel graphics content could not use wl_scalar for fullscreen
> scaling if it could not enforce a 'nearest' filter.
>
>
> Jonas
>
>
> Jonas Ådahl (17):
>    xdg-shell: Add note about that use_unstable will go away
>    xdg-shell: Require proper object tree destruction
>    xdg-shell: Document error conditions when popup and surface getters
>    xdg-shell: Move xdg_shell.get_xdg_popup errors to xdg_shell
>    xdg-shell: Document responsibilities regarding ping events
>    xdg-shell: Require a buffer and a wl_surface.commit for mapping a
>      window
>    xdg-shell: Document that xdg_surface.set_window_geometry needs a
>      commit
>    xdg-shell: Further clarify xdg_surface.move semantics
>    xdg-shell: Fix a couple of typos
>    xdg-shell: Clarify the meaning of app ID and give example
>    xdg-shell: Further clarify xdg_surface.resize semantics
>    xdg-shell: Some minor clarifications
>    xdg-shell: Some xdg_popup clarifications
>    xdg-shell: Specify the meaning of 0x0 window geometry in configure
>    xdg-shell: Document the set_maximized and unsetmaximized requests
>    xdg-shell: Specify fullscreen size-mismatch handling
>    xdg-shell: Bump unstable version to 6
>
>   clients/simple-damage.c |   2 +-
>   clients/simple-egl.c    |   2 +-
>   clients/simple-shm.c    |   2 +-
>   clients/window.c        |   2 +-
>   desktop-shell/shell.c   |  65 ++++++++++++-----
>   protocol/xdg-shell.xml  | 183 +++++++++++++++++++++++++++++++++++++++---------
>   6 files changed, 198 insertions(+), 58 deletions(-)
>