On ven., 2015-07-17 at 13:38 +0200, Piotr Martycz wrote:
> The whole procedure is broken by design. The dbus methods which
> dm-tool/lightdm use
> org.freedesktop.DisplayManager.{Session|Seat}.Lock()
> org.freedesktop.login1.Session.Lock()
> don't return any value to the caller.
That's why
On Sun, 08 Mar 2015 11:46:54 -0300 Ben Armstrong
wrote:
> Yep, that's all it took. But wow, what a big accident waiting to happen
> for unsuspecting users! Some time ago, I had disabled xscreensaver to
> keep my session as light as possible, and the session appeared to be
> getting locked by light
On 08/03/15 10:25 AM, Yves-Alexis Perez wrote:
> Actually that's not what happens. dm-tool locks will just call the
> Lock() dbus method on the current seat. In response to that, lightdm
> will emit a dbus signal for locking, then switch vt to display a login
> screen.
Sure. Makes sense. And align
On dim., 2015-03-08 at 08:35 -0300, Ben Armstrong wrote:
> I wanted to use dm-tool to debug a problem I'm having (lxpanel > "Lock
> screen" does not lock the screen, which I will report separately on that
> package) so I tried "dm-tool lock" to verify if locking works at all.
> Unfortunately, inste
Package: lightdm
Version: 1.10.3-3
Severity: normal
I wanted to use dm-tool to debug a problem I'm having (lxpanel > "Lock
screen" does not lock the screen, which I will report separately on that
package) so I tried "dm-tool lock" to verify if locking works at all.
Unfortunately, instead of lockin
5 matches
Mail list logo
