fullscreen support for games

[Andre Heynatz]

>> The RandR X extension allows to change the resolution of a screen, but
>> not the depth. I have read that this is not supported because toolkits
>> have emulation code dealing with it.

Glynn Clements wrote:

> It's not supported because other applications, having queried the
> screen depth and pixel format, won't deal well with it suddenly
> changing.

Ok, I go into it briefly. It would be nice to have a callback for visual change and other dynamics, this would enhance usability. But I know that there are many, many applications expecting no changes after initial program start. Nevertheless, it is possible to introduce new features: new applications supporting dynamics can say so, and a depth change request will fail if there is only one application not supporting it (unless the force flag is set). Additionally, it would be nice then to get a list of blocking applications (like fuser for file/directory usage).

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.

Glynn Clements wrote:

> So start a second X server at 16 bpp and run the game on that.

This is inconvenient, because it involves user action. I want the same usability and convenience than on Windows XP, having the casual user in mind, without breaking any existing applications, of course.

Glynn Clements wrote:

> Suspending the other programs isn't realistic. E.g. if they are
> network clients, suspending them will likely cause connections to time
> out.

But I can iconify applications so that they do not show a window anymore, only a string on the Window List, i.e. k3b showing the completion state in percent. This is possible now, and I assume that k3b or any other well-behaving X client does not render anything which is not visible, does it?

Glynn Clements wrote:

> Also, games often want to mess with global display state (e.g. 
> keyboard processing, mouse acceleration), so you probably want a
> completely separate display rather than just a screen.

Yes, I mean a display. One scenario with multiple screens: Let us assume that I want to play a flight simulator on three screens, with LCD shutter glasses for a stereo display. Then the application likely wants another display with several screens, because often the resolution is limited in stereo mode (depends on the hardware of course ;-) ).

Jaymz Julian wrote:

> I believe that DGA2 actually supports depth changes, but of course that 
> doesn't play nice with 3d on many/most (all?) drivers.  Of course, there
> is a whole list of things that you can't do with DGA, actually, ignoring the 
> whole security danger of it.  But it does provide the whole "exclusive
> fullscreen" functionality that you suggest.

I do not want exclusive access. I only want to allow an application to enumerate possible visuals, open a new display with a chosen visual, and to activate the display suspending the actual desktop. It should not be a problem for an actual graphics driver to serve another display, because I can switch to a VGA console and then back to the X desktop right now. Yes, I have heard about drivers having problems with this, but they are going to be fixed soon if they are not already solved I think. This switching need not be a realtime operation, but should be rock stable.

It is a generalization of console switching with runtime configuration added, I think.

Security:
Of course, this would allow a denial-of-service attack. So I would add a profile "home use"/"business use" which defines capabilities like "X client may open new display" or "X client may grab the mouse". Eventually, a hook dialog could intercept such calls and ask the user for permission, like in Mozilla/Firefox with Cookies. If the xlibs send the application name to the X server, a white list could be kept, again like in Mozilla/Firefox with Cookies. This is an interesting topic for usability as well.

It is all kind of brainstorming for now, and I like to hear more opinions on how usability of the desktop can be enhanced, in this thread for an important home use topic: games.

André Heynatz