Closed kennethrrosen closed 1 year ago
Hi I'm not a BT expert - but:
while
loop means rc.local will also be running indefinitely ; not sure if that's an issue with systemd (it could report the booting process as incomplete and/or it could delay shutdown).
- rather than active polling, isn't there a better way to handle an "BT device attached" event, eg. an asynchronous udev rule with an action (or associated systemd service) ?
Totally. Could do 99-bluetooth.rules
in /etc/udev/rules.d like so: ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="BT.sh"
with the small rc.local script
- the infinite
while
loop means rc.local will also be running indefinitely ; not sure if that's an issue with systemd (it could report the booting process as incomplete and/or it could delay shutdown).
If there rc.local is used for more, yes. But with only that script in a Video/Audio VM there shouldn't be an issue. At any rate, could just execute with an appended &
- what if the device needs to be disconnected before being detached from the qube ?
boom:
disconnect_bluetooth_device() {
sudo hidd --disconnect ${address}
}
trap disconnect_bluetooth_device SIGTERM
Yes - I know that this would be mitigated with &
, a sig trap, and that udev or dbus could be used ; but IMHO there should be a hint that this is a simple solution / hack, and that a full-fledged solution would require more work. At the minimum, if the loop isn't a background task with &
, there should be a comment that the loop should be the last thing in rc.local
(I know it sounds obvious - but people aren't necessarily "power users").
Unrelated: your " A "Truly Disposable" Qube" commit got included here - could you revert it? (then either wait that I merge this PR or make a new one with a new branch).
Thanks!
Thanks @taradiddles. I take your points and I've updated to reflect our discussion. I've also split shadow into a separate PR.
Added rc.local script and separate media qube instructions Edit: as a second commit, added "shadow qube" repo