A bug the Linux folks recently found in the interaction between compiz,
VT's and the kernel DRM drivers that we should watch out for...

        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering

-------- Original Message --------
Subject: Waiting for vblank vs VT switching
Date: Tue, 18 Nov 2008 00:38:16 -0800
From: Keith Packard <kei...@keithp.com>
To: dri-devel <dri-devel at lists.sourceforge.net>, Jesse Barnes
<jbarnes at virtuousgeek.org>
CC: keithp at keithp.com

Airlied pointed me at a fairly easy bug to reproduce -- VT switch while
compiz is running and the server locks up when you switch back.

The cause is fairly simple to understand -- VT switching involves a mode
set, and that mode set erases the hardware frame counter registers.
However, Mesa doesn't know that, and so it asks to wait for the next
frame to pass by when compiz asks it to wait. As it has an old frame
count, it waits for a long time.

It seems like what we want is for the kernel to keep some kind of
'offset' when vt switching and add that into the frame counts returned
for each crtc. Does this make sense?

We've got DRM_PRE_MODESET and DRM_POST_MODESET as well as
I915_GEM_LEAVEVT/I915_GEM_ENTERVT to play with here. It seems like
recording vblank numbers at suitable points within these functions could
help resolve the problem.

keith.packard at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: file:///tmp/nsmail-1.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: file:///tmp/nsmail-2.txt

Reply via email to