On 09/07/2010 08:42 AM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 07 Sep 2010 03:33:48 +0200 Roland Plüss <rol...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com