Bug 86889

Summary: fbdev backended Weston called with logind (without weston-launch) does not handle tty switches
Product: Wayland Reporter: n3rdopolis <bluescreen_avenger>
Component: westonAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: bluescreen_avenger
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description n3rdopolis 2014-12-01 01:03:31 UTC

    
Comment 1 nerdopolis1 2014-12-01 04:32:10 UTC
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
Comment 2 Pekka Paalanen 2014-12-01 09:45:56 UTC
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?
Comment 3 nerdopolis1 2014-12-01 11:58:02 UTC
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
Comment 4 nerdopolis1 2014-12-01 12:37:02 UTC
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.
Comment 5 nerdopolis1 2014-12-02 02:13:24 UTC
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.
Comment 6 nerdopolis1 2014-12-02 02:19:38 UTC
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.
Comment 7 nerdopolis1 2014-12-05 13:22:32 UTC
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;
 	}
Comment 8 nerdopolis1 2014-12-10 04:03:27 UTC
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.
Comment 9 nerdopolis1 2014-12-16 12:32:18 UTC
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
Comment 10 Pekka Paalanen 2015-01-02 15:50:25 UTC
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
Comment 11 nerdopolis1 2015-01-03 01:52:38 UTC
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
Comment 12 nerdopolis1 2015-01-03 03:55:27 UTC
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.
Comment 13 nerdopolis1 2015-01-17 03:04:09 UTC
Newest commits in Weston fix this issue
Comment 14 Bryce Harrington 2015-01-22 21:55:16 UTC
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>

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.