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

[Pekka Paalanen]

On Fri, 10 Apr 2015 08:01:39 +0200
Mario Kleiner <mario.kleiner.de at gmail.com> wrote:

> 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.

Hi Mario,

sorry, I cannot see that happening. We very specifically do not want to
give random applications the control of the display beyond their own
window. Not in the protocol that will be the basis for all desktops. The
design principle for desktops is that the user (person) is in control
through the compositor, and random apps can't mess that up even if they
tried.

I think we have discussed this before, and there are some things we can
provide like timings, but absolute control is something we probably
won't give for desktop apps. There are conflicting goals here, your use
case is not really a desktop use case but something special where the
application knows things better than the compositor.

The "driver" method and framerate in the wl_shell fullscreen protocol
are defined only as hints. Most compositors would likely ignore them as
they can't bother implementing the support or enabling them by default.
They were mostly intended as convenience for gamers and game writers:
if the user agrees that a game can change the video mode, then it might
cause it to happen, based on the compositor user preferences.

For a non-desktop case, like the fullscreen shell, it might be
possible. Although, that'd mean replicating much of DRM APIs in the
fullscreen shell interfaces, which then raises the question of why
bother instead of using KMS directly, if you want your special program
to be in full control of the machine.

There actually was an attempt to define and implement a RandR
equivalent, but it died on controversy.


Thanks,
pq