Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Lukas Jirkovsky <l jirkovsky gmail com>]

Hello guys,
First I'd like to apologize I'm posting this as a reply, but I've just
registered in this mailing list.

I'm an occasional user (as a programmer and a player) of fullscreen
applications that needs a resolution change. I must agree the current
state is a mess, which should be dealt with once and for all. I don't
think having WM to do resolution change is a good idea (Martin Gräßlin
already wrote about the problems if WM would change the resolution).
There was also scaling mentioned, but I don't think this a good way to
go either because of the possible slowdown.

Finally I'm getting to my idea, which is why I'm writing into this
list. I think this should be handled in display server – either Xorg,
or more likely wayland (Luke Benstead mentioned starting similar
thread in Wayland mailing list [1]). I'm no specialist in the low
level details of the display servers, so pardon me for possibly not
being specific enough.

My idea is like this:
0. assume you are running some WM and you start a full screen
application that requires resolution change
1. the display server temporarily disables the drawing of the current
screen (I think it wouldn't even be necessary to inform the WM about
that, but maybe WM could do something useful with such information,
such as disabling some work in eg. hardware sensors applet)
2. the display server spawns a light-weight child display server with
a specified resolution
3. the fullscreen application runs in the the server created in 2.

This is very similar to starting a separate X server, where a new X
server is created before the application starts and then starting the
application on this newly created x server. The good thing about this
approach is that this has a good performance and it doesn't mess up
the desktop in any way.

However, the separate X server in its current form has its problems.
The display server needs to be started before the application starts
(though there are utilities such as xmove that should somewhat fix
this). Also a full initialization is required during startup. Finally
it is problematic when there are sometimes multiple X servers running
(ie. do I need to run "xinit someapp  -- :1" or "xinit someapp  --
:2"?).

I think by integrating a similar functionality directly into the
display server (X/wayland) these issues can be fixed. Eg. the full
initialization can be skipped for the child display server, because
the HW is unlikely to change between starting the fullscreen
application and creation of the new display server.

I hope this post has at least some interesting ideas.

[1] http://lists.freedesktop.org/archives/wayland-devel/2010-November/000080.html

Lukas