Mailinglist Archive: opensuse-bugs (15082 mails)
| < Previous | Next > |
[Bug 310528] display locking conflicts on acer aspire 5684WLMi
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Tue, 25 Sep 2007 05:23:05 -0600 (MDT)
- Message-id: <20070925112305.DD9C4CC7AA@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=310528#c1
Holger Macht <hmacht@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
Info Provider| |olli@xxxxxxxxxxxxx
--- Comment #1 from Holger Macht <hmacht@xxxxxxxxxx> 2007-09-25 05:23:05 MST ---
(In reply to comment #0 from Olli Artemjev)
> I've configured display lock in KDE & it works fine. Though currently I've
> found two locking applications running after my laptop lid close. The 1st ask
> for password & unvlocks, but then I see xlock random screen saver & it also
> asks for password. The password is not accepted, but is passing to current
> application under the lock. So I had a fun passing my password to another gaim
> user - gaim opened a popup when I was out of my workplace. Well, it's not a
> problem to change pass & to kill xlock from console session, but there're
> problems anyway:
Does this happen always? Is kpowersave configured to lock the screen on lid
close?
> 1. Some application/package installed installs a hook in X on a lid close w/o
> checking KDE settings (how can I find that application, BTW - 'grep -r xlock
> /etc' ?).
It's most likely the powersave daemon. Can you please check
/etc/powersave/events:EVENT_BUTTON_LID_CLOSE and post the content?
> 2. The xlock in the situation above:
> 2.1 passes input to background app.
> 2.2 ignores that password is correct.
> The 2.2 is just annoying - need to switch to console & run 'killall xlock', but
> 2.1 is very dangerouse, for example I've sent my pass to some gaim user, but it
> could be, for example, fdisk opened in a console window..
>
> I'm running open SeSE 10.2 on Acer Aspire 5684WLMi .
Does this happen always? What happens after exiting kpowersave?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Holger Macht <hmacht@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
Info Provider| |olli@xxxxxxxxxxxxx
--- Comment #1 from Holger Macht <hmacht@xxxxxxxxxx> 2007-09-25 05:23:05 MST ---
(In reply to comment #0 from Olli Artemjev)
> I've configured display lock in KDE & it works fine. Though currently I've
> found two locking applications running after my laptop lid close. The 1st ask
> for password & unvlocks, but then I see xlock random screen saver & it also
> asks for password. The password is not accepted, but is passing to current
> application under the lock. So I had a fun passing my password to another gaim
> user - gaim opened a popup when I was out of my workplace. Well, it's not a
> problem to change pass & to kill xlock from console session, but there're
> problems anyway:
Does this happen always? Is kpowersave configured to lock the screen on lid
close?
> 1. Some application/package installed installs a hook in X on a lid close w/o
> checking KDE settings (how can I find that application, BTW - 'grep -r xlock
> /etc' ?).
It's most likely the powersave daemon. Can you please check
/etc/powersave/events:EVENT_BUTTON_LID_CLOSE and post the content?
> 2. The xlock in the situation above:
> 2.1 passes input to background app.
> 2.2 ignores that password is correct.
> The 2.2 is just annoying - need to switch to console & run 'killall xlock', but
> 2.1 is very dangerouse, for example I've sent my pass to some gaim user, but it
> could be, for example, fdisk opened in a console window..
>
> I'm running open SeSE 10.2 on Acer Aspire 5684WLMi .
Does this happen always? What happens after exiting kpowersave?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
| < Previous | Next > |