| Summary: | Mouse unusable on NUC | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Paul Eggleton <bluelightning> |
| Component: | bsps-meta-intel | Assignee: | Nitin Kamble <nitin.a.kamble> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | dvhart, ionutx.chisanovici, ross.burton, tom.zanussi |
| Version: | unspecified | ||
| Target Milestone: | 1.5 M4 | ||
| Hardware: | NUC | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Paul Eggleton
2013-08-07 17:05:21 UTC
Paul, You are right about this being a USB suspend issue. FYI, key press on keyboard wakes up the mouse. There is also a kernel parameter to disable USB suspend to overcome the issue, if you need that let me know. But IMO this needs further investigation, to understand why is it happening. If I press keys on the keyboard it does not wake up the mouse. The way I have things currently plugged in (mostly by chance) I have the keyboard plugged into the front port and the mouse into one of the ones on the rear, so at first I thought that maybe this was because the front and rear ports were on separate hubs. However, lsusb -t seems to show that this is not the case. I note that meta-nuc turns on autosuspend globally for all devices via a kernel parameter. I'm pretty sure this isn't encouraged by upstream (as it's not default) and they're taking the approach of whitelisting devices that *do* suspend or letting people with known working configurations turn it on globally on a case-by-case basis. (I've got a ThinkPad USB keyboard/trackpoint, and when it suspends only keyboard input wakes it, and that takes ~one second to actually wake fully) Nitin, could you please have a look at this today or tomorrow? Darren, ok, I will to some poking here. I think this is not NUC specific. Possibly the generic kernel config meta data in v3.8 kernel repo. Nitin I think a udev rules like this should solve the issue. I will be testing it out soon.
SUBSYSTEM=="input", ACTION=="add", ATTR{power/control}="on"
A fix sent to linux-yocto mailing list. So my thought that autosuspend was globally enabled on NUC was incorrect, it's globally enabled on atom-pc (which is why I was seeing on my NUC occasionally). I'll send a patch to fix that too. The linux-yocto-3.8 kernel repo is updated to change the kernel config for Intel BSPs. Now all Intel BSPs using linux-yocto-3.8 kernel need to update the commit of their meta branch, which will solve the issue. I will be doing this for bunch of BSPs from meta-intel layer. Rest of the Intel BSPs need to be updated by their maintainers. Thanks, Nitin commit a6b7129fa25bf295a5b0f6ae5fd3f28ef04974ad Author: Nitin A Kamble <nitin.a.kamble@intel.com> Date: Fri Aug 9 17:14:58 2013 +0000 nuc:linux-yocto-3.8: update meta branch srcrev This fixes USB autosuspend issues related to non-responsive mice & keyboards. Fixes bug: [YOCTO #4992] Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Verified, usb mouse and keyboard are working normally without interruptions on NUC, mouse is working/functional after minutes of inactivity. |