Created attachment 117339 [details] xcb test code resulted from https://bugreports.qt.io/browse/QTBUG-47179 The issue is reproducible also in other situations, for example when "session / screen is locked by Light Locker (Xubuntu, standard configuration)" xcb test code in the attachment. Code works as expected when glx extension is not initialized. As soon as you enable glx extension you start to get a blocking behaviour on xcb_get_input_focus_reply; Expected outcome when switching to VT: syncX: 12:20:30 syncX: 12:20:31 syncX: 12:20:32 syncX: 12:20:33 syncX: 12:20:34 syncX: 12:20:35 syncX: 12:20:36 syncX: 12:20:37 syncX: 12:20:38 syncX: 12:20:39 syncX: 12:20:40 syncX: 12:20:41 Actual outcome (switch to VT and then back to GUI session after for example 5 seconds): syncX: 12:20:30 syncX: 12:20:31 syncX: 12:20:32 syncX: 12:20:33 syncX: 12:20:39 syncX: 12:20:40 syncX: 12:20:41
The issue is with DRI once the server has lost its context, its clients are no longer authorized to access the GPU, hence glxDRILeaveVT() blocks all clients. It should be immediately apparent that this only prevents the clients from dieing by happenstance - they can still be rendering when the server switches and so can die before being blocked. Also blocking all X communication rather than using DRI2Throttle() . commit 86450998da616e3d00d4d6293acc35eccc2061e7 Author: Kristian Høgsberg <krh@redhat.com> Date: Thu Sep 7 15:35:16 2006 -0400 Fix AIGLX VT switching. See https://bugs.freedesktop.org/show_bug.cgi?id=7916 There may be a simpler, less intrusive fix that involves just rearranging DRI locking between 2D and 3D drivers around VT switch.
I am not a X developer, so I am not sure how much work it would involve to fix this issue. What I am wondering about is - Is there any other pattern that could be used to sync with X server? Currently in Qt we use xcb_get_input_focus_reply for the reasons explained in: http://lists.freedesktop.org/archives/xcb/2008-August/003671.html The buggy-blocking behaviour blocks Qt's GUI thread (which includes processing timer events and etc.) which is kind of a serious issues especially because locking your screen is a very common action.
We only block clients that have used GLX. (We could do even better, but don't currently.)
I think this is related with https://bugs.freedesktop.org/show_bug.cgi?id=94108
-- 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/xorg/xserver/issues/206.
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.