[00:00] <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:01] <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:02] <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:03] <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:04] <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:05] <ochosi> 4) is another locking programme installed
[00:07] <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:08] <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:09] <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:10] <knome> huhu
[00:11] <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:12] <knome> night
[00:12] <knome> i guess i should go as well
[00:51] <bluesabre> hm
[00:51] <bluesabre> its not an easy task to even build xfpm
[01:31] <bluesabre> cool, so that works
[01:31] <bluesabre> :)
[02:18] <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:19] <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
[08:15] <Unit193> bluesabre: Just in case you didn't see it: https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1320830
[08:15] <Unit193> it=the reply.
[09:15] <ochosi> bluesabre: sounds like a good start
[09:15] <ochosi> morning everyone
[09:16] <slickymasterWork> morning ochosi 
[09:16] <ochosi> ahoj slickymasterWork 
[11:02] <bluesabre> Unit193: yeah, I saw it, will try to fix that today (not entirely sure how that happened)
[11:05] <ochosi> morning bluesabre 
[11:07] <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:08] <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:09] <ochosi> right
[11:10] <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:11] <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:12] <bluesabre> awesome
[11:12] <ochosi> i'm not sure atm how/where to integrate some of the light-locker settings...
[11:13] <ochosi> it's mostly about late-locking, because that's a very ll specific option
[11:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20]  * 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:22] <bluesabre> yeah
[11:23] <bluesabre> ochosi: did you see https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1321244
[11:24] <ochosi> i did
[11:24] <ochosi> it's a very very specific case though
[11:28] <brainwash> and what about the idea to always late-lock?
[11:28] <ochosi> it isn't the ideal behavior for everyone
[11:29] <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:30] <ochosi> no
[11:30] <ochosi> it has no effect on that
[11:30] <brainwash> so the vt switch is not the culprit?
[11:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <ochosi> (as far as i understand this9
[11:39] <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:40] <brainwash> ltae-locking is the solution :D
[11:40] <brainwash> late
[11:41] <ochosi> solution to what?
[11:44] <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:45] <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:46] <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:47] <ochosi> but it's hard to narrow down why/what doesn't work exactly
[11:54] <ochosi> brainwash: feel like debugging xdg-screensaver a bit?
[11:56] <brainwash> general debugging?
[11:58] <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:59] <brainwash> but only if late-locking is enabled or?
[12:00] <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:01] <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:02] <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:03] <brainwash> not even bash
[12:03] <brainwash> only sh
[12:03] <brainwash> 1000 lines of code o.o
[12:04] <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:05] <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:07] <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:08] <brainwash> it's present twice in the code
[12:09] <ochosi> yuo
[12:09] <ochosi> i dont know why though
[12:10] <ochosi> could be part of the problem
[12:13] <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:14] <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:15] <ochosi> or cares about mediaplayers
[12:15] <brainwash> but many people use simple screen lockers
[12:15] <brainwash> mmh
[12:17] <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
[17:23] <SaXx_> Hey
[17:23] <elfy> hi SaXx_ 
[17:24] <SaXx_> Hey Elfy :)
[18:07] <ochosi> brainwash: did you look into xdg-screensaver any further?
[18:34] <brainwash> ochosi: no =S
[18:35] <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:37] <brainwash> does the media player blanking problem affect you?
[18:40] <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:42] <brainwash> but even with the duplicated entries it should work fine I think
[18:44] <brainwash> it's only a shell script, so it can be easily debugged
[18:46] <ochosi> yeah, i know, i just don't have the time for it right now...
[18:46] <elfy> evening both
[18:47] <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:48] <brainwash> and it's strange that ubuntu ships this patch
[18:50]  * ochosi shrugs
[18:50] <ochosi> i've never really bothered with xdg-utils
[18:51] <ochosi> until i debugged this screensaver thingy and found xdg-screensaver
[19:05] <brainwash> low priority issue, we will get it fixed in .1
[19:10] <ochosi> yeah, i hope
[20:14] <brainwash> and maybe https://code.launchpad.net/~thad-fisch/lightdm-gtk-greeter/lp-1024482 too
[20:17] <brainwash> ochosi: interesting report here bug 1322305