Closed aetzlecx closed 1 year ago
What do you mean by "not work anymore"? Can you change the behaviour using the Solaar GUI? Is the behaviour different after resume? Please provide output of solaar show
when the problem is occurring and then after you have restarted Solaar.
Edit: I deleted my previous comment as it was terribly wrong. Today I could reproduce the issue and here are the answers to your questions:
What do you mean by "not work anymore"?
The swap fn functionality does not work anymore. E.g. when hitting F5 key on my Logitech K400+ the search functionality is executed rather the F5 key ;)
Can you change the behaviour using the Solaar GUI? Is the behaviour different after resume? No, I cannot access the devices anymore and the list is empty:
Please provide output of solaar show when the problem is occurring and then after you have restarted Solaar
solaar show
before restart
solaar show
after stop/start
Something appears to be going wrong in Solaar. Please run solaar -ddd
and report the output around the time you experience the problem.
Something appears to be going wrong in Solaar. Please run
solaar -ddd
and report the output around the time you experience the problem.
Here they are:
Aah, I meant run Solaar as solaar -ddd
, keep it running, and report its output around the time you experience the problem. Also, quit any running Solaar first.
aight, got you. will do :)
@pfps here they are:
Somehow the permissions on /dev/hidraw1 are not being set correctly. Solaar needs write permissions on these files to be able to make changes to their settings.
Please provide output of ls -l /dev/hidraw*
both when Solaar is working correctly and when it is not. Also what did you do when you ran Solaar to produce the log above?
The permissions are set by a udev rule that is likely /etc/udev/rules.d/42-logitech-unify-permissions.rules
. Please determine that this file is present, owned by root, and world-readable. If the file is not present there please look for it under /usr/lib/udev
.
Also, I think you ran solaar -dd
instead of solaar -ddd
. The output does show an error and might be sufficient but next time please use -ddd
.
Somehow the permissions on /dev/hidraw1 are not being set correctly. Solaar needs write permissions on these files to be able to make changes to their settings.
True, the described files don't have write permissions for non root users:
crw-------. 1 root root 241, 0 8. Mai 06:53 /dev/hidraw0
crw-rw----+ 1 root root 241, 1 8. Mai 06:53 /dev/hidraw1
crw-rw----+ 1 root root 241, 2 8. Mai 06:53 /dev/hidraw2
crw-rw----+ 1 root root 241, 3 8. Mai 06:53 /dev/hidraw3
crw-rw----+ 1 root root 241, 4 8. Mai 09:00 /dev/hidraw4
Please provide output of
ls -l /dev/hidraw*
both when Solaar is working correctly and when it is not. Also what did you do when you ran Solaar to produce the log above?
I will try to do that the next time I can reproduce the issue.
The permissions are set by a udev rule that is likely
/etc/udev/rules.d/42-logitech-unify-permissions.rules
. Please determine that this file is present, owned by root, and world-readable. If the file is not present there please look for it under/usr/lib/udev
.
Yes, /usr/lib/udev/rules.d/42-logitech-unify-permissions.rules
exists and is word-readable, however it slightly differs from https://github.com/pwr-Solaar/Solaar/blob/master/rules.d-uinput/42-logitech-unify-permissions.rules
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"
TAG+="uaccess"
instead of TAG+="uaccess", TAG+="udev-acl"
Could that be related?
The permissions are done as access control lists, signalled by the +, so things should be OK. You can see the lists using getfacl /dev/hidraw*
.
The difference in the rules file should not be relevant to this issue. The first difference is to allow input simulation under Wayland. The second is for very old versions of Ubuntu.
It may be that the udev rule is running too late after restarts so Solaar isn't able to write when it restarts. I'll put in a PR that retries the open.
Try PR #2057 and see if that appears to fix your problem. Run Solaar as bin/solaar -ddd
and post the output around the time you restart. Then try as bin/solaar
.
To clone and use Solar from its GitHub repository
git clone https://github.com/pwr-Solaar/Solaar.git
cd Solaar
Run Solaar as bin/solaar from this directory.
To run PR #2057, first clone Solaar if you have not already done so and cd to the clone directory. The first time you download the pull request, fetch it into a new branch and checkout that branch, as in:
git fetch origin pull/2057/head:pull_2057
git checkout pull_2057
To download a new version of the pull request, fetch it and then set your pull branch to the new fetch, as in:
git checkout pull_2057
git fetch origin pull/2057/head
git reset --hard FETCH_HEAD
Checked the code locally, started solaar and will check if I still can reproduce the issue or if it will be gone. Thank you :)
Still can reproduce the issue with the pull request code. Please find attached the logs I gathered with solaar -ddd
zipped as its >10MBs
Thanks. The relevant part of the log is the part just around the suspend and resume, i.e.,
2023-05-15 13:02:30,865,865 INFO [ReceiverListener:hidraw1] solaar.listener: connection Notification(10,2,41,04,426D40) for <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)> (mouse)
2023-05-15 13:02:30,866,866 INFO [ReceiverListener:hidraw1] solaar.listener: status_changed <UnifyingReceiver(/dev/hidraw1,14)>: present, 2 paired devices. (0)
2023-05-15 13:02:30,867,867 DEBUG [ReceiverListener:hidraw1] logitech_receiver.notifications: <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>: protocol 4 connection notification: software=False, encrypted=False, link=False, payload=False
2023-05-15 13:02:30,867,867 DEBUG [MainThread] solaar.ui: status changed: <UnifyingReceiver(/dev/hidraw1,14)> (NONE) None
2023-05-15 13:02:30,867,867 INFO [ReceiverListener:hidraw1] solaar.listener: status_changed <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>: paired offline, {'LINK ENCRYPTED': False, 'BATTERY LEVEL': 20, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 5, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0)
2023-05-15 13:02:30,868,868 DEBUG [ReceiverListener:hidraw1] logitech_receiver.base: (14) => r[20 02 4201 0000000000000000000000]
2023-05-15 13:02:30,868,868 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,869,869 DEBUG [ReceiverListener:hidraw1] logitech_receiver.notifications: <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)> (4.5) DJ Notification(20,2,42,01,0000000000000000000000)
2023-05-15 13:02:30,870,870 INFO [ReceiverListener:hidraw1] logitech_receiver.notifications: <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>: DJ connection: False Notification(20,2,42,01,0000000000000000000000)
2023-05-15 13:02:30,871,871 INFO [ReceiverListener:hidraw1] solaar.listener: status_changed <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>: paired offline, {'LINK ENCRYPTED': False, 'BATTERY LEVEL': 20, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 5, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) disconnected
2023-05-15 13:02:30,877,877 DEBUG [MainThread] solaar.ui: status changed: <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)> (NONE) None
2023-05-15 13:02:30,877,877 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,878,878 DEBUG [MainThread] solaar.ui.tray: picked device with lowest battery: ('/dev/hidraw1', 2, 'Marathon Mouse M705 (M-R0073)', {'LINK ENCRYPTED': False, 'BATTERY LEVEL': 20, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 5, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None})
2023-05-15 13:02:30,878,878 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,879,879 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,881,881 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,883,883 DEBUG [AsyncUI] logitech_receiver.settings: hires-smooth-invert: cached value False on <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,884,884 DEBUG [MainThread] solaar.ui: status changed: <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)> (NONE) disconnected
2023-05-15 13:02:30,884,884 DEBUG [AsyncUI] logitech_receiver.settings: pointer_speed: cached value 256 on <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,884,884 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,885,885 DEBUG [AsyncUI] logitech_receiver.settings: hires-smooth-resolution: cached value True on <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,885,885 DEBUG [AsyncUI] logitech_receiver.settings: hires-scroll-mode: cached value False on <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,886,886 DEBUG [AsyncUI] logitech_receiver.settings: reprogrammable-keys: settings read {80: 80, 81: 81, 82: 82, 83: 83, 86: 86, 91: 91, 93: 93} from <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,887,887 DEBUG [MainThread] solaar.ui.tray: picked device with lowest battery: ('/dev/hidraw1', 2, 'Marathon Mouse M705 (M-R0073)', {'LINK ENCRYPTED': False, 'BATTERY LEVEL': 20, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 5, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None})
2023-05-15 13:02:30,887,887 DEBUG [AsyncUI] logitech_receiver.settings: divert-keys: settings read {82: 0, 83: 0, 86: 0, 91: 0, 93: 0} from <Device(2,406D,Marathon Mouse M705 (M-R0073),8371ECF5)>
2023-05-15 13:02:30,887,887 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,888,888 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:30,888,888 DEBUG [MainThread] solaar.ui.icons: battery icon for 20:False = battery-low
2023-05-15 13:02:31,725,725 DEBUG [ReceiverListener:hidraw1] logitech_receiver.base: (14) => r[10 01 4903 005800]
2023-05-15 13:02:31,805,805 DEBUG [ReceiverListener:hidraw1] logitech_receiver.base: (14) => r[10 01 4903 044C00]
2023-05-15 13:02:35,243,243 WARNING [ReceiverListener:hidraw1] logitech_receiver.base: read failed, assuming handle <_ThreadedHandle(/dev/hidraw1)> no longer available
2023-05-15 13:02:35,244,244 DEBUG [ReceiverListener:hidraw1] logitech_receiver.listener: <_ThreadedHandle(/dev/hidraw1)> closing [14]
2023-05-15 13:02:35,246,246 WARNING [ReceiverListener:hidraw1] logitech_receiver.listener: Unifying Receiver disconnected
2023-05-15 13:02:35,246,246 INFO [ReceiverListener:hidraw1] solaar.listener: <UnifyingReceiver(/dev/hidraw1,14)>: notifications listener has stopped
2023-05-15 13:02:35,247,247 DEBUG [MainThread] solaar.ui: status changed: <UnifyingReceiver(/dev/hidraw1,14)> (NONE) None
2023-05-15 13:32:20,481,481 WARNING [MainThread] hidapi.udev: Report Descriptor not processed for BID 0003 VID 00000D8C PID 00000102: No module named 'hid_parser'
2023-05-15 13:32:20,483,483 WARNING [MainThread] hidapi.udev: Report Descriptor not processed for BID 0003 VID 0000046D PID 0000C52B: No module named 'hid_parser'
2023-05-15 13:32:20,483,483 INFO [MainThread] hidapi.udev: Found device BID 0003 VID 0000046D PID 0000C52B HID++ None None USB 2 2
2023-05-15 13:32:20,483,483 INFO [MainThread] solaar.listener: receiver event add DeviceInfo(path='/dev/hidraw1', bus_id=3, vendor_id='046D', product_id='C52B', interface=2, driver='logitech-djreceiver', manufacturer=None, product=None, serial='', release=None, isDevice=None, hidpp_short=None, hidpp_long=None)
2023-05-15 13:32:20,784,784 WARNING [MainThread] solaar.listener: failed to open DeviceInfo(path='/dev/hidraw1', bus_id=3, vendor_id='046D', product_id='C52B', interface=2, driver='logitech-djreceiver', manufacturer=None, product=None, serial='', release=None, isDevice=None, hidpp_short=None, hidpp_long=None)
2023-05-15 13:32:21,732,732 INFO [MainThread] solaar.upower: received resume event
2023-05-15 13:32:21,732,732 INFO [MainThread] solaar.listener: ping all devices when resuming
Thread 0x00007f4a8ffff6c0 (most recent call first):
File "/usr/lib64/python3.11/threading.py", line 320 in wait
File "/usr/lib64/python3.11/queue.py", line 171 in get
File "/home/<private>/dev/misc/Solaar/lib/solaar/tasks.py", line 61 in run
File "/usr/lib64/python3.11/threading.py", line 1038 in _bootstrap_inner
File "/usr/lib64/python3.11/threading.py", line 995 in _bootstrap
Current thread 0x00007f4ab13b7740 (most recent call first):
File "/home/<private>/dev/misc/Solaar/lib/solaar/gtk.py", line 133 in _handlesig
File "/usr/lib64/python3.11/site-packages/gi/_ossighelper.py", line 92 in signal_notify
File "/usr/lib/python3.11/site-packages/gi/overrides/Gio.py", line 42 in run
File "/home/<private>/dev/misc/Solaar/lib/solaar/ui/__init__.py", line 178 in run_loop
File "/home/<private>/dev/misc/Solaar/lib/solaar/gtk.py", line 180 in main
File "/home/<private>/dev/misc/Solaar/bin/./solaar", line 55 in <module>
solaar: exit due to keyboard interrupt
This log does look odd in that it appears as if the mouse and receiver went offline just before the suspend and then the receiver was not accessible at resume time. Is there anything that would cause the mouse and receiver to go offline before the system suspends?
The actual error occurs when the receiver is being opened, not the keyboard. I've modified the PR to show more information. Please download the PR again and run as before and post the output of bin/solaar -ddd
, but only the part around the suspend/resume that caused the problem. Also post the output of ls -l /dev/hidraw*
as soon as possible after the suspend. It would also be worthwhile to know whether this happens for each suspend/resume or only sometimes.
I'm still on this answering your questions, however last days I was a bit busy...
Checked now a while the issue and the only change I see is that the device list is not empty anymore:
However the swap fn function seems to not get restored and the fn keys still not work as expected unfortunately :(
Maybe the logs are helpful?
@aetzlecx
What I see is that at 19:22:45 there is a resume events and the receiver and both devices connected to it are identified, but at this point both are not active.
The mouse goes active at 19:22:52 and appears to be set up correctly. The K400 goes active at 19:22:53 but something might be going wrong. I will have to investigate further.
There are some uses of a diverted mouse wheel at 18:26:02. Did you divert the mouse wheel? I can't tell from this debug output.
Next, at 19:35:40 there are several presses and releases of a diverted Next key. Did you divert the Next key? You didn't provide a concurrent output of solaar show
and this debug output doesn't contain settings for your K400. Which key do you think was behaving incorrectly.
Then at 19:35:49 there is some startup communication with the K400. I don't understand why this is so delayed and may have to investigate further.
Please provide your current saved settings for the devices from ~/.config/solaar/config.yaml.
I figured out why settings are not being pushed to the K400. Both it and your mouse have a way for asking to be updated (because they have lost their settings). Your mouse sent this message but the K400 didn't. So Solaar appears to be doing the right thing here.
It is, however, very possible that the K400 has a bug and does need to have settings pushed. The next time you notice the problem please provide the output of solaar show
as soon as possible afterwards along with the current contents of ~/.config/solaar/config.yaml
solaar show
outputhope that helps and hope that I did everything right :)
@aetzlecx
OK. This looks cleaner. It appears that you no longer have any key diversions. Did you change anything?
@aetzlecx
I am now suspecting that there is an issue with how the device works I have a K400 Plus but I won't be where it is for several months so I'll have to get you to test out some things.
Please run Solaar as solaar -ddd
. Turn your keyboard off and on again and capture the debugging output for both. Then type a few keys on the keyboard, ideally the Next key, and see whether any new debugging output results.
@aetzlecx
Also please run Solaar as solaar -ddd
and disconnect the receiver, plug it back in, and then type a key on your keyboard. Post the debugging output from the time the receiver is disconnected.
Information
solaar --version
orgit describe --tags
if cloned from this repository): 1.1.8uname -srmo
):Linux 6.2.10-200.fc37.x86_64 x86_64 GNU/Linux
solaar show
:~/.config/solaar/config.yaml
(or~/.config/solaar/config.json
if~/.config/solaar/config.yaml
not present):Describe the bug I mainly use solaar to make use of the swap fx function and I see that when coming back from suspend mode that this functionality does not work anymore.
To Reproduce Steps to reproduce the behavior:
My workaround at the moment: Simply restart solaar (hit quit button start it regularly)
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Add any other context about the problem here.