Summary: | Mouse cursor disappears when switching windows while zooming | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Elez J. Shenhar <elezsh> |
Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chrismaple, edgbla, obuolis1, seally.1186, sebsauer, silvan.calarco, sven.burmeister, timerbes, travisgevans |
Priority: | NOR | ||
Version: | 4.9.0 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | togglecursor.c test application |
Description
Elez J. Shenhar
2011-12-19 08:16:02 UTC
The issue seems to be caused by coverswitch and other effects changing the cursor. It looks to me like the zoom effect does not keep track of what is changing. Adding Sebastian, who touched the code last. The comment "Mouse cursor should have stayed visible throughout the process, and beyond, like it did in KDE 4.6 and below" indicates that it's a regression introduced with >=4.7. Now to the interesting pieces; * If I use the "Box Switch" then it works as expected but if I use "Cover Switch" it does not. * The same problem is visible with the "Track Mouse" effect. If I activate it it works fine (through slightly wrong but that#s another bug) if I zoom in but as soon as I used "Cover Switch" the "Track Mouse" effect does not work any longer means nothing is displayed at all if I press the shortcut to activate that effect. Looks for me as we are dealing with a general bug that hits in when we leave those Window-overview that is displayed when "Cover Switch" is activated. In short: it's not related to anything done by me / it wasn't me (this time) :-) It is also not just related to CoverSwitch, but in fact to all effects using a mouse pointer grab. I guess it's somewhere caused in KWin core and will have a look at it later this week or after the holidays. The problem is somewhere on the GLTexture which is used to paint the cursor while zoom != 1.0 (cross check present windows + zoom on OpenGL & XRender) It's likely a shader issue, since in 4.7 (no shaders on this GPU at all) it doesn't happen on GL or XRender here while in 4.8 (correct shader invocation) it's 100% reproducable Is this still an issue? I just tried and can't reproduce it locally anymore... Still very much (100%) reproducible over here with 4.8.1 is the vsync setting crucial? No. I just tried without vsync (I'm usually with it) and it's reproducible just the same. Have you btw. tried w/o OpenGL shader support? It does NOT reproduce after I disable OpenGL 2 Shaders. FYI, I'm using KDE 4.8.2 now. p.s. Sorry it took me so long to reply This bug still exists in KDE 4.9 Most likely same as or similar to bug #304404 but on other item @Martin would you accept a stack implementation of the shader "stack" for 4.9.x or prefer fixing it by explicit uniform setting until 4.10? I would prefer changes like making it a real stack go into 4.10 With KDE 4.9.3, I have a similar issue with the mouse cursor disappearing, but after a Plasma panel popup appears and then disappears while zoomed in. In addition, I see other cursor issues while zoomed that I mention in Bug #276391. This is with official Nvidia drivers and an GeForce GT240. Could these all be related? I have found that as with the reporter's case, the cursor does not disappear when I disable shaders. However, the other issues I mentioned in the other bug report remain. This issue seems to have been solved. This is no longer reproducible for me in 4.9.95 I'm using NVIDIA 310.14 Can anyone else confirm this is indeed fixed? KWin 4.9.4, Nouveau, Fedora 17, dual monitor (over/under) Zoom in, everything OK Zoom out to 1:1, cursor disappears. Zoom in, cursor reappears. Zoom out to 1:1, cursor disappears. reg. comments #16 & #17 there've been soome changes reg. the cursor / texture handling in 4.10 a) it should no longer be reproducible setting the cursor to "keep" at all b) i can't atm. reproduce it with the scaling cursor either, however because of the invocation of the cover switch effect there might be the boxswitch effect (for the additional thumbnail list) in action -> whenever you see this on a 4.9 installation, run "qdbus org.kde.KWin /KWin supportInformation" and attach that output. [root]3999:~#>kwin --version Qt: 4.8.4 KDE Development Platform: 4.9.5 KWin: 4.9.5 [root]4000:~#>qdbus org.kde.KWin /KWin supportinformation Service 'org.kde.KWin' does not exist. On Sun, Jan 6, 2013 at 9:41 AM, Thomas Lübking <thomas.luebking@gmail.com>wrote: > https://bugs.kde.org/show_bug.cgi?id=289336 > > --- Comment #18 from Thomas Lübking <thomas.luebking@gmail.com> --- > reg. comments #16 & #17 > there've been soome changes reg. the cursor / texture handling in 4.10 > > a) it should no longer be reproducible setting the cursor to "keep" at all > b) i can't atm. reproduce it with the scaling cursor either, however > because of > the invocation of the cover switch effect there might be the boxswitch > effect > (for the additional thumbnail list) in action > > -> whenever you see this on a 4.9 installation, run "qdbus org.kde.KWin > /KWin > supportInformation" and attach that output. > > -- > You are receiving this mail because: > You are on the CC list for the bug. (In reply to comment #19) > [root]3999:~#>kwin --version > Qt: 4.8.4 > KDE Development Platform: 4.9.5 > KWin: 4.9.5 > [root]4000:~#>qdbus org.kde.KWin /KWin supportinformation > Service 'org.kde.KWin' does not exist. called "kwin --replace"? This is fixed in 4.10, try "qdbus | grep -i kwin", there'll be some "org.kde.kwin-12345" Here is the output of "qdbus org.kde.kwin /KWin supportInformation", with kde 4.9.5 and same exact problem as comment #17: http://paste.kde.org/649004/ Try setting "mouse pointer" to "keep" and whether you can reproduce the issue when deactivating "OpenGL 2.0" support (or using the XRender backend instead) Also disable the coverswitch effect, resp. deactivate the "additional thumbnailbar" (including the dynamic mode) Then run "kwin --replace&", ensure boxswitch does no longer show up in the supportInformation and see whether the issue remains. "OpenGL" + "scale" does not work. "OpenGL" + "keep" works. "XRender" + "scale" does not work. "XRender" + "keep" works. Disabling "boxswitch" and/or "taskbarthumbnail" does not change the behaviour above both in OpenGL and XRender mode. (In reply to comment #23) > "XRender" + "scale" does not work. It's not GLSL related then. Can you try the behavior with the nvidia blob (or even vesa) instead of nouveau? I have Intel (see below) non nvidia. Maybe tomorrow I can do tests on pcs with nouveau and radeon, but I'm not at all sure that the problem may be chipset dependent. Compositing =========== Qt Graphics System: native Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Mobile Intel GM45 Express Chipset x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 9.0.1 Driver: Intel GPU class: i965 OpenGL version: 2.1 Mesa version: 9.0.1 X server version: 1.10.6 Linux kernel version: 3.4 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes OpenGL 2 Shaders are used Sorry, i didn't notice the user changed interim (and just skipped the GPU section, scrolling forward to settings) There's basically three possible causes for this: a) the function to re-show the actual cursor is not called (but the zoom effect is no longer active) b) the X11 function does not do what it should c) a problem in the framebuffer / driver Most apparent difference is that the reason in the early reports were OpenGL 2.0 shaders (see comments #4 #10 and #15) while now it seems to occur for you on even XRender compositing. kwin version 4.9.5 [root]4002:~#>qdbus | grep -i kwin org.kde.kwin org.kde.kwin-1376 org.kde.kwin.Screenshot org.kde.kwin.Scripting This result is unchanged whether the cursor has disappeared due to zooming out to 1:1 or not. (In reply to comment #27) > kwin version 4.9.5 > > [root]4002:~#>qdbus | grep -i kwin > org.kde.kwin > org.kde.kwin-1376 > org.kde.kwin.Screenshot > org.kde.kwin.Scripting > > This result is unchanged whether the cursor has disappeared due to zooming > out to 1:1 or not. The idea was to get the currently registered dbus service - there's absolutely no change intended to be caused. Try qdbus org.kde.kwin /KWin supportinformation or qdbus org.kde.kwin-1376 /KWin supportinformation for this output. Notice that esp. qdbus org.kde.kwin-1376 /KWin supportinformation will fail for sure if you restarted kwin meanwhile (1376 is the PID at that time) i confirm this bug on 4.9.5. however to workaround the issue i just go to .kde4/share/config and delete kcminputrc file. in this way, the cursor switches to default one, but when you use zoom effect, cursor wont disappear after zooming out Created attachment 76650 [details]
togglecursor.c test application
This is interesting - the issue seems to be in the themed cursor and not that we "forget" to show it.
Can you compile and run the attached applet (it will hide your cursor, wait 5 seconds so you can see that sth. has happened, and the ... "hoepfully" ;-) reshow it) - obviously only makes sense with the critical infrastructure (themed cursor)
If this works as expected, please call back or - if you've more than no coding skills, edit kde-workspace/kwin/effects/zoom/zoom.cpp:~188 and comment
- XcursorImageDestroy(ximg);
+ // XcursorImageDestroy(ximg);
recompile and see what happens?
My guess is that XcursorImage will return some shared object and destroying it will kill it for further usage - a quick test to verify this would be to check whether causing a differnt cursor shape - eg. the I-Beam by hovering some testedit - will re-show the lost cursor.
I am having the exact same problem. I zoomed in on accident. I then zoomed out and my cursor disapeared. If I zoom in again it shows up, but when I zoom out its gone again. What information do you need from me (with instructions on how to get it). (In reply to comment #31) > What information do you need from me (with instructions on how to get it). See comment #30 Download the code, compile and run it. See what happens. Also check what happens if you attempt to alter the shape of the hidden cursor (eg. when entering a textedit, it should turn into an I-Beam). Does it re-occur in this case? I'm probably doing something really obvious wrong, I'm not used to this sort of activity. user@computer:/usr/lib$ gcc togglecursor.c togglecursor.c:3:35: fatal error: X11/extensions/Xfixes.h: No such fildirectory compilation terminated. When I try to get the text edit cursor while zoomed out nothing chanes (hidden the whole time). When I try it zoomed in, the cursor stays the same the entire time. gcc -I/usr/include -L/usr/lib -lX11 -lXfixes -o togglecursor togglecursor.c You'll eventually need libX11-dev packages (pot. libXfixes-dev, if such exists) I can send you a 32bit binary, but it would be better compiled on your system. I tried patching kde-workspace as suggested with no luck. The togglecursor test application seems to behave as expected (cursor disappearing for 5 seconds and then reappearing). If it's worth anything, I'm able to reproduce this in 4.10.5 using OpenGL shaders. Both Keep and Scale seem to be affected for me, but XRender appears to work fine. (I'm only testing window switching, but I also had tooltips fading out cause the cursor to disappear in 4.10.) Using Intel graphics driver. It seems like in my case, the issue is with the Fade effect. When I disable it, everything works. When it's enabled, it looks like the cursor is fading in and out with the window. For example, if I hit Alt+Tab and hold Alt until the switcher shows, once I release Alt, the cursor will fade out partially with the switcher. Git commit fe42ff9c57b5c975b3fed58b9c536bf05f91b8ca by Thomas Lübking. Committed on 03/02/2014 at 20:03. Pushed by luebking into branch 'KDE/4.11'. be more aggressive about exiting zoom effect REVIEW: 115453 M +1 -1 kwin/effects/zoom/zoom.cpp http://commits.kde.org/kde-workspace/fe42ff9c57b5c975b3fed58b9c536bf05f91b8ca Assuming the problem is fixed given that there were no further comments since the last commit comment. In case it's still an issue please reopen. |