On Arch Linux, wayland 1.6.1-1, weston 1.6.1-1. Dual-head on an ATI HD 5570. Starting weston from kmscon fails to start weston but then also "scrambles" the display. The keyboard seems to operate normally, except that VT switching fails. Running "reset" does _not_ "unscramble" the display. Restarting kmscon resets the display to normal. Enabling "--session-control" in kmscon, though, can allow completely losing access to the keyboard and display, but that probably has to do with kmscon and not weston. kmscon is being started from systemd on vt13 with: ExecStart=/usr/bin/kmscon "--vt=%I" --seats=seat0 --no-switchvt --hwaccel I don't know if running weston from kmscon "should work" or not, but, either way, it should not "scramble" the display. I suppose that this has something to do with the kernel KMS not being properly reset by weston. Running "weston > westonlog 2>&1", "westonlog" shows: Date: 2015-02-01 MST [08:22:30.700] weston 1.6.1 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.6.1 Build: 1.6.0-32-g9d27677 configure.ac: bump version to 1.6.1 for stable release (2015-01-23 13:17:01 -0800) [08:22:30.700] OS: Linux, 3.18.4-1-ARCH, #1 SMP PREEMPT Tue Jan 27 20:45:02 CET 2015, x86_64 [08:22:30.700] Using config file '/home/james/.config/weston.ini' [08:22:30.701] Loading module '/usr/lib/weston/drm-backend.so' [08:22:30.704] initializing drm backend [08:22:30.710] logind: cannot set K_OFF KB-mode on /dev/tty13: Operation not permitted [08:22:30.710] logind: cannot setup systemd-logind helper (-1), using legacy fallback [08:22:30.710] fatal: drm backend should be run using weston-launch binary or as root [08:22:30.710] fatal: failed to create compositor Actually running "weston-launch" gives: weston-launch: weston-launch must be run from a virtual terminal Actually running as root gives: Date: 2015-02-01 MST [08:31:25.614] weston 1.6.1 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.6.1 Build: 1.6.0-32-g9d27677 configure.ac: bump version to 1.6.1 for stable release (2015-01-23 13:17:01 -0800) [08:31:25.614] OS: Linux, 3.18.4-1-ARCH, #1 SMP PREEMPT Tue Jan 27 20:45:02 CET 2015, x86_64 [08:31:25.614] fatal: environment variable XDG_RUNTIME_DIR is not set. Refer to your distribution on how to get it, or http://www.freedesktop.org/wiki/Specifications/basedir-spec on how to implement it.
I tested this again with wayland 1.7.0, weston 1.7.0, libinput 0.10.0, and kmscon 8.21, and the display still gets "scrambled".
After reading at Bug 76553 - "Dies on vt switch", I tried starting kmscon without "--hwaccel". That indeed avoids the "scrambled" display, I suppose implying that the problem is EGL related. As weston also fails to run from kmscon, the output now is: Date: 2015-02-15 MST [19:57:40.949] weston 1.7.0 http://wayland.freedesktop.org Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0 Build: 251b4a4 xwm: use always a valid 'primary view' for an X window (2015-02-14 16:53:21 +0200) [19:57:40.949] OS: Linux, 3.18.6-1-ARCH, #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015, x86_64 [19:57:40.949] Using config file '/home/james/.config/weston.ini' [19:57:40.949] Loading module '/usr/lib/weston-1/drm-backend.so' [19:57:40.953] initializing drm backend [19:57:40.957] logind: cannot take control over session c1 [19:57:40.957] logind: cannot setup systemd-logind helper (-5), using legacy fallback [19:57:40.957] fatal: drm backend should be run using weston-launch binary or as root [19:57:40.957] fatal: failed to create compositor backend That's a different issue, though. If I start kmscon with both "--hwaccel" and "--debug", and then run "weston", this also does not scramble the dispaly, though weston still will exit immediately. It's one of those "quantum" bugs - it's not there if you are looking at it. Ha! Suggestions?
All the components here are way out of my expertise, but I think there are two different issues: - if weston fails in any way, it really shouldn't leave the VT (or kmscon) broken, especially when usind weston-launch where the VT handling is external to weston itself. (Might also be an issue with kmscon, not just weston or weston-launch). - weston fails to begin with I know little about systemd and logind, but is the shell inside kmscon in a real user session (in systemd/logind terms)? Does kmscon take DRM master? If yes, that means Weston cannot take it, and KMS calls will fail. Maybe that is the main issue. Unfortunately I have no idea how an app that wants to be a DRM master should run under something like kmscon. I'm adding David Herrmann to CC. Maybe he could explain how things are supposed to work between systemd, logind, kmscon, weston-launch, and weston. Btw. IIRC Sysrq-v is a thing that should forcefully restore fbcon, but I've no idea what it might do to kmscon.
You cannot start Xorg (via startx) or weston (via weston-launch) from kmscon. kmscon runs in graphics mode, therefore, the started compositor cannot take over. If you run kmscon with hw-accel, then you will screw up your hardware state, that's why the screen is scrambled. You either need to pass the TTY explicitly to weston-launch, or run it from a normal VT in text-mode.
Ok, David. Is there something we could do to give the user a sane and graceful failure message rather than just bork everything?
Hmm - ok. What is the long-term solution? It is not good to have a program that will "screw up your hardware state", regardless of the circumstances. I'm still confused, though. David, on your blog, about kmscon, you say "In 2014, I stopped working on it. We implemented a replacement in systemd, based on the lessons learned on KMSCON." What is that kmscon replacement?
(In reply to Pekka Paalanen from comment #5) > Ok, David. > > Is there something we could do to give the user a sane and graceful failure > message rather than just bork everything? Not really. There is no nice way to figure out whether a VT is in use or not, especially if the previous compositor crashed or so.
(In reply to James from comment #6) > Hmm - ok. What is the long-term solution? It is not good to have a program > that will "screw up your hardware state", regardless of the circumstances. Don't use 'weston-launch' or 'startx' or anything like it on production systems. Use proper login-managers, which make sure to assign a fresh VT to the compositor. > I'm still confused, though. David, on your blog, about kmscon, you say "In > 2014, I stopped working on it. We implemented a replacement in systemd, > based on the lessons learned on KMSCON." What is that kmscon replacement? It's still being worked on. It's called systemd-console.
Sounds like this issue is a WONTFIX then, unfortunately.
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.