Bug 91448

Summary: glx/dri* blocks GLX clients on VT switch
Product: xorg Reporter: Gatis Paeglis <gatis.paeglis>
Component: Server/Ext/DRIAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: psychon, thiago
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xcb test code none

Description Gatis Paeglis 2015-07-24 10:22:35 UTC
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
Comment 1 Chris Wilson 2015-07-25 09:20:16 UTC
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.
Comment 2 Gatis Paeglis 2015-07-27 07:47:10 UTC
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.
Comment 3 Adam Jackson 2018-06-13 19:14:47 UTC
We only block clients that have used GLX. (We could do even better, but don't currently.)
Comment 4 gatis.paeglis 2018-09-14 10:33:40 UTC
I think this is related with https://bugs.freedesktop.org/show_bug.cgi?id=94108
Comment 5 GitLab Migration User 2018-12-13 18:32:17 UTC
-- 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.