PSP as a USB HID GAMEPAD

[elynx]

Hello everyone,
My goal is to create a driver for the psp which will let any computer believe it is a HID gamepad.

If i achieve this goal, it would be useful for several reasons:
-I dont have any game controller for my computer and even if the psp isn't as great as a real joystick, i think that it's better than nothing.
-It would be great for playing at final fantasy 7 on epsxe since the psp is very similar to a Playstation 1 controller.
-Well every homebrew creator can then try out the contol of his game without lauching the game itself on the psp.
...

I've been really excited when i saw that more of the usb communication has been figured out (cf pspusbbus.h).
But obviously, from what i saw in the source code of psplink the whole setup of the psp as a usb device for the host is done
automatically by the fonction "sceUsbbdRegister".
This is the problem: if we want the psp to be recognized as a HID device we need to send some HID specific reports at the setup time and there for
we need to control this setup, to know exactly what kind of report the host ask at every moment of the setup etc...

So i 'm coming up to the question:
Do you think that we can add HID report stuff in the structure "UsbDriver" needed by the fonction "sceUsbbdRegister" ?

or else i suppose that if we want to rewrite the setup we need first to figure out more on the USB hardware registers...

[paxux]

You should check out this topic:

http://forums.ps2dev.org/viewtopic.php?t=4197

[elynx]

i've already read this subject but his author uses a different manner to transform his psp as a gamepad.
With his manner a psp user need:
-a wifi access point (to communicate with the pc, the psp must pass through the whole internet protocol)
-a software (PPjoy) that create a virtual gamepad (which simulate a HID device)
-a program (sockettest) which need to be running all the time and which is the link between the data coming from the wifi and PPjoy's virtual gamepad.

If he wants to and has the time to, he can replace the wifi communication with a usb protocol and this way increase the whole speed of his manner, and i will be grateful as i will use his manner for playing at FF7 sooner ;)

BUT..., well, the whole process for get it work is a bit complicated...whereas with my method a psp user only need to plug and play!

The bad thing is that we don't have figured out enough from the usb aspect of the psp so that i can create the "usb hid gamepad driver for psp".

[paxux]

So you already know about: http://www.usb.org/developers/hidpage/

It's just now about manipulating the USB port on the PSP that's the problem?

[elynx]

exactly.

I'd like to help at figuring out the usb port but i've never done reverse-enginering before...

[futaris]

There are plenty of examples of HID drivers for USB microcontrollers out there. It should be possible to adapt the code to the PSP...

The example on pg 41 at http://www.usb.org/developers/hidpage/#Usage_Tables should lay it out.

Search microchip.com...

http://artjoy.narod.ru/ is a example for the 18F2550.
http://forum.microchip.com/tm.aspx?m=15 ... y=&#157003 is another example of code...

[elynx]

Thanks for the links but i already have many examples & documents on the subject. In particuliar, i have the source code of a project that does exactly what i want to do but for another handheld (GP32 :))...

I have a clear idea on how to achieve my goal, but unfortunatly, it's seems that it's too early: we don't know enough from the usb port of the psp.

The goal of this subject is knowing if this project may interest other people than me and can eventually help me in using the pspsdk.

Is there a person in this comunity which has already used/understood pspusbbus.h and which can confirm me that there is (currently) no other way to setup the connection between the psp and the pc than with sceUsbbdRegister?

Again thanks for helping me : )

[TyRaNiD]

*sigh*

Well to emulate a HID driver you just need to handle the HID descriptor requests, this is possible just I am far too lazy to document my stuff with the usb driver ;)

Basically as far as I know you need to handle the HID cases in usb_request and fill out the return data. usb_request is called when a USB descriptor request is sent to the USB driver which the bus driver itself cannot satisfy. I can't really be bothered to remember how you do that of course, it has been a long time and it wasn't really needed for usbhostfs. Time you got out that disassembler, and built an SIO debug cable :)

The best way to learn is through doing, modify the device/configuration descriptors to indicate it is a HID driver and throw debug output to SIO when the callbacks are hit, perhaps the undocumented callback is used specifically in HID stuff who knows. Then just extrapolate from what results you get and what you know the HID driver on the PC is doing to work out what you need to do :)

[elynx]

thank you very much for your help!
Now i'm going to try out extrapolating as you said;
I'll come back when i figure out more on the unkown callback functions...

[elynx]

I've modified usbhostfs so that windows detect the psp as a hid device and it does works but i didn't manage yet to setup completly the hid driver...
what is strange is the fact that usb_request isn't called at all during the setup!

[MikeDX]

Has there been any progress on this? I'd love to be able to use my psp as a normal HID gamepad but sadly I lack the resources to do so.

[elynx]

Hello, I'm finally back on this project since I have some time to spend on it.

