ochosi | so this line needs to be conditional actually: https://github.com/EricKoegel/xfce4-power-manager/blob/21b8e5abf4e5f93c28cb964b4618b9b509780951/src/xfpm-manager.c#L350 | 00:00 |
---|---|---|
ochosi | or if you prefer upstream: http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n347 | 00:00 |
ochosi | if light-locker is in use, this cannot be called, if xscreensaver is in use, it has to be called | 00:01 |
bluesabre | xfpm in xubuntu is neither though, right? | 00:01 |
ochosi | logind is completely independent of it, it'll just fire a lock-signal that only light-locker will catch | 00:01 |
ochosi | xfpm in xubuntu has a few patches, but this part (logind inhibition) should be the same | 00:02 |
ochosi | the same patch has been applied upstream as is carried in xubuntu | 00:02 |
ochosi | it just hasn't been released yet | 00:02 |
bluesabre | ok | 00:02 |
ochosi | and yeah, you're right, it'd be nice if light-locker could check for xfpm's settings and flip that config option itself | 00:03 |
ochosi | but it depends on many variables, so it's not a lot of fun to add that code... | 00:04 |
ochosi | 1) is systemd even there | 00:04 |
ochosi | 2) is xfpm there | 00:04 |
ochosi | 3) (lid-close-event=suspend && lock-on-suspend=TRUE) ? | 00:04 |
ochosi | 4) is another locking programme installed | 00:05 |
ochosi | bluesabre: so i'll have to hit the hay now... | 00:07 |
bluesabre | ok, I'll hack on this for a few hours | 00:07 |
bluesabre | try to have something ready by morning | 00:08 |
ochosi | you don't happen to have another laptop you can reproduce this with? | 00:08 |
bluesabre | nope, gave my old laptop to my sister-in-law | 00:08 |
bluesabre | but I can verify if xfconf-settings are applied | 00:08 |
bluesabre | so thats something | 00:08 |
ochosi | you can also add some debug statement | 00:09 |
bluesabre | yeah | 00:09 |
ochosi | to see whether logind is correctly inhibited when the lock/suspend settings are set | 00:09 |
bluesabre | YEAH | 00:09 |
bluesabre | yeah | 00:09 |
bluesabre | I'll figure it out :D | 00:09 |
ochosi | wow, you*re excited, eh? ;) | 00:09 |
bluesabre | YAY CAPS | 00:09 |
ochosi | hehe | 00:09 |
knome | huhu | 00:10 |
ochosi | bluesabre: ok, as it is so befitting now: good night and good luck! | 00:11 |
bluesabre | seeya ochosi | 00:11 |
ochosi | night everyone (else) | 00:11 |
knome | night | 00:12 |
knome | i guess i should go as well | 00:12 |
bluesabre | hm | 00:51 |
bluesabre | its not an easy task to even build xfpm | 00:51 |
bluesabre | cool, so that works | 01:31 |
bluesabre | :) | 01:31 |
bluesabre | ochosi: part 1 http://paste.ubuntu.com/7499838/ | 02:18 |
bluesabre | I've tested and it does inhibit logind based on the setting | 02:18 |
bluesabre | so that's likely a good thing | 02:18 |
bluesabre | the limitation right now is that xfpm needs to be restarted for changes to take effect | 02:19 |
bluesabre | I'll fix that next, but I'm starting to get a bit tired now | 02:19 |
Unit193 | bluesabre: Just in case you didn't see it: https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1320830 | 08:15 |
ubottu | Launchpad bug 1320830 in lightdm-gtk-greeter (Ubuntu) "Please merge lightdm-gtk-greeter 1.8.5-1 from Debian unstable" [Undecided,Confirmed] | 08:15 |
Unit193 | it=the reply. | 08:15 |
ochosi | bluesabre: sounds like a good start | 09:15 |
ochosi | morning everyone | 09:15 |
slickymasterWork | morning ochosi | 09:16 |
ochosi | ahoj slickymasterWork | 09:16 |
=== brainwash_ is now known as brainwash | ||
bluesabre | Unit193: yeah, I saw it, will try to fix that today (not entirely sure how that happened) | 11:02 |
ochosi | morning bluesabre | 11:05 |
ochosi | i think we might be able to also use what you have now for trusty | 11:07 |
bluesabre | hey ochosi | 11:07 |
bluesabre | I'll fix it up today and then we should be in good shape | 11:07 |
ochosi | for the end-user, it boils down to enabling/disabling a switch in xfconf | 11:07 |
bluesabre | yeah | 11:08 |
ochosi | doesn't matter whether it's logind that is inhibited or xflock | 11:08 |
ochosi | in the long run though, we need a better solution in xfpm/light-locker | 11:08 |
bluesabre | the default is true (maintain the current status), so they won't see the setting unless it gets turned off for light-locker | 11:08 |
ochosi | right | 11:09 |
ochosi | I'd also like to integrate all of light-locker's settings somehow in xpfm and get rid of lls | 11:10 |
ochosi | more dialogs just leads to more complication | 11:10 |
bluesabre | yup | 11:10 |
bluesabre | when are you and eric planning on a new xfpm release? | 11:11 |
ochosi | he said he's planning to finish the suspend without systemd feature this weekend | 11:11 |
ochosi | then there's only a rather small issue left on the agenda | 11:11 |
ochosi | so i hope next week there'll be a new release | 11:11 |
ochosi | (that'd be a dev release though) | 11:11 |
bluesabre | awesome | 11:12 |
ochosi | i'm not sure atm how/where to integrate some of the light-locker settings... | 11:12 |
ochosi | it's mostly about late-locking, because that's a very ll specific option | 11:13 |
bluesabre | I'd vote for adding a compile-time option for light-locker support | 11:14 |
bluesabre | which just adds another section to xfpm | 11:14 |
bluesabre | or | 11:15 |
bluesabre | here's an idea | 11:15 |
ochosi | yeah, we could do that | 11:15 |
bluesabre | have a dropdown | 11:15 |
bluesabre | "preffered lock screen" | 11:15 |
ochosi | yeah, i also thought about that... | 11:15 |
bluesabre | detects xscreensaver, gnome-screensaver, light-locker | 11:16 |
ochosi | that'd rid us of xflock | 11:16 |
bluesabre | and disables the one thats not chosen when the xfpm daemon is running | 11:16 |
ochosi | i just don't think it's cool to "burden the user" with stuff like that.. | 11:16 |
bluesabre | its already a burden | 11:17 |
bluesabre | the user just has to install any gnome package that pulls gnome-desktop | 11:17 |
ochosi | ouch. true that... | 11:17 |
bluesabre | and then they have two running screensavers | 11:17 |
ochosi | ok, i'll put it on the roadmap | 11:17 |
ochosi | at least the selection of locker makes sense | 11:17 |
ochosi | xfce4-session is still relying on xflock4 though | 11:18 |
bluesabre | and light-locker settings can be controlled if light-locker is selected, a button for xscreensaver config if its selected, etc | 11:18 |
ochosi | well frankly i don't know of many more lockers | 11:19 |
ochosi | xlock, sure, but it doesn't have a dialog iirc | 11:19 |
ochosi | same for gnome-screensaver | 11:19 |
bluesabre | right | 11:19 |
* ochosi regrets a bit that we decided to drop out the lock window of light-locker... | 11:20 | |
ochosi | but i guess at that point it wasn't foreseeable that VT switching would cause that much trouble | 11:20 |
bluesabre | yeah | 11:22 |
bluesabre | ochosi: did you see https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1321244 | 11:23 |
ubottu | Launchpad bug 1321244 in light-locker (Ubuntu) "Light-locker easy to circumvent when using two separate Desktops" [Undecided,Incomplete] | 11:23 |
ochosi | i did | 11:24 |
ochosi | it's a very very specific case though | 11:24 |
brainwash | and what about the idea to always late-lock? | 11:28 |
ochosi | it isn't the ideal behavior for everyone | 11:28 |
ochosi | and it still pauses the "music" (or whatever is running) when you touch the mouse once | 11:29 |
brainwash | what trouble does it cause? | 11:29 |
brainwash | that is not a problem | 11:29 |
ochosi | so after touching the mouse/kb once, it's just like regular locking | 11:29 |
ochosi | we can consider making it default in 14.10, but for 14.04 that ship has sailed anyways | 11:29 |
brainwash | but it should solve the lid-close problem or? | 11:29 |
ochosi | no | 11:30 |
ochosi | it has no effect on that | 11:30 |
brainwash | so the vt switch is not the culprit? | 11:30 |
brainwash | late-locking would delay it until resume | 11:31 |
ochosi | are you sure about that? | 11:31 |
brainwash | isn't this how late-locking works? | 11:31 |
ochosi | late-locking only is related to the timeout | 11:32 |
ochosi | the suspending sends a lock-signal and that should immediately lock the session | 11:32 |
brainwash | and I suggest that light-locker always does late-locking | 11:33 |
brainwash | by default | 11:33 |
ochosi | on suspend it's less safe, so that'd be a -1 from me | 11:33 |
bluesabre | that has it's downsides | 11:33 |
ochosi | furthermore it works flawlessly with logid | 11:33 |
ochosi | logind | 11:33 |
bluesabre | the vt switch takes a surprising amount of time to perform | 11:34 |
ochosi | only the asynchronously running "stupid" xflock script causes that issue | 11:34 |
brainwash | it does? | 11:34 |
bluesabre | at least with nvidia drivers | 11:34 |
ochosi | yup | 11:34 |
ochosi | same here | 11:34 |
ochosi | lots of flickering and lots of time passing... | 11:34 |
ochosi | (very annoying in fact) | 11:34 |
bluesabre | also, a couple of ideas... | 11:35 |
bluesabre | xflock4 stays, new command tried first "xfce4-power-manager --lock-screen" which will forward commands if it manages them, or returns 1 if not | 11:35 |
ochosi | i recently noticed that lightdm has a new feature to keep the greeter alive to reduce the switching time | 11:36 |
brainwash | but still, late-locking wouldn't act differently than logind triggered locking | 11:36 |
ochosi | bluesabre: that is a very good idea | 11:36 |
brainwash | both switch the vt on resume | 11:36 |
bluesabre | since xfce is modular and xfpm may not be used | 11:36 |
bluesabre | true | 11:36 |
bluesabre | but the scenario is not for lid-lock when late-locking | 11:36 |
bluesabre | but for mouse-wiggle | 11:36 |
ochosi | brainwash: yeah, but it's it least all handled by logind | 11:37 |
ochosi | suspend isn't handled by light-locker at all | 11:37 |
ochosi | so with logind, you have one process synchronously handling the suspending and the resuming and the locking | 11:37 |
ochosi | if it's asynchronous, you get the race condition we're currently dealing with | 11:37 |
ochosi | (as far as i understand this9 | 11:38 |
brainwash | a switch to trigger late-locking would also help if the user manually locks the screen and still wants to hear the sound playing | 11:39 |
bluesabre | idea2 (unrelated): have a 30 second timer after receiving lock command where the greeter does not sleep the display. if no movement, sleep the display early | 11:39 |
bluesabre | (to improve late-locking) | 11:39 |
brainwash | ltae-locking is the solution :D | 11:40 |
brainwash | late | 11:40 |
ochosi | solution to what? | 11:41 |
brainwash | light-locker related problems :) | 11:44 |
ochosi | nah, light-locker2.0 will be the answer to that | 11:44 |
bluesabre | I'm ready to be done with bug fixes and get on with developing new features... trusty.1 is not fun :) | 11:44 |
ochosi | not having to switch vt anymore | 11:44 |
ochosi | bluesabre: we still will want to fix xdg-screensaver though... | 11:45 |
ochosi | that's something we'll need for .1 and 14.10 | 11:45 |
ochosi | sucks if parole can't inhibit the screensaver | 11:45 |
ochosi | and my workaround/patch is just an illustration of xdg-screensaver failing | 11:46 |
bluesabre | yeah, true | 11:46 |
ochosi | as that is also just a dumb script, let's hope the bug is easy to fix | 11:46 |
ochosi | but it's hard to narrow down why/what doesn't work exactly | 11:47 |
ochosi | brainwash: feel like debugging xdg-screensaver a bit? | 11:54 |
brainwash | general debugging? | 11:56 |
ochosi | well i'd like to know why it doesnÃ't work with light-locker | 11:58 |
ochosi | it actually has the fallback option of controlling X11's screensaver extension | 11:58 |
ochosi | which is what light-locker is using | 11:58 |
ochosi | so it should be handled correctly | 11:58 |
brainwash | but only if late-locking is enabled or? | 11:59 |
ochosi | no, that's totally unrelated | 12:00 |
ochosi | xdg-screensaver is a script that inhibits known screensavers | 12:00 |
ochosi | so it has special cases for gnome-screensaver and xscreensaver | 12:00 |
ochosi | and one for kde | 12:00 |
ochosi | and then a fallback | 12:00 |
ochosi | so mediaplayers like parole use it to inhibit the screensaver when playing a video fullscreen | 12:01 |
brainwash | on my main system it simply blanks and unblanks my screen, on top of that even changes screen brightness randomly :/ | 12:01 |
ochosi | you're not supposed to call xdg-screensaver as a user | 12:02 |
brainwash | ah | 12:02 |
ochosi | it's a tool for mediaplayers | 12:02 |
brainwash | oh | 12:02 |
ochosi | or whatever wants to inhibit screensavers | 12:02 |
ochosi | it's a bash-script though, so it's readable in /usr/bin | 12:02 |
brainwash | not even bash | 12:03 |
brainwash | only sh | 12:03 |
brainwash | 1000 lines of code o.o | 12:03 |
ochosi | yeah, but you can skip most of it | 12:04 |
brainwash | so it has no special code for light-locker | 12:04 |
ochosi | no, and it doesn't have to have | 12:04 |
ochosi | because light-locker doesn't manage the screensaver, it only reacts to it | 12:04 |
ochosi | X11 handles it | 12:05 |
ochosi | (the setting you get/set with xset q/s) | 12:05 |
brainwash | ah, got it | 12:05 |
brainwash | light-locker adds so much confusion | 12:05 |
ochosi | in this case it doesn't, it's the same as not using xscreensaver or gnome-screensaver | 12:07 |
brainwash | screensaver_xserver() | 12:07 |
ochosi | yup | 12:07 |
brainwash | it's present twice in the code | 12:08 |
ochosi | yuo | 12:09 |
ochosi | i dont know why though | 12:09 |
ochosi | could be part of the problem | 12:10 |
brainwash | but parole prevents the screen from blanking, right? | 12:13 |
brainwash | light-locker not running | 12:13 |
ochosi | it doesn't without xscreensaver | 12:13 |
ochosi | nope, it's unrelated to light-locker | 12:13 |
ochosi | light-locker does *not* blank the screen :) that's X11 | 12:13 |
brainwash | yes, I know | 12:13 |
brainwash | so xdg-screensaver is somewhat broken | 12:14 |
ochosi | so it happens either way, because xdg-screensaver doesn't detect / have a special scenario for light-locker | 12:14 |
ochosi | p | 12:14 |
ochosi | yu | 12:14 |
brainwash | maybe a bug report already exists | 12:14 |
ochosi | that's my assessment at least | 12:14 |
ochosi | i searched but couldn't find anything relevant so far | 12:14 |
ochosi | seems practically nobody uses the X11 extension | 12:14 |
ochosi | or cares about mediaplayers | 12:15 |
brainwash | but many people use simple screen lockers | 12:15 |
brainwash | mmh | 12:15 |
ochosi | but those maybe just disable the screensaver.. who knows why it hasn't been widely reported | 12:17 |
ochosi | anyway, i gotta run | 12:17 |
ochosi | bbl | 12:17 |
brainwash | ok cya | 12:17 |
=== zequence_ is now known as zequence | ||
SaXx_ | Hey | 17:23 |
elfy | hi SaXx_ | 17:23 |
SaXx_ | Hey Elfy :) | 17:24 |
=== MTwister is now known as ManiacTwister | ||
ochosi | brainwash: did you look into xdg-screensaver any further? | 18:07 |
brainwash | ochosi: no =S | 18:34 |
brainwash | maybe we should report that this patch can be dropped | 18:35 |
brainwash | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xdg-utils/trusty/view/head:/debian/patches/xserver-blanking.diff | 18:35 |
brainwash | does the media player blanking problem affect you? | 18:37 |
ochosi | yup | 18:40 |
ochosi | it does affect everyone that doesn't use xscreensaver or gnome-screensaver afaik | 18:40 |
brainwash | you could add set -x to the script and redirect the output | 18:40 |
ochosi | i wonder whether dropping the patch would fix it | 18:40 |
brainwash | but even with the duplicated entries it should work fine I think | 18:42 |
brainwash | it's only a shell script, so it can be easily debugged | 18:44 |
ochosi | yeah, i know, i just don't have the time for it right now... | 18:46 |
elfy | evening both | 18:46 |
ochosi | hey elfy | 18:47 |
brainwash | hey elfy | 18:47 |
ochosi | brainwash: that's why i asked you in the first place | 18:47 |
brainwash | got no access to my test system right now | 18:47 |
brainwash | and it's strange that ubuntu ships this patch | 18:48 |
* ochosi shrugs | 18:50 | |
ochosi | i've never really bothered with xdg-utils | 18:50 |
ochosi | until i debugged this screensaver thingy and found xdg-screensaver | 18:51 |
brainwash | low priority issue, we will get it fixed in .1 | 19:05 |
ochosi | yeah, i hope | 19:10 |
brainwash | and maybe https://code.launchpad.net/~thad-fisch/lightdm-gtk-greeter/lp-1024482 too | 20:14 |
brainwash | ochosi: interesting report here bug 1322305 | 20:17 |
ubottu | bug 1322305 in xfce4-settings (Ubuntu) "xfc4-settings needs shimmer-themes as a dependency" [Undecided,New] https://launchpad.net/bugs/1322305 | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!