Won’t this disable Gear shifting completely? Any chance of just getting the gearshifting into the correct location? Am I wrong in thinking it’s a python script?
Yes it will. Just want to make sure all other perspectives works before we dive deeper…
To have gear switching to work you’ll have to modify it (quite) a bit to allow interfacing with an external program efficiently.
All these services are python scripts. Gear shifting can be done by just shelling out and call the gearbox on command line. Tried that in earlier versions. Very slow when you’re on low gear. So I figure I can just import the gearbox as a python module.
Ah, ok. I will dive into this tomorrow, it’s fairly late here.
cpi@clockworkpi-a06:~$ systemctl status devterm-keyboard.service
● devterm-keyboard.service - devterm keyboard service
Loaded: loaded (/etc/systemd/system/devterm-keyboard.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-08-04 19:08:33 UTC; 11s ago
Main PID: 4438 (python3)
Tasks: 1 (limit: 4459)
Memory: 3.4M
CPU: 163ms
CGroup: /system.slice/devterm-keyboard.service
└─4438 /usr/bin/python3 /usr/local/bin/devterm_keyboard.py
Aug 04 19:08:33 clockworkpi-a06 systemd[1]: Started devterm keyboard service.
Seems like that allows it to run, but:
cpi@clockworkpi-a06:~$ systemctl status devterm-keyboard.service
● devterm-keyboard.service - devterm keyboard service
Loaded: loaded (/etc/systemd/system/devterm-keyboard.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-08-04 19:08:33 UTC; 6min ago
Main PID: 4438 (python3)
Tasks: 1 (limit: 4459)
Memory: 3.4M
CPU: 426ms
CGroup: /system.slice/devterm-keyboard.service
└─4438 /usr/bin/python3 /usr/local/bin/devterm_keyboard.py
Aug 04 19:13:18 clockworkpi-a06 python3[4607]: sudo: error initializing audit plugin sudoers_audit
Aug 04 19:13:19 clockworkpi-a06 sudo[4610]: root : unknown user yatli ; PWD=/ ; USER=yatli ;
Aug 04 19:13:19 clockworkpi-a06 python3[4610]: sudo: unknown user yatli
Aug 04 19:13:19 clockworkpi-a06 python3[4610]: sudo: error initializing audit plugin sudoers_audit
Aug 04 19:13:19 clockworkpi-a06 sudo[4613]: root : unknown user yatli ; PWD=/ ; USER=yatli ;
Aug 04 19:13:19 clockworkpi-a06 python3[4613]: sudo: unknown user yatli
Aug 04 19:13:19 clockworkpi-a06 python3[4613]: sudo: error initializing audit plugin sudoers_audit
Aug 04 19:13:19 clockworkpi-a06 sudo[4616]: root : unknown user yatli ; PWD=/ ; USER=yatli ;
Aug 04 19:13:19 clockworkpi-a06 python3[4616]: sudo: unknown user yatli
Aug 04 19:13:19 clockworkpi-a06 python3[4616]: sudo: error initializing audit plugin sudoers_audit
After checking for the user:
root-notify-send.py has the user hard coded.
Looks like DBUS doesn’t handle things correctly for the address of the keyboard :
Aug 04 20:20:04 clockworkpi-a06 sudo[5751]: pam_unix(sudo:session): session closed for user cpi
Aug 04 20:20:05 clockworkpi-a06 sudo[5756]: root : PWD=/ ; USER=cpi ; ENV=DISPLAY=:0.0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/100>
Aug 04 20:20:05 clockworkpi-a06 sudo[5756]: pam_unix(sudo:session): session opened for user cpi(uid=1000) by (uid=0)
Aug 04 20:20:05 clockworkpi-a06 python3[5757]: Could not connect: No such file or directory
Aug 04 20:20:05 clockworkpi-a06 sudo[5756]: pam_unix(sudo:session): session closed for user cpi
Modifying the file /usr/local/bin/root-notify-send
seems to let me dynamically set the user:
#!/bin/bash
cur_user=$(who | mawk '{print $1}')
cur_user_id=$(id -u $cur_user)
sudo -u $cur_user DISPLAY=:0.0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$cur_user_id/bus notify-send "$@"
But doesn’t actually work:
cpi@clockworkpi-a06:~$ systemctl status devterm-keyboard.service
● devterm-keyboard.service - devterm keyboard service
● devterm-keyboard.service - devterm keyboard service
Loaded: loaded (/etc/systemd/system/devterm-keyboard.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-08-05 07:23:34 UTC; 38s ago
Main PID: 10840 (python3)
Tasks: 1 (limit: 4459)
Memory: 3.4M
CPU: 1.190s
CGroup: /system.slice/devterm-keyboard.service
└─10840 /usr/bin/python3 /usr/local/bin/devterm_keyboard.py
Aug 05 07:24:05 clockworkpi-a06 python3[10934]: Could not connect: No such file or directory
Aug 05 07:24:05 clockworkpi-a06 sudo[10933]: pam_unix(sudo:session): session closed for user cpi
Aug 05 07:24:06 clockworkpi-a06 sudo[10943]: root : PWD=/ ; USER=cpi ; ENV=DISPLAY=:0.0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send Selector = joystick
Aug 05 07:24:06 clockworkpi-a06 sudo[10943]: pam_unix(sudo:session): session opened for user cpi(uid=1000) by (uid=0)
Aug 05 07:24:06 clockworkpi-a06 python3[10944]: Could not connect: No such file or directory
Aug 05 07:24:06 clockworkpi-a06 sudo[10943]: pam_unix(sudo:session): session closed for user cpi
Aug 05 07:24:06 clockworkpi-a06 sudo[10952]: root : PWD=/ ; USER=cpi ; ENV=DISPLAY=:0.0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/notify-send Selector = gear
Aug 05 07:24:06 clockworkpi-a06 sudo[10952]: pam_unix(sudo:session): session opened for user cpi(uid=1000) by (uid=0)
Aug 05 07:24:06 clockworkpi-a06 python3[10953]: Could not connect: No such file or directory
Aug 05 07:24:06 clockworkpi-a06 sudo[10952]: pam_unix(sudo:session): session closed for user cpi
ugh… sorry about the mess. it was set up for ArchLinux so the DBUS path could be different here.
Try ls /run/user/1000
and see what’s in there?
Hrm, looks like they are enumerating dbus for some reason, so the dbus directory is
/run/user/1000/dbus-1
and there is a subfolder /run/user/1000/dbus-1/services/
Is there /run/user/1000/dbus-1/bus
?
I just checked my homelab (ArchLinux), /run/user/1000
has both the socket “bus”, and a folder “dbus-1”.
“bus” is missing on your side?
Yeah, there is no bus. I tried to write to the directory for both dbus-1 and dbus1/services but get connection refused. There doesn’t appear to be any other dbus related items in there, no likely sockets either.
hmm strange… what’s your desktop environment/session manager?
You can also pull the bus address from a terminal: echo $DBUS_SESSION_BUS_ADDRESS
Taking a guess: it points to somewhere in /tmp… ?
Yes, a /tmp- file.
I am running the OS shipped with it, which looks like Ubuntu upgraded to 22.04.1, and the Armbian repos. The default wm is xfce.
A simple workaround is to use a session startup script to dump $DBUS_SESSION_BUS_ADDRESS
and user info to somewhere the service can access.
The service monitors changes to this file, and we avoid hard coding user name/id, and dbus socket path.
I think that’s totally reasonable. Obviously only /tmp will really be reasonable for a service.
Maybe /tmp/tpi_gear_notify_path or similar from ~/.profile?
Trying it, everything works correctly for notify. Updating my code changes earlier:
sudo vim /usr/local/bin/root-notify-send
#!/bin/bash
cur_user=$(who | mawk '{print $1}')
DBUS_SESSION_BUS_ADDRESS=$(cat /tmp/cpi_dbus_path)
sudo -u $cur_user DISPLAY=:0.0 notify-send "$@"
And from a terminal or .bashrc:
echo $DBUS_SESSION_BUS_ADDRESS > /tmp/cpi_dbus_path
Probably add this as an executable shell script in ~/.config/autostart/
This still doesn’t help with the gears though. What needs to happen for that?
Yeah autostart or .xinitrc
would do it. Nicely done!
For gear switching, check out this:
- Removed all subprocesses, much faster
- Added thermal trip point settings
- Allow modular import
Install this or edit your gearbox script accordingly. Then make sure it’s ln -s
’ed to /usr/local/bin/devterm_gearbox
I thought things were working correctly, but I realized it is actually not changing CPU gears. I suspect this is related to Ubuntu 22.04:
set cpu 5 on off failed
set cpu 5 max freq failed
set cpu 4 on off failed
set cpu 4 max freq failed
set cpu 3 on off failed
set cpu 2 on off failed
set cpu 1 on off failed
set cpu 0 on off failed
set gpu failed
set thermalzone 0 trip point 0 failed
set thermalzone 0 trip point 1 failed
set thermalzone 1 trip point 0 failed
set cpu governor failed
[Errno 13] Permission denied: '/var/lib/devterm/gear'
This was using your changed gearbox script, but looking through the original code it looks like that was using the same method.
Any suggestions or do I post an issue against the gear switching code?
Fun times
Try poke around manually?
sudo -s # go superuser
cd /sys/devices/system/cpu/cpu4
echo 1 > online
Then check:
- File /sys/devices/system/cpu/cpu4/online actually exists
- You can cat the file to get the current status of that cpu
- What does
dmesg
say about the operation
Could you upload the binary files to Github? Your NextCloud seems to be down…
Updated the broken links. Recently moved the storage server back to my homelab.
thanks! I’ll try running your mods soon
PS @yatli:
I’ve been working on the keyboard firmware (the one from clockworpi’s repo for now) this past week with a special focus on the trackball. I’ll create a new thread to discuss it properly, but I wanted to update you on the issue first, since you’ve done lots of other stuff on the code and for much more time than me.
I personally think the mouse is not usable in the current state (even with the v0.3 firmware), so I did a rewrite of trackball.ino
with a naive IRQ counter + a (FIR/IIR) filter on the (x,y)
position. This seems much more usable, simple (no need for “debouncer” or “glider” in the trackball) and makes it possible to move the mouse in “curves”, but adds a bit of a delay. It’s not perfect yet, but the main issue is that the interrupts are too slow and drop too many requests to properly draw a diagonal motion (hence the need for a filter).
this is the tool use to make self-extracting shell script for firmware flashing