fullscreen support for games

[Andre Heynatz]

Glynn Clements wrote:
>>I want far less than that for now: For a home use setting, I simply
>>want to allow applications to set a graphics mode to their likings,
>>and focus on that. Nothing more. Other X clients are not concerned
>>with this, they do not need to be prepared for anything but being
>>inactive. Switching workspaces allows this kind of behavior already,
>>I have not had any problem with it. But all workspaces have the same
>>resolution and color depth, which in this case I want to leave at
>>the discretion of the application.
> 
> 
> This is only realistic for applications which need to take over the
> display entirely. Otherwise, what happens when two applications each
> insist on a different mode?
> 

I focus on fullscreen applications in this thread. For windowed applications wanting a different color depth, an efficient solution would be either a graphics card supporting this directly (i.e. DEC TGA), or using a composite buffer which another poster already has stated.

>>>So start a second X server at 16 bpp and run the game on that.
>>
>>This is inconvenient, because it involves user action.
> 
> 
> It would be trivial for the game to include a "launcher" which starts
> another X server automatically. Any games which take over the entire
> display should probably be using a completely separate X server (even
> if the existing one uses the correct depth) to ensure that they don't
> interfere with existing applications.

Yes, this is possible now and a solution for modern systems with enough main memory. I have tried it with a very recent Debian unstable system. Reconfiguring xserver-common gives me a security setting for X server start:

Select what type of user has permission to start the X server.
* Root Only
* Console Users Only
* Anybody

I have chosen 'Anybody' and started another X server:

$ X :1 -depth 16

It is not that easy to use that display:

$ xterm -display :1
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

I had to

$ xauth
xauth> list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  67891234abcd...
hostname/unix:1  MIT-MAGIC-COOKIE-1  67891234abcd...
xauth> add :1.0 MIT-MAGIC-COOKIE-1  67891234abcd...
xauth> exit
Writing authority file /tmp/.gdmQkALp9


Now it works:

$ xterm -display :1.0

Hopefully, this can be done by an application as well. I think so, but this complex stuff has to be encapsulated somehow. I have not looked yet at the DirectX APIs what they provide to the application developer. I would want a list of modes possible with graphics HW and monitor (resolution, color depth, screen refresh rate) from which I can choose, and start another X server with exactly this mode. And I do not want to determine the right number in 'X :number', I want to do a 'X :give-me-a-unique-number' which is difficult at the process level I think.


One security setting is missing for X server start, which allows the local user sitting in front of the monitor to start a fullscreen game from the X desktop as well:
* Local console and X users only

This setting has to pass not only tty*, but also "local pty" as well (not remote pty's). I do not know how this can be tested.

> 
>>I want the same usability and convenience than on Windows XP, having
>>the casual user in mind, without breaking any existing applications,
>>of course.
> 
> 
> When it was introduced on Win9x, it did break existing applications. 
> Most drivers at least displayed a dialog warning you of that
> possibility. WinXP is new enough that dynamic depth changes can be
> considered part of the API.

It would be nice to have this as well (in a backwards compatible way as I mentioned in my last mail). Showing some dynamics is always impressive, especially for the creative people (artists, etc.). But this thread is about the scenario "fullscreen game". There are more issues with gaming which I have, like audio support for ALSA, so I have to focus on the subject for now. The other thread "Dynamically switch ServerLayout" is about changing the running display which complements this thread well :-)

André Heynatz