fullscreen support for games
Eric Anholt
eta at lclark.edu
Wed Oct 26 14:11:39 PDT 2005
On Wed, 2005-10-26 at 22:38 +0200, Lionel Ulmer wrote:
> > 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.
>
> Basically you can do what you describe (get a list of supported modes and
> then choose one).
>
> The point with the 'second X server proposal' is that it still does not
> solve the 'application want to change depth while still running' problem.
I agree that the "start another X Server" idea is really bad. And, with
the composite extension, we have some infrastructure for changing screen
depth, at the expense of performance for applications that were
previously running.
As far as I know, it would be a matter of:
- add depth changing support back into randr protocol
- add a call for randr to do to Composite to force redirection of a
window (and unforce, if we move the depth back)
- add a driver callback for randr to ask for a depth change
- make the drivers expose all the visuals they could support
- Allow the defualt visual to change at depth changes?
This sounds like a chunk of work, but basically doable. Then we get
clean, on-the-fly depth changes, and could even reallocate some buffers
so we had more offscreen space, in theory.
If the target of this task is OpenGL stuff, though, we do want to make
OpenGL bits aware of composite (since that'll allow redirection at depth
changes, and would also have forced drivers to know about buffers moving
their static buffers already I think). This seems harder, to me.
--
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20051026/71fb0353/attachment.pgp>
More information about the xorg
mailing list