Bug 86889

Hm... maybe it's a bug in v215, and not Weston. https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81932 (it could be related)
Let me test

This doesn't sound like Xwayland related, so the component should probably be Weston, no?

What does "does not handle tty switches" mean? Does it just not allow switching VTs at all after weston is up?

Correct, it should have been Weston, I don't know how xwayland got selected.

It allows TTY switching, but the other session still remains active, so that keyboard input gets sent to the new TTY, and the running fbdev weston server

Hi, sorry about the lack of the description, I tried submitting this with a browser that I guess has some sort of bug that caused the description I typed to not be submitted

Anyway the problem seems to be in the fact that when I call a Weston session with fbdev-backend without using weston-launch, and relying on systemd integration instead, I am able to call the Weston sessions, however


To reproduce: give the user or group permissions to the framebuffer device with chmod, or setfacl.

Login with the user account onto a text mode TTY session.

start weston --backend=fbdev-backend.so

Open up a terminal window, or text editor, or any program that takes text input

Switch to another text mode TTY, and start typing. Not only will the application get that text input, but the drawing of the window starts appearing on the TTY as well. You can also move the mouse, and that will appear on the second TTY as well.

This does not seem to be fixed with systemd v216 as I thought might have been caused by https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81932 in logind v215, it does seem to be a bug in Weston itself. 

I was suggested to try to see if I see "Deactivating session" getting logged by weston when switching VTs when using the fbdev-backend. It does not get logged.


I tried using pixman on drm-backend to try to isolate, as asked on IRC, and I still see "Deactivating Session" in the scrollback, as well as on drm-backend with the default renderer.

Sorry, I just realized that the "Deactivating session" string is for the DRM backend, and the fbdev-backend prints "leaving VT" on TTY switching.  
  
To clarify, when not using weston-launch, I don't see "leaving VT" as well on fbdev-backend called sessions with logind.

I tried to add print lines (in this diff) to try to see if I get any diagnostic output when I try to switch VTs under fbdev-backend.so

However I do not see any of these lines get output.


diff --git a/src/launcher-util.c b/src/launcher-util.c
index ac764dc..2d6051a 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -244,11 +244,13 @@ weston_launcher_data(int fd, uint32_t mask, void *data)
 		launcher->compositor->session_active = 1;
 		wl_signal_emit(&launcher->compositor->session_signal,
 			       launcher->compositor);
+		printf("Deactivate...");
 		break;
 	case WESTON_LAUNCHER_DEACTIVATE:
 		launcher->compositor->session_active = 0;
 		wl_signal_emit(&launcher->compositor->session_signal,
 			       launcher->compositor);
+		printf("Reactivate...");
 		break;
 	default:
 		weston_log("unexpected event from weston-launch\n");
diff --git a/src/logind-util.c b/src/logind-util.c
index 6a1b498..ca6b8e4 100644
--- a/src/logind-util.c
+++ b/src/logind-util.c
@@ -269,7 +269,7 @@ weston_logind_activate_vt(struct weston_logind *wl, int vt)
 	r = ioctl(wl->vt, VT_ACTIVATE, vt);
 	if (r < 0)
 		return -1;
-
+	printf("Activate...");
 	return 0;
 }
 
@@ -695,9 +695,11 @@ signal_event(int fd, uint32_t mask, void *data)
 	switch (sig.ssi_signo) {
 	case SIGUSR1:
 		ioctl(wl->vt, VT_RELDISP, 1);
+		printf("SIG1...");
 		break;
 	case SIGUSR2:
 		ioctl(wl->vt, VT_RELDISP, VT_ACKACQ);
+		printf("SIG2...");
 		break;
 	}

Hi. I was able to actually create a patch that fixes this. 
http://lists.freedesktop.org/archives/wayland-devel/2014-December/018811.html

I admit I made the subject line too long by mistake.

Attempting one of the patches http://lists.freedesktop.org/archives/wayland-devel/2014-December/019032.html

It does not appear that the fbdev backend is getting the signal to deactivate on tty switching

This is a screenshot of two fbdev backended Weston servers https://i.imgur.com/oCm3X5u.png conflicting on a text TTY that is showing the log of one of the servers

Hi,

could you check if the new series of 4 patches might fix this bug for you?
http://lists.freedesktop.org/archives/wayland-devel/2014-December/019196.html

Seems to fix the issues with TTY switching. I don't know if its related or not though but it seems mouse button input is broken. I can move the mouse cursor, but I can't click on anything. I will try to revert to what I had, and update if it comes out to be something else

Doesn't seem to be the patches that caused it, as mouse buttons don't work when I tried it the way I have it (something unrelated that I have to investigate now...)

I am able to tty switch nicely with these patches.

Newest commits in Weston fix this issue

commit 2ecb84a20dab56b9479186e5a32ae7aa31565756
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Tue Dec 30 14:33:22 2014 +0100

    logind: forward Active=true changes for non-DRM backends

    Logind sends us a notification whenever the Active attribute of our session
    changes. However, due to the way compositor-drm.c relies on the master DRM
    device to be synced with the session, we used to delay Active=true
    handling until the DRM device was up, too. See:

        commit aedc7732ebd9bc7b4f51ee247ea857ffec6260a7
        Author: David Herrmann <dh.herrmann@gmail.com>
        Date:   Sat Nov 30 11:25:45 2013 +0100

            logind: delay wakeup until DRM-device is resumed

    However, the other compositor backends do not use DRM, so logind-util will
    never get notified about any DRM device. Therefore, we have to forward the
    Active=true change immediately.

    This commit fixes logind-util to take sync_drm as argument. If it is true,
    we do DRM-device synchronisation, otherwise we don't.

    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=86889
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
    Tested-by: nerdopolis <bluescreen_avenger@verizon.net>