Exclusive Fullscreen Mode

[Carsten Haitzler (The Rasterman)]

On Tue, 07 Sep 2010 03:33:48 +0200 Roland Plüss <roland at rptd.ch> said:

> On 09/07/2010 01:29 AM, Tomas Carnecky wrote:
> > On 9/6/10 8:51 PM, Roland Plüss wrote:
> >> On 09/06/2010 08:17 PM, Tomas Carnecky wrote:
> >>> On 9/6/10 5:53 PM, Roland Plüss wrote:
> >>>>  I tried searching on the Internet for informations on how to take over
> >>>> the screen using Xlib. I think here about fullscreen exclusive access
> >>>> like for example SDLMAME does it. I stumbled so far though only on one
> >>>> single mentioning of an Xlib call which should allow switching a window
> >>>> into a FullscreenExclusiveMode. I could though find nothing about such a
> >>>> call nor this FullscreenExclusiveMode. Has anybody an idea what this
> >>>> FullscreenExclusiveMode could be or in general how one can make a window
> >>>> take over the entire screen?
> >>> X11 doesn't have a 'fullscreen' mode like windows. What you have to do
> >>> is: resize and move the window so that it covers the whole screen.
> >>> However, some window managers won't let you place windows wherever you
> >>> want (because they also want to draw window decorations etc), so the
> >>> modern way to fullscreen your application is to tell the window manager.
> >>> The window manager will then resize your window and make sure it's on
> >>> top of all other windows. You can do that by setting _NET_WM_STATE to
> >>> _NET_WM_STATE_FULLSCREEN. See [1] and/or google 'ewmh fullscreen' or
> >>> variations thereof.
> >>>
> >>> tom
> >>>
> >>> [1]:
> >>> http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694
> >> That sounds like a plan. Thanks for the link there. I've got two
> >> questions left about the topic of fullscreen with X.
> >>
> >> 1) What about changing resolution?
> >> SDLMAME as far as I know changes the resolution while full screen and
> >> some games do this too (typically commercial ones like UT*, Quake* and
> >> company). I read somewhere that only root is allowed to change
> >> resolution on-the-fly. Another place states only resolutions in the
> >> xorg.conf are valid. What's the ground truth in this case? Can one
> >> change resolution dynamically from a client application?
> > Any user can change the resolution. The modern way is to use randr, on
> > older servers you need to use xf86vidmode. Proprietary nvidia drivers
> > don't use either, they have their own API for doing that.
> Sounds good. I checked out that Randr extension. I can't though wrap my
> head around how to use it. Under OpenGL you have a glGetProcAddress
> function to obtain function pointers once you know an extension exists.
> In X as far as I get it there is no such facility as you have to send
> the properly formated requests to the server which Xlib provided
> functions do behind the curtain. I somehow can not find in the scarce
> documentation how to send such requests bare handed using Xlib. Is there
> something liks XSendRequest? I assume you have to do it like that, right?

i suspect it's time to pipe up here... mostly because i've played with some
games etc. ported to linux.. they "diy" or use sdl (and even sdl gets it wrong)
and do all sort sof "bad things" because they simply don't understand x11 and
want to treat x11 like windows. windows != x11. just remember that. don't try
and turn x11 into windows-style handling - you just will fight and end up maybe
working with 1 wm, and breaking on another. so some things

