fullscreen support for games

[Glynn Clements]

Andre Heynatz 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.

Exactly.

> 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).

That would be the right way to do it.

> 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?

> > 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.

> 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.

> > 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?

An application's "icon" can be an X Window into which the application
can draw.

> > 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 ;-) ).

A Display equates to an X server, i.e. a process controlling multiple
screens plus a mouse and keyboard.

-- 
Glynn Clements <glynn at gclements.plus.com>