[Wayland-bugs] [Bug 744932] Wrong (ultra tiny/small) cursor size on HiDPI screen

[mutter (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=744932

--- Comment #41 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Jasper St. Pierre from comment #40)
> I consider nested X11 a developer tool only, so we haven't given it the real
> attention and split it out to a "true" backend. Things like barriers and
> input settings really shouldn't be running as nested X11 either.
> 

Yea, with the backends/x11/(nested|cm) I only mean to move out Dummy things out
of the way, and the is_wayland_compositor/X11_MODE as below to be in their
files. Anyhow it's the least important of the abstractions here, since it isn't
all that bad.

> Note that I already have an enum here for what you call "running mode" to
> cut down on the "meta_is_wayland_compositor" in the backend code.
> 
> https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-backend-x11.
> c#n49

What I mean when I say running mode is not really related to backends.

> 
> But personally, I don't care enough about the nested code -- it's not
> production, it's development and testing only, and as long as it's not too
> messy, let's not overcomplicate things. I'm fine with having nested not use
> a X11 cursor and instead always draw it ourselves, for instance. It's why we
> call XFixesHideCursor even in nested mode. If you don't like that you don't
> have a cursor sometimes, move your mouse back over the nested window enough
> that it shows again, and then alt-tab to another window.

I have patches for that (lost cursor issue), but they depend on these patches
so I haven't pushed them yet.

> 
> If you feel really encouraged to fix this, feel free, but I've just not
> bothered.

That is what these patches tries to do, or at least now we are discussing how
to do it better. A MetaCursorSprite behaves differently depending on whether we
are a CM or a DS, and there is logic related to the client type.

Owen was not particularly fond of me putting so much things that are just
related to being a DS (being able to scale, load different theme sizes; things
irrelevant for a CM) inside a protocols/wayland abstraction and that is why
I've been suggesting another abstraction layer, i.e. the "running mode", and
putting those parts there, and then the Wayland related parts elsewhere.

There are probably other things that could end up behind such an abstraction,
for example some code that is behind (!)meta_is_wayland_compositor in
compositor.c, display.c, screen.c etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150702/6f635ff6/attachment-0001.html>