-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to start command line first to make dongle link when started as service later. #23
Comments
The |
(Since I had fiddled with the udev rule in the mean time and to be 100% sure, I de-installed, rebuilt and re-installed xow. Then a reboot.) For some reason, the udev rules are not being applied when the service is started or they are not being applied.
`> sudo udevadm info -a -n /dev/bus/usb/003/006 Udevadm info starts with the device specified by the devpath and then looking at device '/devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10.4': looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-10': looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3': looking at parent device '/devices/pci0000:00/0000:00:14.0': looking at parent device '/devices/pci0000:00': Jan 17 12:44:54 Tulkas systemd[1]: xow.service: Main process exited, code=kille> |
I've found this issue which seems to deal with the exact same problem. Please try if the mentioned workaround solves the udev issues. |
However, the service does not run beyond
Adding |
Hmm, I can't seem to find a group |
Please disregard the above.
Thank you very much! |
I've added the workaround to the |
I was receiving the same error when trying to pair my controller running under debian 11 First I stopped the service
Next I disabled the service
After that I changed the permissions to the service file to allow writing by all users
Then I re-enabled the service
Finally I started the service and was able to pair my controller as expected.
I hope this help someone GLHF --Update-- Per @kakra's comment below, I have reverted the permissions to the service and now that my controller is paired the wireless adapter it connects as soon as the controller is woken up. Below are the steps for reverting the permissions back to the default values.
Disable service
Revert permissions
Enable service
Start service
Now when the controller is woken it immediately connect to the wireless adapter. |
This makes no sense - and it creates a security problem. This file is never written to, and it should not be possible. The permission problem is more likely with the device node, and xow should probably log which one. |
Now that the controller is paired I reverted the permissions back to the default 644 and was able to connect the controller |
I set up xow to run as a service. However, the service dies when I try to link the pad up to the dongle.
When I make sure the service is shut down again, unplug and plug the dongle in again, and I then start xom from the command line with the dongle plugged in already, all I need to do is wake the pad and the connection is established.
What is really strange: I can kill the command line instance of xom and restart the service again. The pad and the dongle then reconnect as expected and work.
Is there something wrong with the way the service initializes the dongle vs the command line init?
And why is the effect of the command line xom persistent?
Im running this on openSuSE Leap 15.1, Kernel 4.12.14-lp151.28.36-default x86_64
The Pad and dongle are brand new XBox One Controller and Wireless Adapter.
Details:
I boot PC without dongle plugged in, insert the dongle, and switch on the pad.
The pad seems to lock in (slow flashing stops) and after about 1s seems to loose connection (slow flashing starts again), dongle light is on (continuous).
Note: "Error opening device: Permission denied".
Here all users have rw permission.
I restart the service after the pad has gone back to sleep:
Check the status:
So the service is up and running again, dongle initialized.
htop shows me, that xow is running as user 64499 (the DynamicUsers=true in the xow.service.in)
I unplug the dongle.
per htop, xow is still running as user 64499
I guess this is as expected. I shut down the service and check:
Now I start xow from the command line and shut it down again brute force with Ctrl-C (just get the drive running, but don't touch the dongle):
Next I plug in the dongle and restart the service:
I start the pad again, and the same problem arises:
Jan 17 10:05:07 [#.#.#] xow[2444]: 2020-01-17 10:05:07 DEBUG - Client associating: 7e:ed:82:3c:05:f4
Jan 17 10:05:07 [#.#.#] xow[2444]: 2020-01-17 10:05:07 DEBUG - Client identifier: 1
Jan 17 10:05:07 [#.#.#] xow[2444]: terminate called after throwing an instance of 'InputException'
Jan 17 10:05:07 [#.#.#] xow[2444]: what(): Error opening device: Permission denied
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Unit entered failed state.
Jan 17 10:05:07 [#.#.#] systemd[1]: xow.service: Failed with result 'signal'.
Again, I unplug the dongle
Next I plug the dongle back in again, game pad is sleeping.
shows nothing has happened (Is there an udev issue?).
I run once more:
and press the link button on the dongle and wake the pad up again.
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:38 INFO - Pairing initiated
2020-01-17 10:12:49 DEBUG - Client associating: 7e:ed:82:3c:05:f4
2020-01-17 10:12:49 DEBUG - Client identifier: 1
2020-01-17 10:12:49 INFO - Controller '1' connected
2020-01-17 10:12:49 INFO - Serial number: 02600087216940
2020-01-17 10:12:53 DEBUG - Battery type: 1, level: 3
The controller is connected and working.
Now for the really strange part:
I shut down the xow instance again.
^C
And then start the service once more:
per htop, xow is running as user 64499 again.
All seems well.
The text was updated successfully, but these errors were encountered: