Bug 302783 - In kde 4.9 rc1 some opengl fullscreen games dont work correctly, by not going fullscreen
Summary: In kde 4.9 rc1 some opengl fullscreen games dont work correctly, by not going...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 4.9.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 4.9.1
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-30 09:34 UTC by Simonas
Modified: 2012-08-12 17:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.1
thomas.luebking: NVIDIA+
thomas.luebking: ReviewRequest+


Attachments
The output file (839 bytes, application/octet-stream)
2012-06-30 11:47 UTC, Simonas
Details
OpenArena rule (231 bytes, text/plain)
2012-07-14 00:38 UTC, Thomas Lübking
Details
xorg log (17.94 KB, text/x-log)
2012-07-17 08:52 UTC, Simonas
Details
grad xserver around resizing the scene (361 bytes, patch)
2012-07-23 22:12 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2012-06-30 09:34:29 UTC
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
Comment 1 Thomas Lübking 2012-06-30 10:14:36 UTC
Could you please specify the game? (and don't say "all" but at least hand a list of examples)
Comment 2 Simonas 2012-06-30 10:49:42 UTC
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.
Comment 3 Thomas Lübking 2012-06-30 11:27:15 UTC
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>"
Comment 4 Thomas Lübking 2012-06-30 11:27:36 UTC
ps the xprop thing is ok to do now, ie. on 4.8
Comment 5 Simonas 2012-06-30 11:47:42 UTC
Created attachment 72234 [details]
The output file
Comment 6 Simonas 2012-06-30 11:47:52 UTC
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)
Comment 7 Thomas Lübking 2012-06-30 12:02:10 UTC
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/ ?
Comment 8 Simonas 2012-06-30 16:37:32 UTC
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.
Comment 9 Thomas Lübking 2012-06-30 17:32:46 UTC
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.
Comment 10 Simonas 2012-07-02 16:22:23 UTC
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
Comment 11 Simonas 2012-07-02 16:26:31 UTC
Cant attach big images so there they are:
http://wstaw.org/w/1cvX/
http://wstaw.org/w/1cvY/
Comment 12 Simonas 2012-07-02 16:28:19 UTC
btw when i do:
kstart --fullscreen <skulltag_executable_here>
i get still same results, doesnt help
Comment 13 Thomas Lübking 2012-07-02 16:37:31 UTC
> can you actually "xrandr -s 800x600" while compositing is active?
Comment 14 Simonas 2012-07-02 16:44:46 UTC
well when i changed resolution with krandrmanager (or whatever its called) kde resolution changed just fine with compositing on.
Comment 15 Thomas Lübking 2012-07-02 17:07:47 UTC
to the particular 800x600?
does STK expose the same graphical errors when altering the resolution first and then starting the game?
Comment 16 Simonas 2012-07-02 17:11:39 UTC
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.
Comment 17 Thomas Lübking 2012-07-02 17:13:30 UTC
try running glxgears and while it's up alter the resolution from 1280x1024 -> 800x600
-> same trouble?
Comment 18 Simonas 2012-07-04 11:11:59 UTC
well no, the problem doesnt happen in glxgears.
Comment 19 Simonas 2012-07-04 11:27:42 UTC
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
Comment 20 jake 2012-07-12 05:42:04 UTC
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
Comment 21 Simonas 2012-07-12 08:05:00 UTC
so ive upgraded to 4.9 rc2 and the problem still exists :(
jake, it looks like you have identical problem like mine.
Comment 22 Thomas Lübking 2012-07-12 13:03:20 UTC
(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?
Comment 23 Thomas Lübking 2012-07-12 13:44:46 UTC
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)
Comment 24 Simonas 2012-07-12 15:26:52 UTC
Im gonna downgrade my nvidia to 295.59 later today and will tell you if the problem happens in that version
Comment 25 Simonas 2012-07-12 16:13:55 UTC
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
Comment 26 jake 2012-07-12 17:24:11 UTC
> (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
Comment 27 Thomas Lübking 2012-07-12 18:02:00 UTC
(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
Comment 28 jake 2012-07-13 23:29:54 UTC
(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.
Comment 29 Thomas Lübking 2012-07-14 00:03:50 UTC
(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)
Comment 30 Thomas Lübking 2012-07-14 00:38:27 UTC
Created attachment 72515 [details]
OpenArena rule

Sorry, i just forgot to attach it ... it's late :-\
Comment 31 jake 2012-07-14 01:47:21 UTC
(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!
Comment 32 Martin Flöser 2012-07-14 08:52:03 UTC
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.
Comment 33 Simonas 2012-07-15 12:23:16 UTC
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
Comment 34 Simonas 2012-07-17 08:52:12 UTC
Created attachment 72577 [details]
xorg log
Comment 35 Simonas 2012-07-23 17:42:30 UTC
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.
Comment 36 Thomas Lübking 2012-07-23 19:21:16 UTC
(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? ;-)
Comment 37 Simonas 2012-07-23 20:34:54 UTC
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 :]
Comment 38 Thomas Lübking 2012-07-23 20:42:27 UTC
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.
Comment 39 Simonas 2012-07-23 20:57:38 UTC
well ok then, you can give me patch, ill try tonight (its gonna be sleepless night ;) )
Comment 40 Thomas Lübking 2012-07-23 22:12:13 UTC
Created attachment 72714 [details]
grad xserver around resizing the scene
Comment 41 Simonas 2012-07-23 22:49:03 UTC
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.
Comment 42 Simonas 2012-08-04 13:15:40 UTC
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?
Comment 43 Simonas 2012-08-08 22:29:24 UTC
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.
Comment 44 Thomas Lübking 2012-08-08 22:53:00 UTC
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.
Comment 45 Simonas 2012-08-08 23:12:28 UTC
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 :)
Comment 46 Thomas Lübking 2012-08-10 22:28:43 UTC
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.
-
Comment 47 Thomas Lübking 2012-08-10 23:31:25 UTC
It's probably not even limited to nvidia, see RR https://git.reviewboard.kde.org/r/105974/

Thanks for pointing us there.
Comment 48 Simonas 2012-08-11 12:26:04 UTC
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?
Comment 49 Thomas Lübking 2012-08-11 20:34:35 UTC
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