discussing overall design

[rhaschke]

Dear @jtsiomb,

thanks for merging #1 so quickly. I would like to raise a very fundamental question: Where do you see the benefit of using a daemon to dispatch device events? I guess, that this decision is primarily a historical one: The native 3dconnexion driver originally used a daemon to dispatch events via the X server.

I see some drawbacks of this approach:

• X11 communication suffers from permission issues: Running the daemon and the client as different users, requires to add client user's permissions in the ~/.Xauthority file of the daemon's user. The simple solution in FAQ10 only works for a single user. This is very annoying in a multi-user environment.
• The socket communication adds a considerable overhead, especially in maintenance, but also regarding delays.
• Clients cannot distinguish between multiple devices connected to a machine.
• Clients cannot grab the device. Currently all connected clients receive all events. However, imagine several X11 windows making use of the device. In this case only the window having focus should receive device events. Otherwise multiple windows will react to those inputs, which is usually not desired. In a single-application environment, of course, this doesn't pose a problem.

I think that all/most of the functionality can be provided by a lib-only approach as well, which will considerably simplify the design: Both axis remapping and sensitivity adaptation could be realized on the client-side, e.g. with a thin wrapper around libevdev.

The only exception, I see currently is X11 forwarding through ssh. With a lib-only approach, the X11 client has no chance to access the server's device. However, X11 natively supports all input devices via xf86-input-evdev / xf86-input-libinput. Also, the auto-led feature requires a central daemon...

Some interesting reads:

• https://www.freedesktop.org/wiki/Software/libevdev/
• https://www.x.org/releases/X11R7.7/doc/libXi/inputlib.html

As you see, I'm strongly biased towards Linux. I have no idea, which implications a lib-only approach will have on Windows or Mac.

[jtsiomb]

A few points in short, because I don't like holding conversations over web interfaces. For more details or if you wish to discuss this further, please send me an email at nuclear@member.fsf.org. Also I'm closing this as it's not really an issue.

• The X11 communication mechanism is only for compatibility with programs written for the official driver. I'm not suggesting it's a good way to design something like this.
• UNIX domain socket IPC does not add any overhead. It's a simple buffer copy, and the data being copied are tiny.
• The only point I can see in having multiple devices, is to combine their inputs. So let's say use two joysticks with x-y-twist controls to make a full 6-dof manipulator. And even that was never in the original design.
• Clients are perfectly able to ignore input from spacenavd when they don't have input focus.
• Factoring out the device handling code into a library which is used by spacenavd, but could also be used by applications which prefer that direct approach is one of the ideas I mean to do for some time now, but I never got around to doing.
• A big advantage of having a daemon handle the device, is that the user doesn't have to fiddle with device permissions to allow random programs access to the device. Otherwise every program which needs 6-dof input would have to come with instructions on how to manage permissions.

Hope I answered your questions. If not, please send me an email with further questions.