INFO/FIXED logitech universal recievers keep sleeping

[wintpe]

I had a problem at the weekend with my logitech k750 keyboard and logitech MX 2 anywere mouse sleeping, as commented in another post.
realy anoying only had to stop and ponder and im shaking the mouse to waking it up.
same with keyboard.
not sure what changed as ive had this keyboard/mouse for over a year no problems.

anyway in case others have a similar issue, i wanted to share the solution.

in /sys/bus..... etc there are paths that represent the drivers values, and down that path is a power/control and autosuspend.

you have to run lsusb to find what ports your device is on and then follow that path until you find the setting.

powertop also helps here as it will tell you the right path.

I tried to create a udev rule as documented on a fedora forum, but it just would not work, so this is what i ended up doing.
.........

the cause of this problem can be seen with powertop, when you see that auto power suspend is on

the fix is to identify the device down the /sys path and create a start up script to fix it.


systemd startup service created as follows

Code: Select all


cd /etc/systemd/system
 
vi disableusbpowercontrol.service
 
[Unit]
Description=disable usb power control for logitec usb recivers
After=network.target
 
[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/bin/disableusbpowercontrol
Restart=on-abort
 
[Install]
WantedBy=multi-user.target
:wq
 
cat /bin/disableusbpowercontrol
#!/bin/sh
echo on > /sys/bus/usb/devices/7-1/power/control
echo 2 > /sys/bus/usb/devices/7-1/power/autosuspend
echo on > /sys/bus/usb/devices/7-2/power/control
echo 2 > /sys/bus/usb/devices/7-2/power/autosuspend
 
systemctl enable disableusbpowercontrol.service
systemctl start disableusbpowercontrol.service


and thats it, that will survive a reboot.


of course if you move sockets then you may have to change the path to the device.


this could be scripted further to identify the device, as the udev rule should

this is also a good example of adding a basic startup script with systemd, probably not the best example, but it beats rc.local.
regards peter

[jiml8]

Unless it has been fixed, rc.local doesn't work anyway.

Creating a service for systemd actually is a rather straightforward process, once you've done it once. I presently have services defined to mount/unmount shares on my NAS, set up vlans on the workstation, start my custom firewall, mount a swapfile, and configure the system properly to use SSDs. The only part that can be a bit tricky is deciding where in the startup/shutdown process to run these scripts.

[wintpe]

OK i realise why this suddenly became an issue.

sometime last week i installed powertop thinking it was just a reporting utility.

however just been going through the logs for another problem, and i see

Code: Select all

Dec  1 09:47:59 localhost powertop[1262]: Leaving PowerTOP
Dec  1 09:47:59 localhost powertop[1262]: Cannot load from file /var/cache/powertop/saved_parameters.powertop
Dec  1 09:47:59 localhost powertop[1262]: File will be loaded after taking minimum number of measurement(s) with battery only
Dec  1 09:47:59 localhost powertop[1262]: Cannot load from file /var/cache/powertop/saved_parameters.powertop
Dec  1 09:47:59 localhost powertop[1262]: File will be loaded after taking minimum number of measurement(s) with battery only
Dec  1 09:47:59 localhost systemd[1]: Started PowerTOP autotuner.


so installing and running powertop installs

./multi-user.target.wants/powertop.service
[root@localhost system]# cat ./multi-user.target.wants/powertop.service
[Unit]
Description=PowerTOP autotuner

[Service]
Type=oneshot
ExecStart=/usr/sbin/powertop --auto-tune

[Install]
WantedBy=multi-user.target


great not what i intended, but perhaps an opportunity for some, and a warning to others, of what installing powertop can enable.

regards peter