To let you know what is done so far, you'll see what the program "lsusb" tells me.

Here are the current results for the psp:

Code: Select all

[elynx@abo-126-43-69 sbin]$ ./lsusb -v -s 3:3

Bus 003 Device 003: ID 054c:01ca Sony Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x054c Sony Corp.
  idProduct          0x01ca
  bcdDevice            1.00
  iManufacturer           1 Sony
  iProduct                2 PSP Type C
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Connection timed out
Device Status:     0x0001
  Self Powered

And here is what It should look like (it's the result for my GP32):

Code: Select all

[elynx@localhost sbin]$ ./lsusb -v -s 1:13

Bus 001 Device 013: ID 0eb6:3241
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        16
  idVendor           0x0eb6
  idProduct          0x3241
  bcdDevice            1.00
  iManufacturer           1 GamePark
  iProduct                2 GP32
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      47
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              32
cannot read device status, Broken pipe (32)

I've modified the usbhostfs driver to obtain a HID interface

bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None

And now, under linux only, I get some output from usb_request:

Reqtype-----Request ----Value----- Index----- length
128--------------6----------300---------0-----------FF
128--------------6----------301------- 409----------FF
128--------------6----------300---------0------------FF
128--------------6----------302--------409----------FF
128--------------6----------600---------0------------A
128--------------6----------A00---------0------------4

basically, from what I know of the usb specs,

Reqtype=128 and Request=6 means "Descriptor request"
and the Value should be the type of the descriptor.

To get my Hid driver working, I have to send a HID Device Descriptor and a Report Descriptor, which types are 0x33 and 0x34, but has you can see, It hasn't been requested yet... Instead some strange descriptor types are requested (0x300, 0x301, 0x302, 0x600, etc...)

I'm reading the specs to figure out what are thoses descriptors, but If someone knows anything, Just let me know.

For the Endpoints, I don't know yet if I can just modify the driver to only keep one Endpoint Descriptor and to modify It so it look like

Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 32

I'll try this soon and I will post the results here.

I'm Also creating a "psp hid mouse driver" which should help me figuring out how to manage HID stuff on the psp.

see you later!

[EDIT]my last pb is solved and doesn't need to appear in this post any more

[ps2dev]

Dear elynx,

does

my last pb is solved and doesn't need to appear in this post any more

means that you have fix your problems and you have released a runable version of an HID-Simulation?

In this case is it possible that you share your experiences with us?

The reason is, I start with the same goal to create a PSP-HID-Joystick.
And now i saw your/this thread. For that it would be nice from you to give us/me some hints or a small code snippet.

Thank you
Jordan

[elynx]

means that you have fix your problems and you have released a runable version of an HID-Simulation?

The last problem I'm talking about was a silly error on my linux and doesn't really concern this project. (that's why I removed It)

My current "runable version" doesn't work yet because of the problems I evocated above.

In fact when I connect my psp to my computer and next I run my program then I get this messages coming from the system tray on windows:

"PSP Type C"
"USB Human Interface Device"
"A problem occured during the installation of your new hardware" (or somethings like that)

Which is normal since I can't send the needed descriptors yet.
But the thing which is strange is the fact that on the psp I dont get much output:none of the callback such as usb_attach or usb_request are called at all! (apparently)

In the contrary when I do the same on linux, then I've got output from usb_attach and when I run lsusb I get a few usb_request...(the strange descriptor requests).

As for now, I didn't manage to identify what are those descriptor of type 0x300 etc... but since the goal of lsusb is to get as much informations on the connected usb devices as possible, I suppose that It asks some different kind of descriptors.
Besides I have no request of the descriptors 0x33 and 0x34 (which are the ones I need to send) so I suppose that maybe they are automatically send by the psp and therefore they need to be put in the padded data structure UsbData (cf pspusbbus.h) or somewhere in the things which haven't been figured out on the usb stuffs of the psp.

That's why I'm a bit stuck for now...

In this case is it possible that you share your experiences with us?

The reason is, I start with the same goal to create a PSP-HID-Joystick.
And now i saw your/this thread. For that it would be nice from you to give us/me some hints or a small code snippet.

Thank you
Jordan

Well, I can tell you what I did for now, It not very complicated:
I started from the source code of usbhostfs by TyRaNiD which is the only homebrew which setup completly and succesfully the driver on the psp which allows it to communicate with the pc.
And then I've modified some of the standard descriptors (actually the ones which are automatically sent by the psp when using usbhostfs)
so that they describe a HID device. And from the result I've got on windows, I guess It works...but up to the HID specific descriptors!

After that, I started to code the main function which handle sending to the computer the pressed buttons etc...but for now this part is useless since I'm stuck with those HID descriptors...

That's all for now, good luck!

[elynx]

usb_request is called when a USB descriptor request is sent to the USB driver which the bus driver itself cannot satisfy.

So from my results it seems that the bus driver might be able to satisfy the HID descriptor request by itself.

throw debug output to SIO when the callbacks are hit, perhaps the undocumented callback is used specifically in HID stuff who knows.

I throw the debug output directly to the psp screen, why is it needed to throw them to SIO?

[gbj1]

Order a Windows DDK from M$ first. They have .h files for hid device drivers. You won't need to guess anymore and you can write your own driver. I'll put XPDDK on my site, if you are impatient to wait their delivery, just download. It's totally free to distrubute. http://218.81.210.200/files/

[TyRaNiD]

You dont really need the XP DDK now do you, especially considering all the info you could possibly want is available on usb.org and in the linux source code. And that said you can now just download the DDK again, they renamed it for Vista (something like the Windows Driver Kit) but it is now accessible direct for MS :)

[gbj1]

http://www.microsoft.com/whdc/devtools/ddk/default.mspx

You can download the iso directly from MS. I'll not host this file anymore.
Thanks,TyRaNiD. It has been a LONG time since last time I hit in mic..soft. So I'm not updated on this. I'm now completely devoted to linux and embeded devices. :)

