Bug 612620 - Fade-out to screensaver cannot be reliably interrupted
Fade-out to screensaver cannot be reliably interrupted
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
14
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Patch, Reopened, Triaged
: 615786 620264 626472 629419 643184 (view as bug list)
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-07-08 11:50 EDT by James
Modified: 2012-08-24 08:02 EDT (History)
49 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.9.3-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-21 19:00:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
yum.log showing the packages that were update/installed on 2010-07-08 (6.05 KB, text/plain)
2010-07-09 13:26 EDT, Jeff Raber
no flags Details
dmesg output with drm.debug=0x04 after failed attempt to stop a fadeout (80.89 KB, text/plain)
2010-07-09 15:11 EDT, James
no flags Details
Xorg.0.log after failed attempt to stop fadeout (65.03 KB, text/plain)
2010-07-09 15:12 EDT, James
no flags Details
(NOT INTERRUPTED) Log generated by 'gnome-screensaver --no-daemon --debug' (16.66 KB, text/plain)
2010-07-12 17:25 EDT, Jeff Raber
no flags Details
(PROPERLY INTERRUPTED) Log generated by 'gnome-screensaver --no-daemon --debug' (1.96 KB, text/plain)
2010-07-12 17:29 EDT, Jeff Raber
no flags Details
.config for kernel.org kernel 2.6.34.1 (83.88 KB, text/plain)
2010-07-24 08:01 EDT, James
no flags Details
Root cause analysis 1 (15.79 KB, text/plain)
2010-08-10 00:12 EDT, Tim Taiwanese Liim
no flags Details
Fig.38 illustration on Def.1 and Def.3 of +/- transition alarms (33.57 KB, image/png)
2010-09-09 16:40 EDT, Tim Taiwanese Liim
no flags Details
Proof-of-concept patch to fix this issue based on Comment #49. (2.23 KB, patch)
2010-11-12 21:39 EST, Tim Taiwanese Liim
no flags Details | Diff
proof-of-concept patch with debug code. (6.50 KB, patch)
2010-11-12 21:41 EST, Tim Taiwanese Liim
no flags Details | Diff
proof-of concept patch v3. (need to undo previous patch first, then apply this patch) (2.06 KB, patch)
2010-11-17 00:33 EST, Tim Taiwanese Liim
tim.liim: review? (ajax)
Details | Diff
proof-of concept patch v3, with debug code. (need to undo previous patch first, then apply this patch) (6.06 KB, patch)
2010-11-17 00:36 EST, Tim Taiwanese Liim
no flags Details | Diff
proof that the user event is not generated the same tick when idle alarm is triggered (2.18 KB, text/plain)
2010-11-19 10:55 EST, Tim Taiwanese Liim
no flags Details

  None (edit)
Description James 2010-07-08 11:50:49 EDT
Description of problem:
With xorg-x11-server-Xorg-1.8.2-1.fc13, it is no longer possible to interrupt fade-out-to-screensaver with either a keypress or mouse movement.

Works OK under xorg-x11-server-Xorg-1.8.0-12.fc13.x86_64.

Version-Release number of selected component (if applicable):
gnome-screensaver-2.30.0-1.fc13.x86_64
gnome-power-manager-2.30.1-1.fc13.x86_64

