| Summary: | Xwayland: doesn't remove RandR output on Wayland server Output removal | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Martin Flöser <mgraesslin> |
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Yeap. makes sense, I think we'd need to do the same as with bug 92273. update_desktop_dimensions() gets called from output_handle_done() which is by definition called each time an output gets changed/added/removed so we're safe with this. This event is sent after all other properties has 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. Beside, we can tell update_desktop_dimensions() is updated because "xwininfo -root" shows the right size after the output removal, so it's really just an xrandr problem. output_handle_done() is NOT called on remove. Remove is only announced through the removal of the global object on the wl_registry. (In reply to Martin Gräßlin from comment #3) > output_handle_done() is NOT called on remove. Remove is only announced > through the removal of the global object on the wl_registry. It is on weston apparently but not on gnome-shell so we cannot rely on that indeed. > It is on weston apparently but not on gnome-shell so we cannot rely on that indeed.
Neither in KWin. From my understanding of reading the Wayland protocol there is nothing which would indicate that the server should send a done when removing an output.
(In reply to Martin Gräßlin from comment #5) > Neither in KWin. From my understanding of reading the Wayland protocol there > is nothing which would indicate that the server should send a done when > removing an output. True, it depends on the actual layout and which output is being removed, I reckon. So we need to do update_desktop_dimensions() in both handlers, destroy and done. We also need to either destroy the RROutput or mark it as disconnected, I'm not sure what's best there. And at last, I noticed Xwayland would segfault on exit if an output was removed, so there is something dodgy there as well. > And at last, I noticed Xwayland would segfault on exit if an output was removed, so there is something dodgy there as well.
Yeah I can confirm that. I noticed that one as well, but as I don't have debug packages, I was not able to create a backtrace.
Patch sent to xorg-devel list. The memory corruption is being tracked in bug 93045 and a patch has also been sent to xorg-devel for review. Patch pushed in git master as commit ab9837c, closing. |
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.
When the Wayland compositor removes a global wl_output_interface the corresponding XRandR output is not removed, resulting in incorrect data. Steps to reproduce: 1. Start a Wayland compositor with Xwayland support (e.g. weston or KWin) 2. Plug in a second output 3. run xrandr to verify there are two outputs listed 4. unplug second output 5. run xrandr again Expected result: Only one output is shown Actual result: Both outputs from step 3 are still shown I verified this behavior with both KWin (as of git master, that is 5.5 alpha) and weston (version 1.9) against Xwayland from 1.18 release. Looking through the code this seems to be caused by: void xwl_output_destroy(struct xwl_output *xwl_output) { wl_output_destroy(xwl_output->output); xorg_list_del(&xwl_output->link); free(xwl_output); } which frees the xwl_output, but does not free the member xwl_output->randr_crtc and xwl_output->randr_output and also doesn't call update_desktop_dimensions()