Btw, my mobile phone runs Symbian os 9.1 and it supports MS-Duo. I have S60v3 SDK (gcc with customized libraries)but I have no idea on how to trace raw access. It seems that they do not offer any of such APIs at all. They have so called 'security' either. I know it's running on ARM9TDMI@235Mhz. Can anyone break the ice?

[elynx]

thanks for the link.

[elynx]

My psp has been stolen during my trip to my parent's house, so I can't work on this project anymore... I might continue it if I buy a new psp when I'll be at Singapore in August.

[DickyDick]

I'm currently working at a PSP project, I want also to emulate a USB device using my PSP.

I have some questions about the sce/pspsdk functions (Or I just don't understand the API):

1. In the psplink source.... why do you have to start the 'default driver' also? why is it not enough to start your driver only?

sceUsbStart(PSP_USBBUS_DRIVERNAME, 0, 0);

Anyway I used the usbhostfs code of psplink to start up the usb driver,
but changing the vendor id en product id in the DeviceDescriptor struct in the code did not change the vendor id and product id recognized on the PC side.

2. Is the SONY Vendor Id a fixed one on the PSP?

3. Why do you have to provide the product id in the function sceUsbActivate?

4. How does this product id match with the UsbDriver structs used in sceUsbbdRegister? Where is the link between them?

5. why is it necessary to fill the device descriptor info in the "start_func" can 't you do that before the sceUsbbdRegister call...?

[TyRaNiD]

1. Because you have to.
2. Yes
3. Because how else would you specify the PID?
4. There isn't one
5. Because you have to for alignment reasons.

[DickyDick]

Thanks for your time and replies. It must be a burden to be the only person in the scene to actually know these answers!! ;-)

Anwsering your question in answer 3: In an ideal world I would expect:

- registering driver - starting by driver name/id - activating by driver name/id

and picking up the PID in the device descriptor struct you provided earlier.

About the fifth answer, when I do the usbdata/gdriver stuff before the sceusbbdregister call, it initializes just as fine.. Anyway...

So this USB driver API is fairly rigid, and not very logical (from an API standpoint) The StringDescriptor you provide in the driver struct isn't even used, or not published when connecting to the PC. So what is it doing there then?! Only sony knows. EDIT: when I installed an USB analyzer on the PC, I could see that the string descriptor does come through but for some reason that name doesn't show in the Windows USB Device List.. weird


Still not giving up though.. I wonder if these API limitations are software induced (by the firmware) or hardware, so I can bypass the whole fixed stuff by talking to the hardware directly.

BTW: Happily the device i want to emulate using the PSP is a SONY device, so the fixed Vendor Id stuff does't bother the project YET ;-)

[TyRaNiD]

Well yah with 5 I suppose it doesn't matter when you do it, I just cloned what other stuff did. But the maual building of the structures is for alignment reasons.

It isn't totally logical but for what Sony needed to do it does the job, plus it is internal APIs so they probably couldn't care less about how easy it is to use. I think the string descriptor will show if you specify a PID outside of the range assign to the PSP (i.e. 0x1C8 - 0x1CC), otherwise it will pull the device name from the internal descriptors of PSP Type X.

And it is probably less limited talking to the hardware directly, just you have to find what chip it is using which in at least my initial investigation didn't throw up much.

[DickyDick]

What I found out..

that the string descriptor provided in the g_driver struct ends up being a Interface string descriptor!!?

I called it "Plofkip" for testing purposes.. see where 't ends up in this USB dump, as an Interface description (underlined it here)!!


