GNOME Bugzilla – Bug 765196
X: mouse cursor isn't HiDPi during login animation & when hovering over the chrome
Last modified: 2021-01-11 12:27:06 UTC
There have been a few HiDPi regressions in Gnome 3.20. * When I change the brightness of the screen, or the volume, the popup/overlay that appears has a huge icon. It looks about twice as big as it was previously, and there is almost no padding around it. It looks like the size of the popup is correct, only the icon is too big. See attached screenshot. * During the login animation where the screen zooms and fades in, the cursor is half the size. (So it has its regular low-DPI size.) In some cases it could shrink too when I was using the activities menu, but I cannot reproduce that reliably. It might be that 3.20.1 fixed it. I can reproduce the issue during login reliably. I am using auto-login, so there is no user/password prompt after boot. Affected versions of gnome-shell are 3.20 and 3.20.1. In 3.18.4 this did work properly.
Created attachment 326223 [details] Sun icon fills the popup completely, previously it was about half or two thirds the size.
The cursor size issue is still here in 3.20.1, it happens sometimes when I hover over the icons in the dock in the activities menu, but I cannot reproduce it reliably.
(In reply to Ruud van Asseldonk from comment #0) > Affected versions of gnome-shell are 3.20 and 3.20.1. In 3.18.4 this did > work properly. Is that for both issues or just for the cursor. There's a report for the brightness icon already but that seems to have been broken since 3.16 (bug 748925). In any case, let's try to keep one issue per bug report so let's make this one about the cursor since the icon is already reported. Feel free to edit the bug title to better describe the cursor issue if I got it wrong
Both issues (cursor and icon) only started happening after I upgraded to 3.20. The screenshot in bug 748925 looks exactly like mine so I’ll continue the discussion there, then this bug is about the cursor.
Note: this only happens to the pointer cursor. When this happens in the activities menu, the cursor has the correct size on the desktop, but it shrinks when I hover over “activities” in the top left corner. When I press the super key to open the activities menu, the cursor is small everywhere when the activities menu is open. When I press super again to close the activities menu, the cursor becomes normal again on the desktop. If I open the activities menu again, the cursor is small again. Etc. If the pointer changes to a different cursor, like the I-beam when I hover over the search field, or an hourglass when I open an application, then afterwards the pointer cursor is displayed correctly, even in the activities menu.
Created attachment 328672 [details] [review] Patch that fixes the bug for me
I find this issue annoying, so I decided to investigate. I bisected with the following results: First bad commit: gnome-shell: b8e29ae8c78658917c8a8ddd391667d7d9e36971 gnome-session: 95cc97920b5701563921d61d9ce2fd90b9b887c6 Last good commit: gnome-shell: cdba8e5cea313f43d479982ce9ec8bbb8c87281c (parent of bad) gnome-session: 1526e965f68fe8e644b85be5f8e068a6818a4c13 (parent of bad) The changes to gnome-session aren't related, but the versions are incompatible due to a rename. One thing in the offending commit that looks suspicious is the change to X-GNOME-Autostart-Phase, so I tried reverting that change (see attached patch), and this resolved the bug for me. It actually resolves both issues that I reported initially (the mouse cursor size, and the size of the icons for the media key overlays). While my patch does fix the issue for me, I have a feeling that the offending commit isn't the real problem, it merely exposed a bug that existed elsewhere. The issue with the overlay icons was reported before, but it did not affect me before the offending commit. Can somebody who is more familiar with the gnome-shell internals please take a look at this? I hope this new information can help identify the real problem. CC Ray Strode, as the author of the commit that exposed the issue, do you have an idea where to look?
Another thing that triggers this bug: when I plug in headphones, a dialog shows up to pick which device I plugged in. When that happens, in a flash all UI elements look too big (I think that for a moment they have 4x magnification instead of 2x). Things return to normal within a second, except that after this dialog is shown, the cursor is again too small when it hovers over the top bar and in the activities menu. This is not resolved by my patch. I don't remember if this was present in 3.18. If I recall correctly, 3.18 didn't show a dialog at all when I plugged in headphones.
Triage: still an issue in 3.20.4.
*** Bug 770343 has been marked as a duplicate of this bug. ***
*** Bug 769900 has been marked as a duplicate of this bug. ***
(In reply to Ruud van Asseldonk from comment #0) > In some cases > it could shrink too when I was using the activities menu, but I cannot > reproduce that reliably. It might be that 3.20.1 fixed it. I can reproduce > the issue during login reliably. I am using auto-login, so there is no > user/password prompt after boot. Yes, it is also unscaled when hovering over the gnome-shell chrome, but it gets fixed once you start an application.
Also note that this is specific to the X session. I haven't seen this happen with Wayland.
Review of attachment 328672 [details] [review]: I am not a gnome-shell reviewer. ::: data/org.gnome.Shell.desktop.in.in @@ +11,3 @@ OnlyShowIn=GNOME; NoDisplay=true +X-GNOME-Autostart-Phase=WindowManager We can't just do this because it breaks the Wayland session. Specifically, the gnome-shell chrome doesn't get scaled even though the mouse cursor is fine.
> We can't just do this because it breaks the Wayland session. That’s a pity. For my setup I haven’t found any bad side effects, but I am not using Wayland yet, so that makes sense. Perhaps the underlying issue is the same one that causes #748925, but I am not familiar with the gnome-shell codebase and I have no clue where to look to further diagnose the true cause.
*** Bug 778593 has been marked as a duplicate of this bug. ***
(In reply to Debarshi Ray from comment #14) > Review of attachment 328672 [details] [review] [review]: > > I am not a gnome-shell reviewer. > > ::: data/org.gnome.Shell.desktop.in.in > @@ +11,3 @@ > OnlyShowIn=GNOME; > NoDisplay=true > +X-GNOME-Autostart-Phase=WindowManager > > We can't just do this because it breaks the Wayland session. Specifically, > the gnome-shell chrome doesn't get scaled even though the mouse cursor is > fine. I see that gnome-shell now defines this: X-GNOME-Autostart-Phase=DisplayServer ...which if I'm reading the docs correctly means that it runs even in an earlier stage than when this bug was reported (if there was no X-GNOME-Autostart-Phase key, that meant the "Applications" phase, right?), so I wonder if setting "WindowManager" (which runs at a later stage than "DisplayServer" but still before "Applications") now would still be an issue for Wayland? I've read a bit the docs I could find [1][2][3] but I could not really understand what "DisplayServer" is exactly for, but from the code it looks related to Wayland somehow, so perhaps changing to "WindowManager" will still be an issue? The reason I ask this is two-fold: * I can reproduce the very same issue with the cursor being initially too small in gnome-shell 3.24, and would be nice to get it fixed. * I don't use Wayland yet (nor does Endless OS, which is my main use case) and I don't really understand these interactions with gnome-session, so any help welcome Comments? [1] https://wiki.gnome.org/Projects/SessionManagement/GnomeSession [2] https://wiki.gnome.org/Projects/SessionManagement/NewGnomeSession [3] https://git.gnome.org/browse/gnome-session/tree/gnome-session/README
(In reply to Mario Sánchez Prada from comment #17) > I see that gnome-shell now defines this: > > X-GNOME-Autostart-Phase=DisplayServer > > ...which if I'm reading the docs correctly means that it runs even in an > earlier stage than when this bug was reported (if there was no > X-GNOME-Autostart-Phase key, that meant the "Applications" phase, right?) No, this bug was reported after the key was changed from "WindowManager" to "DisplayServer". At the core, the issue is that gnome-shell can run either as wayland display server, or as X11 window manager. In the former case, it needs to be started before components that require the display server to be running (for example gnome-settings-daemon), in the latter it needs to run after gnome-settings-daemon.
(In reply to Florian Müllner from comment #18) > (In reply to Mario Sánchez Prada from comment #17) > > I see that gnome-shell now defines this: > > > > X-GNOME-Autostart-Phase=DisplayServer > > > > ...which if I'm reading the docs correctly means that it runs even in an > > earlier stage than when this bug was reported (if there was no > > X-GNOME-Autostart-Phase key, that meant the "Applications" phase, right?) > > No, this bug was reported after the key was changed from "WindowManager" to > "DisplayServer". Oops! Somehow I misread the patch and thought it was *adding* a ` X-GNOME-Autostart-Phase` key to the desktop file, not replacing an already existing one. Sorry about the confusion. > At the core, the issue is that gnome-shell can run either as wayland display > server, or as X11 window manager. In the former case, it needs to be started > before components that require the display server to be running (for example > gnome-settings-daemon), in the latter it needs to run after > gnome-settings-daemon. Thanks for the clarification. I think I'd need to spend some time checking the relevant code in g-s-d and how it interacts with the shell to better understand what the right fix here would be, that would solve the issue regardless of whether we're using X11 or Wayland. From your comment, it sounds to me like it could be a matter of hooking into some signal somewhere, or doing some extra checks when starting the shell, g-s-d or both (but I might be wrong).
FWIW, this fix seems to have the unwanted opposite effect of showing the cursor way too big when logging in when running a non-HighDPI resolution on a HighDPI display. At this point, I'm not sure what the right fix would be. Perhaps we need indeed to hook into some signal somewhere on startup, as I mentioned in my previous comment, but I'm not clear on what that signal/hook would be. Any ideas?
(In reply to Mario Sánchez Prada from comment #20) > FWIW, this fix seems to have the unwanted opposite effect of showing the > cursor way too big when logging in when running a non-HighDPI resolution on > a HighDPI display. > > At this point, I'm not sure what the right fix would be. Perhaps we need > indeed to hook into some signal somewhere on startup, as I mentioned in my > previous comment, but I'm not clear on what that signal/hook would be. > > Any ideas? Hiding the cursor until the compositor has completely started. Pretty sure I have another bug dating back years where I discussed this with Owen, when Wayland was just a glimmer in krh's eyes.
URL to the other bug that Bastien mentioned (thanks for the link): https://bugzilla.gnome.org/show_bug.cgi?id=688228
The functionality was implemented in gnome-settings-daemon's cursor plugin: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/cursor?h=gnome-3-14
The behaviour seems to be regressed in 3.26 and it's also affecting autostart now. My Telegram desktop (which is Qt and uses font DPI for scaling) is started with small text.
Is this still a problem in recent versions (preferably 3.38, or maybe 3.36)?
Unfortunately(*), I no longer have access to a High DPI display, so I can't really tell. Maybe Tatsuyuki or someone else could check? -- (*) ...or "fortunately", because I don't really like High DPI displays anyway :)
The wrongly sized icon when changing volume has been fixed, and the cursor on the login screen has been fixed as well, at least under Wayland in Gnome 3.38. I do get a half-size cursor when using Celluloid, but that could be a Celluloid bug rather than a Gnome bug.
I can't reproduce this bug any more with gnome-shell-3.36.7.