By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2775 - kdesktop_lock is incompatible with multiple screens layout
Summary: kdesktop_lock is incompatible with multiple screens layout
Status: NEEDINFO
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.x [Trinity]
Hardware: All Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2968
  Show dependency tree / graph
 
Reported: 2017-05-24 06:09 CDT by Nick Koretsky
Modified: 2023-12-07 09:39 CST (History)
6 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Koretsky 2017-05-24 06:09:35 CDT 
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)
Comment 1 deloptes 2018-01-13 15:23:08 CST 
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?
Comment 2 Nick Koretsky 2018-01-14 00:32:24 CST 
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.
Comment 3 Nick Koretsky 2018-01-14 05:57:27 CST 
The previous comment was wrong :( On next reboot i was not able to unlock. It seems random, sometimes it unlocks, sometimes not.
Comment 4 Nick Koretsky 2018-05-28 16:32:09 CDT 
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.
Comment 5 Michele Calgaro 2018-08-05 03:41:39 CDT 
Hi Nick,
there has been some recent changes to kdesktop_lock code. Are you able to check again when R14.0.5 is out?
Comment 6 Nick Koretsky 2018-08-06 09:06:10 CDT 
Are this changes already in preliminary stable build? I just upgraded and bug is still there.
Comment 7 Michele Calgaro 2018-08-06 09:21:41 CDT 
yes, they have been in PSB for a few weeks now. 
Thanks for the feedback, keeping the bug open.
Comment 8 Michele Calgaro 2019-03-02 06:32:39 CST 
Hi Nick,
there has been some changes in kdesktop_lock recently. Could you verify if those changes also fixed this problem? Thanks.
Comment 9 Nick Koretsky 2019-04-09 06:53:31 CDT 
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?
Comment 10 Michele Calgaro 2019-04-09 08:58:53 CDT 
Thanks for the feedback Nick. We will see if we can find a fix for R14.0.7
Comment 11 Slávek Banko 2019-04-09 09:02:04 CDT 
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.
Comment 12 Nick Koretsky 2019-04-09 09:49:40 CDT 
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.
Comment 13 Slávek Banko 2019-09-20 08:21:58 CDT 
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.
Comment 14 Slávek Banko 2019-11-28 13:20:26 CST 
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?
Comment 15 Nick Koretsky 2019-11-28 17:06:11 CST 
Nope, same exact problem.

I ask again, cant we just get an option to disable inactive session locking completely?
Comment 16 Nick Koretsky 2020-11-09 01:44:27 CST 
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.
Comment 17 Nick Koretsky 2023-12-07 09:39:01 CST 
Just want to remind that this bug still exist in R14.1.1 :(