Making Wayland Game-friendly

[Kristian Høgsberg]

On Tue, Nov 9, 2010 at 4:28 AM, Luke Benstead <kazade at gmail.com> wrote:
> Hi all,
>
> This is my first post to this list, and I fear it may be a lengthy one, so
> bear with me :)
>
> Firstly, I may be totally off base with this. I'm working under the
> assumption that once complete Wayland will take care of resolution changes
> instead of xrandr (as xrandr is obviously an X extension). If someone could
> point me to any information on resolution switching in Wayland I'd
> appreciate it.
>
> So, the rest of this email is based on the assumption that Wayland has, or
> will have, an API for switching resolution. If I'm wrong, just disregard :)

Nope, you're spot on and I agree.  Carsten Haitzler recently posted a
good writeup on the good and bad things games do under X:

  http://lists.x.org/archives/xorg/2010-September/051152.html

and at the end of the email he's proposing something similar to what
you describe.  I even think we shouldn't expose the full modesetting
API to regular applications, just enough that they know the screen
sizes and layout.  Either the compositor can run a special client with
access to the modesetting interface or changing the resolution and/or
screen layout could just be part of the compositor.

Either way, a native resolution fullscreen mode is definitely planned.
 Both scaling (with or without aspect ratio/black bars) and native
modes (we can page flip directly to the applications buffer) make
sense, but I think that will be policy/configuration options in the
compositor.  What will be in the protocol will be a way to request to
be fullscreen, which the compositor will honor when the application
has focus, but it will always be possible to alt-tab away (or press
the "home button" or similar).  So the compositor is in control, it
will change the resolution, scale and draw black bars, or maybe even
just center the application window and fade out the rest of the
desktop around it.

This also ties in with capturing the mouse pointer and relative events
(which Carsten also talks about in his mail).  Typically games also
want to make sure the pointer stays inside the window and they want
relative events.  It's no good if you're trying to turn around in
quake and the pointer leaves the window or hits the screen edge.  X
applications solve this by grabbing the mouse, confining it to the
window and continuously warping the cursor into the center to simulate
relative events.  This is obviously a hack, and wayland isn't going to
support open-ended pointer or keyboard grabs, nor warping the pointer.
 Instead, we provide relative events when the device generates them,
and in fullscreen mode, all the events go to the fullscreen
application, so no need to confine the pointer.  Possibly, an
application can request "application pointer", where the compositor
hides the pointer when the fullscreen application receives focus,
doesn't update its location and only sends relative events.  This is a
pointer mode that may be useful to allow when an application has a
button grab as well (that is, grabbing the pointer for the duration of
a button click).

Anyway, this is all kinda half-baked, but it is the general direction
I see this going.

Kristian