After upgrading to 4.9 rc1 from 4.8.4 i noticed that when i run opengl game in fullscreen mode the game doesnt go fullscreen but in higher left corner i see a glitchy window in which there is game, but it also doesnt work correctly because the game content glitches. In opengl game i am running it at 800x600 resolution, but my native desktop resolution is 1280x1024, thats why i see a window in black background, and it doesnt stretch out. When i disable compositing the game runs just fine. I have also found workaround, for example i run ksnapshot, set its screenshot timeout to 10 secs, then press ok and when ksnapshot timer runs i quickly open the game, then when ksnapshot takes the screenshot it should show a new ksnapshot window, and then the game goes fullscreen as it should. But this workaround is far from enough, because you need to repeat that procedure everytime you open the game. I also noticed that option in system settings "Suspend desktop effects for fullscreen windows" no longer works in that opengl game, while in 4.8 it worked just fine (i can tell you because the performance of the game doesnt go smooth). I am using latest nvidia 302.19 driver, video card is geforce 9500gt 1gb, running latest xorg. I would think that this is somewhat related to the new nvidia driver, because new one actually supports xrandr 1.3 (or whatever version it is) so perhaps it doesnt give right signal to go fullscreen? But then again, in kde 4.8.4 everything works just fine. Reproducible: Always Steps to Reproduce: 1.See details 2. 3. Actual Results: Game doesnt go fullscreen and instead shows a glitchy window Expected Results: It should go fullscreen
Could you please specify the game? (and don't say "all" but at least hand a list of examples)
Well the game is called Skulltag, a classic doom port, but its closed source so i only have binary executable. Altough other game called SuperTuxKart works fine when i play it fullscreen and using other than native screen resolution. I havent tested more games, because now im back to 4.8, but when ill reinstall rc1 i will take a look at more games, and will give you photo of how the problem looks like.
could be about some pointer/server grab (beause ksnapshot "fixes" it) please run (in konsole) "sleep 10; xprop > skulltag.props", run the game, wait for the cursor to turn into a cross and click the window. Then attach the skulltag.props here. also on 4.9 try "kstart --fullscreen <skulltag_executable_here>"
ps the xprop thing is ok to do now, ie. on 4.8
Created attachment 72234 [details] The output file
Well when i do that when the game is fullscreen konsole outputs error: xprop: error: Can't grab the mouse. But when i run the game in windowed mode, i get the file (see in attachment)
yupp, it grabs the pointer - you'd have to wait for the xprop pointer before launching skulltag then (ie start skulltag delayed by sleep from another konsole window/tab or so) it however doesn't set too much - can you actually "xrandr -s 800x600" while compositing is active? PS: this http://www.skulltag.com/ ?
Well i tried to delay skulltag file, but it still doesnt work, it prints empty file. I will check when i will reinstall 4.9 rc1. and yes the site is correct.
The game (just like plain gzdoom - what's the advantage of skulltag justifying the extremely high cpu load?) only offers me the current native resolution for the fullscreen mode. If i set 800x600 in windowed mode and switch to fullscreen i get a tiny game area within the black center of the screen (just like with plain gzdoom) This is on 302.17 / GT520 Since skulltag (just as gzdoom, i frankly wonder whether gzdoom has a bsd style license...) uses SDL for the OpenGL backend i'd say that the SDL version is more important than the actual game.(1.2.15 here) There's no difference whether i run OpenGL compositing or not.
So ive reinstalled 4.9 rc1. Well after the tests this weird issue actually happens on all opengl games. It didnt happen in supertuxkart because i have had checked suspend composition on fullscreen apps option in system settings. Now i am not sure what to do else, if it happens with all the games. So im attaching screenshots
Cant attach big images so there they are: http://wstaw.org/w/1cvX/ http://wstaw.org/w/1cvY/
btw when i do: kstart --fullscreen <skulltag_executable_here> i get still same results, doesnt help
> can you actually "xrandr -s 800x600" while compositing is active?
well when i changed resolution with krandrmanager (or whatever its called) kde resolution changed just fine with compositing on.
to the particular 800x600? does STK expose the same graphical errors when altering the resolution first and then starting the game?
well it happens to any resolution lower than my desktop native. So of course, when i lower my desktop to e.g. 800x600 game at 800x600 runs just fine like it does now, so when my native desktop resolution is 1280x1024 and game resolution is 1280x1024 everythings fine too.
try running glxgears and while it's up alter the resolution from 1280x1024 -> 800x600 -> same trouble?
well no, the problem doesnt happen in glxgears.
heres a log when start kwin from my console, to give you more info about my hardware: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 9500 GT/PCIe/SSE2/3DNOW! OpenGL version string: 3.3.0 NVIDIA 302.17 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 302.17 GPU class: G80/G90 OpenGL version: 3.3 GLSL version: 3.30 X server version: 1.12.2 Linux kernel version: 3.4.4 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes
4.9-rc1 broke openarena for me. I played openarena regularly in kde 4.8.4 but after updating to kde-4.8.90 openarena stopped working. When I start openarena in kde-4.8.90, I see what appears to be the game window up in the upper left corner, mostly off the screen, and it is unresponsive. I must go to a tty and restart kdm to regain control of the machine. If I select xfce session in kdm I can then play openarena with no problem. kubuntu 12.04, kde-4.8.90 from ppa, intel graphics
so ive upgraded to 4.9 rc2 and the problem still exists :( jake, it looks like you have identical problem like mine.
(In reply to comment #21) > so ive upgraded to 4.9 rc2 and the problem still exists :( There's no magix fix with version numbers. If the bug gets fixed it will be updated here. (In reply to comment #20) > screen, and it is unresponsive. I must go to a tty and restart kdm to regain > control of the machine. It will likely be sufficient to kill openarena from there (it supposingly grabs the input, therefore you can't control the system otherwise. ctrl+alt+F[,n] are kernel space commands and thus remain operative) The issue likely occurs because we do no longer re-create the OpenGL context on screen resizes but simply resize it. Nvidia has completely changed the xrandr implementation in 302.17 (so there mjight be bugs) but it should rather not haapen with intel. First off and regardless of this bug: Before playing games you want to suspend the compositor for performance reasons, this can also be controlled through a window rule. Second: please ensure to disable the blur effect and set the scale method to "smooth" ("kcmshell4 kwincompositing", 2nd and 3rd tab) Third: do those games use SDL? (usually yes, "ldd `which <game_binary_here>`", ensure the game bin is no script, then grep the ldd output for SDL) In case, please try SDL_VIDEO_X11_DGAMOUSE=1 SDL_MOUSE_RELATIVE=1 <game> > kubuntu 12.04, kde-4.8.90 from ppa, intel graphics intel on what chip and with the UXA or the SNA driver?
Ok, i get "random" issues with tyr-quake On an intel N10 the game starts in the lower left corner of an 1024x768 section in a black fullscreen area when the games is started -width 800 -height 600 -fullscreen (and the display is 1366x768) This affects the OpenGL compositor /only/ - xrender compositing or no compositing is not affected. On nvidia 302.17 the game is placed in a similar way, but a) the rest of the screen does not turn black but remains operative b) it's regardless of the compositor (ie. even with no compositing or running openbox the application cannot resize the screen) In either case the game runs as expected, just the geometry is "wrong" (because the resolution did not change) tyr-quake however does NOT use SDL (those games as eg. gzdoom cause no issue here at all) but it does USE dga (so forcing SDL to use it is likely unrelated)
Im gonna downgrade my nvidia to 295.59 later today and will tell you if the problem happens in that version
Ok so the problem doesnt happen in 295.59 version. But heres what, when i play any game on opengl prior 302.19, my actual monitor resolution doesnt change from desktop native. For example if i play game at 800x600 i go to my monitor settings and it shows me the resolution is 1280x1024 (desktop native). So from what i understand it actually creates game window and stretches it to fill the empty areas, so i actually play in desktop native resolution but everything in game is like at 800x600. So nvidia 302.19 has changed that, and now my resolution changes work just fine, when i play game at 800x600 my monitor shows that my resolution is 800x600. I hope you understand what i meant
> (In reply to comment #20) > > screen, and it is unresponsive. I must go to a tty and restart kdm to regain > > control of the machine. > > It will likely be sufficient to kill openarena from there (it supposingly > grabs the input, therefore you can't control the system otherwise. > ctrl+alt+F[,n] are kernel space commands and thus remain operative) No, that's the first thing I tried. But killing openarena only results in a distorted and unresponsive screen. In order to regain control of the machine it is necessary to restart kdm. > The issue likely occurs because we do no longer re-create the OpenGL context > on screen resizes but simply resize it. > Nvidia has completely changed the xrandr implementation in 302.17 (so there > mjight be bugs) but it should rather not haapen with intel. > > First off and regardless of this bug: > Before playing games you want to suspend the compositor for performance > reasons, this can also be controlled through a window rule. Yes, kde is configured to suspend effects when full screen opengl apps are running. > Second: > please ensure to disable the blur effect and set the scale method to > "smooth" ("kcmshell4 kwincompositing", 2nd and 3rd tab) OK, I will check that setting tonight. > Third: > do those games use SDL? (usually yes, "ldd `which <game_binary_here>`", > ensure the game bin is no script, then grep the ldd output for SDL) jjs@pandora:/usr/lib/ioquake3$ ldd ioquake3 | grep -i sdl libSDL-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 (0xb7723000) jjs@pandora:/usr/lib/ioquake3$ > In case, please try > SDL_VIDEO_X11_DGAMOUSE=1 SDL_MOUSE_RELATIVE=1 <game> OK, will try that tonight - > > kubuntu 12.04, kde-4.8.90 from ppa, intel graphics > intel on what chip and with the UXA or the SNA driver? [ 299.284] (II) intel(0): Integrated Graphics Chipset: Intel(R) G45/G43 [ 299.284] (--) intel(0): Chipset: "G45/G43" [ 299.269] xorg-server 2:1.11.4-0ubuntu10.5 (For technical support please see http://www.ubuntu.com/support) ... [ 299.274] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale, Sandybridge Desktop (GT1), Sandybridge Desktop (GT2), Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1), Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+), Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2), Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server ... [ 299.666] (II) UXA(0): Driver registered support for the following operations: [ 299.667] (II) solid [ 299.667] (II) copy [ 299.667] (II) composite (RENDER acceleration) [ 299.667] (II) put_image [ 299.667] (II) get_image [ 299.667] (==) intel(0): Backing store disabled [ 299.667] (==) intel(0): Silken mouse enabled [ 299.667] (II) intel(0): Initializing HW Cursor [ 299.700] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 299.700] (==) intel(0): DPMS enabled [ 299.700] (==) intel(0): Intel XvMC decoder enabled [ 299.700] (II) intel(0): Set up textured video [ 299.700] (II) intel(0): [XvMC] xvmc_vld driver initialized. [ 299.700] (II) intel(0): direct rendering: DRI2 Enabled [ 299.700] (==) intel(0): hotplug detection: "enabled" [ 299.700] (--) RandR disabled ... jjs@pandora:~$ lsmod | grep 915 hid 81915 2 hid_generic,usbhid i915 455909 3 drm_kms_helper 32563 1 i915 drm 226226 4 i915,drm_kms_helper i2c_algo_bit 13197 1 i915 video 18641 1 i915
(In reply to comment #26) > Yes, kde is configured to suspend effects when full screen opengl apps are > running. In case you refer to the unredirection setting on the first tab in the kwincompositing kcm: TURN IT Off! The intel driver is known to cause random issues with this, that's among other things why it's off by default. Do *really* suspend the compositor through a window rule, dbus or the alt+shift+f12 shortcut
(In reply to comment #27) > (In reply to comment #26) > > Yes, kde is configured to suspend effects when full screen opengl apps are > > running. > > In case you refer to the unredirection setting on the first tab in the > kwincompositing kcm: TURN IT Off! > The intel driver is known to cause random issues with this, that's among > other things why it's off by default. Actually I was referring to the 3rd ("advanced") tab in "System Settings" -> "Desktop Effects" which contains a check box titled "Suspend desktop effects for fullscreen windows" > Do *really* suspend the compositor through a window rule, dbus or the > alt+shift+f12 shortcut When I "really" disable effects using the alt-shift-f12 key combination, the game works properly. So apparently the "Suspend desktop effects for fullscreen windows" checkbox doesn't really work. I looked briefly through the window rules tabs and didn't see any intuitive way to make that happen. So the good new is, if effects are disabled, openarena runs properly. The question is, why doesn't the checkbox work.
(In reply to comment #28) > Actually I was referring to the 3rd ("advanced") tab in "System Settings" Yes, my bad - wrong tab, right issue. TURN IT OFF > I looked briefly through the window rules tabs and didn't see any intuitive > way to make that happen. Import the attached rule. (The detect button doesn't work since the game grabs the pointer) > So the good new is, if effects are disabled, > openarena runs properly. The question is, why doesn't the checkbox work. The feature is broken to various degrees in the intel driver ever since. @Martin What do you think about mapping the config item to "suspend compositing for all fullscreen windows" and dropping the unredirection code? BUG STATUS: Issue so far limited to nvidia blob 302.17 on a G96 and KWin 4.9 @Simonas the older nvidia drivers had an option on how to handle other screen size (center, scale, force scale)
Created attachment 72515 [details] OpenArena rule Sorry, i just forgot to attach it ... it's late :-\
(In reply to comment #30) > Created attachment 72515 [details] > OpenArena rule > > Sorry, i just forgot to attach it ... it's late :-\ OK, I imported the rule, now I understand a little better how this works. As it turns out I had to change the window class from "openarena" to "ioquake3" since, as it turns out openarena is just a shell around the ioquake3 engine nowdays. With that change, it works quite nicely!
On Saturday 14 July 2012 00:03:50 you wrote: > @Martin > What do you think about mapping the config item to "suspend compositing for > all fullscreen windows" and dropping the unredirection code? Completely turning off compositing through a checkbox seems maybe too much. Consider a user has turned it on and uses Firefox in fullscreen... Though I would not mind removing the config option, unsure about the code. It's actually quite useful, just the drivers suck and well it still flickers I think.
ive just tried with the new nvidia 304.22 beta driver, and the problem is still there :( some of the changes of this driver: http://www.phoronix.com/scan.php?page=news_item&px=MTEzOTc
Created attachment 72577 [details] xorg log
disabling compositing through window rules on nvidia doesnt work at all, when i run game i still see glitches and see that glitchy window glow shadow, which indicates that compositing is active. It basically doesnt do anything better than option suspend desktop effects for fullscreen applications in 4.9, while on 4.8 both options worked just fine. If its because of the new method in which you just resize opengl context, why not just revert to old behaviour? Also i can remind that ksnapshot method always workarounds the issue just fine.
(In reply to comment #35) > disabling compositing through window rules on nvidia doesnt work at all, WOW wait - you mean "it does not work at all" or "it does not prevent this issue"? Can you please move to VT1, login, and call DISPLAY=:0 qdbus org.kde.kwin /KWin compositingActive > when i run game i still see glitches and see that glitchy window glow > shadow, which indicates that compositing is active. Or the framebuffer is corrupted. Please ensure the state - also notice that i created the rule for OpenArena and the version I used here does not even the one Jake uses (different class name) It will for sure NOT work with "skulltag" > It basically doesnt do anything better than option suspend desktop effects for fullscreen applications in 4.9, while on 4.8 both options worked just fine. I assume unredirecting the window actually never worked but the compositor was simply not re-established after > because of the new method in which you just resize opengl context, why not > just revert to old behaviour? It's faster an causes far less flicker when eg. attaching, removing or rotating a screen or change the resolution for other reasons. if the issue here is that some games (locally, openarena & ioquake cause nothing like that here) corrupt the framebuffer (what's a driver issue in the first place) the apparent solution would be not scale the games and otherwise to wrap them in a script which toggles either compositing or resolution around the game. (as with all wine games when they could neither alter the resolution nor enter fullscreen mode ....) > Also i can remind that ksnapshot method always workarounds the issue just fine. I assume the game waits until it can grab the pointer - does it resize the screen in between? Wanna try another patch? ;-)
Well i think this week i wont have time to do anything at all, but when ill have some spare time, ill definitely test everything and try a patch :]
NOTICE: Wednesday, July 25, 2012: KDE 4.9 Final Tag If we don't have solution before that date (i want to try grabbing the server around the context resize, you'll only have to compile and test that once - either it works or not) the patch will NOT be in 4.9.0 but 4.9.1 at best.
well ok then, you can give me patch, ill try tonight (its gonna be sleepless night ;) )
Created attachment 72714 [details] grad xserver around resizing the scene
well the patch didnt fix the problem. anyway it seems like disabling compositing through window rules works just fine, i probably did something wrong last time. I guess its gonna be good workaround because games without compositing work much better.
the problem which became annoying now is that for instance when i fullscreen dosbox i see that problem, and i dont want to disable compositing for that app when im not in fullscreen mode, because my whole desktop glitches during compositing on/off. and option is system settings to disable it on fullscreen apps doesnt work. maybe there is some way to make certain apps disable compositing only when going fullscreen?
tried with nouveau driver, same problem exists and nouveau uses window scaling method when changing game resolution (like nvidia 295.xx by default) rather than real pixel changing which is on latest nvidia drivers.
Dosbox (unlike gzdoom) does sth. really weird here. (304.32) It activates my (left) second screen, deactivates the primary one and displays (in case of compositing) a "distorted" result on the second screen (which is still operative, i can just "exit" dosbox) This behavior is clearly a client bug (i said "-fullscreen", not "-re-arrange_my_screen_setup") and while it should not confuse the compositing scene (i'm under the impression the major resolution is scaled to the minor screen) or the driver, the foremost thing to fix here is the client (which also does not advert a regular fullscreen feature, so it will try its own little fullscreen thing there) Nevertheless I got a "does freaky things and why does that cause us trouble" testcase now.
yes i get same distorted screen which is also operative. Im not sure how can i help you but only wish you good luck investigating :)
What happens is that the application (or rather SDL) "somehow" attempts to set a different video size (1024x768) and that is also signaled through xrandr and kwin correctly and successfully resizes the overlay window as well as the glViewport (there's no GL error on the stack afterwards) BUT the geometry is not *really* changed but a canvas (original video size) is created (with a 1024x768 viewport) "pkill -9 dosbox" will shut it down but prevent unsetting the video mode, you can then see that moving the cursor to the screen edge will move the viewport around the canvas FTR: just not doing anything in reaction (ie not attempting to change the screen size as it's not necessary anyway) will "just work" ie. you get a fully functional dosbox window. I'd like you to confirm this finding by injecting a "return;" statement to the very top of void SceneOpenGL::screenGeometryChanged(const QSize &size) in scene_opengl_glx.cpp:617 We got to figure whether we can detect this failed resize approach and therefore at least prevent invalid reaction, kind of working around this issue. -
It's probably not even limited to nvidia, see RR https://git.reviewboard.kde.org/r/105974/ Thanks for pointing us there.
I applied __use_virtual_screen_size.diff patch and the problem is fixed to me too! Thanks for working out the issue! Altough i found out the new issue (it actually existed before that patch too), when i have option suspend desktop effects for fullscreen apps checked, and go fullscreen, then the window content is frozen, i can hear sound effects when i interact in e.g. dosbox and other stuff, but the video is frozen, it basically leaves me with image which i had before going fullscreen. Altough when i uncheck this option in system settings then all is working fine. But i guess that problem isnt related to this bug, so i should probably create a new bug report?
Git commit f070a24527a64117149c005a9813f348e9479f8e by Thomas Lübking. Committed on 11/08/2012 at 21:32. Pushed by luebking into branch 'KDE/4.9'. use virtual screen size when desktop is resized QDesktopWidget::screenGeometry() fails if there's a panning or overlapping screen setup REVIEW: 105974 FIXED-IN: 4.9.1 M +3 -1 kwin/geometry.cpp http://commits.kde.org/kde-workspace/f070a24527a64117149c005a9813f348e9479f8e