After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765196 - X: mouse cursor isn't HiDPi during login animation & when hovering over the chrome
X: mouse cursor isn't HiDPi during login animation & when hovering over the c...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 769900 770343 778593 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-04-18 07:30 UTC by Ruud van Asseldonk
Modified: 2021-01-11 12:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sun icon fills the popup completely, previously it was about half or two thirds the size. (275.89 KB, image/png)
2016-04-18 07:35 UTC, Ruud van Asseldonk
  Details
Patch that fixes the bug for me (974 bytes, patch)
2016-05-28 18:41 UTC, Ruud van Asseldonk
none Details | Review

Description Ruud van Asseldonk 2016-04-18 07:30:30 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.
Comment 1 Ruud van Asseldonk 2016-04-18 07:35:49 UTC
Created attachment 326223 [details]
Sun icon fills the popup completely, previously it was about half or two thirds the size.
Comment 2 Ruud van Asseldonk 2016-04-18 07:37:14 UTC
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.
Comment 3 Rui Matos 2016-04-18 13:58:46 UTC
(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
Comment 4 Ruud van Asseldonk 2016-04-18 14:32:48 UTC
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.
Comment 5 Ruud van Asseldonk 2016-04-19 09:47:35 UTC
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.
Comment 6 Ruud van Asseldonk 2016-05-28 18:41:28 UTC
Created attachment 328672 [details] [review]
Patch that fixes the bug for me
Comment 7 Ruud van Asseldonk 2016-05-28 18:42:15 UTC
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?
Comment 8 Ruud van Asseldonk 2016-05-29 12:03:48 UTC
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.
Comment 9 Ruud van Asseldonk 2016-08-28 10:33:25 UTC
Triage: still an issue in 3.20.4.
Comment 10 Debarshi Ray 2016-08-29 08:57:07 UTC
*** Bug 770343 has been marked as a duplicate of this bug. ***
Comment 11 Debarshi Ray 2016-08-29 08:57:44 UTC
*** Bug 769900 has been marked as a duplicate of this bug. ***
Comment 12 Debarshi Ray 2016-08-29 09:00:21 UTC
(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.
Comment 13 Debarshi Ray 2016-08-29 09:02:06 UTC
Also note that this is specific to the X session. I haven't seen this happen with Wayland.
Comment 14 Debarshi Ray 2016-08-29 09:13:42 UTC
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.
Comment 15 Ruud van Asseldonk 2016-08-30 19:27:19 UTC
> 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.
Comment 16 Debarshi Ray 2017-02-14 09:29:43 UTC
*** Bug 778593 has been marked as a duplicate of this bug. ***
Comment 17 Mario Sánchez Prada 2017-09-29 13:43:01 UTC
(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
Comment 18 Florian Müllner 2017-09-29 15:36:44 UTC
(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.
Comment 19 Mario Sánchez Prada 2017-09-29 17:40:18 UTC
(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).
Comment 20 Mario Sánchez Prada 2017-10-06 17:54:20 UTC
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?
Comment 21 Bastien Nocera 2017-10-06 18:11:44 UTC
(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.
Comment 22 Mario Sánchez Prada 2017-10-11 10:38:27 UTC
URL to the other bug that Bastien mentioned (thanks for the link):
https://bugzilla.gnome.org/show_bug.cgi?id=688228
Comment 23 Bastien Nocera 2017-10-11 11:51:46 UTC
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
Comment 24 Tatsuyuki Ishi 2017-10-22 04:41:11 UTC
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.
Comment 25 André Klapper 2020-10-27 20:59:03 UTC
Is this still a problem in recent versions (preferably 3.38, or maybe 3.36)?
Comment 26 Mario Sánchez Prada 2020-10-28 09:56:49 UTC
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 :)
Comment 27 Ruud van Asseldonk 2020-10-28 20:02:29 UTC
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.
Comment 28 Debarshi Ray 2020-10-29 18:23:57 UTC
I can't reproduce this bug any more with gnome-shell-3.36.7.