Javier complained the other day, that Weston freezes on starting any X11 app via Xwayland. I can't recall the details. The Weston log was very interesting, though: it showed that as soon as XWM initializes, Weston thinks it's leaving the VT. Looking at the code, I'm surprised it hasn't blown up for anyone else yet. Weston routinely uses SIGUSR1 for VT-switching signalling. Weston-launch watches SIGUSR1, that is not a problem. However, when Weston is started without weston-launch, Weston itself may be watching for SIGUSR1: - src/launcher-util.c (Weston as root, without logind?) - src/logind-util.c (non-root with logind support?) Those two seem mutually exclusive, but there is a third one: - xwayland/launcher.c (for Xwayland server start-up notification) I guess what happens in Javier's case, is that when Xwayland server starts, it sends SIGUSR1 to Weston, which then runs all SIGUSR1 handlers in some arbitary order: VT switch and XWM init. This leads to Weston thinking it's no longer current, likely refusing all input, and you have a frozen VT. Seems like something should be moved to another signal number. (And why does logind-util.c call signalfd() manually instead of wl_event_loop_add_signal()?)
(In reply to Pekka Paalanen from comment #0) > Javier complained the other day, that Weston freezes on starting any X11 app > via Xwayland. I can't recall the details. The Weston log was very > interesting, though: it showed that as soon as XWM initializes, Weston > thinks it's leaving the VT. > > Looking at the code, I'm surprised it hasn't blown up for anyone else yet. > > Weston routinely uses SIGUSR1 for VT-switching signalling. Weston-launch > watches SIGUSR1, that is not a problem. However, when Weston is started > without weston-launch, Weston itself may be watching for SIGUSR1: > - src/launcher-util.c (Weston as root, without logind?) > - src/logind-util.c (non-root with logind support?) > > Those two seem mutually exclusive, but there is a third one: > - xwayland/launcher.c (for Xwayland server start-up notification) > > I guess what happens in Javier's case, is that when Xwayland server starts, > it sends SIGUSR1 to Weston, which then runs all SIGUSR1 handlers in some > arbitary order: VT switch and XWM init. This leads to Weston thinking it's > no longer current, likely refusing all input, and you have a frozen VT. > > Seems like something should be moved to another signal number. Simply switch logind-util.c to use SIGRTMIN+1. Patch is appended. > > (And why does logind-util.c call signalfd() manually instead of > wl_event_loop_add_signal()?) I guess back in the days I wasn't aware of wl_event_loop_add_signal(). Feel free to change it. Thanks David
Created attachment 110856 [details] [review] [PATCH] logind: use SIGRTMIN to not conflict with xwayland
Only note that I've tested this and the patch didnt fix the issue for me
Hi Javier, David has posted a new series of 4 patches in http://lists.freedesktop.org/archives/wayland-devel/2014-December/019196.html Could you check if those fix this bug for you? Thanks.
Ping?
(In reply to Pekka Paalanen from comment #4) > Hi Javier, > > David has posted a new series of 4 patches in > http://lists.freedesktop.org/archives/wayland-devel/2014-December/019196.html > > Could you check if those fix this bug for you? Sorry for the late reply on this. I can confirm that I do not have problems anymore with the new weston release (1.7.0) (that includes these patches) xwayland now works if you start a X11 app in a session started like: weston --backend=fbdev-backend.so --modules=xwayland.so before I have to run weston-launch to make xwayland work properly: weston-launch -- --backend=fbdev-backend.so --modules=xwayland.so So feel free to close the bug Thanks!
Confirmed fixed in a release.
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.