Exclusive Fullscreen Mode

Tue Sep 7 08:17:38 PDT 2010


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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20100907/460d0a18/attachment.pgp>