Simple approach to write PS3/PS4 usermode driver?

Hello,

now I've been trying several things, but maybe I missed something.

- If I just blacklist "hid-sony", then everything is dead. No bluetooth 
binding, no "/dev/hidrawX".
- After some searching, I found out that the core reason for this is a 
"hid_have_special_driver" list in hid-core.c which contains the PS3/PS4 
controller.
- So I thought: Maybe I can keep "hid-sony" to keep "/dev/hidrawX" and 
somehow detach the generated eventX and jsX devices. I've been searching 
/sys for about half an hour but I didn't find any way to do this. Maybe 
impossible?

I know that libusb may be an option, but this way I also give up easy 
bluetooth binding. Especially the PS4 gamepad is easy to bind. If the 
resulting bluetooth device wouldn't be blacklisted in hid-core.c.

Maybe someone can give me a hint. Is there any easy way to get the HID 
to input device translation process ported into usermode without giving 
up all the things that work automatically if hid-sony is active?

Thank you very much for any information.

Best regards,

Manuel

On Mon, 15 Feb 2016 20:29:18 +0100
Manuel Reimer [off-list ref] wrote:

Hello,

now I've been trying several things, but maybe I missed something.

- If I just blacklist "hid-sony", then everything is dead. No bluetooth 
binding, no "/dev/hidrawX".
- After some searching, I found out that the core reason for this is a 
"hid_have_special_driver" list in hid-core.c which contains the PS3/PS4 
controller.
- So I thought: Maybe I can keep "hid-sony" to keep "/dev/hidrawX" and 
somehow detach the generated eventX and jsX devices. I've been searching 
/sys for about half an hour but I didn't find any way to do this. Maybe 
impossible?

Have you tried loading hid.ko with the ignore_special_drivers=1
parameter? I guess that will ignore _all_ special drivers tho, even
mouse and keyboard ones.

I know that libusb may be an option, but this way I also give up easy 
bluetooth binding. Especially the PS4 gamepad is easy to bind. If the 
resulting bluetooth device wouldn't be blacklisted in hid-core.c.

Alan Ott's hidapi[1] is a better alternative to libusb for hid
devices.

[1] http://www.signal11.us/oss/hidapi/

Maybe someone can give me a hint. Is there any easy way to get the HID 
to input device translation process ported into usermode without giving 
up all the things that work automatically if hid-sony is active?

Thank you very much for any information.

I reckon a patched kernel is not an option, is it?

If I may, why a userspace driver? Can't you improve the kernel driver
to match your needs? You'd also avoid code duplication this way.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

On 02/15/2016 10:34 PM, Antonio Ospite wrote:

Have you tried loading hid.ko with the ignore_special_drivers=1
parameter? I guess that will ignore _all_ special drivers tho, even
mouse and keyboard ones.

Exactly. And so it is not what I planned to do.

Alan Ott's hidapi[1] is a better alternative to libusb for hid
devices.

Of course, but just for fun, I'll at least try to use libusb directly. 
There are many examples on the net. I've already collected some code 
snippets to use.

I reckon a patched kernel is not an option, is it?

The kernel side driver does a great job. It has minor bugs (kernel panic 
when disconnecting controller while in game), but nothing too bad.

My plan is to remap to Xbox gamepad button mapping so games actually 
work with the controller. In fact, I bought a brand new PS4 controller 
just for my driver project. At least so far, I only own the PS3 console.

What I've done so far is to write a daemon which connects to the 
existing event device to get events from there, but this didn't really 
work as games still see the original controller.

That's why my current plan is to connect one layer deeper so the 
original event devices aren't created at all.

My reason for userspace is, that it's easier to debug and for the 
potential end user it is easier to install. I just had too much trouble 
with dkms in the past.

Best regards,

Manuel

2016-02-16 20:45 GMT+01:00 Manuel Reimer [off-list ref]:

On 02/15/2016 10:34 PM, Antonio Ospite wrote:

quoted

Have you tried loading hid.ko with the ignore_special_drivers=1
parameter? I guess that will ignore _all_ special drivers tho, even
mouse and keyboard ones.

Exactly. And so it is not what I planned to do.

quoted

Alan Ott's hidapi[1] is a better alternative to libusb for hid
devices.

Of course, but just for fun, I'll at least try to use libusb directly. There
are many examples on the net. I've already collected some code snippets to
use.

quoted

I reckon a patched kernel is not an option, is it?

The kernel side driver does a great job. It has minor bugs (kernel panic
when disconnecting controller while in game), but nothing too bad.