Device Descriptor
Offset Field Size Value Description
0 bLength 1 12h
1 bDescriptorType 1 01h Device
2 bcdUSB 2 0110h USB Spec 1.1
4 bDeviceClass 1 00h Class info in Ifc Descriptors
5 bDeviceSubClass 1 00h
6 bDeviceProtocol 1 00h
7 bMaxPacketSize0 1 08h 8 bytes
8 idVendor 2 054Ch Sony Corp.
10 idProduct 2 0125h
12 bcdDevice 2 0100h 1.00
14 iManufacturer 1 01h "Sony"
15 iProduct 1 00h
16 iSerialNumber 1 00h
17 bNumConfigurations 1 01h

Configuration Descriptor 1 Self Powered
Offset Field Size Value Description
0 bLength 1 09h
1 bDescriptorType 1 02h Configuration
2 wTotalLength 2 0027h
4 bNumInterfaces 1 01h
5 bConfigurationValue 1 01h
6 iConfiguration 1 00h
7 bmAttributes 1 C0h Self Powered
4..0: Reserved ...00000
5: Remote Wakeup ..0..... No
6: Self Powered .1...... Yes
7: Reserved (set to one)
(bus-powered for 1.0) 1.......
8 bMaxPower 1 01h 2 mA

Interface Descriptor 0/0 Vendor-Specific, 3 Endpoints
Offset Field Size Value Description
0 bLength 1 09h
1 bDescriptorType 1 04h Interface
2 bInterfaceNumber 1 00h
3 bAlternateSetting 1 00h
4 bNumEndpoints 1 03h
5 bInterfaceClass 1 FFh Vendor-Specific
6 bInterfaceSubClass 1 01h
7 bInterfaceProtocol 1 FFh
8 iInterface 1 02h "Plofkip."

[MBx]

[DELETED FOR NOW]

[MBx]

I was working on this topic for few days, but since I'm not experienced enough with PSP I stuck right now and all I'm able to do is to share what I've done and what I cannot solve.

I really hope that some one can help me out of here.


here we go:

all we need to do to define an HID device is:

1. set some bytes in USB interface descriptor.
2. send an HID descriptor AFTER interface descriptor and BEFORE endpoints.
3. send an HID report after the connection has been established.


the first part is nothing serious:

Code: Select all

.bLength = 9, 
	.bDescriptorType = 4, 
	.bInterfaceNumber = 0, 
	.bAlternateSetting = 0, 
	.bNumEndpoints = 1,
	.bInterfaceClass = 0x03,
	.bInterfaceSubClass = 0x00,
	.bInterfaceProtocol = 0x00,
	.iInterface = 1

I'm currently stuck on the second part. I was not able to send any thing BETWEEN interface and endpoints descriptors.
my experiments:

1. none of the known usb functions called during the registration of a usb device. all the information will be send automatically by an unknown function after start_func of a usb driver returned.

2. this unknown function works with UsbData structure. the only comment above this structure is "Padded data structure, padding is required otherwise the USB hardware crashes." obviously someone (probably TyRaNiD) reversed engineered this function, so he knows how this function manipulates the given structure.

3. Being blind about this unknown function I just tried to put HID descriptor bytes somewhere:

3.1 UsbData has a member of type UsbData::Interfaces which can points to two interface descriptor and an IntCount which probably is an interface count. I tried to to put HIDD in the second one and set intcount = 2. but device do not sends the second interface descriptor (using an USB analyzer it's easy to see send/receive).

3.2 I've tried to put HIDD in pad part of the first interface descriptor which caused the usb to crash.

3.3 I've tried to put in endpoints but the usb port of my PC crashed. I think it's waiting for more data to come (the real endpoints)! the funny thing about this is that windows detects the PSP as a HID which installed successfully! (this method is a real pain in the ass since you have to reboot your PC to back online so: Do not try this at home!)

3.4 I've tried to put it in some other places which I cannot remember!


all we need to do right know is to find out how that unknown function works. how it sends the data and in particular how we can send TWO interface descriptor.
I really don't know how one may find this out :(


I HOPE some one can help. :p


P.S.
it seems that the third part is not difficult because it's AFTER the connection has been established.
btw, we have to solve the second part before third!

[DanielC]

Wow, this is worthy of a bump! Using the Wifi controller stuff in Vista is just buggy as hell, I can't stand wireless and would love a standard USB controller... maybe with a front-end like XBCD has to remap buttons and axis... thats way in the future though....

Hope you keep working on this, i'd pay $10 for a working controller driver for my PSP! Yes, you can hold me to that, do you need a donation? :D

[MBx]

I far more need an experienced guy help than a donation :p
but tnx anyway :)

[MBx]

should I wait here like ... forever?