Can I enable mode switching from wayland/weston?

[Pekka Paalanen]

On Thu, 01 Oct 2015 17:03:47 +0200
Robert Folland <robert.folland at me.com> wrote:

> The monitor/camera input receiving the signal is providing a list of
> resolutions in its EDID data, and I guess one is preferred as a
> native resolution. But as long as there are more entries in that EDID
> list, would it not be a good idea to allow these to be “forced”
> through weston?

Forced? No, not with desktop.

We are implicitly talking about desktop here, and on desktop the
compositor *must* be fully in charge of the output, because that
eventually puts the user in charge of his desktop rather than arbitrary
applications he might be running. (I believe games are pretty notorious
about playing carelessly with video modes, screwing up the whole
desktop on the side, on X11.)

We want to reserve the right for the user to forbid all video mode
changes regardless - maybe he is using a TV that has one good mode
tuned just right and several bad ones and wants the compositor to scale
as necessary, for instance.

As mentioned by Jasper, if SDL2 does not use the proper protocol to
even try to ask for a video mode switch, it obviously won't happen. If
SDL2 was to use wl_shell's fullscreen state with "driver" mode, I think
Weston should then be switching the mode for you. At least the code in
Weston exists, but I assume it's not tested much. Weston's current
policy is to obey application mode requests in "driver" mode, AFAIK.
(And automatically undo that mode switch if a different window gets
activated.)

However, for special use cases like yours, there are alternatives that
would work more reliably, but also require more work to implement:

- fullscreen shell; This is a replacement to desktop shell, which means
  you cannot run desktop apps on it, unless they (the toolkit they use)
  specifically implements support for it. This is primarily meant for
  running another Wayland compositor on Weston, using Wayland as
  the hardware abstraction.

- Not using a display server at all. This is the most reliable way
  which gives you all the control without anything else meddling with
  your program and direct feedback from the kernel driver on what
  really is going on, but the downside is that you get to implement
  DRM/KMS usage and the whole input handling yourself. The good thing
  is that nowadays you don't need to use any hardware or driver
  specific APIs to do this (the xf86-video-* driver component is not
  necessary anymore).

Btw. I don't think SDL2 exposes any timing interfaces, does it? So if
you care about exact timings and knowing when your frame was presented,
you'd have to use something else. I have a vague recollection SDL2
would not even be able to tell you that the display server has accepted
your frame (the frame callback in Wayland) which we normally use for
driving the rendering loop in an app to avoid wasted rendering.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/691ec881/attachment.sig>