| Summary: | [Regression] Kaffeine does not block screensaver | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Slávek Banko <slavek.banko> |
| Component: | non-core programs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, darrella |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | All | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Slávek Banko
2012-02-15 13:49:54 CST
Confirmed. Works fine in 3.5.10 and Kaffeine 0.8.8. I started kaffeine and redirected stdout/stderr to a log. Before starting kaffeine I set my screen saver timeout to 60 seconds, which is the shortest value possible through KControl. Using tail I confirmed kaffeine is sending fake mouse movements every 55 seconds, which is the hard-coded default time (kaffeine.cpp:250). The kdebug message (kaffeine.cpp:1580) looks like this: kaffeine: Kaffeine: Fake mouse movement Looking at kaffeine.cpp indicates that in order to send that debug message kaffeine first must establish communications with twin (kaffeine:243). That too is confirmed with another debug message (kaffeine.cpp:245) in the stdout/stderr log: kaffeine: Window manager: KWin found Monitoring kaffeine while playing a video indicates twin does not always process the fake mouse movement. That is, sometimes the screen saver kicks in, then the kaffeine fake mouse movement halts the screen saver. Yet at other times a fake mouse movement is issued as observed by monitoring/tailing the stdout/stderr output, and a moment later the screen saver kicks in --- as though the fake mouse movement was never issued. I believe twin is not seeing the fake mouse movements or, if seeing them, is not processing them. Kaffeine sends the fake mouse movements through X (kaffeine.cpp:1581-1582). At the moment my guess is the dcop link between the two processes. Unknown whether there is any relationship, I am unable to start kdcop. This is with the latest GIT. (Odpověď na komentář #2) > > Monitoring kaffeine while playing a video indicates twin does not always > process the fake mouse movement. That is, sometimes the screen saver kicks in, > then the kaffeine fake mouse movement halts the screen saver. Yet at other > times a fake mouse movement is issued as observed by monitoring/tailing the > stdout/stderr output, and a moment later the screen saver kicks in --- as > though the fake mouse movement was never issued. > > I believe twin is not seeing the fake mouse movements or, if seeing them, is > not processing them. > > Kaffeine sends the fake mouse movements through X (kaffeine.cpp:1581-1582). At > the moment my guess is the dcop link between the two processes. > > Unknown whether there is any relationship, I am unable to start kdcop. > > This is with the latest GIT. Thank you for your excellent research. Confirms my conclusion: "I would like to see corrected, but even after repeated studying the source code I found nothing. I'm starting to worry that the problem is elsewhere - perhaps in kwin?" ( from http://trinity-users.pearsoncomputing.net/?0::2922 ) Yes, I think the problem is twin or dcop. Modifying the report to a regression for easier identification. Fixed in GIT hash 80deb529 (tdebase). Now, how did you discover that? :-) (Odpověď na komentář #7)
> Now, how did you discover that? :-)
The beginning was your impetus to update the kdeclassic icons. Because for v3.5.13.1 I still have no changes in tdeartwork, so I cloned it first time. In doing so I noticed the screen savers. It gave me the impetus to re-start bug hunt - this time begining from the code of screen savers. After a while I got to the code xautolock where I found HAVE_XIDLE and HAVE_SCREENSAVER. And so it was obvious where to go next...
|