Bug 1482649 - Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
Summary: Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: powertop
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Regression, Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-17 19:38 UTC by Mike Simms
Modified: 2018-01-03 11:30 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-09-17 18:42:34 UTC
micsim2007: needinfo-


Attachments (Terms of Use)
dmesg | less (68.31 KB, text/plain)
2017-08-17 19:38 UTC, Mike Simms
no flags Details
verbose lspci output (5.58 KB, text/plain)
2017-08-17 19:39 UTC, Mike Simms
no flags Details
verbose lsusb output (49.20 KB, text/plain)
2017-08-17 19:39 UTC, Mike Simms
no flags Details
comparison of kernel autosuspend value output (3.36 KB, text/plain)
2017-08-29 11:05 UTC, Mike Simms
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1530572 None CLOSED RFE: add an option not to enable autosuspend for certain devices 2019-04-20 07:39 UTC

Internal Trackers: 1530572

Description Mike Simms 2017-08-17 19:38:23 UTC
Created attachment 1314863 [details]
dmesg | less

Description of problem: For some reason the trackball is no longer able to respond to user input immediately. it only responds when I click a button to wake it up or roll the ball about a bit first. With earlier kernels this was not necessary. Booting from the previous kernel 4.11.11-300.fc26 and it still works fine.


Version-Release number of selected component (if applicable):4.12.5-300.fc26.x86_64


How reproducible: consistently


Steps to Reproduce:
1. start computer with the unified receiver attached
2. login and use the computer as normal

Actual results: trackball works initially but if left for a few seconds to type or read for example, it needs waking up with movement or a click of a button.


Expected results: should respond normally without this lag or waking up nonsense


Additional info:the unified receiver is plugged into the same USB 2 port it has always been.

Comment 1 Mike Simms 2017-08-17 19:39 UTC
Created attachment 1314864 [details]
verbose lspci output

Comment 2 Mike Simms 2017-08-17 19:39 UTC
Created attachment 1314865 [details]
verbose lsusb output

Comment 3 Tom Georgoulias 2017-08-18 20:22:26 UTC
I believe I'm seeing the same issue with my M325 mouse.  I don't have any issues when I switch back to the previous 4.11 kernel (kernel-4.11.11-300.fc26.x86_64)

Comment 4 Dominik 'Rathann' Mierzejewski 2017-08-19 23:45:57 UTC
Same here (4.12.5-300.fc26.x86_64) with the same mouse. I also have a Logitech K800 keyboard paired with the same Unifying receiver and it's affected as well, making normal typing impossible. If I stop typing for a few seconds, it stops accepting input for the next few seconds, leading to missed characters in input. I noticed some new entries in dmesg compared to 4.11.11:

