Description of problem: The spacenavd package contains integration with systemd to start the demon. In this current form it is no usable because no program using libspnavd the user starts in the graphical session will fail to find the daemon. The `spnav_x11_open` call will fail because the X atoms the server is providing cannot be found. I think this is because the spacenavd daemon and the user's programs use different X sessions. Version-Release number of selected component (if applicable): spacenavd-0.8-1.fc33.x86_64 How reproducible: always Steps to Reproduce: 1.make sure spacenavd has been started using the systemd service 2.run a program using libspnavd (e.g., the cube demo program of that project) 3. Actual results: spnav_x11_open fails because the atoms aren't found. Expected results: daemon and user code use the same atom namespace Additional info: If I start spacenavd from a terminal within the graphical session all works fine.
In the past I have used udev activation. To be honest, I'm not sure what "atom" is in this context.
(In reply to Richard Shaw from comment #1) > In the past I have used udev activation. To be honest, I'm not sure what > "atom" is in this context. "atom"s are objects/events programs can register in the X server. See the XInternAtom man page for details. The daemon registers atoms for the new events. The libspnav library then queries the atoms and so can see whether any of the events that are delivered match the new events. Think about this as a registry. What happens is that the library run by the user tries to query the atoms (with the fourth argument set to false) and these calls fail. After that the library immediately bails. From what I can see the reason is that the daemon doesn't registers with the X server the user session uses. Everything works fine if I start spacenavd directly, the code works. I don't know enough about systemd. Is there a way to start a program with the X server that is created for the user sessions? The graphical target specifier in the .service file is not sufficient.
I played around with starting spacenavd as a normal user. Maybe it would make more sense to make this a user service? I need to look up how to do that.
(In reply to Richard Shaw from comment #3) > I played around with starting spacenavd as a normal user. Maybe it would > make more sense to make this a user service? I need to look up how to do > that. Thanks. I think I understand what you mean and I agree. But I don't know enough about this either. In it's current form the deamon needs to run as the user, it seems.
Can you confirm it works for you? When I tried it HP Space Pilot I have worked just like a mouse, however when I run spnavcfg and "Ping Daemon" it doesn't find it.
(In reply to Richard Shaw from comment #5) > Can you confirm it works for you? When I tried it HP Space Pilot I have > worked just like a mouse, however when I run spnavcfg and "Ping Daemon" it > doesn't find it. I assume you mean testing spnavcfg when running spacenavd as a user versus using the existing systemd integration. The behavior I see is matching what you see. The spnavcfg program does not detect the daemon when it runs as a user but works when started via systemd. The reason is that spacenavd started by the user cannot create /var/run/spnavd.pid and this is no fatal mistake. It just continues. spnavcfg checks for this file, though. If you manually create the file with the appropriate PID of the user-started spacenavd the configuration program will be able to ping the daemon.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.