Bug 348273

Created attachment 92838 [details]
qdbus org.kde.KWin /KWin supportInformation

I added qdbus org.kde.KWin /KWin supportInformation output as an attachment

I assume restarting Kwin doesn't fix the issue?

No, it doesn't. 

I have also tried changing the Compositor Render backend and Open GL interface, but no change.

As a side-note, I just noticed that hovering over the Plasma desktop the pointer behaves the same way.

ohh very interesting. Same question as with KWin: does restarting plasmashell fix it?

No. Sorry.

If you want I can try with different window decoration themes. Is there one that's not based on QML?

no need to try different window decorations (and for the matter: breeze is not QML based). But what I'd like you to do is test a few QML based windows and whether there the cursor has correct size. E.g. the window decoration list in systemsettings.

I'm away from the machine right now, but I'll come back tomorrow with the test results. If I remember correctly the mouse behaves as it should, but I want to double check.

Currently I'm on a different machine also running Plasma 5.3.1 on Archlinux and the behaviour is similar but not the same. The comment below refers to this machine:

The display is 96DPI and if I change the pointer size to 48px, hovering over the decorations it reverts to 24px, but as soon as it reaches the edge and changes to the resize icon, it switches to the correct size of 48px. In this case the Window Decorations window doesn't affect the pointer size, it remains 48px.
 
I'm not sure it's the same issue, but maybe you can verify this without needing a HiDPI display.

Indeed the Window Decorations list shows a correct cursor on the HiDPI machine.

that's not what I expected - I thought all of QtQuick is broken.

Is there any other information you need from me Martin?

BTW, thanx for taking the time to look at this. :)

Interestingly, the cursor size does not change for "xrandr --dpi 200" (which the resolution does) - it's likely operating on the physical res?

However, what I noticed after changing the resolution to 48px by hand, the titlebar took a click to update. The "on hover" cursor remained 24px until the shape was changed - so we might miss the size update and operate on the cached cursor.

That however doesn't explain that it remains on a kwin/plasmashell restart: just to be sure, when Martin asked for "restarting Kwin", you ran "kwin_x11 --replace &" and did NOT log out/in, did you?

Yes Thomas. It was kwin_x11 --replace

Your description for the issue with xrandr --dpi 200 matches the behaviour I mention in comment #8.

I'm seeing the same issue on kwin 5.4.1 on Fedora 22 with a 3200x1800px screen.

Updated to latest "kde*" packages from fedora updates-testing and the issue seems fixed now.

given comment # 15 I assume a distro issue -> RESOLVED DOWNSTREAM

Same here on gentoo.
Maximiliano Bertacchini, can you tell which update exactly resolved the issue? (so that I can find out, what's the problem and what's the fix)

I'm afraid I can't tell exactly which update resolved the issue. Looking at kwin's build history (http://koji.fedoraproject.org/koji/packageinfo?packageID=19445) it looks like there were no new releases around the date it was fixed for me (2015-09-23). So maybe another package was involved?

I have the same issue with Plasma 5.5.2 on gentoo with cursor size setting "resolution dependent".
Are you sure this is a distro issue, given that I use a different distro and setting the cursor size to fixed "48px" leades to a normal behaviour?

It was tagged so only because of comment #15, what doesn't imply any "certainty" ;-)

Can you please attach you ~/.config/kcminputrc ?

and please check the output of:
    tr '\0' '\n' < /proc/`pidof kwin_x11`/environ | grep -i xcursor

Created attachment 96595 [details]
kcminputrc

Thanks for giving it a chance. ;)

$ tr '\0' '\n' < /proc/`pidof kwin_x11`/environ | grep -i xcursor
XCURSOR_SIZE=0
XCURSOR_THEME=breeze_cursors

I also should mention, that in addition the mouse cursor gets "small" when hovering over gtk3 applications (not only the decoration, but the whole window).

That seems ok - to be sure it's the same issue: do you get the same problem with explcitly set 48px? (see OP; it's "normal" that the cursor shape needs to change after the settings change, eg. when you click a window to drag it)

(In reply to Thomas Lübking from comment #23)
> That seems ok - to be sure it's the same issue: do you get the same problem
> with explcitly set 48px? (see OP; it's "normal" that the cursor shape needs
> to change after the settings change, eg. when you click a window to drag it)

I do not have this issue when explicitly setting it to 48p (neither with decorations nor with the gtk app).

Sounds like a different issue.
Does restarting "kwin_x11 --replace &" change anything?
What resolution (logically & physically) are you on (NOT "1024x768", but "xdpyinfo | grep  resolution" for the logical and probably /var/log/Xorg.0.log for the physical resolution)

(In reply to Thomas Lübking from comment #25)
> Does restarting "kwin_x11 --replace &" change anything?
No.

> What resolution (logically & physically) are you on (NOT "1024x768", but
> "xdpyinfo | grep  resolution" for the logical and probably
> /var/log/Xorg.0.log for the physical resolution)
$ xdpyinfo | grep  resolution
  resolution:    162x161 dots per inch

I'm not sure what you mean by "physical resolution", but my monitor's native resolution is 3840 x 2160 and it's diagonal length is 27 inch. Assuming my monitor's physical length ratio is exactly 16:9 (which I didn't check), this gives a resolution of 163.178 x 163.178 dpi.

(In reply to Lukas Schneiderbauer from comment #26)

> I'm not sure what you mean by "physical resolution", but my monitor's native
> resolution is 3840 x 2160 and it's diagonal length is 27 inch.

That. ;-)
xdpyinfo returns the set resolution which can differ from the actual one - but I assume it's correct in this case (27" is a category - not necessarily 100% correct)

The auto-size seems calculated (pretty much everywhere) as dpi*16/72 what get's you < 36px for the vertical and 36px for the horizontal resolution .... this smells highly suspicious (because you're right on the rounding edge), but I've no idea why it would differ between Qt5 and gtk/kwin.

@Kai, any idea how this works under the hood?
Does Qt5 override the size by a "better" calculation?

I just turned off the "resolution independent" cursor size and set a fixed 48px, I never bothered actually looking into why it's broken.

Hello,
this bug also affects me on kwin 5.5.3.

Is any solution available? As a side not for me this bug has appeared as a regression when updating kubuntu 15.10 to the backports ppa with kwin 5.5.3.

I tried changing the mouse pointer theme and noticed something unusual: I provide this information just because it can be useful to spot the problem described by this bug. I know that what I describe here is broader then #348273 (and maybe off-topic here). Maybe deserves a new bug submission.

What I do:
1) I change the cursor theme (breeze/ice breeze)
2) I click apply
3) I can see the pointer theme change
4) I hover the mouse on the decoration

What I expect:
The mouse pointer should not change

What I get:
The mouse pointer becomes smaller (because of bug 348273) and (surprise) it gets rendered with the previously selected theme while hovering the window decorations.

5) I move the pointer outside the SystemSettings window and then hover it again on some windows decoration

What I expect:
 The same behavior as in 4)

What I get:
The mouse pointer is small but rendered with the correct theme while hovering the decorations.