[I understand this might be a X server bug, but I've filed it under g-ss for the time begin. Please reassign as appropriate.]
Comment 1 Jeff Raber 2010-07-08 17:55:53 EDT
I have the same package versions as mentioned in comment 1, but am unable to reproduce this issue.
Comment 2 James 2010-07-09 12:16:05 EDT
(In reply to comment #1)
> I have the same package versions as mentioned in comment 1, but am unable to
> reproduce this issue.    

Maybe it's hardware dependent. I have Intel X3100 graphics with xorg-x11-drv-intel-2.11.0-5.fc13.x86_64.
Comment 3 Jeff Raber 2010-07-09 12:38:14 EDT
Please add drm.debug=0x04 to the kernel command line, restart your computer, reproduce the issue, then attach to following items to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

Also, is the computer fading out to a screensaver, or to low power mode?
Comment 4 Jeff Raber 2010-07-09 13:26:08 EDT
Created attachment 430725 [details]
yum.log showing the packages that were update/installed on 2010-07-08

Yesterday I could not reproduce this issue.  Today I can.

I have attached a log showing the 80 packages (minus the debuginfo packages) that were installed/updated on my machine yesterday.

Prime suspects are 'libdrm' and 'kernel' and maybe 'xorg-x11-drv-vmmouse'.  In my free time, I will try downgrading each to see if that resolves the problem.
Comment 5 Nils Philippsen 2010-07-09 13:58:28 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > I have the same package versions as mentioned in comment 1, but am unable to
> > reproduce this issue.    
> 
> Maybe it's hardware dependent. I have Intel X3100 graphics with
> xorg-x11-drv-intel-2.11.0-5.fc13.x86_64.    

Sounds reasonable:

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

xorg-x11-drv-intel-2.11.0-5.fc13.x86_64
Comment 6 Jeff Raber 2010-07-09 14:50:12 EDT
Sorry, I should have mentioned mine is:
   ATI Technologies Inc RS690M [Radeon X1200 Series] [1002:791f]
Comment 7 James 2010-07-09 15:11:39 EDT
Created attachment 430743 [details]
dmesg output with drm.debug=0x04 after failed attempt to stop a fadeout
Comment 8 James 2010-07-09 15:12:19 EDT
Created attachment 430744 [details]
Xorg.0.log after failed attempt to stop fadeout
Comment 9 James 2010-07-09 15:15:05 EDT
(In reply to comment #3)
> Please add drm.debug=0x04 to the kernel command line, restart your computer,
> reproduce the issue, then attach to following items to the bug report as
> individual uncompressed file attachments using the bugzilla file attachment
> link above.
> 
> * your X server config file (/etc/X11/xorg.conf, if available),
> * X server log file (/var/log/Xorg.*.log)
> * output of the dmesg command, and
> * system log (/var/log/messages)
> 
> Also, is the computer fading out to a screensaver, or to low power mode?    

No xorg.conf. dmesg and Xorg logs attached. Not posting full /v/l/m since it contains IP addresses I don't want announced here; give me a grep cmdline to extract what's needed and I'll do it.

This is fading out to the screensaver. My laptop has no facility for software brightness control.
Comment 10 Kieran Clancy 2010-07-12 05:29:22 EDT
I also see this bug, with ATI Technologies Inc RV350 AR [Radeon 9600].
Comment 11 Nils Philippsen 2010-07-12 08:50:11 EDT
FWIW, I've found that it works again now for me since I rebooted in the meantime (Intel video chipset).
Comment 12 Nils Philippsen 2010-07-12 10:10:50 EDT
(In reply to comment #11)
> FWIW, I've found that it works again now for me since I rebooted in the
> meantime (Intel video chipset).    

And now again it doesn't... Not sure if that is because of the time the system/X server is running or something else.
Comment 13 jmccann 2010-07-12 15:10:10 EDT
I have also seen this on intel hardware but it doesn't happen every time.

Can you try to reproduce the problem while running "gnome-screensaver --no-daemon --debug" and attach the log from that here?
Comment 14 Jeff Raber 2010-07-12 17:25:52 EDT
Created attachment 431279 [details]
(NOT INTERRUPTED) Log generated by 'gnome-screensaver --no-daemon --debug'

Attaching the output of 'gnome-screensaver --no-daemon --debug'.  During this session I started moving the mouse and pressing keys on the keyboard moments after the 'fade' started.  While moving the mouse/pressing keys I noticed that no new debug messages were being printed in the terminal running gnome-screensaver.

A similar log from when the 'fade' was properly interrupted will be attached next.
Comment 15 Jeff Raber 2010-07-12 17:29:14 EDT
Created attachment 431281 [details]
(PROPERLY INTERRUPTED) Log generated by 'gnome-screensaver --no-daemon --debug'

Log generated by 'gnome-screensaver --no-daemon --debug' showing the screensaver being interrupted by moving the mouse.  This log was created just moments after the previous log, using the same PC/terminal/command line/etc.
Comment 16 Charles R. Anderson 2010-07-13 09:47:23 EDT
Same issue here:

gnome-screensaver-2.30.0-1.fc13.x86_64
xorg-x11-server-Xorg-1.8.2-1.fc13.x86_64
xorg-x11-drv-intel-2.11.0-5.fc13.x86_64
>uname -r
2.6.33.6-147.fc13.x86_64

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Comment 17 James 2010-07-24 08:01:24 EDT
Created attachment 434132 [details]
.config for kernel.org kernel 2.6.34.1

OK, this gets weirder: this problem goes away for me if I use a "vanilla" kernel.org kernel rather than the one from Fedora. Specifically:

  kernel.org 2.6.34.1  -- fine;
  kernel-2.6.34.1-29.fc13.x86_64  -- results in the bug.

I have attached the .config I have been using for the vanilla kernel.
Comment 18 James 2010-07-26 05:34:36 EDT
(In reply to comment #17)
> OK, this gets weirder: this problem goes away for me if I use a "vanilla"
> kernel.org kernel rather than the one from Fedora.

Actually scratch that, seems like a fluke. Like Comment 13, I now see it intermittently (even with kernels I've built myself).
Comment 19 Hannes Frederic Sowa 2010-08-07 19:03:51 EDT
I have the same issue and tried to debug it a little bit. I traced calls
to the function gs_fade_set_alpha while running gnome-screensaver with
"--gdk-debug=misc,events --gtk-debug=misc". At each breakpoint I printed the value of the alpha-argument to gs_fade_set_alpha. Albeit gdk receives the
keyboard-events gnome-screensaver keeps on fading.

Excerpt:
$214 = 0.5500000000000046
$215 = 0.5466666666666713
Gdk-Message: key press  :               window: 44040195         key:    Control_L  65507
Gdk-Message: property notify:   window: 44040195, atom(337): "_NET_WM_USER_TIME"
$216 = 0.543333333333338
$217 = 0.5400000000000047
Comment 20 D. Hugh Redelmeier 2010-08-08 22:51:53 EDT
I too see this on my Fedora 13 x86-64 desktop with all current updates.

My video card is an Asus EAH3650 Silent Magic.  That is a Radeon HD3650.
X is using the radeon driver from xorg-x11-drv-ati-6.13.0-1.fc13.x86_64
The kernel is kernel-2.6.33.6-147.2.4.fc13.x86_64

The uninterruptible fade started happening a couple of months ago (my memory is fuzzy, but it could have been when I installed F13 (in June) or after a subsequent update).

The problem seems to happen every time.

I have two menu entries under System:Preferences identically labelled "Screensaver".  The first is "Screensaver Preferences (XScreenSaver 5.11-8.1.fc13.respin1, 25-Jul-2010".  The other is the Gnome Screensaver.  When I switch between them, they want to stop the other's daemon and start theirs.  Neither solves the problem.
Comment 21 Tim Taiwanese Liim 2010-08-10 00:12:28 EDT
Created attachment 437758 [details]
Root cause analysis 1

I believe the issue is with Xorg, in Xext/sync.c.  Here is the trace.
I saw this issue about 60-80% of the runs, on several F13 with various
(three, that is) video cards.

#1 What is g-ss thinking?
   output from "gnome-screensaver --no-daemon --debug"; see [1] for details

   Good case:
        [_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (12:11:16):
		Changing idle notice state: 1
      <User hit a key>
        [watcher_idle_notice_cb] gs-monitor.c:125 (12:11:19):    
		Idle notice signal detected: 0  <=== '0' in good case

   Bad case:
	[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:202 (12:08:15):
		Changing idle notice state: 1
      <User hit a key>
	[watcher_idle_cb] gs-monitor.c:95 (12:08:25):    
		Idle signal detected: 1		<=== '1' in bad case

#2 Does g-ss receive that fading-interruption msg at all?
   output from "strace -tt -e read=all -e write=all -o g-ss.strace 
		gnome-screensaver --no-daemon --debug"; see [2] for details.
   Good case:
	write(2, "... Changing idle notice state: 1")
	read (6, "/org/gnome/SessionManager/Presence ... StatusChanged ..."
	write(2, "... Idle notice signal detected: 0")
   Bad case:
	write(2, "... Changing idle notice state: 1")
	write(2, "... Idle signal detected: 1")

   So in bad case, no, g-ss did not receive fading-interruption msg at
   all, which came in at fd 6.  Who sent (or should send) this msg?
   Luckily the sender announced its name in msg: SessionManager
   ("gnome-session", "g-s" for short).

#3 Why does g-s not sending the fading-interrupt msg?
   output from "strace -tt -e read=all -e write=all -o g-s.strace 
		-p $(pgrep gnome-session)" [3]
   - good case:
     g-s received a msg from fd 3,
	00:23:24.569436 read(3, "`\1\237\1\206\0\300\0\0"..., 4096) = 32
     then wrote "StatusChanged" msg on fd 6, which goes to g-ss (You
     can do strace on both g-s and g-ss at the same time to confirm;
     the msg content will be identical, but the time stamp will be
     slightly off.  There is a dbus in the middle acting as event
     channel, thus the delay.).
   - bad case:
     g-s receives no msg from fd 3; instead, at the end of fading, g-ss 
     sends "ActiveChanged" to inform g-s "screen saver started already."

#4 Who sent the msg to g-s on fd 3?
   This one took much tracing.  Previously (bug566350) I tracked it
   down to Xorg (the X sever), in Xext/sync.c.

   sync.c provides some counter services, one of which is the idle
   counter.  The idle counter (in msec) goes up as time passes, and
   resets to 0 upon user activity (mouse, keyboard).  (sync.c keeps a
   "last activity time stamp," which is updated with every user
   activity.  The idle counter is actually the difference of current
   time and last activity time stamp).

   g-ss uses two "alarms" on idle counter: positive transition
   ("+trans") and negative transition ("-trans").  Eg. with idle time
   set to 60 sec, g-ss registers two alarms: one +trans 60,000ms, the
   other -trans 60,000ms.  When the user idles, the idle counter goes
   from 0ms and up.  When it reaches 60,000ms or more, the +trans
   alarm is fired.  The "transition" means the alarm is fired only
   once when the counter cross the threshold.  When the user hits a
   key after idling for 70 sec, the counter drops from 70,000ms to
   0ms, triggering the -trans alarm (the counter was more than
   60,000ms, then becomes less then 60,000, thus a negative
   transition).

#5 How do I debug Xext/sync.c?
   For debug code, see bug591750 Coment#17.
   Also see bug591750 Coment#11 on how to run the debug code.
   For this bug, we will need this msg [4].
        "%s #5 SyncChangeCounter newval=%8u, oldval=%8u 
               pIdleTimeValueLess=%8d, pIdleTimeValueGreater=%8d\n"
   See [5] for output for good and bad cases.
   Note that the oldval is always 60000 in bad cases.
        oldval=   60000 pIdleTimeValueLess=    9999,
   In good cases, oldval is 60001-60003ms, but never 60000.

#6 So how is a "+/- transition" defined, exactly?
   See [6] for code listing; after stripping the anti-syntatic-sugar,
   they boil down to
        test #1 (+trans):  oldval <  test_value <= newval
        test #2 (-trans):  newval <= test_value <  oldval
   This works under all usual cases.  But here is a corner case that
   breaks this code.

  - Assume we have test_value of 60000ms, with a pair of +trans
    trigger (when the user is idle for >=60sec) and -trans (when the
    user is no longer idle, ie. idle time drops to be <60 sec from
    >=60 sec).
  - In good cases, the newval is usually 60001-60003ms when +trans
    passes test #1 
        oldval (eg.59999) <  test_value (60000) <= newval (eg. 60002)
    So when it comes to test for -trans, we have test #2
        newval (eg.  1ms) <= test_value (60000) <  oldval (eg. 60002)
    which is true, so the -trans is triggered, and g-ss is no longer idle.

  - In bad cases, the newval is always 6000ms when +trans passes test #1 
        oldval (eg.59999) <  test_value (60000) <= newval (eg. 60000)
    So when it comes to test for -trans, we have test #2
        newval (eg.  1ms) <= test_value (60000) <  oldval (eg. 60000)
    which is false, so the -trans is *not* triggered, and g-ss does not 
    receives no-longer-idle notice.

  - so I think test #2 should be
        newval (eg.  1ms) <  test_value (60000) <= oldval (eg. 60000)

#7 Changing test #2 to be
    SyncCheckTriggerNegativeTransition(SyncTrigger *pTrigger, CARD64 oldval) 
    { 
        return (pTrigger->pCounter == NULL || 
                (XSyncValueGreaterOrEqual(oldval, pTrigger->test_value) && 
                 XSyncValueLessThan(pTrigger->pCounter->value, 
                                       pTrigger->test_value))); 
    }
   And now my g-ss fading is interruptable, everytime.  It seems the
   proposed change in Xext/sync.c fixes this bug.


I opened
    bug622651 Xext/sync.c IDLETIME counter sometimes fails to fire 
              negative transition alarms
to track this issue in xorg-x11-server-Xorg-1.8.2-3.fc13.i686.

See the attachment for Notes [1]-[6], which is too long and boring for
the body of a bug comment.
Comment 22 Tim Taiwanese Liim 2010-08-10 00:18:29 EDT
These 4 bugs seems to be related, or are the same one.
  bug612620 Fade-out to screensaver cannot be interrupted 
            with xorg-x11-server-Xorg-1.8.2-1.fc13
  bug615786 As screensaver activates and screen dims cannot intervene 
            with mouse/keys
  bug620186 The fading of the screen when GNOME screensaver start is 
            not interruptible  
  bug620264 gnome-screensaver activates whether or not activity occurs 
            once dimming starts
Comment 23 Matt Chan 2010-08-10 00:38:07 EDT
*** Bug 615786 has been marked as a duplicate of this bug. ***
Comment 24 Matt Chan 2010-08-10 00:38:39 EDT
*** Bug 620264 has been marked as a duplicate of this bug. ***
Comment 25 Hannes Frederic Sowa 2010-08-10 22:04:58 EDT
(In reply to comment #21)

Thanks for your analysis. I updated my xserver with your proposed patch and it works well here.
Comment 26 Hannes Frederic Sowa 2010-08-11 06:27:34 EDT
(In reply to comment #25)
> Thanks for your analysis. I updated my xserver with your proposed patch and it
> works well here.    

Hm, bad news. I just had a couple of fade-outs that I could not interrupt.
Comment 27 Tim Taiwanese Liim 2010-08-11 23:31:10 EDT
Hannes,
Thanks for your independent verification that Fix #1 (Comment #21 item
#7) works in some cases (Comment #25), and your report of unsolved
cases (Comment #26).  Yesterday I started to notice the same unsolved
cases too, and it took me a while to track down the issue.

Here is an example of Issue #2, which is not covered by Fix #1.
    19:44:33.343 #5 SyncChangeCounter     newval=60000, oldval=21114, 
                                          pIdle<=-1, pIdle>=60000 
    19:44:33.344 #4 SyncAlarmTriggerFired alarm id 0x00c00005, counter=60000
    19:44:33.344 #9 SyncComputeBracketVal counte=60000, test  = 60000, psci<=0
    19:44:37.441 #7 IdleTimeQueryValue    idle  =    1, oldval=60000, 
                                          pIdle<=-1, pIdle>=   -1 

sync.c uses "pIdleTimeValueLess", "pIdleTimeValueGreater" (denoted as
"pidle<", "pIdle>" hereafter) to track when alarms should be
triggered.  They (pIdle<,pidle>) could be null pointer (denoted as
"-1" in my debug output), or some value (eg. 60000 msec).  For +trans
(-trans) alarms, sync.c checks current idle count against pIdle>
(pIdle<), *if* the pointer is not null.  

At "19:44:37.441 #7", when idle count goes from 60000 to 1 (idle = 1,
oldval= 60000; caused by user key activity),
    *** the -trans alarm should be triggered, but it is not. ***
Why?  Because pIdle< is null (denoted by "-1"), which is wrong; it
should be 60000ms for the -trans alarm from g-ss.

Who sets pIdle<?  "#9 SyncComputeBracketValues" does.  Look at this
code snippet:
    else if (pTrigger->test_type == XSyncNegativeTransition ...) {
        if (XSyncValueGreaterThan(pCounter->value, pTrigger->test_value) && 
            XSyncValueGreaterThan(pTrigger->test_value, psci->bracket_less)) 
It also has boundary condition issue.  Why this first test?
      pCounter->value > pTrigger->test_value    # Test#1
            eg. 60001 > 60000
Because we want to check for -trans, which means the idle counter
(pCounter->value) goes from above test_value to below test_value
(eg. from 60001ms to 1ms, which crosses the 60000ms boundary).  We
need this 2nd test
      pTrigger->test_value > psci->bracket_less # Test#2
to handle multiple -trans alarms, in which case we want the trigger
with largest test_value.

What happens to Test#1 in the case of this?
    19:44:33.344 #9 SyncComputeBracketVal counte=60000, test = 60000, psci<=0
It does not pass Test#1 (it should).
      pCounter->value > pTrigger->test_value    # Test#1
                60000 > 60000?  False.
So issue #2 has the same boundary issue: 60000 should be considered as
"above the threshold", as in Fix #1.


Fix#2:
Change Test#1 to
      pCounter->value >= pTrigger->test_value    # Test#1bis


After both Fix #1, Fix #2, I have not seen this issue again.  But then
again, the issue always pops up when you think you have it nailed :-).

I searched sync.c for "Negative" and look for similar pattern as in
Fix #1,#2.  There are only two occurences, fixed by #1,#2 separately.
So please let me know if you see further occurences.


Fix #1 (Comment #21 item #7)
    SyncCheckTriggerNegativeTransition(SyncTrigger *pTrigger, CARD64 oldval) 
    { 
        return (pTrigger->pCounter == NULL || 
                (XSyncValueGreaterOrEqual(oldval, pTrigger->test_value) && 
                 XSyncValueLessThan(pTrigger->pCounter->value, 
                                       pTrigger->test_value))); 
    }

Fix #2 
SyncComputeBracketValues(SyncCounter *pCounter) 
  else if (pTrigger->test_type == XSyncNegativeTransition && 
             ct != XSyncCounterNeverIncreases) 
  { 
    /*if (XSyncValueGreaterThan   (pCounter->value, pTrigger->test_value) && */
      if (XSyncValueGreaterOrEqual(pCounter->value, pTrigger->test_value) && 
          XSyncValueGreaterThan(pTrigger->test_value, psci->bracket_less))
Comment 28 Tim Taiwanese Liim 2010-08-11 23:41:27 EDT
Some thoughts on this issue.

1. Why 60-80% of the cases are bad?  Why not 100%?  Where is the
   randomness coming from?
   - Looks like it's from the timing.  When alarms are triggered, they
     may or may not be right on the requested moment.  It's perfectly
     fine to be late by a few msec.  When it's right on time, it
     turned out be a corner case (bug612620 Comment#21) that is not
     handled well by sync.c.

   - people with faster machine (than my 1997 vintage desktop) will
     probably experience higher rate (eg. 95%) of bad cases, because
     faster machines have higher chance to trigger the alarm right on
     time.

2. Why was it not an issue in F12?
   - in F12, the alarms is also triggered right on time, which
     _would_ be the corner case.  However in F12 sync.c always invoke
     SyncChangeCounter() a few more times than necessary, after the
     alarm is triggered. The net result is that the counter value is
     never right on the border.
	00:02:11.110 #5 SyncChangeCounter newval=60000, oldval=10003
	00:02:11.110 #4 SyncAlarmTriggerFired alarm id 0x00c0000d,counter=60000
	00:02:11.111 #5 SyncChangeCounter newval=60001, oldval=60000
     Note that "newval= 60001", not 60000 (the border, aka. 
     test_value).  In F12 the newval always ends up a few msec more 
     than the test value.

   - in F13, this extra invocation of SyncChangeCounter is
     eliminated.  So when the alarm is triggered, newval remains right
     on the border.
	17:34:58.532 #5 SyncChangeCounter newval=60000, oldval=20010
	17:34:58.533 #4 SyncAlarmTriggerFired alarm id 0x00c00015,counter=60000
	17:35:04.796 #5 SyncChangeCounter newval=    1, oldval=60000
     Note that, after #4 SyncAlarmTriggerFired, newval remains 60000,
     the boundary condition that exposes an existing old bug.  Also
     note that the second "#5 SyncChangeCounter" in F13 was 6 sec
     later, unlike F12, which is within 1 msec.

   - so my guess is that sync.c in F13 has some good improvements
     (removing extra calls to SyncChangeCounter), which exposes an
     existing old boundary-condition bug.
Comment 29 Hannes Frederic Sowa 2010-08-12 15:20:38 EDT
Again, thanks a lot! I am using your patch for some hours and have not seen a misbehaving gnome-screensaver so far.
Comment 30 Tim Taiwanese Liim 2010-08-13 00:21:22 EDT
Hannes,
Also thanks for your independent verification!  I tried my own fix
#1,#2 all day today, interrupted fading 100+ times without issue.
Looks like we have this issue fixed properly.

Anyone knows how to bring this issue and fix to the attention of Xorg
folks?  I filed
    bug622651 Xext/sync.c IDLETIME counter sometimes fails to fire 
              negative transition alarms
on the Xorg side, but saw no action on it yet.  We need them to review
and approve this two fixes and put into the source tree.
Comment 31 Tim Taiwanese Liim 2010-08-13 00:35:46 EDT
Adam,
Has this bug been fixed already in F13?  If so, can we close this bug?

While debugging
    bug612620 Fade-out to screensaver cannot be interrupted with 
              xorg-x11-server-Xorg-1.8.2-1.fc13  
I tested 
    xorg-x11-server-Xorg-1.8.2-3.fc13.i686
with the test case in Comment #3.  xorg 1.8.2-3 (with fix#1,#2 in
bug612620 Comment #27) actually performed properly, no missing alarms
as it did in F11, F12.  So please close this bug if you agree.
Comment 32 Tim Taiwanese Liim 2010-08-13 00:37:14 EDT
Oops, please ignore Comment #31.  It was meant for bug566350.
Comment 33 François Cami 2010-08-13 20:28:50 EDT
Change component to xorg-x11-server, assign to ajax.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 34 Tim Taiwanese Liim 2010-09-01 14:02:59 EDT
Adam,
Any news on this issue?  Anything we can help?  Thanks.
Comment 36 Tim Taiwanese Liim 2010-09-03 23:51:41 EDT
Hannes,
Thanks for info!  I checked out their fix just now.  It looks
like an awkward solution to a simple issue.  I still say the right and
simple solution is in Comment #27.

Adam,
Any news?
Comment 37 Chris Halse Rogers 2010-09-05 21:06:24 EDT
Both of those Ubuntu patches have gone to the X mailing list, and have been reviewed by Adam Jackson; once Xserver starts seeing some commits again I expect them to be applied to master.

I think the changes in https://bugzilla.redhat.com/show_bug.cgi?id=612620#c27 , while they will fix the gnome-screensaver issue, are wrong.  The SYNC extension defines a negative transition as triggered from a counter strictly *above* the threshold to ≤ the threshold, whereas the changes proposed will trigger from ≥ the threshold to < the threshold.

Gnome-screensaver is separately broken; they shouldn't be setting a positive & negative transition trigger with the same threshold.  There's a patch on the upstream GNOME bug for that.
Comment 38 Tim Taiwanese Liim 2010-09-09 16:40:41 EDT
Created attachment 446373 [details]
Fig.38 illustration on Def.1 and Def.3 of +/- transition alarms

Chris,
Thanks for replying!  Sure, you guys did the work on Xext/sync.c, so
you decide what to do.  I am just saying that there is an easier way
(Comment #27) to fix the same issue (and the problematic definition of
negative transition) without jumping through hoops (ie. schedule a 1ms
timer when the counter falls on the threshold, which occurs quite
often).  I am of the old school of "keep it simple and stupid."

For this bug, I saw 3 definitions of the transition counters; they
boil down to the following: (th=threshold, oldval=previous value of
counter, newval=new value of counter)

    Def.1 (Before any of these fix)
      +trans: triggers when oldval <  th && th <= newval
      -trans: triggers when newval <= th && th <  oldval

    Def.2 (from Chris, link in Comment #35)
      +trans: triggers when oldval <  th && th <= newval
      -trans: triggers when newval <  th && th <  oldval

      (Please correct me if I wrongly interpreted your definition; I got
       this interpretation from your comment
           The {Positive,Negative}Transition triggers only fire when the
           counter goes from strictly {below,above} the threshold.
       and your other comment
            * We've been called exactly on the idle time, but we have a
            * NegativeTransition trigger which requires a transition from
            * an idle time greater than this.  Schedule a wakeup for the
            * next millisecond so we won't miss a transition.
      )

    Def.3 (from Tim, Comment #27)
      +trans: triggers when oldval <  th && th <= newval
      -trans: triggers when newval <  th && th <= oldval

Def.1 can be interpreted as follows.  
Assume th=60; let th' = th -/+ epsilon (eg. 0.1) = 59.9/60.1.
  +trans: oldval < 59.9 && 59.9 < newval
  -trans: oldval < 60.1 && 60.1 < newval
This view results in the the same behavior as Def.1.  But in this view
it is obvious that, given the same th, +trans and -trans actually
occur on different thresholds (th -/+ epsilon, respectively).  See
attached Fig.38 for illustration.

From this point of view, Def.3 is more consistent than Def.1: Def.3
uses the same threshold (th - epsilon) for both +/- transition alarms
(see Fig.38).  It is also less surprising to the API users, as proven
by the usage of SYNC ext by g-ss and g-p-m (both use the same
threshold for +/- trans. alarms).



> The SYNC extension defines a negative transition as triggered from a
> counter strictly *above* the threshold to ≤ the threshold

If this is the case, why do you need to change anything?  The current
implementation (before your change) correctly implemented this
definition.  But could you point me to where this is defined?  [1]
seems to be the standard about SYNC ext, but it leaves the exact
definition of +/- trans. to the implementation.  [2] has concrete
definition, which is same as Def.1.  But [2] is a Programmer's Guide,
not a doc defining SYNC ext.

> I think the changes in [Comment #27] ... are wrong.

Yup, it committed the crime of going against a Programmer's Guide,
which is carved in the stone.  Reminded me of the guy who was in jail
for two years, because he failed to put a US. Federal-required label
on his UPS package.

Again, my thanks to you guys working on Xext/sync.c.  What I described
was just a suggestion, and hopefully an easier way for the same job.
You don't have have to heed or follow.


[1] X Synchronization Extension Library, Version 3.0, X Consortium
    Standard X Version 11, Release 6.4.  Tim Glauert, Dave Carver, Jim
    Gettys, David P. Wiggins; 1991.
    http://www.xfree86.org/current/synclib.pdf
    - no concrete definition of +/- transition.

[2] "X Synchronization Extension," X Window System Programmer's Guide
    Chapter 9
    "If the test-type is NegativeTransition, the trigger is initialize
    to FALSE and it will become TRUE when the counter changes form a
    value greater than the test value to a value less than or equal to
    the test value."
    http://www.google.com/url?sa=t&source=web&cd=11&ved=0CBcQFjAAOAo&url=http%3A%2F%2Flesstif.sourceforge.net%2Fdoc%2Fsuper-ux%2Fg1ae04e%2Fchap9.html&rct=j&q=x%20server%20sync%20extension&ei=IPCGTIbwJYKclgfv2NHRBQ&usg=AFQjCNF4b_tat55BFSfjQva0x5J6EhSOzA&cad=rja
Comment 39 Chris Halse Rogers 2010-09-09 20:38:59 EDT
My commit messages might have mislead you.  There are two commits there, neither of which change the definition of a +ve or -ve transition trigger.

The first one adjusts the bounds that the sync implementation is looking for.  Currently, if you've got a -ve transition threshold of 60, the sync code will ignore any event over 60 *and not update the current count*.  This was the main problem, which the first patch fixes by ensuring the bracket values where the sync code will respond to events are enough to get the current value *past* the thresholds.

This doesn't change the meaning of either a positive or negative transition, just ensures that they'll actually trigger in appropriate circumstances.

The second patch, requiring a wakeup in 1ms if we exactly hit the threshold, is really more for completeness than anything.  The server tends to get woken up multiple times in a millisecond anyway.

(In reply to comment #38)
...snip...
> > The SYNC extension defines a negative transition as triggered from a
> > counter strictly *above* the threshold to ≤ the threshold
> 
> If this is the case, why do you need to change anything?  The current
> implementation (before your change) correctly implemented this
> definition.  But could you point me to where this is defined?  [1]
> seems to be the standard about SYNC ext, but it leaves the exact
> definition of +/- trans. to the implementation.  [2] has concrete
> definition, which is same as Def.1.  But [2] is a Programmer's Guide,
> not a doc defining SYNC ext.
> 
> > I think the changes in [Comment #27] ... are wrong.
> 
> Yup, it committed the crime of going against a Programmer's Guide,
> which is carved in the stone.  Reminded me of the guy who was in jail
> for two years, because he failed to put a US. Federal-required label
> on his UPS package.

I'm sorry if I caused offence.  I didn't mean to denigrate your work; indeed, your analysis of the problem was very helpful.  I meant that I think changing the meaning of the triggers is not the correct way to solve the problem.  Other applications using SYNC objects other than IDLETIME might be broken by changing the meaning.
Comment 40 Tim Taiwanese Liim 2010-09-10 00:39:24 EDT
Chris,
Understand, thanks.

> ... changing the meaning of the triggers is not the correct way to
> solve the problem.

This I agree.  I made the proposal, not because it's a short cut to
solve the issue at hand, but because I think the current definition of
-ve trigger is questionable.  The fact that the proposal happened to
solve this current issue is a bonus.

> Other applications using SYNC objects other than IDLETIME might be
> broken by changing the meaning.

Don't we do this all the time ;-), in open source world.  I still have
hard time with gthumb 2.11.x, which is a complete rewrite from 2.10.x.
Many of the old functionalities are still missing.
Comment 41 Adam Jackson 2010-10-11 16:10:04 EDT
Fixed in 1.9.0
Comment 42 Tim Taiwanese Liim 2010-10-11 22:53:04 EDT
Adam,
Thanks!  Appreciate your effort.
Comment 43 Nils Philippsen 2010-10-13 04:32:22 EDT
I still have this issue in xorg-x11-server-Xorg-1.9.0-13.fc14.x86_64.
Comment 44 Tim Taiwanese Liim 2010-10-16 12:53:53 EDT
Agree with Nils.  I tried xorg-x11-server-1.9.0-15.fc14.src.rpm and
was unable to stop fading 15 out of 367 tries (~4% failure rate).
This is big improvement, compared to >90% in 1.8.2-4 in F13.

Still, this bug is not fixed completely.  (I still say the current
definition of negative transition is bad for life (but not wrong), and
could be deprecated after communication with its users.  More widely-
used standards evolved in the past (check the IETF standards for
example), and this -ve trans. definition is not even defined in the
standard.  But hey, Adam is the owner of the module.  I just present
my argument (aka nagging :-) and whatever Adam decides is good for
me.)

For the failed cases, I still saw this (my own) debugging msg:
    10/16 09:15:50.053 #5 SyncChangeCounter newval=   60000
This msg suggests the fix in Comment #35, Comment #39 missed some
scenarios.
Comment 45 Chris Halse Rogers 2010-10-18 23:17:05 EDT
That looks like you're hitting the gnome-session problem I alluded to earlier - that's https://bugzilla.gnome.org/show_bug.cgi?id=627903 .
Comment 46 Tim Taiwanese Liim 2010-10-18 23:46:03 EDT
Chris,
I still have this question. Could you point out what is wrong with the
following scenario?
  - set a +ve trans (60000ms) and a -ve trans (60000ms also) alarm.
  - the +ve trans fires at idle_counter=60000
  - 5 sec later (so idle_counter=65000) the user hit a key to
    interrupt fading.
  - idle_counter goes from 65000 to 0.
Any reason why the -ve trans (60000) should not be fired?
Comment 47 Chris Halse Rogers 2010-10-19 00:36:08 EDT
That's the bug which *should* have been fixed by the xserver patches.  They certainly fix at least one problem which caused that behaviour; there may be other bugs I didn't pick up.

The gnome-session bug is where the +ve transition fires at idle_counter=60000 and in the same tick some input events are generated, so idle_counter never goes above 60000 and the -ve transition (correctly) is never triggered.
Comment 48 Robert de Rooy 2010-10-19 14:47:34 EDT
I just had this occur 2 out of 3 times on a T410 with Intel HD Graphics running f14 64bit with all updates. 

kernel-2.6.35.6-46.fc14
xorg-x11-drv-intel-2.12.0-6.fc14
xorg-x11-server-1.9.0-15.fc14
Comment 49 Tim Taiwanese Liim 2010-10-19 23:18:10 EDT
Re: Comment #47
Chris,
> ... and in the same tick some input events are generated, so
> idle_counter never goes above 60000

Will you believe me if I claim I can generate the input event
(keyboard or mouse), on the same tick (within 1 msec time window) when
idle_counter=60000, with >90% probability in F13 and 4% in F14?  I
don't believe such claim; for humans (me included), <0.01% maybe,
definitely not 4% or 90% or 2 out of 3 times.

Here is what I think we overlooked.
  - when determining to trigger an alarm or not, sync.c uses previous
    counter value and new counter value to compare with test_value.

  - This (using previous counter value) is adequate for non-system
    counter, because such counter value change must go through
    SyncChangeCounter(), ie. pCounter->value does not change on its
    own.

  - Unfortunately for idle_counter, the *apparent* value does change
    as time goes by, without invoking SyncChangeCounter().  Why?
    Because idle_counter value is defined as
        idle = GetTimeInMillis() - lastDeviceEventTime.milliseconds;
        /* ie. idle = now - lastEventTime; */
    which changes on its own (GetTimeInMillis() returns different
    value for each milli sec).

  - in view of the above, for idle_counter, we should save
    lastDeviceEventTime.milliseconds in some local variable, eg.
    prevLastDeviceEventTime.  When oldval is needed, instead of
        oldval = pCounter->value;  
        /* adequate only for non-system counters */
    we should use 
        oldval = GetTimeInMillis() - prevLastDeviceEventTime; 
        /* for idle_counter */
    so the current idle_counter value is properly updated.

With this change, the different definitions in Comment #38 become
largely irrevelant: they occur only on rare occasions.
Comment 50 tobyknudsen@gmail.com 2010-10-29 10:57:55 EDT
(In reply to comment #41)
> Fixed in 1.9.0

I observed this problem continued yesterday, 10/28/2010.  Let me know if I can assist with any testing.  tobyknudsen@gmail.com
Comment 51 Nils Philippsen 2010-10-29 12:01:44 EDT
I noticed that the events are sometimes processed out of order: When scrolling with the scroll wheel (well, synaptics touch pad right hand side), _afterwards_ pressing "Control" chromium sometimes zooms in/out of a page, i.e. it recognizes the "Control" key as happening during the scroll-whell action. Is this related to this problem?
Comment 52 Jon Dufresne 2010-10-30 16:48:19 EDT
*** Bug 629419 has been marked as a duplicate of this bug. ***
Comment 53 James 2010-11-03 10:54:03 EDT
Still not fixed in F14, update released. Just observed with:

gnome-screensaver-2.30.2-2.fc14.x86_64
xorg-x11-server-Xorg-1.9.1-2.fc14.x86_64
Comment 54 Steevithak 2010-11-04 14:05:30 EDT
I'm experiencing this bug on F13 and F14 on my Dell Inspiron 8600 laptop.
Comment 55 vadi01 2010-11-06 18:22:15 EDT
Confirm the same in lenovo t510 with f14
Comment 56 Need Real Name 2010-11-07 16:41:37 EST
*** Bug 643184 has been marked as a duplicate of this bug. ***
Comment 57 Tim Taiwanese Liim 2010-11-12 21:39:10 EST
Created attachment 460189 [details]
Proof-of-concept patch to fix this issue based on Comment #49.

Re: Comment #55, Comment #54, Comment #53, Comment #50
Me too, observed this issue on F14 with 80-90% occurence, about the
same frequency as in F13.

Here is a proof-of-concept patch, based on my Comment #49.  Anyone
interested please try it out and see how it goes for you.  Thanks.
When I tried it, I was able to break the gamma fading all the time.
As a prototype patch, I also added a flag file
"/tmp/disable.bug612620.fix" so you can enable/disable the proposed
fix on the fly.


Adam,
Chris,
If you don't mind, would you please review the proposed patch?
Thanks.
Comment 58 Tim Taiwanese Liim 2010-11-12 21:41:53 EST
Created attachment 460190 [details]
proof-of-concept patch with debug code.

Here is the same proof-of-concept patch, with debug code.  So those
who are interested can observe the behavior of sync.c themselves.
Comment 59 Tim Taiwanese Liim 2010-11-12 21:43:54 EST
Re: Comment #51
Nils,
No, my opinion was these two are separate issues.  Bug612620 is caused
by negative transition alarms not fired properly.  Comment #51 is for
apparent out-of-sequence event delivery.  I suggest we open another
bug to track Comment #51.
Comment 60 James 2010-11-13 10:25:13 EST
(In reply to comment #58)
> Created attachment 460190 [details]
> proof-of-concept patch with debug code.
> 
> Here is the same proof-of-concept patch, with debug code.  So those
> who are interested can observe the behavior of sync.c themselves.

Tim, I'm using this patch against xorg-x11-server-Xorg-1.9.1-3.fc14, and it seems to be working (around 6 tests, each one successfully interrupted).
Comment 61 Tim Taiwanese Liim 2010-11-14 01:46:34 EST
Re: Comment #60
James,
Thanks for testing out the patch!  And nice to know it worked for you.
Let's test a bit more and see how the patch holds.
Comment 62 Tim Taiwanese Liim 2010-11-17 00:33:14 EST
Created attachment 460990 [details]
proof-of concept patch v3.  (need to undo previous patch first, then apply this patch)

I found some issue with previous patch in Comment #57, Comment #58, so
here is a second try.  The issue: when g-p-m (gnome-power-manager)
doubles its timeout to be beyond that of g-ss (eg. g-ss has 60 sec
timeout, and g-p-m has 80 sec timeout; see bug566351 Comment #1),
pIdleTimeValueLess was not updated properly.  To test this scenario
without much waiting, do
    k=/apps/gnome-power-manager/backlight/idle_dim_time
    gconftool-2 -g $k             # note down this number
    gconftool-2 -s $k -t int 80   # remember to set it back when done

Remember to undo previous patch before applying this one.  This patch
is also based on Comment #49.

Adam,
Chris,
James,
Would you please review this patch as well?
Thanks.
Comment 63 Tim Taiwanese Liim 2010-11-17 00:36:02 EST
Created attachment 460991 [details]
proof-of concept patch v3, with debug code.  (need to undo previous patch first, then apply this patch)

Here is the same proof-of-concept patch v3, with debug code.  So those
who are interested can observe the behavior of sync.c themselves.
The debug output is in /var/log/gdm/:0.log.
Comment 64 Tim Taiwanese Liim 2010-11-19 10:55:45 EST
Created attachment 461586 [details]
proof that the user event is not generated the same tick when idle alarm is triggered

Re: Comment #47
Chris,
> ... and in the same tick some input events are generated, so
> idle_counter never goes above 60000

Here is a proof that the event is NOT generated "in the same
tick."    
    00:26:37.032 last user event before idle, last event time=444440660
    00:27:37.032 60 sec later, idle alarm fired, counter=   60000
    00:27:41.631 4 sec later, user hit a key, but the -ve trans. alarm is not
                 triggered.  Bad behavior.
                 last event time=444505260
                 time since last user event = 444505260 - 444440660 = 64600 ms

Original log: (see attached file for easier-to-read formatting):
00:26:37.032 #6 IdleTimeQueryValue now=444440660, last event time=444440660, diff=       0
00:26:53.032 #5 SyncChangeCounter newval=   16001, oldval=       4, pIdle<=      -1, pIdle>=   16000
00:26:53.032 #4 SyncAlarmTriggerFired alarm id 0x01800003, counter=   16001
00:26:53.035 #1 ProcSyncCreateAlarm   alarm id 0x0180006b, type=XSync-Trans, value=   16000
00:27:37.032 #5 SyncChangeCounter newval=   60000, oldval=   16004, pIdle<=   16000, pIdle>=   60000
00:27:37.032 #4 SyncAlarmTriggerFired alarm id 0x0080000b, counter=   60000
00:27:41.631 #6 IdleTimeQueryValue now=444505260, last event time=444505260, diff=       0
00:27:41.631 #5 SyncChangeCounter newval=       0, oldval=   60000, pIdle<=   16000, pIdle>=      -1
00:27:41.632 #4 SyncAlarmTriggerFired alarm id 0x0180006b, counter=       0
00:27:41.633 #2 ProcSyncChangeAlarm   alarm id 0x01800003, type=XSync+Trans, value=   16000
00:27:41.633 #3 ProcSyncDestroyAlarm  alarm id 0x0180006b
00:27:41.770 #6 IdleTimeQueryValue now=444505399, last event time=444505399, diff=       0
00:27:43.270 #6 IdleTimeQueryValue now=444506899, last event time=444506899, diff=       0
00:27:43.405 #6 IdleTimeQueryValue now=444507034, last event time=444507033, diff=       1
00:27:43.549 #6 IdleTimeQueryValue now=444507178, last event time=444507177, diff=       1
00:27:43.652 #6 IdleTimeQueryValue now=444507281, last event time=444507281, diff=       0
00:27:43.789 #6 IdleTimeQueryValue now=444507418, last event time=444507418, diff=       0
00:27:43.883 #6 IdleTimeQueryValue now=444507512, last event time=444507512, diff=       0
Comment 65 Dave Jones 2010-11-19 20:49:37 EST
*** Bug 626472 has been marked as a duplicate of this bug. ***
Comment 66 James 2010-11-20 07:12:12 EST
(In reply to comment #62)
> Created attachment 460990 [details]
> proof-of concept patch v3.  (need to undo previous patch first, then apply this

Still using the older patch, all interruptions working still. Will test new patch.
Comment 67 James 2010-11-23 15:48:10 EST
Using the new patch now. Seems to be working OK so far!
Comment 68 Matěj Cepl 2010-11-24 08:27:27 EST
Could we close this?
Comment 69 Nils Philippsen 2010-11-24 08:45:34 EST
(In reply to comment #68)
> Could we close this?

Um, no (official) package with this patch is built (yet)?
Comment 70 Matěj Cepl 2010-11-24 09:02:43 EST
(In reply to comment #69)
> (In reply to comment #68)
> > Could we close this?
> 
> Um, no (official) package with this patch is built (yet)?

Right, leaving it as it is.
Comment 71 Nils Philippsen 2010-11-24 11:03:19 EST
(In reply to comment #59)
> I suggest we open another bug to track Comment #51.

I'm pretty sure it's related to the "coasting" feature of the synaptics driver, I opened up bug #656977 for that issue.
Comment 72 Kaare Fiedler Christiansen 2010-12-01 02:27:17 EST
I'm now using the patch from Comment #62 and can confirm that I can now interrupt fading reliably. Before that, it was impossible to interrupt the fade 90% of the time. Thank you.

xorg-x11-server-Xorg-1.9.1-3.fc14.i386
gnome-session-2.32.0-1.fc14.i686
gnome-screensaver-2.30.2-2.fc14.i686

System: http://www.smolts.org/client/show/pub_1b5e24f5-9357-4c27-b485-1c332c93e67b
Comment 73 James 2010-12-02 09:54:28 EST
Well I'm happy using a hand-built server with Tim's patch, so is there now any chance of an update for Fedora 14 with this fix included?
Comment 74 Tim Taiwanese Liim 2010-12-18 15:09:09 EST
James,
Kaare,
Thanks!  For trying out the proposed patch and confirming it works
reasonably well.


Nils,
Matej,
James,
Yes, I am still trying to convince Adam and Chris (owners of this
issue) that the issue is in Xext/sync.c and should be fixed in sync.c,
not in other modules (Chris Comment #45).  I provided proof in Comment
#64 and patch in Comment #62, waited for Adam or Chris to either
concur or disprove, but got no response so far.  The last time I heard
from them was around mid-October (Comment #41, COmment #47).

> ... is there now any chance of an update for Fedora 14 with this fix
> included?

I am curious too.  Adam and Chris would know, but they are not
responding.
Comment 75 Kaare Fiedler Christiansen 2010-12-18 15:38:03 EST
As a curiosity, if I have a VMWare player running, and release the keyboard from the VMWare client (Windows XP) to the host (Fedora 14) after a period of inactivity, the screen will start fading uninteruptably at that point, with or without the patch.

This may be intended behaviour, since any other behaviour would mean that an active and focused VMWare player would effectively disable the screen lock. However, it's still annoying to have to wait for the fade to complete.

The fading seems to take a very different length of time before completing, though.

These are all just observations that I am unsure whether have anything to do with the bug at hand, I leave that to the maintainers.

Best,
  Kåre
Comment 76 Chris Halse Rogers 2010-12-18 23:50:27 EST
Ah.  The reason why this isn't fixed in Xserver 1.9 is that the patches didn't get applied, and I didn't notice because (a) we had applied these in Ubuntu and (b) we hadn't updated the X server until now.

Adam has pinged the upstream xserver maintainer to get those patches applied.

There is still a gnome-session bug, but you're quite unlikely to hit it - it requires microsecond timing to trigger.
Comment 77 Fedora Update System 2010-12-20 10:42:06 EST
xorg-x11-server-1.9.3-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.3-3.fc14
Comment 78 Fedora Update System 2010-12-20 17:05:38 EST
xorg-x11-server-1.9.3-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.3-3.fc14
Comment 79 Eduardo Habkost 2010-12-21 06:52:49 EST
The update works for me if I wait for the screensaver timeout (I can interrupt the fade-out now). But I can't interrupt the fade-out if I use 'gnome-screensaver-command -a'. Should that go to a new bug report?
Comment 80 James 2010-12-21 07:25:09 EST
(In reply to comment #79)
> But I can't interrupt the fade-out if I use
> 'gnome-screensaver-command -a'. Should that go to a new bug report?

Is this not the intended behaviour, a-la System/Lock Screen? (In other words, why would you want to interrupt a fade you deliberately invoked?)
Comment 81 Eduardo Habkost 2010-12-21 07:44:53 EST
(In reply to comment #80)
> (In reply to comment #79)
> > But I can't interrupt the fade-out if I use
> > 'gnome-screensaver-command -a'. Should that go to a new bug report?
> 
> Is this not the intended behaviour, a-la System/Lock Screen? (In other words,
> why would you want to interrupt a fade you deliberately invoked?)

Because I can interrupt it as soon as the fade-out finishes. Screen locking is not enabled here, I am just starting the screensaver, not locking the screen.

I don't care about it as I don't use 'gnome-screensaver-command -a', but maybe the developers (or an user who uses gnome-screensaver-command for some reason) see it as a bug.
Comment 82 Fedora Update System 2010-12-21 18:59:59 EST
xorg-x11-server-1.9.3-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 83 D. Hugh Redelmeier 2011-01-20 23:04:01 EST
It would be nice to fix this in Fedora 13 too (that's where the original problem was found).
Comment 84 Kieran Clancy 2011-03-15 23:18:29 EDT
Can this please be fixed in F13?
Comment 85 Richard Baxter 2012-08-14 06:20:53 EDT
Fade-out to screensaver (eg blank screen) cannot be interrupted in EL6.3.
Comment 86 Nils Philippsen 2012-08-15 09:14:19 EDT
(In reply to comment #85)
> Fade-out to screensaver (eg blank screen) cannot be interrupted in EL6.3.

Please open a support case in this case, or at least open a new bug against EL6. Commenting in a closed Fedora bug won't help...
Comment 87 Richard Baxter 2012-08-24 08:02:59 EDT
I figured that might be the case and opened a new support case here; https://bugzilla.redhat.com/show_bug.cgi?id=848016

Note You need to log in before you can comment on or make changes to this bug.