* [ISSUE] ratbgagd starts too early?
@ 2020-11-16 15:05 sardior
2020-11-16 15:16 ` ratbagd " ericonr
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: sardior @ 2020-11-16 15:05 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
New issue by sardior on void-packages repository
https://github.com/void-linux/void-packages/issues/26430
Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### System
* xuname:
Void 5.8.18_1 x86_64 AuthenticAMD uptodate rrrrmmnFFFFF
* package:
libratbag-0.14_1
### Expected behavior
After enabling the ratbagd service ratbagctl should automatically see the available devices.
### Actual behavior
When the service is started automatically by runit it seams to be running but `ratbagctl list` doesn't see any devices. If service is restarted manually with `sv down ratbagd && sv up ratbagd` then everything starts working. It looks to me like there is some unknown dependency so I tried adding a condition to the service run script to wait untill a tty login is active, but that didnt help either.
### Steps to reproduce the behavior
1. Enable ratbagd service
2. reboot
3. execute `ratbagctl list`
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
@ 2020-11-16 15:16 ` ericonr
2020-11-17 13:16 ` sardior
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ericonr @ 2020-11-16 15:16 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-728126726
Comment:
I wonder if you could try waiting on `udevd`, assuming that's the issue...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
2020-11-16 15:16 ` ratbagd " ericonr
@ 2020-11-17 13:16 ` sardior
2020-11-22 12:15 ` ahesford
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: sardior @ 2020-11-17 13:16 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
New comment by sardior on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-728919995
Comment:
Tried it just to be sure and it didn't work. In my understanding by the time I login all system services should be running so the tty condition would have worked.
Also tried a condition to wait untill the x server is started as I use i3 and xinit is triggered post login and it might be some basic gui dependency but no luck.
Here is my run script so far:
```
#!/bin/sh
sv check dbus >/dev/null || exit 1
# Added conditions START
[[ ! xset q >/dev/null ]] || exit 1
sv check udevd >/dev/null || exit 1
[[ ! -z $(w | awk '/tty[0-9]+/ {print $1}') ]] && exit 1
# Added conditions END
exec ratbagd
```
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
2020-11-16 15:16 ` ratbagd " ericonr
2020-11-17 13:16 ` sardior
@ 2020-11-22 12:15 ` ahesford
2020-11-22 13:50 ` Duncaen
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ahesford @ 2020-11-22 12:15 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-731738805
Comment:
You probably don't even need to start the service. It should be activated by dbus. Make sure your `dbus` service is enabled and that you start your window manager wrapped by `dbus-run-session` to make sure you have a consistent user session.
If, for some reason, you really do need the daemon, your modifications to the run script have several issues. The `xset q` test is guaranteed to fail because the service script doesn't know what 'DISPLAY` to use. The udev check is effectively a no-op. (The `sv check` construct works for dbus because the dbus service defines a `check` script that properly defines conditions under which it may be considered "up". Most services, udev included, do not; in that case, `sv check` effectively tests whether the service is linked in `/var/service`, not whether it's running, and certainly not whether it's in a stable state.) The `w` check, if one user is logged in, may be ok, but will crash and burn with more than one logged-in user because you aren't quoting the subshell output.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
` (2 preceding siblings ...)
2020-11-22 12:15 ` ahesford
@ 2020-11-22 13:50 ` Duncaen
2020-11-24 15:58 ` sardior
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Duncaen @ 2020-11-22 13:50 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-731738805
Comment:
You probably don't even need to start the service. It should be activated by dbus. Make sure your `dbus` service is enabled and that you start your window manager wrapped by `dbus-run-session` to make sure you have a consistent user session.
If, for some reason, you really do need the daemon, your modifications to the run script have several issues. The `xset q` test is guaranteed to fail because the service script doesn't know what `DISPLAY` to use. The udev check is effectively a no-op. (The `sv check` construct works for dbus because the dbus service defines a `check` script that properly defines conditions under which it may be considered "up". Most services, udev included, do not; in that case, `sv check` effectively tests whether the service is linked in `/var/service`, not whether it's running, and certainly not whether it's in a stable state.) The `w` check, if one user is logged in, may be ok, but will crash and burn with more than one logged-in user because you aren't quoting the subshell output.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
` (3 preceding siblings ...)
2020-11-22 13:50 ` Duncaen
@ 2020-11-24 15:58 ` sardior
2020-11-24 16:02 ` ericonr
2020-11-24 16:03 ` ericonr
6 siblings, 0 replies; 8+ messages in thread
From: sardior @ 2020-11-24 15:58 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
New comment by sardior on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-733067186
Comment:
I need the daemon because the MX master 3 mouse I'm using does not retain settings after poweroff, so after some research I constructed the following udev rule to remedy that when I turn on the mouse:
```
$ cat /etc/udev/rules.d/70-logitec-mouse.rules
ACTION=="change"\
, SUBSYSTEM=="power_supply"\
, ENV{POWER_SUPPLY_MODEL_NAME}=="Wireless Mouse MX Master 3"\
, ENV{POWER_SUPPLY_ONLINE}=="1"\
, ENV{POWER_SUPPLY_STATUS}=="Discharging"\
, RUN+="/usr/bin/su root -c 'ratbagctl Logitech\ MX\ Master\ 3000 dpi set 4000'"
```
However for ratbagctl to work I need the daemon properly running and seeing the device, e.g. `ratbagctl list ` outputting the device list : `singing-gundi: Logitech MX Master 3000` , which is not happening for some reason unless I restart the service manually.
I changed i3 startup in my xinit from `exec i3` to `exec dbus-run-session i3` but it didn't help in this case.
Also I know the conditions are bad, they aren't meant to stay there :D
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
` (4 preceding siblings ...)
2020-11-24 15:58 ` sardior
@ 2020-11-24 16:02 ` ericonr
2020-11-24 16:03 ` ericonr
6 siblings, 0 replies; 8+ messages in thread
From: ericonr @ 2020-11-24 16:02 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-733069965
Comment:
Could your udev rule instead restart the `ratbadg` service? Really ugly, but might just work
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ratbagd starts too early?
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
` (5 preceding siblings ...)
2020-11-24 16:02 ` ericonr
@ 2020-11-24 16:03 ` ericonr
6 siblings, 0 replies; 8+ messages in thread
From: ericonr @ 2020-11-24 16:03 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 240 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/26430#issuecomment-733069965
Comment:
Could your udev rule instead/also restart the `ratbadg` service? Really ugly, but might just work
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-11-24 16:03 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-16 15:05 [ISSUE] ratbgagd starts too early? sardior
2020-11-16 15:16 ` ratbagd " ericonr
2020-11-17 13:16 ` sardior
2020-11-22 12:15 ` ahesford
2020-11-22 13:50 ` Duncaen
2020-11-24 15:58 ` sardior
2020-11-24 16:02 ` ericonr
2020-11-24 16:03 ` ericonr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).