On Sun, 08 Mar 2015 11:46:54 -0300 Ben Armstrong
sy...@sanctuary.nslug.ns.ca 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
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 you
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, instead of
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 locking
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 aligns
5 matches
Mail list logo
