| Summary: | kdesktop_lock is incompatible with multiple screens layout | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Nick Koretsky <nick.koretsky> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEEDINFO --- | ||
| Severity: | normal | CC: | bugwatch, deloptes, michele.calgaro, mrmazda, nick.koretsky, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2968 | ||
commit 4c308190789d7f5ffc940d70dd5ea8a002fa4b30 Author: Roman Savochenko <rom_as@oscada.org> Date: Sun Jul 30 10:48:57 2017 +0200 Add brightness keys support The code partially taken from Qt4 This relates to bug 2775 Signed-off-by: Roman Savochenko <rom_as@oscada.org> Is this resolved? Upgraded to preliminary stable to check: yes it is resolved for the most part. Second screen do present lock dialog at startup but it can be unlocked and everything works fine after that. The previous comment was wrong :( On next reboot i was not able to unlock. It seems random, sometimes it unlocks, sometimes not. BTW, i believe the is a simple way to check the presence of this bug without having a second monitor or messing with your monitor setup. Just startx a second TDE session, and if you get a lock screen there or on first session when you switch back to it or a kdesktop_lock process eating a 100% CPU then you will get this bug on multi-screen setup. Hi Nick, there has been some recent changes to kdesktop_lock code. Are you able to check again when R14.0.5 is out? Are this changes already in preliminary stable build? I just upgraded and bug is still there. yes, they have been in PSB for a few weeks now. Thanks for the feedback, keeping the bug open. Hi Nick, there has been some changes in kdesktop_lock recently. Could you verify if those changes also fixed this problem? Thanks. Are this changes in 14.0.6 ? If yes, then no, the bug is still there. If detecting multi screen setup correctly is too problematic, can't you just add a setting somewhere that disables locking of "inactive" X sessions? Thanks for the feedback Nick. We will see if we can find a fix for R14.0.7 I assume that this occurs when one and the same user is logged in to multiple X sessions? Is SAK off? SAK can never work with multiple sessions. SAK if off. In my case this happens with a multi monitor setup configured as multiple X screens, not a single screen with multiple monitors. But this same behavior is present with actual multiple X sessions as a same user - when you switch sessions "inactive" one gets locked. I once again looked at this problem and I suspect if another of the files in ~/.trinity/socket-<hostname>/ should be unique for $DISPLAY. However, files that are not unique now only concern the arts server - MCOP interface. Right now, on my test machine (with R14.0.7~pre), I have two sessions of the same user running - first on DISPLAY=:0, second on DISPLAY=:1. And everything looks fine - no unwanted CPU load, no screen lock / unlock issues. SAK is off, of course. Nick, please can you verify if the problem persists with R14.0.7~pre on your configuration? Nope, same exact problem. I ask again, cant we just get an option to disable inactive session locking completely? Still present in R14.0.9, but in slightly different form. There is no "desktop session locked" dialog, but both screens flicker constantly and dont respond to input. Still "solved" by deleting kdesktop_lock. Just want to remind that this bug still exist in R14.1.1 :( |
If you add something like this Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen 0" 1920 0 Screen 1 "Screen 1" 0 0 to xorg.conf upon logging into tde session you will be presented with "desktop session locked" dialog which cannot be unlocked (to be precise - it relocks immediately). The only way i found to avoid this is to remove kdesktop_lock executable. This seems to stems from kdesktop_lock attempting to constantly lock "inactive" X sessions, the behavior that i find weird and which should at least have some way to be disabled (if there is any reason for it in the first place)