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 744933 - Wrong input region on wayland in HiDPI
Wrong input region on wayland in HiDPI
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-22 07:41 UTC by Giovanni Campagna
Modified: 2015-03-03 20:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: Make the surface actor set its own state (9.41 KB, patch)
2015-03-03 04:09 UTC, Jonas Ådahl
accepted-commit_now Details | Review
wayland: Fix surface damage region scales (2.84 KB, patch)
2015-03-03 04:09 UTC, Jonas Ådahl
accepted-commit_now Details | Review
wayland: Sync surface actor state when changing main monitor (7.54 KB, patch)
2015-03-03 04:09 UTC, Jonas Ådahl
accepted-commit_now Details | Review

Description Giovanni Campagna 2015-02-22 07:41:36 UTC
Testing gnome-control-center 3.15.90 in wayland on a HiDPI screen, I found that for some reason it reports an invalid input region, meaning that only the upper left half of the window can be interacted with and will be repainted.

Interestingly, only this portion of the window is repainted correctly, the rest has the grey GDK background, but clicking on any panel gets the previous content in place of the non updated areas.

This does not happen in any other app. It does not happen in Xwayland either (although there are other glitches there)
Comment 1 Giovanni Campagna 2015-02-22 08:09:18 UTC
I rectify: this happens in geary too.
Reassigning to gtk+.
Comment 2 Jonas Ådahl 2015-02-25 03:23:36 UTC
Seems to work fine in weston and according to WAYLAND_DEBUG it sets correct input regions (although multiple times before a commit which is harmless only a bit unnecessary).

It rather seems to be an issue with mutter which doesn't handle region scaling properly, so this bug should probably be moved there (but I can't do that).
Comment 3 Matthias Clasen 2015-02-25 14:20:17 UTC
thanks, moving it over then
Comment 4 drago01 2015-02-28 09:41:46 UTC
We scale the input region by output_scale / buffer_scale ... so if you have buffer_scale of 1 and output scale of 2 it gets scaled up by 2.

If the app sets buffer scale to 2 it gets scaled by 1 (i.e not at all) because the app is supposed to be rendering at the correct resolution.

Also is it really "the upper half" or the the "upper left quarter" ?

We always scale the opaque region by the buffer scale which looks wrong ... unfortunately can't test it right now does something like this work? :

diff --git a/src/wayland/meta-wayland-surface.c b/src/wayland/meta-wayland-surface.c
index b1364e8..76c1fc1 100644
--- a/src/wayland/meta-wayland-surface.c
+++ b/src/wayland/meta-wayland-surface.c
@@ -426,7 +426,8 @@ commit_pending_state (MetaWaylandSurface      *surface,
 
   if (pending->opaque_region)
     {
-      pending->opaque_region = scale_region (pending->opaque_region, surface->scale);
+      pending->opaque_region = scale_region (pending->opaque_region,
+                                             meta_surface_actor_wayland_get_scale (META_SURFACE_ACTOR_WAYLAND (surface->surface_actor)));
       meta_surface_actor_set_opaque_region (surface->surface_actor, pending->opaque_region);
     }
   if (pending->input_region)
Comment 5 Jonas Ådahl 2015-02-28 10:27:43 UTC
Its not. That scale might change without the client changing any of its surface state. I have some code that reworks how thatvis handled some. I'll post a patch next week.
Comment 6 Jonas Ådahl 2015-03-03 04:09:00 UTC
Created attachment 298365 [details] [review]
wayland: Make the surface actor set its own state

Since the surface actor knows more about how it draws itself, instead of
pushing texture state (buffer and scale), input region and opaque region
from MetaWaylandSurface after having transformed into what the surface
actor expects, make the surface actor set its own state given what state
the Wayland surface is in.
Comment 7 Jonas Ådahl 2015-03-03 04:09:06 UTC
Created attachment 298366 [details] [review]
wayland: Fix surface damage region scales

Use the correct scale when processing damage from the client.
Comment 8 Jonas Ådahl 2015-03-03 04:09:11 UTC
Created attachment 298367 [details] [review]
wayland: Sync surface actor state when changing main monitor

In order to switch to the correct surface actor scale given the monitor
the surface is on, without relying on the client committing a new state
given some other side effect, sync the surface actor state when the main
monitor associated with the corresponding window changed.
Comment 9 drago01 2015-03-03 09:58:03 UTC
Review of attachment 298365 [details] [review]:

Makes sense.
Comment 10 drago01 2015-03-03 09:58:45 UTC
Review of attachment 298366 [details] [review]:

LG.
Comment 11 drago01 2015-03-03 10:01:20 UTC
Review of attachment 298367 [details] [review]:

OK.
Comment 12 Ray Strode [halfline] 2015-03-03 20:03:45 UTC
(pushing now so this stuff makes it into tonight's release)

Attachment 298365 [details] pushed as bbcee17 - wayland: Make the surface actor set its own state
Attachment 298366 [details] pushed as adf7c0e - wayland: Fix surface damage region scales
Attachment 298367 [details] pushed as fffb863 - wayland: Sync surface actor state when changing main monitor