psmouse serio1: synaptics: Your touchpad (PNP: FOX0015 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
[...]
logitech-hidpp-device 0003:046D:2010.0005: HID++ 1.0 device connected.
[...]
logitech-hidpp-device 0003:046D:400A.0006: HID++ 2.0 device connected.

Going back to 4.11.11-300.fc26.x86_64 makes the issue go away.

Comment 5 Dominik 'Rathann' Mierzejewski 2017-08-20 00:13:42 UTC
Another workaround is to disable USB autosuspend for the Unifying Receiver. In my configuration, it's:

echo 'on' > /sys/bus/usb/devices/2-2.1.4/power/control

This can be done from powertop, too.

Comment 6 Mike Simms 2017-08-20 11:47:43 UTC
thanks for the workarounds but I'll stick with 4.11.11-300 for the time being. I've emailed upstream with a brief description of the issue linking to this thread and the attachments it contains.

Comment 7 Mike Simms 2017-08-20 17:05:15 UTC
no joy with the email. it was rejected by the email server

Comment 8 Dominik 'Rathann' Mierzejewski 2017-08-21 15:01:13 UTC
I'll try to open a bug report at bugzilla.kernel.org tonight unless someone beats me to it.

Comment 9 Mike Simms 2017-08-23 11:35:09 UTC
still present with kernel release 4.12.8-300.fc26.x86_64

Comment 10 Dominik 'Rathann' Mierzejewski 2017-08-23 22:07:14 UTC
Still haven't opened a report, because existing bugzilla reports redirect to linux-usb mailing list.

I've had pcie_aspm=force in my kernel command line since forever. After removing it, I no longer see the issue described here, because powertop --auto-tune doesn't enable autosuspend for some USB devices by default anymore, including the Logitech Unifying Receiver. As expected, after enabling autosuspend for the receiver, the issue returns.

Comment 11 Mike Simms 2017-08-24 08:07:56 UTC
I've never used that kernel command but do use powertop with the autotune settings. with 4.11 and exactly the same powertop settings this never happened for me. it's only started happening with kernel 4.12 and there hasn't been a powertop update recently which would alter behaviour either.

Comment 12 Dominik 'Rathann' Mierzejewski 2017-08-24 10:10:21 UTC
Can you compare your powertop "Tunables" tab under kernel 4.11 and 4.12? In my case, I have all "Good" under 4.11, but some (including the Unifying Receiver) as "Bad" under 4.12.

Comment 13 Mike Simms 2017-08-24 10:51:46 UTC
all displayed options in the tunables tab of powertop v2.9 are showing as "Good" for both kernels. that's why I'm not sure what has changed and why regarding this particular receiver because I haven't altered anything personally:



>> Good          NMI watchdog should be turned off                                                                      
   Good          Bluetooth device interface status
   Good          Enable Audio codec power management
   Good          Enable SATA link power management for host2
   Good          Enable SATA link power management for host4
   Good          Enable SATA link power management for host1
   Good          Enable SATA link power management for host3
   Good          Enable SATA link power management for host5
   Good          Enable SATA link power management for host0
   Good          VM writeback timeout
   Good          Runtime PM for I2C Adapter i2c-5 (i915 gmbus dpd)
   Good          Runtime PM for I2C Adapter i2c-1 (i915 gmbus vga)
   Good          Runtime PM for I2C Adapter i2c-4 (i915 gmbus dpb)
   Good          Runtime PM for I2C Adapter i2c-2 (i915 gmbus panel)
   Good          Runtime PM for I2C Adapter i2c-0 (i915 gmbus ssc)
   Good          Runtime PM for I2C Adapter i2c-7 (SMBus I801 adapter at efa0)
   Good          Autosuspend for USB device Ultra Fit [SanDisk]
   Good          Autosuspend for unknown USB device 2-1.4 (8087:07da)
   Good          Autosuspend for unknown USB device 2-1 (8087:0024)
   Good          Autosuspend for USB device xHCI Host Controller [usb3]
   Good          Autosuspend for USB device EHCI Host Controller [usb2]
   Good          Runtime PM for I2C Adapter i2c-3 (i915 gmbus dpc)
   Good          Autosuspend for unknown USB device 1-1 (8087:0024)
   Good          Autosuspend for USB device xHCI Host Controller [usb4]
   Good          Autosuspend for USB device USB Receiver [Logitech]
   Good          Autosuspend for USB device EHCI Host Controller [usb1]
   Good          Autosuspend for USB device FJ Camera [Chicony Electronics Co., Ltd.]
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller
   Good          Runtime PM for PCI Device Intel Corporation Centrino Wireless-N 2230
   Good          Runtime PM for PCI Device Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   Good          Runtime PM for PCI Device Intel Corporation HM75 Express Chipset LPC Controller
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1
   Good          Runtime PM for PCI Device NEC Corporation uPD720200 USB 3.0 Host Controller
   Good          Runtime PM for PCI Device Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode]
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3
   Good          Runtime PM for PCI Device Intel Corporation 3rd Gen Core processor Graphics Controller
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2
   Good          Runtime PM for PCI Device Intel Corporation 3rd Gen Core processor DRAM Controller
  Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family SMBus Controller
   Good          Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 4
   Good          Wake-on-lan status for device enp2s0
   Good          Wake-on-lan status for device wlp1s0

Comment 14 Mike Simms 2017-08-24 10:54:55 UTC
the unknown usb device is the intel bluetooth adaptor 8087:07da, and an Integrated Intel Rate matching hub 8087:0024

