Sometimes loses input devices on suspend/resume: Device has changed - disabling.

Hi Colin,

I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=20025 - please subscribe to this bug in case upstream needs further info or wishes you to test something.

Are you able to reproduce this bug at will? I've uploaded the patch for 322946 to -evdev, so it would be good if you could re-test.

Bryce, I think the best thing would be to patch this code so that it prints out exactly which value changed when comparing with the cache. That way, we could see immediately what the problem is and whether the patch in 322946 would help at all.

Okay; try this. (Don't think it's necessary to print all the bitmask values, unless it can be verified the 322946 patch doesn't address the issue.)

Also, upstream would like to know exact steps to reproduce.

This is the first time I've noticed this, so I can't guarantee being able to reproduce at will. I'll see what I can do.

I just saw this again:

(EE) ThinkPad Extra Buttons: Device has changed - disabling.

after noticing that my hotkeys stopped working.

I've just updated, but the patch above doesn't seem to have been uploaded yet?

I wasn't planning on uploading it to the distro since it's merely an debug instrumentation patch. Do you want me to anyway?

On Wed, Feb 11, 2009 at 08:59:01AM -0000, Bryce Harrington wrote:
> I wasn't planning on uploading it to the distro since it's merely an
> debug instrumentation patch. Do you want me to anyway?

The error message is not useful as it is, and there may be multiple bugs of
this type. I don't see any harm in providing this extra detail in the error
message, and expect it would be useful to submit upstream as well.

I've built it locally and will watch for a recurrence, but I expect that
there are others experiencing this issue who could diagnose it from their
logs if this patch were included.

--
 - mdz

Setting to medium to match upstream's priority, and also from recent comments, it seems this issue is not easily reproduced. Searching google for the error message, it doesn't turn up very many results (mostly just this bug, bug #216927, and some closed launchpad bugs).

I will upload the patch and forward it to upstream.

Error message patch is pushed to ubuntu and forwarded upstream.

The status on this bug is waiting for confirmation that the patch to bug #322946 did not already fix the issue, and if not either steps to reproduce the error at will, or a log file from running with the error message patch (included in -evdev 2.1.1-1ubuntu3).

Error message patch taken upstream.

Assigning to myself to acknowledge I'm monitoring this bug as a potential regression.

Hrm, debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520718 looks like it might be something similar.

After updating to jaunty this happens here too

As a workaround, it is possible to download source of X evdev driver, and comment a line like that:

evdev.c:EvdevReopenTimer
        ....
        if (1) /*EvdevCacheCompare(pInfo, TRUE) == Success)*/
        ....

The problem lies in the fact that kernel reports that device slightly changed, (changed key bitmap), and evdev reacts to that very badly by disabling the device.

Probably evdev didn't do that in interpid.

On Jaunty-rc I've tried to change the relevant line in evdev.c as suggested

Compiled and installed, reboot, suspend, resume : my keyboard is still disabled

Could you show the Xorg.log, after resume?

I sshed into the laptop after it had resumed and copied the Xorg.0.log file.

It looks like you have some different bug.

I am not expert on that, I have just read the bug summary on freedesktop.
In next step however, I would suggest you to install program called 'evtest'

It is nice program, that reads input directly from input devices.
It has no own package, but it is present in few packages
(I think that this is a bug, btw)

maxim@maxim-laptop:~$ dpkg -S $(which evtest)
joystick: /usr/bin/evtest

Then ssh to your laptop, and see if the keyboard device generates events.

For that you do

evetest /dev/input/event1
evetest /dev/input/event2
...

There are many event devices, they include power buttons, keyboards, mices,

evtest shows you roughtly what device you have opened, by listing keys it can generate, and besides, it will show all events everytime you press a key.

Do you have a usb keyboard?

I can confirm this behaviour on my acer aspire one running jaunty with latest updates. In fact, the porblem has been present since I started using jaunty (since beta).

It is also an issue for me. Latest Jaunty updates are installed. Most of the time, when I resume from suspend (either to RAM or from hibernation), X throws the mentioned error and my keyboard no longer responds until I restart it.

This is on a Toshiba Satellite A15-S127 laptop, Intel drivers.

@Mike Ramiro, Cory Maccarrone:

Version 1:2.1.1-1ubuntu3 of xserver-xorg-input-evdev (in February) added
some additional debugging to show exactly what changes in the device state
cause this problem. Your log files should show this additional detail.

Please attach whichever /var/log/Xorg.*.log shows this message so that we
can see it.

--
 - mdz

I use git of evdev driver.
this is what I get

(--) AlpsPS/2 ALPS GlidePoint touchpad found
(EE) AT Translated Set 2 keyboard: device key_bitmask has changed
(EE) AT Translated Set 2 keyboard: Device has changed - disabling.
(II) PS/2 Mouse: Device reopened after 1 attempts.
(II) Video Bus: Device reopened after 1 attempts.
(II) UnloadModule: "synaptics"
(II) PS/2 Mouse: Close
(II) UnloadModule: "evdev"
(II) Video Bus: Close
(II) UnloadModule: "evdev"
(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
 ddxSigGiveUp: Closing log

I've been experiencing this recently with the Bluetooth mouse. It occurs after multiple suspend/resume cycles - I'd guess 4 or 5 cycles before it hits. The mouse associates but the cursor is no longer controlled, and Xorg.0.log shows:

II) config/hal: Adding input device Bluetooth Travel Mouse
(**) Bluetooth Travel Mouse: always reports core events
(**) Bluetooth Travel Mouse: Device: "/dev/input/event10"
(II) Bluetooth Travel Mouse: Found 8 mouse buttons
(II) Bluetooth Travel Mouse: Found x and y relative axes
(II) Bluetooth Travel Mouse: Configuring as mouse
(**) Bluetooth Travel Mouse: YAxisMapping: buttons 4 and 5
(**) Bluetooth Travel Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(EE) Too many input devices. Ignoring Bluetooth Travel Mouse
(II) UnloadModule: "evdev"
(EE) config/hal: NewInputDeviceRequest failed (11)

It indeed appears that this one is fixed, at least here it works now

Colin, you're the original reporter - can you also confirm the issue as fixed in current jaunty?

It's working for me now.

I was never able to reproduce this with a recipe, though it did happen to
me several times. I haven't seen it happen in a long time, though.

--
 - mdz

Sadly, still an issue for me on:

uname -a

2.6.28-14-generic #46-Ubuntu SMP Wed Jul 8 07:21:34 UTC 2009.

Manifests when resuming from hibernate (hibernating whilst on battery) and
resuming while on power. Switching user on password screen works partially
but ALT or SHIFT keys become stuck. Restart X fixes problem.

This is not consistent btw... :(

HW: Dell XPS M1330 Model:PP25L

Please advise how to supply more info.

> --
> Sometimes loses input devices on suspend/resume: Device has changed -
> disabling.
> https://bugs.launchpad.net/bugs/327175
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in X.Org X server: Fix Released
> Status in “xserver-xorg-input-evdev” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: xserver-xorg-input-evdev
>
> On the way back from Berlin on Friday, I resumed my laptop on the plane to
> find that X was no longer accepting keyboard events. I tracked this down as
> far as EvdevCacheCompare having decided that the keyboard wasn't in the same
> state as it was on suspend and therefore disabling it. It's possible that
> this is related to bug 322946, but I don't know whether the position fields
> are defined for keyboard devices; unfortunately, my laptop ran out of
> battery before I could get it connected to a network, download debugging
> symbols, and attach gdb to the X server, which had been my plan.
>
> I've attached all the information I gathered before running out of battery,
> in the hope that it will be helpful. I was running kernel version
> 2.6.28-6.17.
>
> The error message was: (EE) AT Translated Set 2 keyboard: Device has
> changed - disabling.
>

@mcnaz, given your results differ from everyone else's, you might have some unrelated bug, although you've not provided enough info to guess one way or another.

Anyway, given that three people who have been following this bug for a while have confirmed they are no longer seeing it, and it's been marked fixed upstream since February, I'm going to provisionally close the bug as resolved. Colin, do of course feel free to reopen it if it is still is reproducing.

This bug is affecting me on Karmic, Acer Aspire 5920 -- no keyboard on resume from suspend. Mouse works. Zap brings the keyboard back.

I know this particular bug has been marked "Fix Released", but I thought it might be worthwhile to chime in that I am seeing the same behavior as TJ and Rod McFarland above. This is on a MacbookPro1,1, with Karmic. Both my bluetooth keyboard and mouse will randomly become unresponsive after resume from suspend. From what I can tell, both the keyboard and mouse re-associate properly, but X fails to pick them up. Excerpt of Xorg log attached.