Cursor is super large when inside any Qt4/Qt5 app. It's ok inside GTK apps, http://x.rushbase.net/4fc81ea29ceafb60637b91629a52823a61b352bd/inside-app.png When cursor is moved outside, it becomes normal: http://x.rushbase.net/a83a97f183dd34ab6d8249561a1cd78d89d374cf/outside-app.png It leads me to believe that kwin may in the position to fix it, I'm running latest openSUSE Tumbleweed with slight modification in Mesa build to enable DRI3. Primary monitor is driven by the Intel card (Sandy Bridge) and secondary monitor is driven by reverse PRIME through nouveau (Intel does the rendering and Nvidia does the display) Xrandr for the primary monitor: LVDS1 connected primary 1600x900+0+992 (normal left inverted right x axis y axis) 309mm x 174mm Xrandr for the secondary monitor: DP-1-1 connected 2560x1440+1600+0 (normal left inverted right x axis y axis) 597mm x 336mm Problem can be worked around by enabling "Force fonts DPI" to 96 inside Fonts configuration dialog. Which btw. is another problem cause apparently this option does much more than change fonts DPI. It should probably be tracked in another issue. Reproducible: Always
> It leads me to believe that kwin may in the position to fix it Nope. KWin manages window, not cursor pixmaps ;-) It's the client (ie. Qt) > Problem can be worked around by enabling "Force fonts DPI" to 96 inside Fonts configuration dialog. Your resolution is probably screwed, Qt aligns to that when picking a cursor (i think, kai will know much better) What's the output of "xdpyinfo | grep resolution"?
Why is my bug marked as invalid? Clearly it's a bug. Why is it marked as resolved? It's not resolved. This is the DPI (96): https://x.rushbase.net/726de801394a19439c0dbd6f7b630f00124951da/Spectacle.kn5749.png
Because it's not a bug in kwin (which is not responsible) or one of its dependencies. It's not even a bug in KDE. Ie. invalid because "you're telling the wrong people." Please don't post images containing text, but is that before or after enforcing the DPI in systemsettings? (Obviously only the troublesome condition is relevant)
I'm posting the problem to the best department I could have thought of and I'm using KDE for many years now (thank you!) so I roughly know its architecture. I hope ordinary users aren't expected to file a bug until they guess the correct department. The bug happens when using KDE so it's also KDE's job to make sure its dependencies are working well. And about general approach to bugs, If bugs are gonna be closed instead of reassigning them to the correct department or to upstream how are we gonna improve the quality of the project? How are using gonna find the very same exact problem if somebody else encounters it? Anyway, I'm working around this problem by forcing the DPI. If somebody finds this issue at least they're gonna know a workaround. Have a good day
Just found out that another is forcing the cursor size inside `kcmshell5 cursortheme` fixes it. Assigning it to "plasmashell" as indicated by Fabian "fvogt" Vogt user from #opensuse-kde Thanks Fabian.
You managed to avoid answering the crucial question... ===> What about the unenforced resolution? Without that it's not possible to tell where the problem is, ok? We cannot re-assign the bug, because it's either in Qt or X11 (where neither is handled in this bugzilla) And it's not KDE's job to fix bugs in other software - not even *iff* that would be possible (what it is not in this case, there's *probably* a miscalculation of the screen resolution, but KDE only sees the resolution and cannot decide whether that's for a user enforcement or a bug in the X11 server, so it would actually be a bug to mindlessy override that with internal calculations) You're not supposed to know any of this, but you *are* supposed to cooperate and answer questions instead of questioning determinations notably *since* you lack the technical insight. The resolution is merely an internal tag on the bugs status (it's not a bug in kwin or it's deps so it's invalid) and *NOT* a call to "piss off" or such.
I did provide the DPI output of the command you asked for: it's 96 DPI (96x96 dots per inch) - screenshot is optional to click. If I indeed missed anything, please ask again in bold letters. I might have omitted it by mistake. Btw. here is the "kcmshell5 cursortheme" screenshot (optional to click!) http://x.rushbase.net/019eb5236da21b77a38590ca97e14f7347a3edf1/Spectacle.wX6507.png - what's interesting is that it shows that the increased size is exactly x2 - so maybe it's the high DPI logic that's incorrectly kicking in.
It's important to obtain that information *before* enforcing a resolution in systemsettings. Your actual resolutions are ~131dpi (LVDS-1) and ~108dpi (DP-1-1) so the 96dpi in your screenshot are very likely the value you enforced. That information is worthless because it doesn't describe the problematic situation at all.
I did run it before. The command was run without force DPI and after re-login. It shows 96x96 all the time.
It would seem that the cursor size is based upon the physical resolution instead of the logical then. The other bug (which I googled up ;-) has a similar constellation. The internal screen has a physical resolution of 96dpi and that is set by the server (the condition might stem from an Xorg config snippet in your case) but the second screen has a resolution of ~131dpi and as soon as it's added, the bigger cursor is used (wrt 72dpi being the base, 131 is 1.82 times larger, so the big cursor should be used while 96dpi is only 1.33 times 72dpi) Unfortunately I don't know who's in charge here - it's either Qt or the plasma QPA. I cannot even say whether this would be considered a bug given that the physical resolution is used to determine an input event (*shrug*) What is stunning though is your claim to work around it by altering the font resolution, for this would actually rule out physical resolution trumping the logical one. *** This bug has been marked as a duplicate of bug 301622 ***
Thanks for tracking down the earlier bug report. The other report is using huge instead of large and pointer instead of cursor, -_-