GNOME Bugzilla – Bug 755099
wayland: HiDPI cursor fixes when G-S-D X11 assumes HiDPI
Last modified: 2021-07-05 13:47:59 UTC
Attaching two patches to this bug. The first one I'd say is a bit hacky (somewhat a RFC), but the main issue is that we cannot use the same setting when running as an X11 CM as when we run as a Wayland compositor, mainly because the settings infrastructure we use ill premultiply the cursor theme size with a globally set scale used for HiDPI GTK+ X11 windows. The effect is, if we use this setting we'd multiply a pre-multiplied theme size and get double the cursor size as what is to be expected. Either we never scale such a cursor (i.e. any cursor set by the shell / WM), which would break the multi-DPI functionality, or we need to get the setting from another source (in the attached patch the gsetting value). I suppose an alternative approach to the patch would be to always use a non-pre-multiplied size for both Wayland and X11, and then do the multiplication elsewhere for X11. The other patch is also a bit hacky, mostly because we lack information needed to do anything properly with cursors from XWayland. In the future, to support scaling X11 windows, we'd need to add support for these things both in the client and in mutter, but the point of this patch is to simply let tiny cursor be tiny if we don't know that we can scale them up without breaking things.
Created attachment 311437 [details] [review] wayland: Don't pre-multiply root cursor sizes with global X11 monitor scale We cannot use the GTK+ setting for the cursor theme size because it will use the X11 method of drawing the cursor without the compositor knowing anything about it. We need to use the real non-pre-multiplied theme size, and then instead multiply with whatever scale should be used when we know what scale should be used.
Created attachment 311438 [details] [review] wayland: Don't scale XWayland pointer cursor sprites We don't have any way of knowing what the intended size of a XWayland cursor is supposed to be, so lets do what we do with regular XWayland surfaces and don't scale them. The result is that cursor sprites of HiDPI aware X11 clients will show correctly, but non-aware clients may have tiny cursor sprites.
Review of attachment 311437 [details] [review]: This one looks OK to me.
Review of attachment 311438 [details] [review]: While this one does not ... at least on its own. I don't like the idea of having tiny cursors in some applications and a proper one in others. We should probably change gnome-settings-daemon to not set the cursor xsetting when running with xwayland and simply assume that X cursors are unscaled.
(In reply to drago01 from comment #4) > Review of attachment 311438 [details] [review] [review]: > > While this one does not ... at least on its own. > I don't like the idea of having tiny cursors in some applications and a > proper one in others. > > We should probably change gnome-settings-daemon to not set the cursor > xsetting when running with xwayland and simply assume that X cursors are > unscaled. That'd mean Xwayland would give a wl_surface assigned a cursor role with a low-resolution cursor sprite. We'd then scale it up, result: HiDPI X11 cursors would look blurry.
(In reply to Jonas Ådahl from comment #5) > (In reply to drago01 from comment #4) > > Review of attachment 311438 [details] [review] [review] [review]: > > > > While this one does not ... at least on its own. > > I don't like the idea of having tiny cursors in some applications and a > > proper one in others. > > > > We should probably change gnome-settings-daemon to not set the cursor > > xsetting when running with xwayland and simply assume that X cursors are > > unscaled. > > That'd mean Xwayland would give a wl_surface assigned a cursor role with a > low-resolution cursor sprite. We'd then scale it up, result: HiDPI X11 > cursors would look blurry. Yeah that's true ... now the question is what's better a blurry cursor or a cursor that changes size based on which window it is on ... There is also another way ... we could toggle the x setting based on which monitor the cursor is on. Given that there is only one cursor that should work.
(In reply to drago01 from comment #6) > (In reply to Jonas Ådahl from comment #5) > > (In reply to drago01 from comment #4) > > > Review of attachment 311438 [details] [review] [review] [review] [review]: > > > > > > While this one does not ... at least on its own. > > > I don't like the idea of having tiny cursors in some applications and a > > > proper one in others. > > > > > > We should probably change gnome-settings-daemon to not set the cursor > > > xsetting when running with xwayland and simply assume that X cursors are > > > unscaled. > > > > That'd mean Xwayland would give a wl_surface assigned a cursor role with a > > low-resolution cursor sprite. We'd then scale it up, result: HiDPI X11 > > cursors would look blurry. > > Yeah that's true ... now the question is what's better a blurry cursor or a > cursor that changes size based on which window it is on ... Indeed. Does it work like that on X11 now already with both GTK+ and xterm etc (I have never tried on actual HiDPI hardware)? > > There is also another way ... we could toggle the x setting based on which > monitor the cursor is on. Given that there is only one cursor that should > work. I suppose if we move those settings from g-s-d we could update those properties in mutter as the cursor moves. Might discover new bugs here and there given we'd in these cases update the Xcursor.size and Gtk/CursorThemeSize properties a lot more often than before, but can see how it works.
Created attachment 311732 [details] HiDPI cursor on X11
(In reply to Jonas Ådahl from comment #7) > (In reply to drago01 from comment #6) > > (In reply to Jonas Ådahl from comment #5) > > > (In reply to drago01 from comment #4) > > > > Review of attachment 311438 [details] [review] [review] [review] [review] [review]: > > > > > > > > While this one does not ... at least on its own. > > > > I don't like the idea of having tiny cursors in some applications and a > > > > proper one in others. > > > > > > > > We should probably change gnome-settings-daemon to not set the cursor > > > > xsetting when running with xwayland and simply assume that X cursors are > > > > unscaled. > > > > > > That'd mean Xwayland would give a wl_surface assigned a cursor role with a > > > low-resolution cursor sprite. We'd then scale it up, result: HiDPI X11 > > > cursors would look blurry. > > > > Yeah that's true ... now the question is what's better a blurry cursor or a > > cursor that changes size based on which window it is on ... > > Indeed. Does it work like that on X11 now already with both GTK+ and xterm > etc (I have never tried on actual HiDPI hardware)? I didn't test it on wayland + xwayland yet but I have attached a video how it looks like on x11 currently i.e not blurry at all. > > > > There is also another way ... we could toggle the x setting based on which > > monitor the cursor is on. Given that there is only one cursor that should > > work. > > I suppose if we move those settings from g-s-d we could update those > properties in mutter as the cursor moves. Might discover new bugs here and > there given we'd in these cases update the Xcursor.size and > Gtk/CursorThemeSize properties a lot more often than before, but can see how > it works. Yeah this seems like the proper way to do it. Jasper doesn't like having xsettings in mutter at all but having gsd does it based on the cursor position doesn't seem right.
(In reply to drago01 from comment #9) > (In reply to Jonas Ådahl from comment #7) > > (In reply to drago01 from comment #6) > > > (In reply to Jonas Ådahl from comment #5) > > > > (In reply to drago01 from comment #4) > > > > > Review of attachment 311438 [details] [review] [review] [review] [review] [review] [review]: > > > > > > > > > > While this one does not ... at least on its own. > > > > > I don't like the idea of having tiny cursors in some applications and a > > > > > proper one in others. > > > > > > > > > > We should probably change gnome-settings-daemon to not set the cursor > > > > > xsetting when running with xwayland and simply assume that X cursors are > > > > > unscaled. > > > > > > > > That'd mean Xwayland would give a wl_surface assigned a cursor role with a > > > > low-resolution cursor sprite. We'd then scale it up, result: HiDPI X11 > > > > cursors would look blurry. > > > > > > Yeah that's true ... now the question is what's better a blurry cursor or a > > > cursor that changes size based on which window it is on ... > > > > Indeed. Does it work like that on X11 now already with both GTK+ and xterm > > etc (I have never tried on actual HiDPI hardware)? > > I didn't test it on wayland + xwayland yet but I have attached a video how > it looks like on x11 currently i.e not blurry at all. Thanks. I guess it comes from the Xcursor.size Xsetting then as well. > > > > > > > There is also another way ... we could toggle the x setting based on which > > > monitor the cursor is on. Given that there is only one cursor that should > > > work. > > > > I suppose if we move those settings from g-s-d we could update those > > properties in mutter as the cursor moves. Might discover new bugs here and > > there given we'd in these cases update the Xcursor.size and > > Gtk/CursorThemeSize properties a lot more often than before, but can see how > > it works. > > Yeah this seems like the proper way to do it. Jasper doesn't like having > xsettings in mutter at all but having gsd does it based on the cursor > position doesn't seem right. Yea, either we tell mutter to tell gsd to tell xsettings, or we let mutter tell xsettings directly. Going via gsd doesn't seem very useful.
(In reply to Jonas Ådahl from comment #7) > > There is also another way ... we could toggle the x setting based on which > > monitor the cursor is on. Given that there is only one cursor that should > > work. > > I suppose if we move those settings from g-s-d we could update those > properties in mutter as the cursor moves. Might discover new bugs here and > there given we'd in these cases update the Xcursor.size and > Gtk/CursorThemeSize properties a lot more often than before, but can see how > it works. I really see no reason to do this - it's going to all Xwayland apps that receive notifications about cursor themes (gtk2 apps, perhaps) to reload the cursor themes from disk when the cursor crosses monitors. Apps that don't receive notifications (any legacy apps that are getting themed cursors via libXcursor) will have their cursors stuck at the size from some arbitrary size. [Actually, on my system, legacy apps don't seem to be getting scaled cursors - it seems like the code in GSD to set X resources isn't running at all.] The thing to remember is that we can *scale down* cursors perfectly well. * Simplest course: assume that all X cursors reflect the Xsetting set by GSD, scale them up or down as needed for non-primary monitors. * Complication: detect *based on the actual size of the cursors* whether they are hi-dpi or not. A themed cursor should be fairly close to the nominal theme size - something that deviates significantly is probably either a) a bitmap cursor not in the cursor theme loaded by some ancient X app b) a themed cursor loaded by an app not receiving notifications before a change to the screen configuration. * GSD change: make it ask for hi-dpi sized cursors if any monitor is hi-dpi rather than basing it off the primary monitor.
Forgot to comment on the bug after the IRC conversation yesterday. (In reply to Owen Taylor from comment #11) > (In reply to Jonas Ådahl from comment #7) > > > There is also another way ... we could toggle the x setting based on which > > > monitor the cursor is on. Given that there is only one cursor that should > > > work. > > > > I suppose if we move those settings from g-s-d we could update those > > properties in mutter as the cursor moves. Might discover new bugs here and > > there given we'd in these cases update the Xcursor.size and > > Gtk/CursorThemeSize properties a lot more often than before, but can see how > > it works. > > I really see no reason to do this - it's going to all Xwayland apps that > receive notifications about cursor themes (gtk2 apps, perhaps) to reload the > cursor themes from disk when the cursor crosses monitors. > > Apps that don't receive notifications (any legacy apps that are getting > themed cursors via libXcursor) will have their cursors stuck at the size > from some arbitrary size. [Actually, on my system, legacy apps don't seem to > be getting scaled cursors - it seems like the code in GSD to set X resources > isn't running at all.] Just for the record we call XcursorSetDefaultSize at statup and in response to changes to the XSetting. So as long as the (legacy) app does not mess with the cursor it should get the correct size. > The thing to remember is that we can *scale down* cursors perfectly well. > > * Simplest course: assume that all X cursors reflect the Xsetting set by > GSD, scale them up or down as needed for non-primary monitors. > > * Complication: detect *based on the actual size of the cursors* whether > they are hi-dpi or not. A themed cursor should be fairly close to the > nominal theme size - something that deviates significantly is probably > either a) a bitmap cursor not in the cursor theme loaded by some ancient X > app b) a themed cursor loaded by an app not receiving notifications before a > change to the screen configuration. > > * GSD change: make it ask for hi-dpi sized cursors if any monitor is hi-dpi > rather than basing it off the primary monitor. The idea of scaling down the cursor for non HiDPI monitors sounds good to me. Its the less complicated one and the end result shouldn't be worse then when running under X11 (i.e no blurry cursors and no tiny cursor for some apps).
(In reply to drago01 from comment #12) > Forgot to comment on the bug after the IRC conversation yesterday. > > (In reply to Owen Taylor from comment #11) > > (In reply to Jonas Ådahl from comment #7) > > > > There is also another way ... we could toggle the x setting based on which > > > > monitor the cursor is on. Given that there is only one cursor that should > > > > work. > > > > > > I suppose if we move those settings from g-s-d we could update those > > > properties in mutter as the cursor moves. Might discover new bugs here and > > > there given we'd in these cases update the Xcursor.size and > > > Gtk/CursorThemeSize properties a lot more often than before, but can see how > > > it works. > > > > I really see no reason to do this - it's going to all Xwayland apps that > > receive notifications about cursor themes (gtk2 apps, perhaps) to reload the > > cursor themes from disk when the cursor crosses monitors. Yea, had some discussions about making the settings more locally scoped (per window) but nothing felt right. > > > > Apps that don't receive notifications (any legacy apps that are getting > > themed cursors via libXcursor) will have their cursors stuck at the size > > from some arbitrary size. [Actually, on my system, legacy apps don't seem to > > be getting scaled cursors - it seems like the code in GSD to set X resources > > isn't running at all.] > > Just for the record we call XcursorSetDefaultSize at statup and in response > to changes to the XSetting. So as long as the (legacy) app does not mess > with the cursor it should get the correct size. > > > The thing to remember is that we can *scale down* cursors perfectly well. This is not really true. A scaled down cursor will be more blurry than a one drawn in the exact same scale. But of course it will be less noticeable compared to scaling up. I guess it might look good enough. > > > > * Simplest course: assume that all X cursors reflect the Xsetting set by > > GSD, scale them up or down as needed for non-primary monitors. > > > > * Complication: detect *based on the actual size of the cursors* whether > > they are hi-dpi or not. A themed cursor should be fairly close to the > > nominal theme size - something that deviates significantly is probably > > either a) a bitmap cursor not in the cursor theme loaded by some ancient X > > app b) a themed cursor loaded by an app not receiving notifications before a > > change to the screen configuration. How well does QT clients deal with the Xsetting? > > > > * GSD change: make it ask for hi-dpi sized cursors if any monitor is hi-dpi > > rather than basing it off the primary monitor. Seems like a decent solution, given that most X11 clients tend to get the cursor scale right given what GSD sets Xsettings to. > > The idea of scaling down the cursor for non HiDPI monitors sounds good to > me. Its the less complicated one and the end result shouldn't be worse then > when running under X11 (i.e no blurry cursors and no tiny cursor for some > apps). Yes, I will look into implementing this.
Review of attachment 311438 [details] [review]: This makes cursors behave the same way as X11 clients themselves - they scale only to the extent that they listen to xsettings and pick up the hi-dpi and compatibility gymnastics of gnome-settings-daemon. If we eventually get to the point where we are scaling Xwayland clients themselves, then it would be consistent to take Adel's approach and just make X11 clients always have fuzzy cursors on hi-dpi, but this seems fine for now - especially as something to land for 3.18.x.
Review of attachment 311437 [details] [review]: Subject: We cannot use the GTK+ setting for the cursor theme size because it will use the X11 method of drawing the cursor without the compositor knowing anything about it. doesn't parse for me - I don't understand what you are trying to say. We cannot use the XSETTINGS value for cursor theme size because gnome-settings-daemon already multiplies it by the primary monitor's scale. ? Beyond that, I think this patch needs some major bold comments added that cursor_size *includes* the scaling factor on X11, but doesn't on Wayland. (It would be considerably cleaner to consistently use the GSettings and on X11 make the 'theme_scale' track the window scaling factor, but practically would come to the same thing, and tracking the window scaling factor dynamically isn't that easy, so this seems OK.)
(In reply to Owen Taylor from comment #15) > Review of attachment 311437 [details] [review] [review]: > > Subject: > > We cannot use the GTK+ setting for the cursor theme size because it > will use the X11 method of drawing the cursor without the compositor > knowing anything about it. > > doesn't parse for me - I don't understand what you are trying to say. What I mean is that, since on X11 we'd use one global theme size which is controlled via xsetting we cannot use it on Wayland because there the compositor will deal with the scaling. > > We cannot use the XSETTINGS value for cursor theme size because > gnome-settings-daemon already multiplies it by the primary monitor's > scale. > > ? Beyond that, I think this patch needs some major bold comments added > that cursor_size *includes* the scaling factor on X11, but doesn't on > Wayland. > > (It would be considerably cleaner to consistently use the GSettings and on > X11 > make the 'theme_scale' track the window scaling factor, but practically > would come > to the same thing, and tracking the window scaling factor dynamically isn't > that > easy, so this seems OK.) Yes, I agree. Would it be fine to change to always using the gsetting in 3.18.1 already? The reason for the "hack" was to not change any semantics when running on X11. AFAIK what we'd need to do is to start tracking "Gdk/WindowScalingFactor" and then multiply that with the cursor size gsetting in display.c and meta-cursor.c (or prefs.c).
(In reply to Jonas Ådahl from comment #16) > (In reply to Owen Taylor from comment #15) > > Review of attachment 311437 [details] [review] [review] [review]: > > > > Subject: > > > > We cannot use the GTK+ setting for the cursor theme size because it > > will use the X11 method of drawing the cursor without the compositor > > knowing anything about it. > > > > doesn't parse for me - I don't understand what you are trying to say. > > What I mean is that, since on X11 we'd use one global theme size which is > controlled via xsetting we cannot use it on Wayland because there the > compositor will deal with the scaling. OK - that makes sense, but the original sentence still doesn't to me :-) > > We cannot use the XSETTINGS value for cursor theme size because > > gnome-settings-daemon already multiplies it by the primary monitor's > > scale. > > > > ? Beyond that, I think this patch needs some major bold comments added > > that cursor_size *includes* the scaling factor on X11, but doesn't on > > Wayland. > > > > (It would be considerably cleaner to consistently use the GSettings and on > > X11 > > make the 'theme_scale' track the window scaling factor, but practically > > would come > > to the same thing, and tracking the window scaling factor dynamically isn't > > that > > easy, so this seems OK.) > > Yes, I agree. Would it be fine to change to always using the gsetting in > 3.18.1 already? The reason for the "hack" was to not change any semantics > when running on X11. AFAIK what we'd need to do is to start tracking > "Gdk/WindowScalingFactor" and then multiply that with the cursor size > gsetting in display.c and meta-cursor.c (or prefs.c). If there was a clean patch, I'd be OK with that. I think to track Gdk/WindowScalingFactor you need to A) connect to GdkScreen::monitors-changed B) In the callback call gdk_x11_screen_get_monitor_scale_factor() (on an arbitrary monitor) It's not propagated as a GtkSetting
Created attachment 312545 [details] [review] wayland: Don't pre-multiply root cursor sizes with primary monitor scale We cannot use the XSETTINGS value for cursor theme size because gnome-settings-daemon already multiplies it by the primary monitor's scale.
(In reply to Owen Taylor from comment #17) > (In reply to Jonas Ådahl from comment #16) > If there was a clean patch, I'd be OK with that. I think to track > Gdk/WindowScalingFactor you need to > > A) connect to GdkScreen::monitors-changed > B) In the callback call gdk_x11_screen_get_monitor_scale_factor() (on an > arbitrary monitor) > > It's not propagated as a GtkSetting Won't be that easy. We override the monitor scale in meta_ui_init() which causes us to not receive any updates. We'd have to manually start listening for gtksettings. I updated the patch changing and adding documentation, in case we wan't to go with that for 3.18. Then we can replace the split of cursor size retrieval adding gtksetting reading support in prefs.c later if preferred.
Review of attachment 312545 [details] [review]: Let's go with this. I don't think adding a copy of xsettings-client.c into Mutter just to clean things up a bit makes sense.
Attachment 311438 [details] pushed as e84f694 - wayland: Don't scale XWayland pointer cursor sprites Attachment 312545 [details] pushed as 130807a - wayland: Don't pre-multiply root cursor sizes with primary monitor scale
*** Bug 756517 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.