The XWayland test in Weston is currently failing. Investigate why exactly, and what would make it work again. Would also be nice to write another XWayland test that does not rely on DRI2.
There's a new test now that usually works, but I'm still investigating a couple of potential race conditions in it. The test works by checking for the presence of the WL_SUBSURFACE_ID atom and checking the name of the window manager. Right now I need to investigate when the WL_SUBSURFACE_ID atom is interned - can the test launch before that occurs? And whether the test can start before the window manager has created its support window.
Created attachment 114438 [details] test failure: compositor log
Created attachment 114439 [details] test failure: test log
Created attachment 114440 [details] test failure: run log Hee, I reproduced it! Looks like a Weston crash. Now if I decoded the backtrace right, it would be SEGVing at xwayland/window-manager.c:645 which looks like it means hash_table_lookup() maybe returns NULL or something in weston_wm_handle_configure_notify(). It's a total bitch to reproduce.
Created attachment 114441 [details] test failure: compositor log with WM_DEBUG I had distcheck running in loop for a good while and it eventually reproduced. Attaching the server log with XWM debugging enabled.
I think we can finally close this saga with having landed: commit 493721499927a354375ea86cf7563bf107e6fb72 Author: Derek Foreman <derekf@osg.samsung.com> Date: Thu Apr 9 10:51:22 2015 -0500 xwm: Add and use helper function for looking up windows in the hash table
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.