Exclusive Fullscreen Mode

[Carsten Haitzler (The Rasterman)]

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

> 
> 
> On 09/07/2010 08:42 AM, Carsten Haitzler (The Rasterman) wrote:
> > 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
> That's why I came here asking not looking into SDL. I don't trust SDL
> farther than I can see without glasses.
> > 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. :)
> Makes sense. After the comments above I had in mind to go down that
> route. The engine is supposed to only go fullscreen if the platform
> below supports it so a cant-do window mode is not a problem and fully
> acceptable.
> > 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~" :)).
> Yeah, I would like to avoid such a behavior if possible.
> > 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!.
> My system is more advanced than common engines so there is always a
> layer around the running game which catches such situations and can
> switch back to the normal resolution if something fails (even down to
> Segfaults). I'm though not forcing such a resolution change on the user.
> What I want is if the user "wishes" for a fullscreen with resolution
> change (which does improve performance if using deferred rendering) that
> he gets it. Nobody is forced to use fullscreen and especially not to use
> a resolution change. It's only for those willing to have it. I think
> that's a legit way to deal with it. If the user wants it he can get it
> but it's not forced upon him. I just know a bunch of people who would
> prefer to have the possibility to use fullscreen with a different
> resolution for playing games and in my opinion this makes sense. On my
> weaker test system for example playing fullscreen at 1680x1050 is simply
> not possible although office/web performance is more than enough. At
> half the size though it gets usable. In that situation it would make
> sense to have such a functionality in place.

if you leave the keyboard and grabs alone, then this all seems like it will be
ok. users have their "alt tab" escape route available :)

> > 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.
> I only grab the mouse pointer but this is a must. Try playing an FPS
> with absolute mouse position. That's not really an option. You need
> relative input there and for that only a grab is useful. The way I
> handle it right now is that if the game window looses focus (for example
> due to alt+tab) I give up the grab and reacquire it once the window gets
> back the focus. I don't grab the keyboard for the exact reason that the
> user has to be able to alt+tab out whenever he wants, in the worst case
> because something goes wrong. An additional hotkey to break the grabbing
> would be possible but I don't know yet what kind of key combo would be
> suitable for that.

as i said *IF* you have to - grab. i realize fps games that need relative
positioning need to grab and play warp tricks. at least provide a way out of
the grab so the user can go and click on his irc window on his other screen and
quickly answer a question, then come back to your app and keep on playing :)

> > 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.
> Nah, that's not the problem. I didn't figure out unless today that X11
> extensions provide headers and libraries with function prototypes. I
> thought using something like Randr requires messing with the protocol
> itself like in OpenGL where you have to get functions for extensions
> outside the standard using GetProcAddress. Looks though like I can use a
> simple way for this.
> > 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
> I don't know, performance drops all the way down to 50% or worse doesn't
> sound to me like a "small" performance hit. Granted under full load the
> performance drop is not that heavy but still, every FPS counts. If this
> is though in general a WM problem I can live with it. I just want to
> know what stance to take on this. In this case I can toss the blame
> fully on the WM if compositing drags speed down. That's fine with me and
> one problem less to tackle.

yes. leave this blame at the feet of the compositor. there is very little you
can do... (actually you COULD try and create a child of the compositing overlay
window which is where compositors draw these days... but trust me - that has
limited success even when a compositor does it itself...). you're pretty much
stuck with the compositor here and what it decides is good. as such 50% hit
sounds horribly bad. i have done benchmarks ... on a PHONE that as a compositor
(gl-es2) and i measure about an 18% drop in fps.. on a PHONE. :) 50% is
probably an "extreme" with a very simple scene and thus you go from 100fps to
50fps - maybe... the more complex scenes suffer much less. it's probably also
due to driver as well. chances are the driver is doing a few too many copies
where it could be doing swaps, and possibly blocking ALL gl using
apps/clients while waiting for a copy/swap from back to front buffer. :) there
is a lot of room to move in driver-land still.

(that brings me to a quick q - do most desktop drivers still do a blit/copy
from back to front buffer if the opengl window/surface is composited "full
pixmap"? (ie if top-left of gl window/surface is at 0,0 of the composited
pixmap and its width and height match the composited pixmap? as such internally
x+gl could simply keep front and back buffer bound to the composited pixmap and
simply swap which is the front at any time - technically the entire compositing
pipeline could be reduced to a single copy only (draw composited triangle pair
into compositor back-buffer). everything else (compositor back -> front buffer
and app back -> front buffer) could be swaps.

> > 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 :)
> I agree with the need for such a feature. It would help a lot for such
> kinds of applications. I don't agree though with the last part. It is
> only anti-social if you "force" it on the user. If the user wishes
> though to use something like this it is his own responsibility if it
> works out properly or not. I want to simply provide solutions for
> different tastes. Some people use window mode, others prefer fullscreen
> and again others prefer fullscreen with a different resolution for
> performance reasons. I want to give all these groups a viable solution
> and to be honest I don't care if one solution is more social than
> another since it's the user that decides what he wants on his machine.
> If he wants to use something anti-social why stand in his way? He has
> the choice after all.

well ok - anti social in that apps do this out of the box when you run them
then crash, or... they do it and BOTH my screens change resolution. not just
the one they are on (even though i have xinerama/twinview/mergedfb etc. and i
just want my irc window and what not on my right screen to stay as-is, and if i
want fullscreen for my apps/game/whatever it will do so on the left screen).
it's anti-social in that the game affects something outside of its control or
knowledge and i can't change that. at the LEAST provide an option to JUST use
netwm fullscreen and not use xrandr etc. so i - the user can say "no - leave my
resolutions alone. your changing of them breaks things". i guess this is why i
suggest we need a standard for this where the desktop/wm etc. handles this as
it then maintains a consistent policy for the desktop as a whole as to what to
do about a "fullscreen window" - does "fullscreen" mean "occupy all available
monitors and span them all", or does it mean "just change the monitor it's on
to VGA and leave the others as-is" or "don't change resolution at all- simply
occupy the entire screen" etc.

> -- 
> Mit freundlichen Grüssen
> Plüss Roland
> 
> Leader und Head Programmer
> - Game: Epsylon ( http://www.indiedb.com/games/epsylon ,
> http://epsylon.rptd.ch )
> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
> , http://dragengine.rptd.ch )
> - Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php
> ) and others
> 


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