I’ve got a Logitech Wingman Extreme 3D Pro joystick / flight-stick. So many axes and buttons!
I noticed in UGS settings, a “Joystick” feature. How could I pass that up?
Goal:
I can move (“jog”) the router in all dimensions, and can control the spindle speed - using a joystick.
Problem:
UGS is not detecting the joystick “Joystick is not connected”
Operating system: Debian “Bookwork” Linux
Desktop environment: XFCE
Connection: USB-A
I have the joystick plugged in, and I am able to see live input using jstest /dev/input/js0 (using the joystick package, available from apt package installer).
Who’s got suggestions on how to get this connected?
I’ve yet to be able to figure it out either using a PS3 controller, creating /dev/js0 and using jstest-gtk to verify controls and device are functional.
Without /dev/js0 I could enable the setting in UGS and it would complain but once /dev/js0 was created, enabling the joystick in USG resulted in the joystick tab being blank on subsequent restarts of UGS.
UPDATE: cleared my .ugs* files and started a new ugs v2.1.12 directory so no custom PS3 code and no /dev/js0 device and it wouldn’t work. I relinked the /dev/input/… device to /dev/js0 and then UGS found the joystick and connected.
LONG Story:
got it working on my system but it was a journey since my core system is still 18.04 KUbuntu.
I found the my libg++ wasn’t the correct version for UGS v2.1.12 so I spun up a docker container with a more current ubuntu version. I could not get anything to work even after I’d put the custom string in from the gamepad-mapping tool( gamepad-tool-amd64_1.2.zip ) AND had it set my env variable for SDL access
I had tried exposing /dev/js0 device to the docker container but it wasn’t until I exposed the whole /dev directory (-v /dev:/dev ) that it worked.
So I’m guessing you just need to get the gamepadTool, run it, get the mapping string for your controller, maybe also set your env, open a new terminal so the env var is sourced.
@dougl
I just poured through a bunch of ‘get docker to access /dev block devices’ stuff for another issue here. I thought I’d add what I learned here for reference.
In most circumstances you need to expose the whole /dev via a -v /dev:/dev option, exposing individual devices is problematic since the list is only evaluated once during invocation. If the connected device then resets you lose access (most relevant for control boards, not such an issue for a permanently plugged joystick).
However; you also need privileges to access the block devices; by default your container cannot access them. This is controlled these days by ‘cgroups’:
OR you need to use --priviliged and accept that the container now has full, hardware level control over your machine if /dev/ is mapped.
Using ‘–priviliged’ is acceptable If you use a trusted, signed, base image (Ubuntu ones are good!) and then just install UGS + dependencies from Ubuntu repositories in the dock and nothing else you are OK. I would happily run UGS like this.
The issue is that there are bad actors out there, teaching bad habits, posting ‘solutions’ that are toxic. If you take some random ‘Joes Ubuntu for Yr Device’ as a base image you are taking a risk; and especially if they do not provide the dockerfile that would let you build and verify the image yourself.
yup, here’s my docker call, it’s derived from what I’d setup for running LightBurn since it too needed a newer version of Linux. And from what you said, I can likely remove the js0 and ttyUSB0 device settings since I had included /dev .
Oddly enough the joystick was not connected without the --device /dev/js0 setting which is different than exposing the whole directory in -v /dev:/dev setting.
My user is able to view the Joystick’s input data on /dev/input/js0. Shouldn’t this be available to applications like UGS? I’m not following why we’d need to get Docker involved.
My use of docker was because I couldn’t run the latest UGS and I mentioned how I eventually got USG running in that docker setup.
Have you tried running that gamepad tool, getting the device string, adding it to the UGS Joystick “Custom” field along with making sure /dev/js0 is usable by the user without root privileges?
I think that might be the cgroups cutting in and limiting access (though I’m not sure). I suspect you could replace all the specific device options with an appropriate cgroups setting… but since what you have works the old “if it ain’t broke, don’t fix it” motto seem appropriate
I use docker a lot; but only for building code. I try to run apps that access hardware on bare metal; containerizing them in any fashion always ends up with me stuck in a twisty maze of permissions headaches and clusterbugs.
This is my joystick configuration in Universal Gcode Sender (UGS) > Settings > UGS > Joystick > Custom mappings.
I added the joystick ID from Gamepad Tool in the text below…
0300eb976d04000015c2000010010000,Logitech Extreme 3D Pro M/N: J-UK17 P/N: 863225-1000,a:b11,b:b10,x:b8,y:b9,back:b6,guide:b7,start:b5,leftstick:b2,rightstick:-a1,leftshoulder:b4,rightshoulder:b0,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a2,platform:Windows,
Sorry about that!