Closed S3NTYN3L closed 2 years ago
There might be a problem with timing here. Solaar might be sending a device command while the device is still starting up and the command is ignored. You could try to add a short (1 second?) pause in the script. You could also run the Solaar config command with debugging turned on -ddd
and send its output to a file.
You could also look at the responses the device is sending. Find out which hidraw node your receiver is using by running the Solaar GUI and opening the info pane for the receiver. THe hidraw node is show as the Path value. From the Solaar directory run ./tools/hidconsole
in a terminal window. Make sure that the Solaar GUI is not running. Then run your script. The last two lines of output from hidconsole should be the device responding to two commands from Solaar - the last line should be the device saying that it has changed the value for fn-swap and the second-last line should be the device saying what its value for fn-swap was at the time. So something like
11 01 090X 0W00...
11 01 091Y 0V00..
Then turn the device off and on. There should again be two lines like the above.
Also, make sure that the Solaar that is being run from the udev rule has PR #1536 applied. (Yes, you've done this, but please make sure.)
Aah, I think I know what is going on. Solaar config now tries to coordinate with the Solaar GUI, if running, so that they do not become confused as to what settings should be retained. However, this might not be possible inside a udev rule.
So please arrange to have debugging output captured from your script and post that here.
So please arrange to have debugging output captured from your script and post that here.
How exactly? I just purged the PPA install from my system (was updated yesterday a few hours after PR #1536 was merged by the maintainer). I cloned the lasted repo from git just now. Am I to leave the udev rule in etc or should I move it into the rules.d directory in the repo? I'm a bit confused on how to do this without a "proper" install.
EDIT: FWIW, we're on hidraw1
You should be able to run Solaar from where you cloned it by changing your script to use a file path (
#!/bin/bash
<Solaar dir>/bin/solaar -ddd config 1 fn-swap 0 &> /tmp/solaar-config.txt
echo "Solaar configuration applied at: $(date)" >> /tmp/solaar.log
I expect that there will be an error message in /tmp/solaar-config.txt complaining about not being able to do some GTK action.
OK, I power cycled the keyboard so settings got reset to default/unwanted. I then ran the script and here's the output;
Oddly enough, it did change the settings. It's just NOT doing it from either the git or stable PPA installs for some reason. Were they not updated? I could have sworn the commit tags matched. (from the git PPA 1.1.2+git1662-693db1d~ubuntu20.04.1)
EDIT: OK, GUI said hidraw1 but above CLI output says hidraw0...
The stable PPA hasn't been updated with the fix to Solaar config. The git PPA may lag a bit.
There are two issues in play here. Solaar config fails for fn-swap in Solaar 1.1.2. This is fixed in PR #1535. Solaar 1.1.2 config will also fail if it cannot set up a GTK application. This has not yet been fixed. It is not clear whether running Solaar config under udev causes this latter issue. Is the output above from a udev rule invocation of Solaar config?
There can be two hidraw nodes for a device, one for the receiver and one for the device itself. The former has all communication going through the receiver, even communication intended for attached devices. The latter has only the communication for the device itself. The Solaar GUI uses mostly the device-specific node to communicate with devices.
Is the output above from a udev rule invocation of Solaar config?
I'm not quite sure. Is the following the wrong way to do this?
I have the script sitting in /usr/local/bin
.
It looks like this;
#!/bin/bash
sleep 1
/home/redqueen/Downloads/Solaar/bin/solaar -ddd config 1 fn-swap 0 &> /tmp/solaar-config.txt
echo "Solaar configuration applied at: $(date)" >> /tmp/solaar.log
The installed git PPA version was purged from the system.
I cloned this github repo to /home/redqueen/Downloads/Solaar
.
I power cycled the keyboard so the settings reset to unwanted defaults.
I open a terminal as root, navigate to script dir and root@REDQUEEN:/usr/local/bin# ./forcesolaarconfig.sh
Yes that runs the script correctly. But does this new script work correctly when triggered from your udev rule?
I'm not sure how to run it without actually installing Solaar. If you mean, does it run when simply power cycling the keyboard, no.
The udev rule runs your script /usr/local/bin/forcesolaarconfig.sh which should now run Solaar out of the Solaar directory. So you should be able to just power cycle the keyboard. Or will udev rules not run executables that are in user directories?
I don't know. That's why I was asking a few comments back about the rules.d
directory in the cloned repo.
Perhaps just try turning the device off and on and see whether you get something new in /tmp/solaar.log. If not, try removing the sleep from the script.
Silly, silly me. I must need more coffee. Yes, there's new ouput;
Yes it appears that the problem is that GTK applications cannot be set up when running from a udev rule. Not too surprising, I guess. PR #1542 should fix this problem. Just set up the PR and try turning your keyboard off and on. The output in /tmp should no longer have the error and the setting should be set appropriately.
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 #1542, 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/1542/head:pull_1542
git checkout pull_1542
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_1542
git fetch origin pull/1542/head
git reset --hard FETCH_HEAD
Well, an exception will still likely show up but it should be handled and the setting should be set correctly.
Latest ouput;
EDIT; Sorry, I neglected to mention that settings were not updated.
The problem is that a function currently used does a hard stop instead of throwing an exception if problems are encountered.
The current version of PR #1542 should (!) work. Please download and try it out.
When running script manually;
When running from udev via power cycle;
Weird. I'm not seeing the unable to init server messages. (But I'm not running under udev, just without a display.)
Download the current version of the PR using
git checkout pull_1542
git fetch origin pull/1542/head
git reset --hard FETCH_HEAD
and try again.
HEAD is now at 416aa7f
Manually;
Power cycle;
Bizaare. I'll have to chase down the problem with some more print statements. :-(
Download the PR and try again.
HEAD is now at 97a2f68
Manually;
Power cycle;
Progress it seems. Manual run looks to be writing to user .config instead of root .config. :/
The problem is that the power cycle run isn't outputting any stdout output. That's either because it is using a different version of Solaar (make sure that the correct script is being invoked and that the script is running Solaar from your clone directory) or because stdout isn't being redirected correctly.
The newest version of the PR should produce better interleaving of stdout and stderr.
Want me to move the script from /usr/local/bin to repo directory?
No, just make sure that the script is running Solaar from the repo directory. (That's almost certainly true but checking is a good idea.)
Just double checked script is as follows:
#!/bin/bash
sleep 1
/home/redqueen/Downloads/Solaar/bin/solaar -ddd config 1 fn-swap 0 &> /tmp/solaar-config.txt
HEAD is now at d0232bf
Manually;
Power cycle;
Not sure if if this has anything to do with this issue, but I thought I'd bring it up anyway. https://stackoverflow.com/questions/20395027/scripts-launched-from-udev-do-not-have-display-access-anymore
Maybe it'd be worthwhile to look at v1.0.6 again and how it was handling this? Probably not, IDK, it seems like you guys overhauled a lot (most?) of the code since then. undecided.gif
The stackoverflow thread is definitely relevant. What is new is that solaar config tries to coordinate with a running Solaar to ensure that remembered device settings are consistent. This is new in 1.1.2 and is what is causing the problem - solaar config is trying to see whether a Solaar UI is running and that requires GTK and that requires a connect to the current display.
The newest version of the PR should have fixed the problem - I added some udev stuff to run the script out of udev and caught another problem. So please try again.
OK, so I've got /etc/udev/rules.d/99-forcesolaarconfig.rules
consisting of
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_SERIAL_NUMBER}=="404d*", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/local/bin/forcesolaarconfig.sh"
Then /usr/local/bin/forcesolaarconfig.sh
containing
#!/bin/bash
sleep 1
/home/redqueen/Downloads/Solaar/bin/solaar -ddd config 1 fn-swap 0 &> /tmp/solaar-config.txt
I then run the script manually in a terminal from /usr/local/bin
with ./forcesolaarconfig.sh
HEAD is now at 3402b6b
Manually;
The settings take hold.
And finally with udev
Power cycle;
Still looks like it's throwing some errors but the settings seem to take hold now! ;)
The unable to connect to server messages are mysterious but benign. They appear in other circumstances as well.
So this looks like a victory. I'll clean out the debugging stuff and update the PR.
The newest version of the PR has the debugging statements removed but no other differences.
HEAD is now at 64c4ccf
Manually;
Power cycle;
Looks like a winner! Thanks so much for the infinite f'ing patience and for maintaining this wonderful app! Now go grab a beer and celebrate, lol! ;)
Information
solaar --version
orgit describe --tags
if cloned from this repository): solaar 1.1.2uname -srmo
):Linux 5.4.0-107-generic x86_64 GNU/Linux
solaar show
:Describe the bug While Issue #1535 seems to have been fixed with PR #1536 my udev rule no longer reapplies settings upon keyboard power cycle.
To Reproduce Steps to reproduce the behavior:
Additional context I know I was running version 1.0.6 last summer and the above was working as intended. IIRC, Solaar had a few minor updates between then and a week or so ago and the above was still working just fine. I think I might have been on 1.1.1 from January up until about a week ago, but I'm not really sure so I can't confirm if above works there or not. Apt didn't have it listed when I was playing around with downgrading and whatnot yesterday. At any rate, something in the code changed and I'm eager to get it sorted. Thanks in advance.