| Summary: | Xwayland: Wrong overall screen size in some multi-monitor layouts | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Olivier Fourdan <fourdan> |
| Component: | XWayland | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED NOTABUG | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | jadahl |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
So, here's the deal, Xwayland recomputes the overall screen size in output_get_new_size() which is called from output_handle_done().
But when rearranging the monitor layout in GNOME, we get output_handle_geometry() and output_handle_mode() but no output_handle_done() so we don't recompute the size...
The protocol reads:
<event name="done" since="2">
<description summary="sent all information about output">
This event is sent after all other properties have been
sent after binding to the output object and after any
other property changes done after that. This allows
changes to the output properties to be seen as
atomic, even if they happen via multiple events.
</description>
</event>
So we should receive the output_handle_done(), if we don't, it could be a mutter bug instead.
(In reply to Olivier Fourdan from comment #1) > So, here's the deal, Xwayland recomputes the overall screen size in > output_get_new_size() which is called from output_handle_done(). > > But when rearranging the monitor layout in GNOME, we get > output_handle_geometry() and output_handle_mode() but no > output_handle_done() so we don't recompute the size... > > The protocol reads: > > <event name="done" since="2"> > <description summary="sent all information about output"> > This event is sent after all other properties have been > sent after binding to the output object and after any > other property changes done after that. This allows > changes to the output properties to be seen as > atomic, even if they happen via multiple events. > </description> > </event> > > So we should receive the output_handle_done(), if we don't, it could be a > mutter bug instead. This sounds like https://bugzilla.gnome.org/show_bug.cgi?id=766528 which was recently fixed. (In reply to Jonas Ådahl from comment #2) > This sounds like https://bugzilla.gnome.org/show_bug.cgi?id=766528 which was > recently fixed. Yeap, although it's not fixed yet as the patch hasn't landed afaics. Anyway, closing as "NOTOURBUG" as the problem lies in mutter instead, sorry for the noise ;-) (In reply to Olivier Fourdan from comment #3) > (In reply to Jonas Ådahl from comment #2) > > This sounds like https://bugzilla.gnome.org/show_bug.cgi?id=766528 which was > > recently fixed. > > Yeap, although it's not fixed yet as the patch hasn't landed afaics. Ah :P Well, hopefully they will soon (seems I forgot to review the new patch). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Apparently, Xwayland fails to compute the right overall desktop size in some case such as the following layout: +--------------------+ | | | | +-------------+ XWAYLAND1 | | | | | XWAYLAND0 | | | +--------------------+ | | +-------------+ Basically, the first monitor is not placed in (0,0) but at some position shifted down relative to the other monitor. In which case xrandr reports: Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192 XWAYLAND0 connected 1920x1080+0+381 310mm x 170mm 1920x1080 59.96*+ XWAYLAND1 connected 1920x1200+1920+0 520mm x 320mm 1920x1200 59.88*+ ie the overall screen height does not account for the actual location of the first monitor (in the xample abovem it should 381 + 1080 instead of 1200) That breaks XEvents for windows placed below y > 1200.