Bug 92914 - Xwayland: doesn't remove RandR output on Wayland server Output removal
Summary: Xwayland: doesn't remove RandR output on Wayland server Output removal
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-12 10:12 UTC by Martin Flöser
Modified: 2015-12-02 07:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Flöser 2015-11-12 10:12:28 UTC
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()
Comment 1 Olivier Fourdan 2015-11-13 07:16:03 UTC
Yeap. makes sense, I think we'd need to do the same as with bug 92273.
Comment 2 Olivier Fourdan 2015-11-13 09:16:36 UTC
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.
Comment 3 Martin Flöser 2015-11-13 09:19:28 UTC
output_handle_done() is NOT called on remove. Remove is only announced through the removal of the global object on the wl_registry.
Comment 4 Olivier Fourdan 2015-11-13 10:50:27 UTC
(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.
Comment 5 Martin Flöser 2015-11-13 10:56:52 UTC
> 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.
Comment 6 Olivier Fourdan 2015-11-13 11:43:50 UTC
(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.
Comment 7 Martin Flöser 2015-11-13 12:26:58 UTC
> 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.
Comment 8 Olivier Fourdan 2015-11-23 10:00:29 UTC
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.
Comment 9 Olivier Fourdan 2015-12-02 07:38:32 UTC
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.