Comment 15 Mike Simms 2017-08-26 20:13:09 UTC
THIS IS A CRITICAL USER FUNCTIONALITY ISSUE

4.12.9-300.fc26.x86_64 uploaded to koji by jforbes is affected as well

what is a user who cannot unplug and replug the adaptor due to a disability because it is out of reach for them at the back of a tower on or under a desk to do? Put up and shut up 'for the greater good'? Not that they'd be able to use the damn thing long enough to report a problem without it cutting out on them half way through anyhow.

ANY keyboard or mouse which uses a Logitech Unified Receiver stops working properly, period.

I've deliberately kept removing the oldest 4.12 kernel version to retain kernel 4.11.11 as it is the last that works properly. I can reach the receiver but don't see why I should wear it or the USB connection out because of a buggy kernel. Please fix asap or report upstream if you cannot do so

I'm glad I don't have nvidia proprietary blobs because then I'd be even further up the creek without a paddle as you or someone upstream has removed a symbol from the kernel which breaks the 304.xx drivers

seems no one learned from the entire mtrr_add and mtrr_del fiasco back in November of 2015 did they?

Comment 16 Tom Georgoulias 2017-08-28 22:46:28 UTC
Disabling USB autosuspend for the Logitech Unifying Receiver works for me too, otherwise I have to stay on kernel-4.11.11-300.fc26.x86_64.

Comment 17 Dominik 'Rathann' Mierzejewski 2017-08-29 10:08:52 UTC
Mike, Tom, could you compare the output of

egrep -v '^#' /sys/bus/usb/devices/*/power/autosuspend_delay_ms 

between 4.11 and 4.12? I'll do the same when I get the chance at home.

I was also told (in #fedora-devel on IRC) that enabling autosuspend for keyboards and mice/touchpads is a bad idea in general.

Comment 18 Mike Simms 2017-08-29 11:05 UTC
Created attachment 1319405 [details]
comparison of kernel autosuspend value output

Thanks for carrying on looking into this Dominik. However, please don't waste your time when you get home running the command as it doesn't turn anything up, the output is identical across both kernel branches.

I really wish these Project contributors would stop talking out their backsides, using autosuspend is valid with these devices, I can't vouch for any other make but Logitech have one of the most developed USB receivers available. The Logitech Receiver and devices are designed to autosuspend and wake up immediately as they have always done so until 4.12 was installed. with the same values there is no such lag with kernel 4.11.

I don't see how they cannot understand it is an issue they have introduced with the new kernel and nothing the user has configured in the wrong manner. I'm fast losing faith and patience in the current direction Fedora Project is taking. They even managed to screw up the FESCo elections - something which could be construed a deliberate ploy to minimise the chances of getting voted off?

Fedora Maintainers have dropped the ball regarding quality and attention to user feedback. not just because of this issue but it doesn't help at all. Fedora in 2017 is far less stable than I've ever experienced with it in the last 7 releases I've used. Not just because of hardware support, but also the software side. There are far more bugs compromising workflow and taking up my time chasing them down and reporting when necessary (just to be ignored).

Fedora is fast becoming an OS I'm only willing to give passing interest to and disk space to in VM.

Comment 19 Tom Georgoulias 2017-09-01 10:58:33 UTC
4.11.11 kernel was removed by the update but here's the data for the current kernel I'm using.

# uname -r
4.12.9-300.fc26.x86_64
[root@crankarm ~]# egrep -v '^#' /sys/bus/usb/devices/*/power/autosuspend_delay_ms
/sys/bus/usb/devices/1-1.4/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/1-1/power/autosuspend_delay_ms:0
/sys/bus/usb/devices/2-1.1/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/2-1.2/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/2-1.6/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/2-1/power/autosuspend_delay_ms:0
/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms:0
/sys/bus/usb/devices/usb2/power/autosuspend_delay_ms:0

