Twin Usb Joystick Driver
Leocricia Flinchum
I have a gamepad with two joystick on it and it function perfectly if I use windows, but when I plug into Linux the two joysticks functions as one (it will take the same direction whatever of the two I move) and right pad buttons do not work (it has a total of 20 buttons, 10 for each side).
If someone has a swifter solution to this issue or is able to upgrade the device driver would be so nice.
Besides, these 2.4Gh USB controllers are nice, cheap (13-17USD shipping and VAT included). Same we cannot play all together right from the plugging!
You are actually right: without this piece of code, by plugging in the USB key, it adds up a couple of event dirs more. But, when I restart the system, udev does not execute the starting script.
Permission issues?
How can I check/debug them?
Moreover, according to the Manjaro package guidelines, packages should go into /bin dirs but I put them in /opt since it is a script and not a binary. But /opt is devised for bulky codes according to the guidelines. Which dir is right then?
i am currently looking for a gamepad/controller solution for my Win98/MSdos rig. Been looking at logitech controllers and mayflash ps2/ps1 adapters. i was wondering if its possible to get these usb controllers/adapter working in MSDOS?
I've got an adapter (based on arduino) called joy2ps2, that let's you connect 2 atari style joystick/gamepads to the ps/2 port of the computer. Usually they are 2 buttons joysticks (like the Competition Pro), but it also supports 6 button Sega Genesis gamepads.
No additional drivers are needed IIRC, Windows 98 detects it as a Logitech Dual Action as long as the switch on the bottom of the controller is set to DirectInput mode, and it being a USB gamepad I doubt it works on real mode DOS as previously pointed out (you'll still need a separate DB15 gamepad for that ? ).
I feel you on the chucking old hardware. Probably 5 or so years ago I had 3-4 different AWE32 cards I gave away as well as some Socket 7 motherboards, a bunch of old processors, etc. a couple years ago I gave away a bunch of old video cards that I didn't want as well as a complete PII system.
In transitioning from the striking Prophecy concept to the production-spec Hyundai Ioniq 6, Hyundai's svelte EV sedan ditched its dual joysticks instead of a traditional steering wheel. But a new patent unearthed by CarBuzz and filed with the United States Patent and Trademark Office (USPTO) explains this system's operation in detail, suggesting it may become a reality sooner rather than later.
Unlike the controls found in an airplane, for example, Hyundai's invention can only pivot in one direction, either left or right. They are also not showcased as single shafts, but rather handle-like controls hinged into the armrests.
The shafts are linked to force feedback actuators to provide counter-pressure to the driver's hands in an imitation of steering feedback. Armrest pressure sensors, steering rack actuators, and a processor unit form the rest of the steering hardware, with the latter being crucial to the operation of the setup.
That's because, using the feedback actuators, the system will attempt to synchronize the movements between left- and right joysticks, to minimize driver confusion. If the two joystick angles differ too widely, the controller will consider the pressure on the armrest sensors to determine which joystick's position should take priority in its calculation of the desired steering angle. In this scenario, the force-feedback actuator will counteract the errant joystick movement as a means of alerting the driver to erroneous input.
The actual steering angle in this drive-by-wire system is determined by first checking if the joystick movement conforms to normal steering conditions and then calculating viable steering angles based on the vehicle's speed and surroundings.
By comparing the two joystick inputs, the system will calculate a target steering angle, and apply the appropriate force to the steering rack to obtain this target steering angle at the front wheels.
The system will also compensate for the driver's body moving while cornering because this could affect the steering inputs. To this end, the system will measure how heavily the driver leans on the armrests and feed this info into its algorithm, to counteract the possibility of the driver's body movement causing incorrect direction inputs on the joysticks.
It's unlikely this will be found on a production car anytime soon, not least of all because of its alien design, but also because legislation won't allow for steer-by-wire systems without mechanical failsafe. However, such a system could have merit as a human control element in something like a Level 3 or 4 Autonomous vehicle that still makes provision for some human input and has an array of additional sensors to ensure the car isn't yanked into a tree.
This isn't the first time we've encountered OEMs trying to reinvent the way we control cars. Ferrari previously patented a single seat-mounted joystick similar to one you might use for gaming, while BMW envisioned replacing the steering wheel with a twin-joystick yoke.
The concept of steer-by-wire is also familiar, although some OEMs have struggled with getting this tech to respond in a natural fashion. Most recently, Lexus delayed the launch of its unique steer-by-wire yoke in the RZ as it refines the tech further. We can only imagine Hyundai's version will be infinitely more difficult to program correctly.
/dev/input/jsX maps to the Joystick API interface and /dev/input/event* maps to the evdev ones (this also includes other input devices such as mice and keyboards). Symbolic links to those devices are also available in /dev/input/by-id/ and /dev/input/by-path/ where the legacy Joystick API has names ending with -joystick while the evdev have names ending with -event-joystick.
While SDL1 defaults to evdev interface you can force it to use the old Joystick API by setting the environment variable SDL_JOYSTICK_DEVICE=/dev/input/js0. This can help many games such as X3. SDL2 supports only the new evdev interface.
As you can see, there are many different modules related to getting your joystick working in Linux, so everything is not covered here. Please have a look at the documentation mentioned above for details.
You need to load a module for your gameport (ns558, emu10k1-gp, cs461x, etc...), a module for your joystick (analog, sidewinder, adi, etc...), and finally the kernel joystick device driver (joydev). You can load the module at boot, or simply modprobe it. The gameport module should load automatically, as this is a dependency of the other modules.
You need to get USB working, and then modprobe your gamepad driver, which is usbhid, as well as joydev. If you use a usb mouse or keyboard, usbhid will be loaded already and you just have to load the joydev module.
There are a lot of applications that can test this old API, jstest from the joyutils package is the simplest one. If the output is unreadable because the line printed is too long you can also use graphical tools. KDE Plasma has a built in one in System Settings > Input Devices > Game Controller. There is jstest-gtk-gitAUR as an alternative.
The new 'evdev' API can be tested using the SDL2 joystick test application or using evtest from evtest or evtest-qt from evtest-qt-gitAUR. Install sdl2-jstest-gitAUR[broken link: package not found] and then run sdl2-jstest --test 0. Use sdl2-jstest --list to get IDs of other controllers if you have multiple ones connected.
Go to -tester.com/. Currently, testing vibration and producing a visual of the gamepad is supported in Chromium but not Firefox. Additionally, as of version 107.0.5304.121-1, Chromium can read Joystick devices but not evdev.
1000 is the default value, but you can set anything between 0 and {{30000. To get the axis number see the "Testing Your Configuration" section of this article.If you already have an option with a specific axis just type in the deadzone=value at the end of the parameter separated by a space.
The easiest way is using jstest-gtk from jstest-gtk-gitAUR. Select the joystick you want to edit, click the Properties button. On this new window, click the Calibration button (do not click Start Calibration after that). You can then set the CenterMin and CenterMax values, which control the center deadzone, and RangeMin and RangeMax, which control the end of throw deadzones. Note that the calibration settings are applied when the application opens the device, so you need to restart your game or test application to see updated calibration settings.
If the commands above give you an empty output, it could be because your controller is connected via Bluetooth, making these unique attributes only visible on the parent device(s). To mitigate this, you could try finding other unique attributes by running:
Imagine that you tested your gamepad with evtest-qt, and find out that your left joystick cannot reach the maximum read value when you direct it to top most position. The side effect of this is that in some games (for example, HITMAN 2) the character cannot run.
Run xboxdrv and determine how the problematic axis is called. In this case it is Y1. Now try to direct it to top most position several times, and determine the lowest value that you saw. Imagine it is 29426. Now to be on a safe side, we take the value that is lower than that, like 29000. Run the command:
Nice thing about xboxdrv is that it exports resulting device as both old Joystick API and new style evdev API so it should be compatible with basically any application. You can now see in jstest that the values of axis 1 (corresponds to vertical axis of left joystick) is read from 0 to -32767, and in evtest-qt that you can reach the maximum value. And your character in game can run.
03c5feb9e7