| TJ- | Doing a few more experiments here because noticed after altering logind.conf suspend wasn't happening on lid close at all ;S | 00:06 |
|---|---|---|
| TJ- | this is weird... it seems like the problem only occurs before some property is specifically saved/set.. I've got 2 identical laptops side-by-side, fresh installs of 19.04, with both x-p-m set to Suspend on Lid close for Battery and/or AC, and those properties confirmed via "grep -rn lid ~/.config/" - the one with /etc/systemd/logind.conf HandleLidSwitch*=ignore does not suspend on lid close (screen | 00:12 |
| TJ- | does DPMS off). | 00:12 |
| TJ- | Would there be anywhere else a setting might be recorded, by either logind, or x-p-m, on a system level rather than per-user? It seems like once the changes have been made, even after removing them, some trace remains (even over a reboot so not in /run/) and I cannot reproduce even with a new user account | 00:39 |
| === GridCube_ is now known as GridCube | ||
| === brainwash_ is now known as brainwash | ||
| brainwash | bluesabre: can you confirm that bug 1046695 is fixed? | 16:44 |
| ubottu | bug 1046695 in xfce4-settings (Ubuntu) "Settings Manager in Xubuntu 12.10 does not have minimize button" [Undecided,Confirmed] https://launchpad.net/bugs/1046695 | 16:44 |
| brainwash | magically | 16:44 |
| brainwash | mmh | 16:46 |
| brainwash | https://git.xfce.org/xfce/xfwm4/commit/?id=bd6481d170cebb56b33a38806e021a5781d82c6c | 16:47 |
| brainwash | brainwash: you have this one on your list? https://bugzilla.xfce.org/show_bug.cgi?id=15428 | 16:52 |
| ubottu | bugzilla.xfce.org bug 15428 in Settings Manager "Xfce 4.14pre1 | Wrong icon layout after settings window is maximized" [Normal,New] | 16:52 |
| TJ- | I've been doing more tests of the LCD being turned off after lid-close suspend-resume. It works fine first cycle of suspend-resume, but blanks on 2nd cycle | 20:49 |
| TJ- | *but* when x-p-m > Security > lock on suspend is *disabled* LCD is blank as soon as system resumes even on first cycle | 20:52 |
| TJ- | HOWEVER, if x-p-m dialog is left on-screen during the suspend-resume cycle the LCD always recovers | 20:58 |
| brainwash | TJ-: but isn't the x-p-m version in 18.04 and 19.04 basically the same? | 21:27 |
| brainwash | TJ-: did you try anything gpu related yet? | 21:29 |
| TJ- | brainwash: in what way GPU related? | 21:29 |
| brainwash | gpu driver to be precise | 21:29 |
| TJ- | This affects any GPU across (now) 9 laptops | 21:29 |
| brainwash | all intel GPUs? | 21:30 |
| TJ- | and it only affects the user session; TTYs can be switched to and LCD is fine, but goes off as soon as switch back to user session | 21:30 |
| TJ- | No, Intel, AMD, Nvidia | 21:30 |
| brainwash | okay | 21:30 |
| brainwash | that is odd | 21:31 |
| TJ- | it's some weird interaction with the Lid handling of logind/x-p-m/light-locker from what I can tell | 21:31 |
| TJ- | Originally I did some major digging and debugging of light-locker alnd lightdm (last year) but being hit by this again for 19.04 found this x-p-m interaction and so want to solve it! | 21:31 |
| TJ- | I'm starting to worry I'll break the lid hinges :D | 21:32 |
| TJ- | it's got to be some internal state getting confused as to what the DPMS state is currently, and toggling it to the wrong state | 21:33 |
| brainwash | it's odd that a wide range of hardware is affected in your case | 21:33 |
| TJ- | greeter shows fine when lock is enabled, but screen goes off as soon as password entered, but can switch to TTYs and screen is on again, Alt+F7 bac to user session, screen goes off | 21:34 |
| TJ- | I've been doing clean installs from a 19.04 desktop amd64 ISO on USB to ensure there's no inherited config | 21:34 |
| TJ- | I can't let users have the laptops with this going on; I work around since 18.04 by manually suspended before closing the lid :) | 21:35 |
| brainwash | uhm | 21:35 |
| brainwash | tried with xfce4-screensaver yet? | 21:36 |
| brainwash | it's new in 19.04 | 21:36 |
| TJ- | is that installed by default? or an add-on ? | 21:36 |
| ochosi | just a heads up, you pinged yourself there: "brainwash$ brainwash: you have this one on your list? https://bugzilla.xfce.org/show_bug.cgi?id=15428" | 21:36 |
| ubottu | bugzilla.xfce.org bug 15428 in Settings Manager "Xfce 4.14pre1 | Wrong icon layout after settings window is maximized" [Normal,New] | 21:36 |
| ochosi | :) | 21:36 |
| brainwash | I noticed that ochosi | 21:36 |
| brainwash | but thought that no one else will, or if then not mention it :) | 21:37 |
| ochosi | :) | 21:37 |
| ochosi | regarding the LP issue you mentioned above (minimize button missing), yes, that's fixed | 21:37 |
| brainwash | TJ-: it's a new locker, just not installed by default yet | 21:37 |
| TJ- | grrr, just installing screensaver and system suspends due to battery! | 21:37 |
| brainwash | ochosi: after all these years! | 21:38 |
| TJ- | brainwash: Wow! | 21:39 |
| TJ- | I just opened its settings an there's a big warning "Xfce power manager is not configured to handle laptop lid events" - is this expected, or a big clue? | 21:39 |
| brainwash | that's /xfce4-power-manager/logind-handle-lid-switch | 21:41 |
| TJ- | yes, it chaned it from true to false | 21:41 |
| TJ- | changed it | 21:42 |
| TJ- | Is screensaver going to argue with light-locker if light-locker is left with its default to lock when suspending? | 21:42 |
| brainwash | maybe | 21:43 |
| brainwash | you could kill the current running process | 21:43 |
| brainwash | and disable the autostart entry | 21:43 |
| TJ- | ahh, no, I disabled that in x-p-m Security and it disabled the screensavers setting too | 21:45 |
| TJ- | and with that enabled, on resume get login dialog as per usual, and as soon as password entered LCD goes off (but TTYs are fine) | 21:46 |
| brainwash | with xfce4-screensaver? | 21:49 |
| TJ- | yes | 21:51 |
| brainwash | really? | 21:53 |
| TJ- | and I'm noticing, with screensaver, the behaviour of how screensaver acts (unrelated to this issue) is all over the place. It seems to be inhibiting suspend for about 30 seconds before system suspends after lid closed. On resume it displays the previous content of the desktop before replacing that with the password dialog, then blanking for fraction of a second, then returning. | 21:53 |
| brainwash | xfce4-screensaver runs in the same TTY | 21:53 |
| TJ- | Entering password - so far - hasn't resulted in lost display .... but got a few more cycles to test - i'm getting lost in all the permutations | 21:53 |
| TJ- | and... its gone blank on 2nd, or is it 3rd, cycle! | 21:54 |
| brainwash | uhm | 21:55 |
| brainwash | I just remembered something | 21:57 |
| brainwash | /etc/UPower/UPower.conf -> IgnoreLid=true | 21:57 |
| brainwash | you tried this already? | 21:57 |
| TJ- | Not so far, no. I've just added --debug to lightdm's service file in case there's clues there | 22:01 |
| TJ- | closed lid but it hasn't suspended; looks to be inihibted and waiting the timeout | 22:01 |
| brainwash | xfce4-screensaver does not use lightdm though | 22:01 |
| TJ- | the DM is lightdm, I just wanted to see if it logs anything related to events. | 22:02 |
| TJ- | This time it failed on 1st cycle | 22:03 |
| TJ- | thi would be funny if wasn't tragic! whilst the screen was dead, closed lid, suspended... resumed and the password login dialog is shown, as soon as password is entered, screen off! | 22:06 |
| TJ- | I wonder if this is backlight and not a full DPMS off? I'll try shining a torch next time but I think I tried this last year :) | 22:07 |
| TJ- | I'm monitoring the lid switch uevent first, than I'll try changing the UPower setting | 22:12 |
| ochosi | Unit193: is /usr/share/xubuntu/applications/xfce4-terminal.desktop a distro-specific file? any idea where that's coming from? at least i dont find anything in xfce4-terminal's git about this minimal/semi-broken desktop file | 22:22 |
| ochosi | Unit193: background: xfce4-terminal registers at the session manager with this desktop file | 22:23 |
| ochosi | Unit193: and since it contains no icon name, there's no icon in the session-settings dialog | 22:23 |
| Unit193 | That is, of course, shipped in xubuntu-default-settings such that xfce4-terminal is hidden in favor of exo-terminal-emulator.desktop. | 22:25 |
| TJ- | brainwash: UPower *may* have worked around it; only done 3 cycles so far though | 22:28 |
| TJ- | brainwash: done many cycles now and it does seem to have solved the issue; Rather disconcertingly though, the options to set Lid close policy in x-p-m's General tab have been removed as a result | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!