[Feature Request]: A hidraw controller plugin for Linux / Analogue buttons for Linux

[Slider-Whistle]

Description

If somebody's up for it, I think it's about time that PCSX2 got its own event device hidraw controller driver.

Reason

LilyPad is unavailable on Linux, and OnePad has wide feature gaps (lack of analogue button support, lack of multitap support, no plug and play dualshock 2/3 access), Apparently there is a lack of desire to either port LilyPad, or to extend OnePad either. I don't want to sound entitled, but a large (sorry, I might have exaggerated here) portion of the PlayStation 2 library is unplayable on Linux without analogue button support. If it's an issue that anyone else who feels like doing the work (unlike myself) is interested in, I think it would make some people happy.

Examples

• RPCS3 has a built-in driver which directly interfaces with a selected /dev/input/event{x} /dev/hidraw{x} file, designed for use with Dualshock 3 controllers, or anything else that looks like one (for example, a Dualshock 2 controller plugged into a USB adapter). With no settings to configure aside from a path to a readable and writeable event file, rumble, analog buttons, and button layout all work instantly. It's basically perfect.
• The Dolphin emulator has similar passthrough functionality built-in, for both bluetooth Wii controller access and for the official Gamecube to USB adaptor.
• Raph has written windows and linux direct driver plugins for his very own Nintendo 64 controller adaptors in both popular emulators, Project64 and Mupen64Plus. What a god.

[weirdbeardgame]

Analogue is on by default in the plugin? I've never once heard anyone having any issues with such games

[Slider-Whistle]

kenshen112: I don't mean the Analogue/Digital analogue stick switching button, but 8-bit sensitivity in the face buttons. Racing games, and famously Metal Gear Solid 2/3 use this hardware feature.

[weirdbeardgame]

You mean pressure sensitivity?

[Slider-Whistle]

Yes, that. Are you saying that it works on your end? I haven't managed to get it working, and whenever I look into it I find plenty of forum threads and at least one github issue so far.

[weirdbeardgame]

No that. That would be a seperate ask from evdev altogether though evdev can make it marginally easier to implement. And yeah. We're aware of the desire for evdev. I've been looking into it slowly but surely though I haven't done anything with pcsx2 yet

[Slider-Whistle]

I see, I assumed that PCSX2 uses something higher-level like SDL2's gamepad interface. As far as I'm aware, it's impossible to support all 12 analogue buttons through something like that (at least, sdl2-jstest doesn't expose them all).

[tadanokojin]

Yeah I mean +1 but..

With regards to DS2, I'm not aware of any adapters that support analog face buttons, are you? I'm aware there's one that says it could but that it's not implemented and you'd have to ask them to do it (maybe it's implemented in some open source driver though?). Would like details if you have any.

There isn't really Onepad and Lilypad anymore. It's just pad. The code is still pretty divergent though which is why there's such a feature gap. I've heard rumblings about the unix side getting improvements, but I doubt anyone is interested in extending the Windows side to work on unix outside of just a reference.

The unix side is basically just SDL2 with hardcoded bindings. Having an libevdev backend with ds3 and ds4 handlers is certainly on the wishlist anyway so I'll keep the issue open for now. Really I think the pad stuff just needs a facelift in general.

[weirdbeardgame]

Yes it does

[Slider-Whistle]

With regards to DS2, I'm not aware of any adapters that support analog face buttons, are you?

I bought a generic looking one, even that seemed to have analog button support when I gave it a spin in evtest. It's been a long while since I switched from that to actual DS3, so I may have misremembered. In terms of actual games I think PCSX2 on windows, RPCS3 and of course a physical Playstation 3 should support the adaptor's analog buttons, but that's about all I could think of.

[tadanokojin]

afaik RPCS3's native ds3 handler isn't through libevdev, it's via hidraw on linux.

[Slider-Whistle]

Oh, I think you're right about that. My mistake there.

[aljohnston112]

I would be willing to work on this, though I am not familiar with the code of either side of the joypad interface, I think I could pick it up.

[refractionpcsx2]

Now we have SDL, what does evdev have to bring to the table that SDL doesn't already cover?

I know the pad stuff isn't perfect right now, it does need improving, but API side, SDL should do everything we need.

