after suspend/resume, the Unity HUD is always open when I unlock the screen

I can confirm this, only for me it's always the HUD that's open on resume.

On Fri, Sep 20, 2013 at 12:57:05PM -0000, Stephen M. Webb wrote:
> I can confirm this, only for me it's always the HUD that's open on
> resume.

In fact, that's what I meant. Sorry for the mis-speak.

Duped a bug I previously closed because of the Hud deal

I also see this on 1 laptop when the laptop lid is set to 'Do nothing'
When re-opening Hud is open unless the Hud was open when closing, it's as if an alt keypress is initiated

To further test disable 'alt' as binding for Hud, at least here then it will not then show on re-opening

I see this when I close the lid or select Suspend from the session menu, but not if I suspend via the hotkey (Fn F4 on my laptop).
As in comment #4 I also see it if I have it set to Do Nothing on lid close.

I think it would help if you open xev before suspending and pressing the key-combo, so we can filter out that keyevents better.

@Marco, sorry not sure what you mean. Which key combo? There is no problem when use Fn F4, only when I close the lid or use the session menu to suspend.

Here's my xev log when activating "suspend" from the session menu.

stephenw@stephen-xt2-13:~$ xev -root -event keyboard -display :0.0

KeymapNotify event, serial 17, synthetic NO, window 0x0,
    keys: 4294967192 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeymapNotify event, serial 17, synthetic NO, window 0x0,
    keys: 4294967192 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Colin: Yes, but it's very likely that when closing/opening the lid of your screen a key event is sent to perform the relative action...

I'm also getting on
xev -event keyboard

KeyPress event, serial 28, synthetic NO, window 0x1600001,
    root 0x2e3, subw 0x0, time 22748356, (-719,449), root:(1022,501),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x1600001,
    root 0x2e3, subw 0x0, time 22748359, (-719,449), root:(1022,501),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Mh, so the event is there when opening the lid and as far I can see, unity side, we can't really do much for filtering it out... I'm not sure if that event is actually sent by some other process using it to wake up the screen.

Marco, did you mean to set the status to Incomplete?

> Marco, did you mean to set the status to Incomplete?

Yes as it probably this is probably not caused by unity...