Comment 20 Dominik 'Rathann' Mierzejewski 2017-09-01 15:17:34 UTC
(In reply to Mike Simms from comment #18)
[...]
> Fedora is fast becoming an OS I'm only willing to give passing interest to
> and disk space to in VM.

Mike, please refrain from ranting in bugzilla tickets, it doesn't help at all.

Comment 21 Mike Simms 2017-09-01 15:47:32 UTC
That's not a rant, it's a comment. Tough luck if you don't find it helpful, I'm allowed to express my opinion as I see fit

Comment 22 Mike Goodwin 2017-09-03 02:51:13 UTC
I can confirm with an m570, but it's not exclusively that either.

I have a k360 keyboard that also had intermittent unresponsive issues (connected _WITH_ the m570 - haven't tried it by itself)

At one point it even killed the controller temporarily:

Sep 02 20:54:12 icarus kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
Sep 02 20:54:12 icarus kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Sep 02 20:54:12 icarus kernel: usb 2-2: USB disconnect, device number 2
Sep 02 20:54:13 icarus kernel: usb 2-6: USB disconnect, device number 4

Can also confirm that reverting to 4.11.11-300.f26 works fine. 

Initially I thought this was all caused by interference or bad signal, then after that message I figured the internal host controller was going bad and my hardware was hosed. Really glad I found this bug.

Comment 23 Mike Goodwin 2017-09-03 03:44:44 UTC
To add another data point:

Unifying Receiver
  DeviceID:             /sys/devices/pci0000:00/0000:00:14.0/usb2/2-2
  Guid:                 77d843f7-682c-57e8-8e29-584f5b4f52a1
  Guid:                 9d131a0c-a606-580f-8eda-80587250b8d6
  Plugin:               unifying
  Flags:                allow-online|supported
  DeviceVendor:         Logitech
  DeviceVendorId:       USB:0x046D
  Version:              RQR12.07_B0029
  VersionBootloader:    BOT01.02_B0014
  Created:              2017-09-03

Is the adapter info from `fwupdmgr get-devices` - i HAVE updated the firmware to RQR12.07_B0029 with this tool. I wonder if it's an interaction with 4.12 and that firmware version, but sadly I've updated all my adapters.

Comment 24 Mike Simms 2017-09-03 09:41:47 UTC
Hi Mike, it isn't firmware specific by the looks of it because I believe I have an older build still on my device. This is what mine has, I've never knowingly updated the firmware but it may well have been done by Windows Update since that installed an updated driver relating to the receiver.

Unifying Receiver
  DeviceID:             /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3
  Guid:                 77d843f7-682c-57e8-8e29-584f5b4f52a1
  Guid:                 9d131a0c-a606-580f-8eda-80587250b8d6
  Plugin:               unifying
  Flags:                allow-online
  DeviceVendor:         Logitech
  DeviceVendorId:       USB:0x046D
  Version:              RQR12.03_B0025
  VersionBootloader:    BOT01.02_B0015
  Created:              2017-09-03

the command I used was

fwupdmgr get-devices -v

I got this error when I tried the command you posted Mike:

bash: M570: command not found

Comment 25 Mike Goodwin 2017-09-03 12:48:45 UTC
@Mike Simms: Not sure why you typed "M570" as a command, since that's the model number of the trackball mouse. (nor did I ever even type it in caps?)

-----

I'd wager we're all powertop users?

I noticed that when I disabled powertop.service and rebooted the Logitech Unifying receiver and my ELAN touchscreen were the _only_ USB devices already configured for not autosuspending (I do have tuned running with the desktop profile).....

   Bad           Autosuspend for USB device Touchscreen [ELAN]
   Bad           Autosuspend for USB device USB Receiver [Logitech]

Everything else was. 

Seems strange that it was set that way by default.... Can someone explain why/how?

I checked all the udev rules in /usr/lib/udev/rules.d and nothing explicitly targets the unifying receiver to set autosuspend off, so I'm not really sure how that's happening.

So what I'm trying to say is that it seems deliberate (as in not coincidental) that this is in a set of USB devices with autosuspended by default, and perhaps someone was aware of this issue but we're overriding the fix by enabling powertop, which overrides this?

Comment 26 Mike Simms 2017-09-03 13:25:24 UTC
I meant that "bash: M570: command not found" is what I got as output after entering `fwupdmgr get-devices` - i

Comment 27 Mike Simms 2017-09-03 20:43:14 UTC
granted, it is possible to disable powertop so it isn't running and the lag disappears. this doesn't get away from the fact that with kernel 4.11.11 and previous kernels, powertop autosuspend being set to good for these logitech devices was not an issue.

That is why I'm going to try installing F27 with kernel 4.13 branch to another external drive and see how the receiver behaves with powertop auto settings applied.

i've never used tuned daemon, only powertop so there were no conflicting power settings.

Comment 28 Mike Simms 2017-09-03 22:15:28 UTC
the same problem happens with Fedora 27 when using powertop 2.9.3 and kernel 4.13.0-0.rc7.git0.1.fc27.x86_64. tested with nightly compose dated 2nd September 2017 installed to USB 3 HDD.

Comment 29 Dominik 'Rathann' Mierzejewski 2017-09-04 07:43:23 UTC
Autosuspend settings don't change between 4.11.11 and 4.12.9 in my case, either.

Comment 30 Justin M. Forbes 2017-09-06 18:20:17 UTC
I am going to have to guess this is directly related to powertop settings. Every kernel I build is tested on a box using a K800 keyboard and m570 through the unifying receiver, and I have not been able to reproduce in general usage. I don't use powertop though, as my concern is the kernel as we build/ship/support it.
If anyone can is reproducing this without having ever run powertop, I am willing to keep it as kernel, but otherwise, it should be moved to powertop.

Comment 31 Mike Simms 2017-09-06 19:34:06 UTC
I'll re-assign it to powertop on the proviso you are willing to acknowledge the fact this only started happening with your 4.12 and 4.13 kernel releases and work closely supporting the powertop maintainers to resolve it and not just dismiss as their issue, not your problem.

Comment 32 Mike Goodwin 2017-09-06 21:10:43 UTC
You guys have it wrong. This isn't a powertop bug, as powertop is doing its job, tuning everything that it can to good. That's its job.

This is a correlation to causation error you're making... meaning that while powertop being enabled exposes the problem, it _didn't occur_ prior to the _kernel upgrade_, ergo the problem is in the kernel, not powertop.

Something is wrong with USB suspend starting in 4.12 and it's _ODD_ that for some reason Logitech unifying receivers are set to _not suspend_ by default. Why is that? Where is that?

This is not a powertop bug, it's a bug with auto-suspending.

Comment 33 Mike Simms 2017-09-06 21:49:24 UTC
I have been making that exact point (it is kernel change related) from the outset but Justin obviously wants to hand off ownership to powertop because his 'test box' is not a notebook where using powertop is necessary so isn't that concerned. I'm beyond caring who deals with it at this point as long as they work together and fix the issue.

Comment 34 Mike Simms 2017-09-06 21:49:58 UTC
I have been making that exact point (it is kernel change related) from the outset but Justin obviously wants to hand off ownership to powertop because his 'test box' is not a notebook where using powertop is necessary so isn't that concerned. I'm beyond caring who deals with it at this point as long as they work together and fix the issue.

Comment 35 Justin M. Forbes 2017-09-07 12:21:02 UTC
(In reply to Mike Simms from comment #31)
> I'll re-assign it to powertop on the proviso you are willing to acknowledge
> the fact this only started happening with your 4.12 and 4.13 kernel releases
> and work closely supporting the powertop maintainers to resolve it and not
> just dismiss as their issue, not your problem.

I understand the value of powertop, and I am quite sure that the kernel is behaving differently in how it responds to certain settings.  My point is, powertop likely needs to change in how it tunes based on this.  Powertop is a kernel tuner at the core, and needs to know how to properly tune newer kernels. I am glad to help in any way I can, but I certainly do not have the powertop knowledge to do so. I last ran powertop a couple of years ago, and even then it was just to take a look at something out of curiosity.

It is the same way that selinux, nvidia drivers, and other packages who exist solely to interface with the kernel must follow upstream kernel releases and make adjustments to support newer releases.

Comment 36 Mike Simms 2017-09-07 13:45:24 UTC
I've sent this request to Intel Opensource for further guidance because debating ownership and who must do what about changes to the kernel they may or may not be aware of isn't going to get us anywhere nearer a fix.

https://lists.01.org/pipermail/powertop/2017-September/001991.html

Comment 37 Mike Simms 2017-09-13 08:20:48 UTC
I've been collaborating the last 6 days with powertop and linux-usb contributors upstream over this issue. They have been very helpful. What we've managed to do is establish exactly what has changed and where using a number of different trace methods.

There's basically not a bug as such, it is a setting that has been fixed in 4.12 and above that never worked before.

The value for power stored in the /sys/bus/usb/devices/2.1.3/power/control file for this device was being ignored when set to auto (Good) by powertop with kernel 4.11 and instead a non-existent setting of ON is used. ON means no autosuspend as power saving is 'Bad' in powertop tunable terms.

with 4.12 it is not being ignored. So what I'm going to do now is investigate masking that setting with powertop by removing it as a system service and coding a script (found something similar done for another distribution so I'm going to at least try it) to autostart powertop at boot ignoring the pointing device. OR using something else like tlp which I have no experience with. Either way, this is clearly not a bug after further investigation upstream so I'm closing it. I will post the powertop solution if I can get it worked but this should remain closed from here on in.

Comment 38 Mike Simms 2017-09-13 13:36:05 UTC
Workaround courtesy of https://www.kirsle.net/wiki/PowerTOP-and-USB-Autosuspend

Make a shell script that starts on user log-in, that undoes PowerTOP's change to the USB device.

Run sudo powertop and go to the Tunables tab.
Find the entry like "Autosuspend for Logitech Unified Receiver", and toggle it into a "Bad" state (meaning it doesn't auto-suspend now).
When toggling it, PowerTOP shows a message of what it did to toggle it, which looks like:

echo 'on' > '/sys/bus/usb/devices/2-1.3/power/control'

Create a shell script that does that job. I made mine at /bin/powertop-fix:

#!/bin/sh

# Disable USB auto-suspend for my mouse on startup
sleep 5;
MOUSE="/sys/bus/usb/devices/2-1.3/power/control";
if [ -f "$MOUSE" ]; then
    echo 'on' > $MOUSE;
fi

Edit your sudoers file (/etc/sudoers) to allow running that script with no password:
yourusernamehere  ALL=(ALL) NOPASSWD: /bin/powertop-fix

Make sudo /bin/powertop-fix start automatically using your desktop's session management settings (e.g. Xfce Sessions and Startup -> Application Autostart).

Comment 39 Mike Goodwin 2017-09-17 16:03:35 UTC
How did we lose sight of the real issue here? 

Autosuspend is broken with this device! 

This has _nothing_ to do with powertop past the fact that it enables autosuspend for this device and that setting is _no longer ignored by the kernel_ (why?)

Think of it this way... if the user runs:

echo "auto" > '<path_to_unifying_device>/power/control' 

every time he/she starts their computer, is the user the bug? That's effectively what you're blaming powertop for doing. 


Most importantly: Who's responsibility is it to fix the fact that autosuspend is broken with logitech unifying devices?

Reopened.

Comment 40 Mike Simms 2017-09-17 18:42:34 UTC
actually, as explained in my post #37 above it turned out from evidence gathered in the various traces that autosuspend was not working with kernel 4.11 or earlier ones but is working now. the delay of 2000ms (2 seconds) is adhered to by the system and that causes the lag. disabling the autosuspend restores normal peripheral response times.

should you want to continue chasing this one please post to this linux-usb mailing list via plain text mode email. if your email address is rejected use a gmail one. you don't have to subscribe, just do reply to all if anyone responds:

linux-usb@vger.kernel.org

cc addresses:
linux-input@vger.kernel.org
jikos@kernel.org
benjamin.tissoires@redhat.com
stern@rowland.harvard.edu

email subject:Re: RH Bugzilla - Bug 1482649 - Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update

archive to date: https://marc.info/?l=linux-input&m=150528972824717&w=2


Note You need to log in before you can comment on or make changes to this bug.