[aljohnston112]

I am using SDL2-jstest and getting only 6 axes which means the pressure sensitive buttons are not being mapped to axes.

On another note, despite there being 6 axes, it appears that onePAD does not register the pressure sensitivity in R2 or L2.

[refractionpcsx2]

OnePAD doesn't exist anymore, can you please concentrate on the Qt version of PCSX2? Thanks.

And you can see 6 axies? how many do you want? The PS2 only had 4.

[stenzek]

And you can see 6 axies? how many do you want? The PS2 only had 4.

Likely left/right triggers.

But yeah, I see no need to complicate things with a specific evdev source, when SDL should handle it.

[Slider-Whistle]

OnePAD doesn't exist anymore, can you please concentrate on the Qt version of PCSX2? Thanks.

And you can see 6 axies? how many do you want? The PS2 only had 4.

He means SDL2's coverage for all of the DualShock 2 & 3's face buttons, which have 8-bit precision to measure the pressure held on each face button. L, R, L2, R2 (4) Left stick vertical + horizontal, right stick vertical + horizontal (8), plus: Up, Down, Left, Right (4) Circle, Cross, Triangle, Square (4) Which would require 20 analogue axes in SDL2, total.

[stenzek]

We use the gamecontroller API in SDL, which doesn't consider pressure for buttons, i.e. it's only binary.

Edit: Do the DS2/3 kernel drivers even expose this information? For the DS2 at least, it would depend on the type of adaptor being used, afaik plenty of them don't report face button pressure.

[Slider-Whistle]

We use the gamecontroller API in SDL, which doesn't consider pressure for buttons, i.e. it's only binary.

Edit: Do the DS2/3 kernel drivers even expose this information? For the DS2 at least, it would depend on the type of adaptor being used, afaik plenty of them don't report face button pressure.

DS3 definitely over bluetooth or USB definitely does, as long as you're using the genuine article. As for DS2, I think I remember analogue buttons showing in evtest, but it's been a while. I used a brandless adaptor. I could try fishing it out of my closet just to confirm.

[stenzek]

From what I can see, it doesn't: https://github.com/torvalds/linux/blob/68e77ffbfd06ae3ef8f2abf1c3b971383c866983/drivers/hid/hid-sony.c#L873-L879

Unless I'm not looking at the correct driver.

[Slider-Whistle]

Just tested my DualShock 2, as if that code you just posted could somehow be wrong. And nope, logically only L2 and R2 gave analogue values, just like it says. I'm sorry for spreading misinformation. I guess it came from my earlier misassumption that RPCS3's driver was based off evdev.

[Slider-Whistle]

Should I change the title of the issue? At this point, having an evdev driver, or a driver which can interpret analogue buttons seem like two completely different issues. Are there people interested in evdev for reasons outside of that?

[stenzek]

The bit I referenced was for DS3/sixaxis, not DS2. I'm guessing DS2 uses some generic driver for dinput-like controllers, since DS2 doesn't speak HID natively :)

Unless you can get analog values out of evdev (assuming kernel support), I see no reason for a specific evdev input source, not when SDL already does it.

[Slider-Whistle]

My adaptor, at least, basically converts the DualShock 2's I/O to the DualShock 3's USB interface. I figure this is probably what most of them do. There may be exceptions, but anything which doesn't almost certainly doesn't support analogue buttons either, anyway. I don't know if it's good form, but I've edited the title and body post to shift the focus from evdev to hidraw, if even that is correct. If there's room in SDL2 to eventually support analogue buttons, then I guess it might be an issue better handled by them, but in the meantime I think it would be pretty cool if PCSX2 could implement its own userspace driver, or copy whatever it is exactly that RPCS3 does.

[stenzek]

Writing a HID implementation in userspace is a pretty significant undertaking, and not something any of us are interested in taking on at this point (from a brief discussion on Discord). A better way would be to extend SDL's existing HID implementation.

[Slider-Whistle]

If the culture allows it, asking RPCS3 nicely if we could adapt their driver to PCSX2's way of doing things could probably remove most of the work. Wouldn't exactly be non-trivial, but I think it would make it a bit more realistic, if anybody (unlike my lazy ass) were personally interested in implementing and making a pull request for it.

