[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg-devel
Subject:    Re: Xwayland fatal error when Wayland output disappears
From:       Pekka Paalanen <ppaalanen () gmail ! com>
Date:       2017-11-27 10:04:18
Message-ID: 20171127120418.2670ac9f () eldfell
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Mon, 27 Nov 2017 10:27:29 +0100
Olivier Fourdan <fourdan@gmail.com> wrote:

> Hi,
> 
> On 23 November 2017 at 16:13, Olivier Fourdan <fourdan@gmail.com> wrote:
> 
> > FWIW, it seems we have that issue with more than just wl_output, in
> > downstream bug 1516859 [1] this occurs with wl_seat on VT switch as well.
> >
> > That's pretty easy to reproduce, issue several VT switches back and forth
> > (I use "chvt" from a remote connection) until the race occurs, here it
> > doesn't take long.
> >
> > Cheers,
> > Olivier
> >
> > [1]   https://bugzilla.redhat.com/show_bug.cgi?id=1516859
> >  
> 
> 
> So, to be clear, the race here is between wl_seat capabilities and
> wl_pointer.
> 
> On VT switch, the compositor notifies the clients of the changes in wl_seat
> capabilities, Xwayland creates and releases the pointer based on these
> capabilities, and when switching quickly between VTs, by the time the
> get_pointer() is processed by the compositor, the pointer has been released
> from a previous capability change.

Hi,

this is a different race from the globals coming and going. It seems a
compositor workaround is in order:

https://cgit.freedesktop.org/wayland/weston/tree/libweston/input.c?id=3.0.0#n2342

The compositor can hand out a "dummy" wl_pointer/wl_keyboard/wl_touch.
The client will see the capability removal later and destroy it again.


Thanks,
pq

[Attachment #5 (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[prev in list] [next in list] [prev in thread] [next in thread]