Thread: CONTEST: Xbox Chatpad Driver Challenge

Originally Posted by GAFBlizzard

0x40, 0xa9, 0xa30c, 0x4423, 0x0000 (call will return failure)
0x40, 0xa9, 0x2344, 0x7f03, 0x0000 (call will return failure)
0x40, 0xa9, 0x5839, 0x6832, 0x0000 (call will return failure)
0xc0, 0xa1, 0x0000, 0xe416, 0x0002 (read 2 bytes, will return a mode)
0x40, 0xa1, 0x0000, 0xe416, 0x0002 (send 2 bytes, data must be 0x09 0x00)
0xc0, 0xa1, 0x0000, 0xe416, 0x0002 (read 2 bytes, this should return the NEW mode)

The key thing is to use the 0x09 0x00 mode instead of the old 0x01 0x02 values we were seeing in a trace. This was apparently discovered by this guy: http://mbed.org/users/AjK/programs/S...8c_source.html I suspect it may have something to do with older chatpads, or "Made for Windows" vs. 360 chatpads, but I don't have confirmation yet. My original plan was just to try both modes and use the one that resulted in a proper mode change first.

Just tested the chatpad init routine on Linux and hell yeah, that stuff works = Such a relieve to see that chatpad come fully alive after all that time. The "0x09 0x00" however did not work for me (no chatpad init, controller dies after a few rounds of 1F, 1E), the "0x01 0x02" was the one that did the trick, data send/received from the last three calls looked like this:

recv: 01 00
send: 01 02
recv: 01 02

If the chatpad is already running:

recv: 01 02
send: 01 02
recv: 01 02

My Xbox360 controller is from Nov 2005, my chatpad from Jun 2008.

A little further testing seems to indicate that the first byte doesn't matter, whatever I send I receive back. While the second byte indicates if the chatpad is on or off. Sending 0 as second byte switches it off, sending 2 switches it on. Only the second bit in the second byte seems to matter. Sending 3, 6 or 42 will also work just fine.

About different Xbox360 controller: Both PC versions and Xbox360 versions of the controller should be identical, except for the package. I can however confirm that there are different kinds of Xbox360 in the wild, some have endpoints 1(IN) and 2(OUT) while others have 1(IN) and 1(OUT). The bcdDevice number also seems different. I however don't really know the exact details, why they differ or when or how to properly distinguish them in a robust way.

Originally Posted by GAFBlizzard

Are you sure that controller comes with the dongle? I don't see it mentioned on the page.

Yes, dongle seems to be included, the packaging with the dongle included can be seen in one of the customer supplied pictures.

all wireless controllers are identical, whether they are labled "for xbox" or "for windows" it does not matter. they are exactly the same and they work interchangeably.

the ONLY difference is the "for windows" controllers are bundled with wireless receivers. if you buy a "for windows" controller and it doesnt come with a receiver, then you didnt get what you paid for.

Hey great work.

Like many other I use the wireless receiver + wireless controller, I would really like to see support for that fast tracked

Keep up the great work what your doing is amazing! Thanks so much! Hope to use this driver soon!

I turned the key stroke/repeat settings down, it seems to have helped but not fixed, it might register stroke on release (rarely), so turning down the systems repeat delay will improve your chances at not getting a duplicate key stroke but it may still happen.

For those Linux users out there, xboxdrv now also features Chatpad support in the development version you can obtain from git:

http://pingus.seul.org/~grumbel/xboxdrv/

And direct link to the repository:

git clone git://github.com/Grumbel/xboxdrv.git

To use it start xboxdrv with:

$ xboxdrv --chatpad

It is still rather rough, no configurability, all the umlauts and special characters won't work (modifier keys are currently mapped to alt, meta, ctrl) and starting and stopping xboxdrv multiple times might crash your gamepad and require to unplug/replug it. That aside, basic typing works.

Originally Posted by supporer

1. NO ONE HERE DOES KNOW HOW HE FOUND OUT THE INITIALIZATION SEQUENCE.

The init sequence was already in the USB logs I posted a long long while ago. The only thing that prevented us from figuring out the chatpad back then most my own incompetence of not really knowing what to do with those control request and then of course getting sidetracked by having part of the chatpad working without the init sequence, thus assuming it wouldn't be needed and the problem would be elsewhere.