1. see the above suggestion. use the netwm fullscreen request where you can. in
fact - just always use it. if it doesn't work - then you user won't get
fullscreen. that's probably fine - their wm is primitive and/or do sold or
useless that they may as well fix their wm or change wm's. :)
2. if you REALLY must - create a window with override_redirect enabled. then
you bypass the wm. move it to 0,0 and make it the size of the root window.
presto. this is MAYBE at best a last resort fallback. please don't do it. it's
highly anti-social. just don't. your users and other window manager, desktop,
compositor etc. authors will much appreciate your being sociable as opposed to
a "spoiled brat" window (ie window must have its own way and take over the
screen - screw everyone else. "i want it my way so :-P~" :)).
3. PLEASE do NOT use xrandr OR xvidmode - don't change resolution. please
PLEASE PLEASSSSSE! see #1. use the fullscreen request above. changing
resolution is highly anti-social behavior. if you crash for some reason the
screen is left in the resolution you set it to and the user has to go clean up
after you. and the tendency for these kind of game/fullscreen apps to crash is
high. please! leave it alone. yes - this means you will have to simply adapt to
the resolution/window size you get. (i'll discuss this later in the email), so
performance will also depend on the users screen resolution - but please don't
fiddle with it! people have multiple screens, multi-head and more. they don't
want you messing with it. leave it alone. :) just handle your window normally -
handle resizes (configure events) and draw to it however you see fit, but just
stick within your window bounds. please! i beg of ye!.
4. if you HAVE to have input like mouse and/or keyboard exclusively there is
XGrabPointer() and XGrabKeyboard() - see the manuals for them. please don't do
this unless you absolutely MUST have NO interference from system keybindings
(eg alt-tab, alt+f1+f2, ctrl+alt+x or whatever bindings your wm/desktop use for
things). *IF* you do this.. PLEASE provide a way to "break out" from the grabs.
eg press ctrl+shift together to then ungrab pointer and keyboard (and your app
also requests normal mode - ie turn fullscreen off) and when it goes fullscreen
again it can grab keys again. but please remember to ungrab and provide a nice
way to ungrab - and also maybe visually a "go to normal windowed mode" button
on the screen so the user easily can see just what to click to "get back out".
but just remember - users ma have multiple screens and unelss there is a need
to do this, don't as they may like to use their mouse to go use the browser,
irc app or email app on their 2nd or 3rd monitor while they play your game
etc. fullscreen on the other screen. xorg at least used to handle ctrl+alt
+keypad-mul/div for killing clients that snarfed your kbd or mouse - or just
forcibly remove the grab. at least there is an emergency opt-out here if a user
knows these key combos.
5. if you want to dynamically find symbols like you do with glGetProcAddress()
look into dlopen(), dlsym() and dlclose() etc. you'll be needing to dlopen()
libX11.so.6 (or libX11.so.5 or libX11.so - try multiple ones). see the manual
pages for these - it's in libdl / part of glibc. though usually no one does
this manual symbol hunting - they just #include the X11 headers and link ti
libX11 etc. at compile time.
6. compositing and fullscreen - this depends on your compositor/wm etc. and
it's config. e17's compositor module has a "don't composite fullscreen
windows" option. it will auto-disable compositing in the event a window is
completely "fullscreen" and not covered by other windows etc. etc.  but this is
up to the compositor to perhaps offer such things. compositors/wm's may still
force even fullscreen windows to have things overlayed. like OSD volume
controls for example. in the windows world this kind of thing badly falls over
when apps go fullscreen and the osd controls battle with the gam to render and
you get horrible flickering. keeping compositing on means these things work
seamlessly - but there is a performance cost you pay. over time this cost is
getting less and less, so only at the lower end does it really matter a lot
anymore

now i need to get on to one thing that is needed in the netwm standards
world... we need a "please go fullscreen at the resolution CLOSEST to the one
that fits this window size". or maybe an extra hint that implies that is
desired when fullscreen is requested, then let the wm handle it from there. it
will change res on the right monitor when your window is in fullscreen mode and
is focused etc. and "go back to normal" when you die, exit, are minimized or
otherwise are "not there anymore". been needing something like this in the
netwm standards world for a while i think - it's easy enough to do. it just
needs doing and agreeing on. this is a HINT so you'd only get the resolution
you ask for IF the wm (and video card/screen and so on) all support it. now i
only wonder if this opens up a can of worms in the "but now do we force clients
to go to xrandr to list possible resolutions? or do we proxy this via the wm
etc."? ie the wm may filter resolutions available based on its own decisions on
what is sensible and what applies (eg on that particular screen/setup). but
until the de's/wm's and so on all talk about this and agree on it... you will
just have to "make do with the resolution you get". PLEASE don't go fiddling
with it. it is highly anti-social :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com