Bug 90532 - Weston doesn't run on secondary X screen
Summary: Weston doesn't run on secondary X screen
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-20 09:14 UTC by Marko Srebre
Modified: 2016-05-23 22:22 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
X dual screen setup (1.59 KB, text/plain)
2015-05-20 09:14 UTC, Marko Srebre
Details
Weston log when running on display :1.0 (7.52 KB, text/plain)
2015-05-20 09:15 UTC, Marko Srebre
Details
Weston log when running on display :1.1 (error) (949 bytes, text/plain)
2015-05-20 09:16 UTC, Marko Srebre
Details
Fix for running on secondary x screen (3.46 KB, patch)
2015-05-20 18:44 UTC, Marko Srebre
Details | Splinter Review
Fix for running on seconrady x screen (2) (3.46 KB, text/plain)
2015-05-22 09:20 UTC, Marko Srebre
Details

Description Marko Srebre 2015-05-20 09:14:06 UTC
I have a dual X screen setup. Screen 0 (DISPLAY=:1.0) is my main monitor, screen 1 (DISPLAY=:1.1) is Oculus Rift.

I can run Weston (1.7.0) on my primary screen such as:

DISPLAY=:1.0 weston

and it works). However, running:

DISPLAY=:1.1 weston

does not work.

I can run other GL applications on secondary display without problems. For example: 

DISPLAY=:1.1 glxgears

runs fine.
Comment 1 Marko Srebre 2015-05-20 09:14:55 UTC
Created attachment 115913 [details]
X dual screen setup
Comment 2 Marko Srebre 2015-05-20 09:15:54 UTC
Created attachment 115914 [details]
Weston log when running on display :1.0
Comment 3 Marko Srebre 2015-05-20 09:16:26 UTC
Created attachment 115915 [details]
Weston log when running on display :1.1 (error)
Comment 4 Pekka Paalanen 2015-05-20 10:05:13 UTC
Oh, NVIDIA proprietary drivers, which means NVIDIA's proprietary EGL implementation.

Testing with glxgears tests GLX while Weston uses EGL instead, so it's not really related. You should try some EGL apps, e.g. mesa-demos has some EGL demo apps like es2gears. If those fail too, it's not Weston's fault.
Comment 5 Marko Srebre 2015-05-20 10:56:12 UTC
I just tested

DISPLAY=:1.1 es2gears_x11

and it works too.
Comment 6 Pekka Paalanen 2015-05-20 11:58:57 UTC
Ok. The only thing that can trigger the error message is a failing eglCreateWindowSurface() call. I can't guess why it fails.

I suppose we could look at the EGLconfig it chose, if it seems any way funny. That means putting the log_egl_config_info(gr->egl_display, egl_config); call just before eglCreateWindowSurface(). However, it's not printing many parameters of the EGLConfig, we'd probably want to know more...

This would probably need hands-on debugging, plus finding someone who bothers with the proprietary driver.
Comment 7 Marko Srebre 2015-05-20 12:18:50 UTC
I tried to compile it from source. It definitely fails at eglCreateWindowSurface(). I am willing to investigate further. It is very easy to compare the two runs, one on primary display that works and one on secondary that doesn't. I am just a bit at loss what to look at. 

I tried log_egl_config_info(gr->egl_display, egl_config);

It prints the same output for both cases:

[14:15:50.833] Chosen EGL config details:
               RGBA bits: 8 8 8 0
               swap interval range: 0 - 1


I'd appreciate any ideas on how to debug it further.
Comment 8 Pekka Paalanen 2015-05-20 12:29:42 UTC
If you dig up the EGL spec from khronos.org, you find that you can query lots more attributes out from an EGLConfig. Looking at those is the only thing that comes to mind.

You could also use http://www.waffle-gl.org/man/wflinfo.1.html with egl_x11 to inspect the possible EGL environment differences. I just hope it prints enough...
Comment 9 Marko Srebre 2015-05-20 12:39:35 UTC
After unsuccessful call to eglCreateWindowSurface(), function gl_renderer_print_egl_error_state() prints:

EGL error state: EGL_BAD_NATIVE_WINDOW (0x300b)

Is there anything to check about this 'window'?
Comment 10 Pekka Paalanen 2015-05-20 13:49:38 UTC
The native window is passed in from compositor-x11.c, and it's actually xcb_window_t or Window, that is, an X11 type. You could query it's properties with X11 calls, or maybe just even print the value and use 'xwininfo -id ###' to inspect it while Weston is halted in debugger. X11 Window is just an integer id.
Comment 11 Marko Srebre 2015-05-20 14:19:13 UTC
This is getting interesting.

I inserted a system call before eglCreateWindowSurface() to call my script which is something of a

echo "display :1.0"
DISPLAY=:1.0 xwininfo -root -tree | grep -i weston
echo "display :1.1"
DISPLAY=:1.1 xwininfo -root -tree | grep -i weston

and however I spin it, it seems that weston is always creating X window on display :1.0, regardless of the prefixed DISPLAY variable.
Comment 12 Marko Srebre 2015-05-20 18:44:39 UTC
Created attachment 115928 [details] [review]
Fix for running on secondary x screen

This is the fix I did to get it running. The problem was: the first screen on the list was always selected from the list of screens given by xcb_setup_roots_iterator(). Instead, this patch tries to select the default screen, which is the one given by DISPLAY variable. Seems nvidia blob's not to blame in this particular case. :)
Comment 13 Derek Foreman 2015-05-20 19:31:15 UTC
At a glance, that looks right to me.

Marko, do you feel like sending that to the wayland mailing list so we can all bike shed the coding style? :)

We put the * next to the variable name not the type.

Otherwise, Reviewed-By and Tested-By me.
Comment 14 Marko Srebre 2015-05-22 09:20:55 UTC
Created attachment 115970 [details]
Fix for running on seconrady x screen (2)
Comment 15 Marko Srebre 2015-05-22 09:22:50 UTC
I'll send it to the list. Here is a modified version, more in line with xcb design patterns.
Comment 16 Derek Foreman 2015-10-05 22:28:40 UTC
I've just posted a new version of this patch to the mailing list.  Hopefully we can actually land it soon...
Comment 17 Yong Bakos 2016-04-21 20:20:59 UTC
I believe this bug can be marked as resolved-fixed.

See https://patchwork.freedesktop.org/patch/61060/
Merged as commit 61b4d3ea4421f390ee2c4c22fde649260e52d28f
Comment 18 Bryce Harrington 2016-05-23 22:22:22 UTC
Closing as fixed as per the previous couple of comments.

Feel free to reopen if there is any remaining/followup to do.


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.