My plan is to remap to Xbox gamepad button mapping so games actually work
with the controller. In fact, I bought a brand new PS4 controller just for
my driver project. At least so far, I only own the PS3 console.

What I've done so far is to write a daemon which connects to the existing
event device to get events from there, but this didn't really work as games
still see the original controller.

Do you mean that games still see the events from the device? In that
case you can grab the event device so you are the only one that can
see the events.

If your problem is that the game only look at the first joystick
device, for SDL games, you can try the SDL_JOYSTICK_DEVICE env var
(set to the event node, not the js node IIRC) to force the use of a
specific joystick.

If the game only open /dev/input/js0, you could try to reserve it
before your gamepad is connected then replace with a new instance of
you daemon. I never had to go that far yet.

I have the same problems with my WiiU gamepad but so far I managed to
make every games work with either xboxdrv+SDL_JOYSTICK_DEVICE or with
SDL_GAMECONTROLLERCONFIG (for modern SDL games).

That's why my current plan is to connect one layer deeper so the original
event devices aren't created at all.

My reason for userspace is, that it's easier to debug and for the potential
end user it is easier to install. I just had too much trouble with dkms in
the past.

Best regards,

Manuel

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 16 February 2016 Clément VUCHENER wrote:

2016-02-16 20:45 GMT+01:00 Manuel Reimer:

quoted

On 02/15/2016 10:34 PM, Antonio Ospite wrote:  

quoted

Have you tried loading hid.ko with the ignore_special_drivers=1
parameter? I guess that will ignore _all_ special drivers tho, even
mouse and keyboard ones.  

Exactly. And so it is not what I planned to do.
 

quoted

Alan Ott's hidapi[1] is a better alternative to libusb for hid
devices.  

Of course, but just for fun, I'll at least try to use libusb directly. There
are many examples on the net. I've already collected some code snippets to
use.
 

quoted

I reckon a patched kernel is not an option, is it?  

The kernel side driver does a great job. It has minor bugs (kernel panic
when disconnecting controller while in game), but nothing too bad.

My plan is to remap to Xbox gamepad button mapping so games actually work
with the controller. In fact, I bought a brand new PS4 controller just for
my driver project. At least so far, I only own the PS3 console.

Have you tried event remapping as supported by evdev?

Have a look at EVIOCGKEYCODE and EVIOCSKEYCODE ioctls for event devices.

Those might be sufficient to perform your remapping (as long as games don't
do magic based on event device identification).

Best regards,
Bruno

quoted

What I've done so far is to write a daemon which connects to the existing
event device to get events from there, but this didn't really work as games
still see the original controller.  

Do you mean that games still see the events from the device? In that
case you can grab the event device so you are the only one that can
see the events.

If your problem is that the game only look at the first joystick
device, for SDL games, you can try the SDL_JOYSTICK_DEVICE env var
(set to the event node, not the js node IIRC) to force the use of a
specific joystick.

If the game only open /dev/input/js0, you could try to reserve it
before your gamepad is connected then replace with a new instance of
you daemon. I never had to go that far yet.

I have the same problems with my WiiU gamepad but so far I managed to
make every games work with either xboxdrv+SDL_JOYSTICK_DEVICE or with
SDL_GAMECONTROLLERCONFIG (for modern SDL games).

quoted

That's why my current plan is to connect one layer deeper so the original
event devices aren't created at all.

My reason for userspace is, that it's easier to debug and for the potential
end user it is easier to install. I just had too much trouble with dkms in
the past.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 02/27/2016 10:59 PM, Bruno Prémont wrote:

Have you tried event remapping as supported by evdev?

Have a look at EVIOCGKEYCODE and EVIOCSKEYCODE ioctls for event devices.

Those might be sufficient to perform your remapping (as long as games don't
do magic based on event device identification).

They do! A few games actually have support for the PS3 controller so I 
would have to enable/disable my modifications depending on that.

I just want some easy way to use my controllers with any game that 
supports xbox pads. This also involves scaling the stick values to the 
range used by the Xbox pad.

I'm nearly done with USB support in my usermode driver and currently I 
think I won't do bluetooth as this starts to suck. USB seems to be many 
times easier...

For whatever reason the PS4 controller doesn't send anything to the 
interrupt socket (I already send all "initialization sequences" I found 
on the web) and the PS3 controller seems to use some crazy special type 
of connecting (does the controller actually try to connect to my PC and 
so I have to listen for it??).

I still hope to be at least able to support the PS4 controller in 
bluetooth mode, but I don't have any clue why the interrupt socket is 
silent...

Best regards,

Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html