| Summary: | kdesktop_lock remained active after awakening | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Slávek Banko <slavek.banko> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bugwatch, kb9vqf, slavek.banko |
| Priority: | P1 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | 7cf0c0b4 | Application Name: | kdesktop_lock |
| Bug Depends on: | |||
| Bug Blocks: | 2014 | ||
| Attachments: |
kdesktop and kdesktop_lock backtrace
Forcibly terminate kdesktop_lock after unlock |
||
Created attachment 2370 [details]
Forcibly terminate kdesktop_lock after unlock
Does this patch fix the issue? It reverts a small part of GIT hash 2f7d50c2, restoring the R14 RC1 kdesktop_lock behavior at the expense of reintroducing a small bug where DCOP hangs and the screen locker does not engage.
Do you mind testing the patch? I need to know if it should be applied for R14 final. Thanks! (In reply to Timothy Pearson from comment #2) > Do you mind testing the patch? I need to know if it should be applied for > R14 final. > > Thanks! Yes, I built tdebase with this patch, installed on my test machine, and not once I observed the previous problem. It looks good. (In reply to Slávek Banko from comment #3) > (In reply to Timothy Pearson from comment #2) > > Do you mind testing the patch? I need to know if it should be applied for > > R14 final. > > > > Thanks! > > Yes, I built tdebase with this patch, installed on my test machine, and not > once I observed the previous problem. It looks good. OK, thanks! I'll apply it for the R14 final release then. Pushed to GIT in hash aaa719d. |
Created attachment 2368 [details] kdesktop and kdesktop_lock backtrace For the second time in a short time I have encountered a situation that kdesktop_lock remained active => input was still grabbed, even though the screen was active - saver is not running.