Created attachment 104794 [details] output of running weston with weston-launch on a VT I’ve upgraded my system to the latest Debian testing (as of yesterday) and was trying to launch Weston. I stopped my display manager and verified X is no longer running. Then I switched to vt1 and started weston-launch (I’m in the UNIX group weston-launch). A bit later, all I see is a black screen. Switching to a different VT and back does not help. I can however click in the place where the terminal icon is supposed to be and see that a new process gets started, so it seems like Weston itself is working, just unable to show anything on the screen. The attached logfile contains the stdout/stderr of “MESA_DEBUG=1 EGL_LOG_LEVEL=debug LIBGL_DEBUG=verbose WAYLAND_DEBUG=1 weston-launch”. Starting weston-terminal via SSH results in this stdout: $ weston-terminal libEGL warning: failed to create a pipe screen for i965 libEGL warning: failed to create DRM screen failed to get cairo EGL argb device EGL does not seem to work, falling back to software rendering and wl_shm. I’ve also attached the output of lshw so that you know which hardware is in the ThinkPad X200 I’m using. I then tried running weston under X11, which results in a segmentation fault in i965_dri.so (“backtrace full” attached, as well as the logfile when running under x11). How can I fix this/further debug this issue?
Created attachment 104795 [details] lshw on the ThinkPad X200
Created attachment 104796 [details] Output of running weston under X11
Created attachment 104797 [details] gdb session running “backtrace full” on the weston core dump
Created attachment 104798 [details] Versions of the Debian packages that I have installed.
Your Weston under X11 output looks like a Mesa issue. Are you able to run any OpenGL applications on EGL on X11? In the same environment you tried to run Weston on X11 in: can you post the output of es2_info from mesa-demos, and check that es2tri and es2gears_x11 work fine? I assume OpenGL apps on GLX work just fine? Mesa-demos is http://cgit.freedesktop.org/mesa/demos/ in case you don't have those test programs in your distribution. After building, you can find the test programs in src/egl/opengles2. "function is no-op" usually means that something is not using EGL properly to initialize GL, but I suppose it could also mean a broken Mesa installation. Have you ever built and installed Mesa manually, from source? Does rebuilding Weston with --with-cairo=image added to configure change anything? Your Weston under DRM (i.e. no X11) output looks fine on first glance, but I do not see any of the wl_surface.frame callbacks answered, which means either the compositor's repaint cycle is stuck or the client dies too soon. But let's do one thing at a time, and first make sure everything works under X11.
Created attachment 104825 [details] es2_info
(In reply to comment #5) > Your Weston under X11 output looks like a Mesa issue. Are you able to run > any OpenGL applications on EGL on X11? I presume the following tests with es2gears_x11 are using EGL, right? > In the same environment you tried to run Weston on X11 in: can you post the > output of es2_info from mesa-demos, and check that es2tri and es2gears_x11 > work fine? I attached the output of es2_info. es2tri and es2gears_x11 open a window and display a color triangle, respectively the rotating gears. glxgears works as well. > I assume OpenGL apps on GLX work just fine? If glxgears is enough to verify that, then yes. > Have you ever built and installed Mesa manually, from source? I think so, but I don’t think any artifacts of that remain. I verified that no files matching *mesa* or *dri* are in /usr/local. Also, none of the paths in the weston output contain /usr/local. > Does rebuilding Weston with --with-cairo=image added to configure change > anything? Indeed, when adding --with-cairo=image, I can run weston under X11 (haven’t tried it under DRM). I’ve attached the log output so that you can compare.
Created attachment 104828 [details] weston log output under X11 when passing --with-cairo=image to configure
(In reply to comment #7) > (In reply to comment #5) > > Your Weston under X11 output looks like a Mesa issue. Are you able to run > > any OpenGL applications on EGL on X11? > I presume the following tests with es2gears_x11 are using EGL, right? Yes, AFAIK EGL is the only way to create a GLESv2 context. > > In the same environment you tried to run Weston on X11 in: can you post the > > output of es2_info from mesa-demos, and check that es2tri and es2gears_x11 > > work fine? > I attached the output of es2_info. es2tri and es2gears_x11 open a window and > display a color triangle, respectively the rotating gears. glxgears works as > well. > > > I assume OpenGL apps on GLX work just fine? > If glxgears is enough to verify that, then yes. Yup, all seems good there. And you are sure that in the same shell, without changing any environment variables between Weston and running the mesa-demos, Weston fails somehow but the mesa-demos and glxgears work fine? > > Have you ever built and installed Mesa manually, from source? > I think so, but I don’t think any artifacts of that remain. I verified that > no files matching *mesa* or *dri* are in /usr/local. Also, none of the paths > in the weston output contain /usr/local. I was more thinking of the traditional problem of overwriting your distribution files with manually built files, but good to check that /usr/local is clean. And your $prefix is clean too? Also, Mesa does provide more than just *mesa* or *dri*, it provides e.g. libEGL.so. > > Does rebuilding Weston with --with-cairo=image added to configure change > > anything? > Indeed, when adding --with-cairo=image, I can run weston under X11 (haven’t > tried it under DRM). I’ve attached the log output so that you can compare. Ok. (In reply to comment #8) > Created attachment 104828 [details] > weston log output under X11 when passing --with-cairo=image to configure I cannot spot anything bad here. Is something still failing or black with Weston-on-X11 or is it totally fine? Do try weston-launch without X, and remember to set all the environment as usual. If you still get a black screen, but Wayland apps appear as if they run when you start them over ssh, could you do over ssh with all the env set up: $ WAYLAND_DEBUG=1 ./weston-simple-shm &> log-file.txt let it run for a couple of seconds, kill it with ctrl-c, and post the resulting log file. Also 'dmesg' just after a fresh boot would be nice. Thanks.
Solved it: building weston manually pulled in libgl1-mesa-glx (which replaced libgl1-mesa-swx11. This is what made it work (both under X11 and under the VT). To make sure I double checked and installed libgl1-mesa-swx11 again. Afterwards, I can reproduce the problem I originally reported. When installing libgl1-mesa-glx, everything starts working again. I’m not sure what the difference really is, but swx11 sounds like “software X11” to me, so perhaps GLX is the proper hardware-accelerated thing and swx11 some software rendering replacement…? Perhaps you could clarify if this is intended behavior or if there still is a bug here. In case of the former, I’d be happy to file a bug in Debian to add a dependency to make sure other people don’t run into the same problem. Let me know.
Michael, that sounds a bit strange to me. I do not know what is packaged in libgl1-mesa-glx or libgl1-mesa-swx11, are these packages mutually exclusive? Does one contain/depend on hardware drivers, and the other forces them to be uninstalled? GLX is purely an X11 thing, and does not really say anything about software vs. hw-accelerated, it can do both AFAIU. Nothing Weston related ever uses GLX. Even Weston on X11 will be using EGL. Wayland apps do not even have choice, it is always EGL, since GLX is tied to X11. If you are getting a software GL-renderer, I would except that to show up in the GL_RENDERER string, but in all info I have seen from you, I haven't recognized that anywhere. I think we can agree that this is not a Weston bug at least, right? Though, Weston could be more graceful about it, and quit if it can't work, rather than stick with a black screen. That would need someone who can reproduce the issue, and then figure out how Weston can detect the situation. I thought Weston was already checking all relevant function calls, but maybe we missed something.
(In reply to comment #11) > Michael, that sounds a bit strange to me. I do not know what is packaged in See https://packages.debian.org/jessie/amd64/libgl1-mesa-glx/filelist for the list of files — both contain libGL.so.1 From the package description of libgl1-mesa-swx11 (built from the mesa source package): This library provides a pure software rasteriser; it does not provide a direct rendering-capable library, or one which uses GLX. For that, please see libgl1-mesa-glx. > libgl1-mesa-glx or libgl1-mesa-swx11, are these packages mutually exclusive? Yeah, both “provide” libgl1, so apt will remove the other. > Does one contain/depend on hardware drivers, and the other forces them to be > uninstalled? Interestingly not. When I swap libgl1-mesa-{glx,swx11}, only those two packages are changed, no other package is installed or removed. > Though, Weston could be more graceful about it, and quit if it can't work, > rather than stick with a black screen. That would need someone who can Agreed :).
(In reply to comment #12) > (In reply to comment #11) > > Michael, that sounds a bit strange to me. I do not know what is packaged in > See https://packages.debian.org/jessie/amd64/libgl1-mesa-glx/filelist for > the list of files — both contain libGL.so.1 So you were swapping between two flavours of libGL.so.1? I can't make sense of that, because Weston never uses it. Weston uses libEGL.so and libGLESv2.so. However, if you built weston using --with-cairo=gl, then all the demo apps, the one drawing the wallpaper and panel included, would indeed be trying to use libGL.so through Cairo. Did you do that? If that was the culprit, then weston-simple-shm should have showed up on screen in any case. Did you ever try that app? If that app does indeed show up when everything else is just black, then there is no problem in Weston, and nothing to fix in Weston itself, because it is running just fine. > From the package description of libgl1-mesa-swx11 (built from the mesa > source package): > This library provides a pure software rasteriser; it does not provide > a direct rendering-capable library, or one which uses GLX. For that, > please see libgl1-mesa-glx. Sounds like you would need a pretty special use case to want libgl1-mesa-swx11. It probably maps to some special build configuration of Mesa that people using GPUs will never use. > > libgl1-mesa-glx or libgl1-mesa-swx11, are these packages mutually exclusive? > Yeah, both “provide” libgl1, so apt will remove the other. > > > Does one contain/depend on hardware drivers, and the other forces them to be > > uninstalled? > Interestingly not. When I swap libgl1-mesa-{glx,swx11}, only those two > packages are changed, no other package is installed or removed. > > > Though, Weston could be more graceful about it, and quit if it can't work, > > rather than stick with a black screen. That would need someone who can > Agreed :). A bit more testing is needed as I suggested above to check if it really is Weston failing, or the apps. And if weston-desktop-shell dies, you would not have even a cursor unless the pointer visited some other app's window that remains alive.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Michael, that sounds a bit strange to me. I do not know what is packaged in > > See https://packages.debian.org/jessie/amd64/libgl1-mesa-glx/filelist for > > the list of files — both contain libGL.so.1 > > So you were swapping between two flavours of libGL.so.1? Correct. > I can't make sense of that, because Weston never uses it. Weston uses > libEGL.so and libGLESv2.so. > > However, if you built weston using --with-cairo=gl, then all the demo apps, > the one drawing the wallpaper and panel included, would indeed be trying to > use libGL.so through Cairo. Did you do that? I was using the Debian weston package, which indeed does that, see http://sources.debian.net/src/weston/1.5.0-2/debian/rules/: """ override_dh_auto_configure: dh_auto_configure -- --disable-libunwind --libexec=/usr/lib/weston \ --with-cairo=gl --enable-libinput-backend """ Would it be advisable to not do that at all for some reason? > If that was the culprit, then weston-simple-shm should have showed up on > screen in any case. Did you ever try that app? I re-installed libgl1-mesa-swx11, started weston-launch on the VT and got a black screen. Then I ran weston-simple-shm, and I can see a quadratic window which contains some animated colored circles, so I think that’s a successful test. > If that app does indeed show up when everything else is just black, then > there is no problem in Weston, and nothing to fix in Weston itself, because > it is running just fine. Hm, but doesn’t Weston draw the panel at the top part of the screen where one can start e.g. a terminal emulator? If that does not show up, isn’t that a bug in Weston? > > From the package description of libgl1-mesa-swx11 (built from the mesa > > source package): > > This library provides a pure software rasteriser; it does not provide > > a direct rendering-capable library, or one which uses GLX. For that, > > please see libgl1-mesa-glx. > > Sounds like you would need a pretty special use case to want > libgl1-mesa-swx11. It probably maps to some special build configuration of > Mesa that people using GPUs will never use. From http://sources.debian.net/src/mesa/10.2.5-1/debian/rules/ """ confflags-swx11 = \ --disable-dri \ --disable-egl \ --with-gallium-drivers= \ --enable-xlib-glx \ --disable-egl \ --disable-shared-glapi \ $(buildflags) """
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > I was using the Debian weston package, which indeed does that, see > http://sources.debian.net/src/weston/1.5.0-2/debian/rules/: > > """ > override_dh_auto_configure: > dh_auto_configure -- --disable-libunwind --libexec=/usr/lib/weston \ > --with-cairo=gl --enable-libinput-backend > """ > > Would it be advisable to not do that at all for some reason? The only benefit from --with-cairo=gl is that you get weston-gears and weston-screensaver which is a matrix-style animation. The downsides are that almost every demo program and desktop helper program in Weston will be trying to use GL for rendering that does not really benefit from it. Initializing all those GL contexts eats resources. For the same reason I would avoid --with-cairo=glesv2, which makes you lose the "nested" demos. > > If that was the culprit, then weston-simple-shm should have showed up on > > screen in any case. Did you ever try that app? > I re-installed libgl1-mesa-swx11, started weston-launch on the VT and got a > black screen. Then I ran weston-simple-shm, and I can see a quadratic window > which contains some animated colored circles, so I think that’s a successful > test. Yes. So nothing wrong with Weston apparently. > > If that app does indeed show up when everything else is just black, then > > there is no problem in Weston, and nothing to fix in Weston itself, because > > it is running just fine. > Hm, but doesn’t Weston draw the panel at the top part of the screen where > one can start e.g. a terminal emulator? If that does not show up, isn’t that > a bug in Weston? No. Both wallpaper and the panel are drawn by a helper app, weston-desktop-shell.
I am closing this report as invalid, because it turned out to be a problem in the host system installation, rather than anything that should be fixed in Weston. I also cannot really see what more Weston could be checking to avoid the black screen problem. If someone has tangible suggestions, feel free to open a new bug for that, or preferably send patches directly to the mailing list. Thanks.
(In reply to comment #16) > I am closing this report as invalid, because it turned out to be a problem > in the host system installation, rather than anything that should be fixed > in Weston. I also cannot really see what more Weston could be checking to > avoid the black screen problem. If someone has tangible suggestions, feel > free to open a new bug for that, or preferably send patches directly to the > mailing list. > > Thanks. For the record: I started the discussion about how Debian builds Weston in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758980 Thanks again for your analysis/help with debugging this issue.
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.