Bug 106179

Could you redirect both stdout and stderr of weston-launch into a file, reproduce the issue, and attach the file here?

Do you actually need to use weston-launch?

You should never kill 'weston-launch', at least with SIGKILL, because that may leave your VT in a useless state. Try killing 'weston' instead.

weston-launch -v does not print anything.

When I installed Weston I looked for way how to start it, then I found weston-launch, it worked, so I use it.

The reason I asked you to redirect weston-launch output into a file is because that will actually be Weston's log output and it will print lots. But if you do not redirect it into a file, you will lose it, because the virtual terminal printing stops working as soon as Weston starts.

weston-launch is only necessary if you do not run a system service similar to logind. This is mentioned in the weston man page. I would not expect this to be related to your problem though. I have a suspicion, but for that I'd need the Weston log.

Created attachment 139034 [details]
Log of weston-launch, when it does not restore to the GUI

This is the file `stdbuf -o 0 -e 0 weston-launch -v` generate from its start, until it doesn't return to the graphical interface after pressing Ctrl+Alt+Fn, and is then terminated with Alt+Backspace.

The line "[07:14:56.166] activating session" is printed after pressing Alt+Backspace.

Thank you. It's a little bit along the lines I suspected, but in a surprising way. The below is my analysis for the record:

Main details from the log:
- atomic modesetting is in use

The interesting sequence:

[07:07:31.718] activating session
...
[07:07:31.797] DRM: expected property DPMS to not be an enum, but it is; ignoring
[07:07:31.797] DRM: expected property DPMS to not be an enum, but it is; ignoring
[07:07:31.817] unexpectedly large timestamp jump (from 31925138 to 31934769)
[07:13:57.726] atomic: couldn't commit new state: Permission denied
[07:13:57.727] deactivating session

Judging by the timestamps, it seems that EPERM might result from a sequence like this:
- user hits Ctrl+Alt+F#
- that ends up calling launcher_logind_activate_vt()
- logind revokes DRM access
- libweston core hits repaint and fails atomic flip with EPERM
- logind signals VT deactivation
- session_notify() gets called, prints "deactivating session"

If an atomic flip fails, I think libweston will never try again, which leads to no screen updates. Looks like two things: fix the race (libweston or logind?), and maybe find a way to recover from atomic failures.

When I close and open my laptop subsequent kprints shown by 'dmesg -T' do not jump with the corresponding time.  The '[07:07:31.817] unexpectedly large timestamp jump (from 31925138 to 31934769)' might be related to this.  However I do not think this is anyhow related to the problem, as weston-launch also stops redrawing the GUI when I do not close and reopen my laptop after its start.

For the record I use systemd's logind as service, but weston-launch I just start as normal process.

From the last comment I understand, that from me no further information is needed for a fix.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/103.