You would see the same xev when using gnome-shell, (keysym 0xffe9, Alt_L) though nothing happens in Gs with Alt
(doesn't occur if the g-s-d power plugin is inactive

The gnome-settings daemon uses the XTEST extension to inject kepresses of the alt key when the lid is opened (or whatever action is taken to unsuspend: it's all "lid opened" to g-s-d). It does this to force-reset the X11 idle time counter. The use of the Alt key is hardcoded in gnome-settings-daemon.

The only way Unity could avoid this problem is to change the default HUD key. The solution rightly lies in changing the behaviour of gnome-settings-daemon.

@Stephen: it's not a frequently reported issue and I can't confirm it, do you have an idea why it's non consistent behaviour?

Sebastien, maybe everyone else is affected by bug #1228406 now, so doesn't notice the problem since they never resume from suspend? ;-P

I get this issue reported to me fairly frequently. If you have the problem, it's consistent and reliably reproduced.

The attached patch fixes the problem for me.

I have seen this bug and it is repeatable after every suspend. I only today discovered this report.

I have 1 machine where this occurs 100 % of the time. It's been doing this since at least when I filed bug on a month ago, probably a week or 2 longer than that.
Several days ago added a new install to same machine & happened to notice it no longer occurs.

So the diff here seems to be 'upower', specifically libupower-glib1
With upower packages (3 here) from upower_0.9.21-3ubuntu2 it always occurs
With packages from 0..9.22-1 it never occurs

If I downgrade to upower_0.9.21-3ubuntu2, log out/in, it comes back, upgrading to 0.9.22-1, log out/in, it stops

Maybe it's just this hardware where the above affects don't know, overall g-s-d is causing a number of small issues anyway.

Status changed to 'Confirmed' because the bug affects multiple users.

I'm the reporter of Bug #1227920 . In my system I can reproduce it 100% of the times, but only if the system is suspended by closing the lid, if I suspend using the menu option that the HUD is not triggered when the computer is woken.

By the way, I have

ii upower 0.9.22-1 amd64 abstraction for power manageme

so comment 20 doesn't seem to apply to my system.

I tried it also using Xmir and in my system the HUD is not shown when waking after suspend by closing the lid.

I see it 100% of the time when suspending using the menu. I still it with upower 0.9.22-1. Looking at the code, the debdiff in comment #18 seems very reasonable-- can someone upload this?

Sorry, ignore my comment #24, now I see this also using Xmir

Just upgraded to 13.10 today and noticed this bug still persists. I've tried suspending using the menu as well as closing the lid, and both methods suffer from the HUD being initialized upon wake. My machine is a Dell XPS 13 Ultrabook (128 GB SSD, 4 GB RAM, Sandy Bridge)

I see this behaviour as well on my desktop. Ubuntu 13.10 64bit, nvidia graphics (binary drivers).

I suspend using menu option, then resume by pressing power button. I get a password screen, enter my password, and when it drops to the desktop, the HUD is already open.

My workaround was to disable the "Left Alt" shortcut key for the HUD.

If Gnome will not fix this brokenness on the grounds that it isn't a problem in Gnome Shell and may be rewritten at some vague time in the future to support a Wayland compositor, can we just distro-patch gnome-settings-daemon to return to sanity?

+10

I built a test version of gnome-settings-daemon with the wakeup keys changed from Alt to Shift at ppa:bregma/unity7-experimental [1]. If folks could test this and confirm it has no unwanted side effects, we can SRU this.

[1] https://launchpad.net/~bregma/+archive/unity7-experimental

@bregma

I tried your patch and it works fine here. I used Suspend via menu and closed the laptop lid. Both methods did not open HUD upon wake. Great job! Thanks for the fix.

Seems fine to me, upstream raised concerns that shift might have similar issue but without giving details. I'm going to sponsor that SRU, let's see how the testing goes

Hello Steve, or anyone else affected,

Accepted gnome-settings-daemon into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.8.5-0ubuntu11.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I was affected by this bug (Suspend-Resume-EnterPassword resulted in HUD displaying). I enabled proposed, upgraded this morning (package version 3.8.5-0ubuntu11.1 amd64 is now installed). Suspend and resume now results in the desired screen with no HUD. I haven't noticed any regressions yet. Thanks!

I was also affected by the bug and tried installing the proposed - gnome-settings-daemon (3.8.5-0ubuntu11.1).
After a reboot I now have the correct behaviour.

Cheers!

This bug was fixed in the package gnome-settings-daemon - 3.8.5-0ubuntu11.1

---------------
gnome-settings-daemon (3.8.5-0ubuntu11.1) saucy; urgency=low

  * debian/patches/git_keyboard-Don-t-set-the-XKB-group-switching-option.patch:
    - If the user has the grp xkb option enabled, pressing the specified key
      might result in a Next Group keysym instead of the normal one. g-s-d
      doesn't use the option, and prevents it from being used with the patch.
  * debian/patches/unity-modifier-media-keys.patch:
    - Caps lock, next group, double modifier workarounds (lp: #1218322)

gnome-settings-daemon (3.8.5-0ubuntu11) saucy; urgency=low

  * debian/patches/ubuntu-lid-open-reset-ideletime.patch:
    change idle-timeout-reset key sequence from Alt to Shift (lp: #1227920)

gnome-settings-daemon (3.8.5-0ubuntu10) saucy; urgency=low

  * debian/patches/unity-modifier-media-keys.patch:
    - Support modifier-only keyboard shortcuts (lp: #1218322)
 -- William Hua <email address hidden> Thu, 24 Oct 2013 10:46:19 -0400

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.