[TellowKrinkle]

I don't have a DS3, so I don't plan on writing a driver for it any time soon, but for anyone curious as to what it's like to add a new HID driver to SDL, here's what it took to add Wii U Pro controller support to SDL (I'll try to upstream it some day...)

It's really not that bad as long as you can find documentation on the controller's communication protocol online somewhere. SDL handles all the actual communication, so you just make the packets and ask SDL to send them.

[stenzek]

I'm not aware what RPCS3's setup is, and whether it's tied to any particular platform, but IMO, if we had our own interface, it would make sense to make it cross platform. Investing so much time for it to only work on Linux, which is a tiny fraction of the userbase, is kinda silly.

That's another reason why we were suggesting SDL; they already have HID APIs for a range of platforms, as far as I understand it, you only have to worry about the device itself and its' protocol.

[TellowKrinkle]

You're in luck, SDL just got HIDAPI PS3 controller support 3 days ago, and it has full analog button support built-in, no hacking around necessary https://github.com/libsdl-org/SDL/issues/4923#issuecomment-1225374840

They default it off on Linux, but you should be able to get it working by building PCSX2 with the latest master of SDL and setting the environment variable SDL_JOYSTICK_HIDAPI_PS3=1. You might have to mess with permissions on /dev/hidraw devices to get it working.

[weirdbeardgame]

Is that something I should consider adding to pcsx2-git?

[TellowKrinkle]

If you rely on a bleeding edge git build of SDL, you should already have it

[weirdbeardgame]

Sorry, I meant. Should I enable that option since you mentioned it's disabled in Linux?

[TellowKrinkle]

I'd wait for someone to test it and verify that it works before enabling it

[lucasmr]

You're in luck, SDL just got HIDAPI PS3 controller support 3 days ago, and it has full analog button support built-in, no hacking around necessary libsdl-org/SDL#4923 (comment)

They default it off on Linux, but you should be able to get it working by building PCSX2 with the latest master of SDL and setting the environment variable SDL_JOYSTICK_HIDAPI_PS3=1. You might have to mess with permissions on /dev/hidraw devices to get it working.

The code has the following disclaimer:

/* Linux drivers do a better job of managing the transition between
     * USB and Bluetooth. There are also some quirks in communicating
     * with PS3 controllers that have been implemented in SDL's hidapi
     * for libusb, but are not possible to support using hidraw if the
     * kernel doesn't already know about them.
     */

I think we need something else for it to work. Related issue: https://github.com/libsdl-org/SDL/issues/5148

[mirh]

I believe they are just talking about https://github.com/libusb/hidapi/issues/259 and udev rules there. Nothing too fancy.

[lucasmr]

I can confirm the SDL implementation works with DS3 and the sdl2-jstest program. All pressure sensitive buttons report as both an axis and a digital button.

I couldn't make it work with pcsx2, though. It detected the controller and was able to adjust the rumble intensity, but couldn't assign any button mappings.

[stenzek]

PCSX2 only supports the game controller API (which reports buttons as binary), not the joystick API. PRs welcome to change that.

[lucasmr]

Just to clarify: would it be better to support SDL's joystick API for DS3, or make a new hidraw implementation for direct access, akin to rpcs3? Both could coexist, it's just a matter of developer interest.

[stenzek]

SDL's joystick API imo, that way it's not limited to just Linux, and can be used with actual joysticks.

[mirh]

SDL only has DS3 working in linux atm. And isn't pcsx2 already relying on it?

[TellowKrinkle]

Can you test #7043 and see if it helps?

[lucasmr]

7043 was merged, so consider this done for at least one option! You need:

• DualShock 3 controller;
• SDL 2.26;
• The environment variable SDL_JOYSTICK_HIDAPI_PS3=1;
• Use PCSX2 Qt build.

[lightningterror]

Is this still valid?

[stenzek]

SDL can provide it, but you could still create a separate input source/backend. I just don't see the value in doing so.

[mirh]

If #7476 enabled this by default, then I think we are good. If any something could still be improved on linux, I feel like a check could be added to warn the user about missing permissions. https://wiki.rpcs3.net/index.php?title=Help:Controller_Configuration#On_Linux