* Simple approach to write PS3/PS4 usermode driver?
@ 2016-02-15 19:29 Manuel Reimer
2016-02-15 21:34 ` Antonio Ospite
0 siblings, 1 reply; 6+ messages in thread
From: Manuel Reimer @ 2016-02-15 19:29 UTC (permalink / raw)
To: linux-input
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Simple approach to write PS3/PS4 usermode driver?
2016-02-15 19:29 Simple approach to write PS3/PS4 usermode driver? Manuel Reimer
@ 2016-02-15 21:34 ` Antonio Ospite
2016-02-16 19:45 ` Manuel Reimer
0 siblings, 1 reply; 6+ messages in thread
From: Antonio Ospite @ 2016-02-15 21:34 UTC (permalink / raw)
To: Manuel Reimer; +Cc: linux-input
On Mon, 15 Feb 2016 20:29:18 +0100
Manuel Reimer <mail+linux-input@m-reimer.de> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Simple approach to write PS3/PS4 usermode driver?
2016-02-15 21:34 ` Antonio Ospite
@ 2016-02-16 19:45 ` Manuel Reimer
2016-02-16 20:56 ` Clément VUCHENER
0 siblings, 1 reply; 6+ messages in thread
From: Manuel Reimer @ 2016-02-16 19:45 UTC (permalink / raw)
To: linux-input
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Simple approach to write PS3/PS4 usermode driver?
2016-02-16 19:45 ` Manuel Reimer
@ 2016-02-16 20:56 ` Clément VUCHENER
2016-02-27 21:59 ` Bruno Prémont
0 siblings, 1 reply; 6+ messages in thread
From: Clément VUCHENER @ 2016-02-16 20:56 UTC (permalink / raw)
To: Manuel Reimer; +Cc: linux-input
2016-02-16 20:45 GMT+01:00 Manuel Reimer <mail+linux-input@m-reimer.de>:
> 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.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Simple approach to write PS3/PS4 usermode driver?
2016-02-16 20:56 ` Clément VUCHENER
@ 2016-02-27 21:59 ` Bruno Prémont
2016-03-01 19:56 ` Manuel Reimer
0 siblings, 1 reply; 6+ messages in thread
From: Bruno Prémont @ 2016-02-27 21:59 UTC (permalink / raw)
To: Manuel Reimer; +Cc: Clément VUCHENER, linux-input
On Tue, 16 February 2016 Clément VUCHENER wrote:
> 2016-02-16 20:45 GMT+01:00 Manuel Reimer:
> > 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.
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
> > 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.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Simple approach to write PS3/PS4 usermode driver?
2016-02-27 21:59 ` Bruno Prémont
@ 2016-03-01 19:56 ` Manuel Reimer
0 siblings, 0 replies; 6+ messages in thread
From: Manuel Reimer @ 2016-03-01 19:56 UTC (permalink / raw)
To: linux-input
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-01 19:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-15 19:29 Simple approach to write PS3/PS4 usermode driver? Manuel Reimer
2016-02-15 21:34 ` Antonio Ospite
2016-02-16 19:45 ` Manuel Reimer
2016-02-16 20:56 ` Clément VUCHENER
2016-02-27 21:59 ` Bruno Prémont
2016-03-01 19:56 ` Manuel Reimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).