Originally Posted by Grumbel

Just tested the chatpad init routine on Linux and hell yeah, that stuff works = Such a relieve to see that chatpad come fully alive after all that time. The "0x09 0x00" however did not work for me (no chatpad init, controller dies after a few rounds of 1F, 1E), the "0x01 0x02" was the one that did the trick, data send/received from the last three calls looked like this:

recv: 01 00
send: 01 02
recv: 01 02

If the chatpad is already running:

recv: 01 02
send: 01 02
recv: 01 02

My Xbox360 controller is from Nov 2005, my chatpad from Jun 2008.

A little further testing seems to indicate that the first byte doesn't matter, whatever I send I receive back. While the second byte indicates if the chatpad is on or off. Sending 0 as second byte switches it off, sending 2 switches it on. Only the second bit in the second byte seems to matter. Sending 3, 6 or 42 will also work just fine.

About different Xbox360 controller: Both PC versions and Xbox360 versions of the controller should be identical, except for the package. I can however confirm that there are different kinds of Xbox360 in the wild, some have endpoints 1(IN) and 2(OUT) while others have 1(IN) and 1(OUT). The bcdDevice number also seems different. I however don't really know the exact details, why they differ or when or how to properly distinguish them in a robust way.

It's interesting that the 0x01 0x02 sequence works for you since we had that data from old USB captures way back...it definitely does NOT work for me. I can use various byte pairs (0x00 0x00, 0x01 0x00, 0x02 0x00, 0x03 0x00) and all of them result in the controller sending me back the same pair of bytes, as if some "mode change" worked, but as far as I know (I need to test, I could be wrong here) only 0x09 0x00 allows me to actually start receiving chatpad data. To further illustrate the difference, I would almost bet that if you plugged your controller into a Mac and used the Mac driver that had chatpad support, it would work, even though some people did not have success with it (probably because they needed the 0x09 0x00 data pair).

Originally Posted by Chatcat

Hi Blizzard,

Tried reinstalling the driver with no luck,

This is what is happening with the chatpad

when pressing the people button the mouse side of things works perfect

when pressing single keys on the chatpad 1 to 9 or A to Z nothing types but the chatpad lights up with every press of key.

BUT when I press the green squere or the orange circle button only once and then press a key on the chatpad 1 to 9 or A to Z the command prompt window prompts

No action binding found for 0x16 + 0x2. (Numbers change with diffrent keys)

Not all keys prompt a message some don't prompt anything at all even when trying a key press with both square and circle buttons tried.

Eg. If you press square then F it wont prompt anything BUT if you press circle then F it will prompt this (No action binding found for 0x18 + 0x4.)


My device manager now has 2 XBox 360 Controller HID Keyboard for chatpad (becouse of reinstall)

and 1 XBox 360 Controller HID Mouse for chatpad in it.

So good news, everything is working properly except for the virtual keyboard (and it probably won't work if it's showing up twice). What I need you to do now is to follow the instructions in the post I linked earlier to remove all the keyboard and mouse devices that are related to the chatpad. Note that in the picture there will be some in HID devices, some in Keyboards, and some in Mouse and pointing devices. Once all of those are gone, THEN run the install one more time, and you should only have one of each device show up in the device manager.

Finally, try running the control utility again, and see if the keyboard and mouse work any better. Sorry about the control hassle...I'm posting this message from over 10,000 feet in the air at the moment but if I have time this weekend I should really focus on getting the install fixed so people don't have these duplicate device problems. I know I still have a bunch of other bugs to chase though. I still haven't heard back from either of the people with the chatpad_config.txt file loading error, to see if the new test version fixed it.

Originally Posted by Persnoody

I turned the key stroke/repeat settings down, it seems to have helped but not fixed, it might register stroke on release (rarely), so turning down the systems repeat delay will improve your chances at not getting a duplicate key stroke but it may still happen.

Thanks for helping test again! Does the problem still only happen after you use the chatpad for an extended period of time (like playing a game for an hour or something), or does it happen even right after you plug in the controller? Also, are you saying that sometimes a keypress happens when you LET GO of a chatpad button?