Created attachment 76029 [details] backtrace of non-responsive Weston session I'm experiencing a problem with Weston where, after starting Weston on VT8, then switching back to VT7 and doing some browsing etc. for a while, then switching back to VT8, I see the Weston desktop, but my system is frozen/unresponsive. Caps lock/num lock have no effect (the LED on the keyboard doesn't turn on), the only thing that works is rebooting with Alt+SysRq+REISUB. If I log into the computer I can switch VT using chvt, so it looks like it's the keyboard input not being processed. I have attached to the weston process and gotten a backtrace with gdb, and I'm attaching this.
Could you also add the Weston log, when you switch VTs a few times back and forth? The backtrace shows no problems, Weston is sleeping just where it should normally be. Most likely it is unable to re-acquire input devices on VT enter. You are using weston-launch, right?
Created attachment 76122 [details] Weston output changing VTs. Freeze at end. Yep, I'm using weston-launch. I'm adding an attachment of a log where first, I start weston, and switch VT back and forth several times. No problem. Then I wait about half an hour, and switch back to Weston at VT8: freeze. I switch back to VT7 by logging in to the machine via SSH and using "chvt", then I switch back to VT8 again (where Weston is still frozen/not responding to keyboard/mouse input) and then change back to VT7 again using chvt. Then I kill Weston. I'd like to point out, just to make sure it's understood, that changing VT back and forth works fine. It's only when I've been at my non-Weston VT for a while, and then switch back to the Weston VT8 that the freeze occurs. It's possible that it's related to the screensaver, since this is the only thing I can think of that only goes off after waiting a while. Maybe it can't handle starting in the background (when I'm not at the VT)?
Seems to be some permission issue, looking at the following part of the log: [15:31:02.854] leaving VT [15:36:02.855] queueing pageflip failed: Permission denied [16:11:46.444] entering VT
[15:31:02.854] leaving VT [15:36:02.855] queueing pageflip failed: Permission denied This is interesting, because the "Permission denied"-error happens exactly 5 minutes after leaving the VT. 5 minutes (300 seconds), is incidentally the default value of --idle-time, which determines when the screensaver is activated. If I set this value to 10 (seconds) (--idle-time=10), leave the VT, then enter it again after 20 seconds, I get a freeze. If I set the value to 60 (seconds), leave the VT, and enter the VT after 20 seconds, I *don't* get a freeze. So it definitely seems like it's when the screensaver (or whatever is triggered after "idle_time" seconds) is activated while away from the VT, switching back to the VT causes Weston to become unresponsive to keyboard input. Staying on the VT while the screensaver is activated doesn't cause a freeze; when I move the mouse the green unlock circle appears and I can proceed as normal.
Ok, definitely not a problem with input devices. Yes, the idle timeout or screen blanking or saving seems to be the culprit. I have recently noticed myself, that on the x11 backend, unlock dialog does not show up anymore after the idle timeout has been hit. That would hint towards that VT switching it not buggy, but the logic related to idle timeout. IIRC the idle timeout stuff was recently modified, I wonder if that produced the regression. Would anyone have time to bisect?
I can reproduce this bug with DRM backend on the following configuration: atk: ATK_2_7_4-3-g689619a cairo: 1.11.2 drm: libdrm-2.4.42-4-g41fc2cc fontconfig: 2.10.91-19-gfb3b410 glib: 2.35.4-59-g82f2ee9 gtk+: 3.7.6-78-g18938b7 kmscon: kmscon-7-27-ge4d2526 libxcb: 1.9 libxkbcommon: xkbcommon-0.2.0-28-g852d920 mesa: snb-magic-14773-g4154ac0 mtdev: e5eb274 pango: 1.32.6-5-g4701908 pixman: pixman-0.28.0-47-g480dd38 wayland: 1.0.1-33-gc3da4a2 weston: 1.0.0-357-g338148f xf86-video-intel: 2.19.0-27-g1c65dd7 xf86-video-wlshm: af6618a xserver: xorg-server-1.12.2-104-g5569c0e Steps to reproduce are: 1. run weston with idle timeout: (the screen should go black after ~10s.) weston-launch -- -i10 2. change from weston to another vt, it would crash after ~10s Expected result is: * weston should not crash after 10s the fix https://gist.github.com/Blei/5128541 seems to reslove it. It's still a bit rusty, e.g. when switching from weston to VT, I get a black screen But after a few seconds the configuration is restored and I can see X.
Same here. I've also tried Philipp Brüschweiler's patches (the last version from the ml) and they also fix the issue for me.
This should fix the problem: commit 57edf7f49ec9349f65b0e8cc330f9e6aa94f8a38 Author: Philipp Brüschweiler <blei42@gmail.com> Date: Fri Mar 29 13:01:56 2013 +0100 compositor: add WESTON_COMPOSITOR_OFFSCREEN state This state is used when the user switches the vt. It turns of rendering and frame events, but doesn't set the DPMS state to off. As a part of this change, also turn off the idle timer when entering the SLEEPING or OFFSCREEN states, which fixes https://bugs.freedesktop.org/show_bug.cgi?id=61910 (rpi backend
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.