Github messages for voidlinux
 help / color / mirror / Atom feed
* [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).