• Lightdm + lightlocker under Gnome research for a working solution


    Hello again!

    Well, it seems I have found a working solution!!!

    This is what I’ve done. As I suspected the cause could be one of the different plugins of the gnome settings daemon, I tried to disable each one of the possible ‘culprits’:

    /etc/xdg/autostart/org.gnome.SettingsDaemon.ScreensaverProxy.desktop
    

    I didn’t get the expected result. It seems to be connected with the Gnome screensaver but it didn’t stop the rewriting of the screensaver rules. In order to disable it, what I did was:

    OnlyShowIn=KDE;
    #OnlyShowIn=GNOME;
    

    If you try to rename or erase the file, Gnome shell simply won’t start.

    • Xsettings
    /etc/xdg/autostart/org.gnome.SettingsDaemon.XSettings.desktop
    

    I thought that this could also be affecting the xset parameters, but it produced no changes, at least, in what we are looking for (the icon themes didn’t work correctly and they defaulted to Adwaita)

    • Power
    /etc/xdg/autostart/org.gnome.SettingsDaemon.Power.desktop
    

    This is it!!! If you disable the power plugin and obviously lose all the power saving functions that you can use in Gnome, light locker and any xsettings work out of the box and they remain in the same values all the time. I’ve had it working for a few hours now without problem. The only little thing I’ve detected is that light locker settings sets the ‘turn off screen’ value in the first place instead of the third position, that is:
    Light locker settings to turn off screen after four minutes:

    Exec=xset s 0 dpms 240 0 0
    

    But it should be:

    Exec=xset s 0 dpms 0 0 240
    

    If I remember correctly, gnome power settings could be disabled globally with the dconf editor in the past, but that key seems not to be available anymore.

    I hope this can be of any help to you. Please test and share your results!!!

  • @johnnybegood thanks! i will have a try if i get time!

  • Last weekend, I’ve spend many hours diagnosis Gnome/Lightdm/light-locker problem.

    Here are some details I got:

    1. Screensaver and locking feature using lightdm/light-locker depend on xset function. xset is responsible for taking care of some settings in your computer, among other: it turn off your screen after x time idling (xset dpms 300), it blank your screen (showing all black pixel) after x time idling (xste s 300).
    2. screensaver-settings.desktop in autostart folder configure xset to desired settings when your computer start.
    3. Light-locker-settings is a tool responsible to gather your parameters for xset and save them in “screensaver-settings.desktop” so it can automatically launch at startup and setup xset as you wish. Light-locker-settings is a python script (see: light-locker-settings.py in Antergos github repo). When you open Light-locker-settings tool, it read “xset q” (See: line 518 of light-locker-settings.py) instead of reading it’s own file (screensaver-settings.desktop).

    So, in short, what happen is this : You open Light-locker-settings, you set it up as you wish, you close it. Your screensaver eventually trigger, your computer get locked. You comeback and unlock your computer. Your xset configuration get overridden. You get away from your keyboard again. Your realize that your screen stayed open and that your computer didn’t lock. You open Light-locker-settings to see what is wrong. It read the overridden data from xset and show it to you and it also override your screensaver-settings.desktop file with xset overridden datas.

    Here are some points that I keep in mind:

    • GDM work well with gnome because it don’t relay on xset.
    • It could be a good idea to make Light-locker-settings.py read from it’s own screensaver-settings.desktop instead of read xset datas.
    • We have to find when, why and how xset datas get overridden and we will be able to correct this bug.

    @johnnybegood seems to be on a good track!

    I would be curious to have @lots.0.logs thoughts on this since he coded Light-locker-settings.

    P.S. sorry about my English, I feel like it is poorly written.

  • @johnnybegood said in Lightdm + lightlocker under Gnome research for a working solution:

    Hello again!

    Well, it seems I have found a working solution!!!

    This is what I’ve done. As I suspected the cause could be one of the different plugins of the gnome settings daemon, I tried to disable each one of the possible ‘culprits’:

    /etc/xdg/autostart/org.gnome.SettingsDaemon.ScreensaverProxy.desktop
    

    I didn’t get the expected result. It seems to be connected with the Gnome screensaver but it didn’t stop the rewriting of the screensaver rules. In order to disable it, what I did was:

    OnlyShowIn=KDE;
    #OnlyShowIn=GNOME;
    

    If you try to rename or erase the file, Gnome shell simply won’t start.

    • Xsettings
    /etc/xdg/autostart/org.gnome.SettingsDaemon.XSettings.desktop
    

    I thought that this could also be affecting the xset parameters, but it produced no changes, at least, in what we are looking for (the icon themes didn’t work correctly and they defaulted to Adwaita)

    • Power
    /etc/xdg/autostart/org.gnome.SettingsDaemon.Power.desktop
    

    This is it!!! If you disable the power plugin and obviously lose all the power saving functions that you can use in Gnome, light locker and any xsettings work out of the box and they remain in the same values all the time. I’ve had it working for a few hours now without problem. The only little thing I’ve detected is that light locker settings sets the ‘turn off screen’ value in the first place instead of the third position, that is:
    Light locker settings to turn off screen after four minutes:

    Exec=xset s 0 dpms 240 0 0
    

    But it should be:

    Exec=xset s 0 dpms 0 0 240
    

    If I remember correctly, gnome power settings could be disabled globally with the dconf editor in the past, but that key seems not to be available anymore.

    I hope this can be of any help to you. Please test and share your results!!!

    Hey!! I think you got it!! Look at this: gnome-settings-daemon/plugins/power/gpm-common.c

    This file have this comment…

    /*
    This timer goes off every few minutes, whether the user is idle or not,
    to try and clean up anything that has gone wrong.
    It calls disable_builtin_screensaver() so that if xset has been used,
    or some other program (like xlock) has messed with the XSetScreenSaver()
    settings, they will be set back to sensible values (if a server extension
    is in use, messing with xlock can cause the screensaver to never get a wakeup
    event, and could cause monitor power-saving to occur, and all manner of
    heinousness.)
    This code was originally part of gnome-screensaver, see
    http://git.gnome.org/browse/gnome-screensaver/tree/src/gs-watcher-x11.c?id=fec00b12ec46c86334cfd36b37771cc4632f0d4d#n530
    */

    Yeah… pretty sure it is disable_builtin_screensaver() XD

  • @iSpeakVeryWell Wow, that’s quite a research! Well done! That code or similar one seems to be present in Gnome Settings Daemon Power plugin, I assume because Gdm has to work both with the X server and Wayland. By disabling this plugin, things seem to return to normal.

  • Wau this looks like we can do a hack for this issue!

    Would be nice to, build this inside or aside to light-locker/settings, to have it possible to reset if using gdm.
    @lots-0-logs should have a look here!!

  • Has anyone noticed while using LightDM & the Switch User Feature, meaning having 2 or more different users, that when you switch user, it takes you to a Blank screen? It should take you to the sign-in screen. My experience with LightDM and different distros, I’ve had this issue. I stopped using it and now use LXDM

  • xset dpms <Standby> <Suspend> <Off>

    looks like light-locker only effect to <Off> but write this value to <Standby> …

    the sudpend rulings do not have any effect to xset

  • @iSpeakVeryWell , one thing I m sure about you is thatyou…“can search very well”, too.👏🏻

  • Hi guys,

    I did a fresh install of Antergos on a different machine. I tried several things and was successful in bringing the screensaver and light-locker to work.

    After installation the config looked like so:

    0_1497805243477_7651ed98-a398-4b0f-b58d-e87240a2aa6e-image.png Screenshot-from-2017-06-18-10-27-26.png

    In the “Privacy” window “Screen Lock” was set to off.

    0_1497806329917_60bfca64-8e05-46d8-9e36-97e89b24b079-image.png

    I left these settings unchanged.

    Original power settings in dconf editor:

    0_1497805334364_b6adcdb4-8ebf-4b67-9507-ff2035bc253a-image.png

    Screenshot-from-2017-06-18-10-15-27.png

    I changed the config to the following values:

    0_1497805373455_233c889c-5e16-4dde-9597-fbc1d9da8cff-image.png -Screenshot-from-2017-06-18-10-17-17.png

    And in fact the screensaver and light-locker are working. I observed the behavior for the last two days now and it seems to work fine. The only problem occurred when the laptop was attached to AC power. After the battery was fully charged the screensaver didn’t work.

    I am now trying the same config on my usual machine.

  • @khedron …and without hacking the desktop files like provided before?

  • I can confirm the above, but in the originally-installed state. I never had any issues with power settings for as long as I used Gnome (about 2 years). All I did was disabling any settings in the native Gnome System Settings and enabling them from Light Locker afterwards. I don t know if anything has changed since then.

  • @joekamprad
    Right, no hacking of any files. Just using dconf editor.

  • @khedron This is a good workaround! Good job!

    Would be great if Gnome could update their own workaround for xset to something more convenient. I’m not a fan of the approche they used to solve their problem with xset conflict. The “we will disable xset so our problem will be solved” approach seem a little bit overkill to me. It’s sounds like if water were infiltrating in their house and instead of fixing the breach, they decided to bubble wrap the entire house so water could not enter in it anymore… Nor anything else. They fixed their problem, but they also prevented anybody to use xset properly.

    What they should have done, is to at least verify if “power manager > blank screen” is enabled before trigger their fix. If it equal “never” don’t interfere with xset.

    Even more, they could have verified if xset was already disabled. If it is the case, do nothing. If xset enabled, disable it AND add an entry into the logs “xset disabled by gnome power management because gnome screensaver is enabled and conflict with xset. If you want to use xset, disable gnome screensaver in power management option”. This sound more adequate to me and more appropriate.

    Can we propose this to gnome power management team? How does it work? I’m not familiar with open source // Linux ways! (I’m still very new in this environment!)

  • @anarch It’s true that disabling any Gnome power settings used, individually or globally, through dconf-editor used to work as expected. Probably what has changed recently, I think, is that gnome settings daemon has been split into a number of plugins and, as @iSpeakVeryWell has shown, they have introduced some code of the old Gnome Screensaver into the power plugin, which overrides xsettings.

    I don’t know what the results of @khedron will be in his usual computer, but his latest test shows that even a fresh install does not work 100% with light locker…

  • Should we add @khedron fix into the wiki until gnome power management get fixed?

  • @iSpeakVeryWell said in Lightdm + lightlocker under Gnome research for a working solution:

    Can we propose this to gnome power management team?

    https://projects.gnome.org/gnome-power-manager/ is the place for reporting bugs, and as i can see it is a bug for shure…

  • In the other hand, xsettings could give more convenient way to know if one of their feature are enable. “xset q” is convenient for the user in the terminal, but not for automated scripts. It’s kind of boring to have to parse the string returned by “xset q” to know if a specific feature is enable.

    An handle like “xset q s_enabled” or “xset q dpms_enabled” returning current used values could be very useful. It would be much more developer friendly.

  • @joekamprad said in Lightdm + lightlocker under Gnome research for a working solution:

    https://projects.gnome.org/gnome-power-manager/ is the place for reporting bugs, and as i can see it is a bug for shure…

    Thank you! I’ll give it a try this week since I have to leave soon.

  • In the meantime, just wondering… Would it be difficult to disable the gsd-power plugin globally in Antergos, which uses lightdm by default, and enable that plugin only if the user decides to switch to gdm? I can’t figure the way to do it but it could be a solution to this problem.

gnome361 lightdm137 lightlocker4 research2 Posts 93Views 25478
Log in to reply
Bloom Email Optin Plugin

Looks like your connection to Antergos Community Forum was lost, please wait while we try to reconnect.