Re: [Usbirboy-devel] Xbox remote compatibility.

[Vassilis V. <va...@ii...>]

Aapo Tamminen wrote:
> Vassilis Virvilis wrote:
> 
>>
>> OK. I take it that I start from usbcore.c then. I will nag you again 
>> when I have the prommer ready. 
> 
As I promised...
I built the prommer and usb-ir boy itself. It works, xmode2 et all. 
Wow...! I am really amazed from this. Thank you for the design and your 
support. I used firmware-0.1 because I was scared from a report here in 
the list and I didn't want test against all odds (prommer, usb 
firmware). Now I will switch to 0.2.

As a side note would you consider changing the schematics to have a 
white background. It's more toner friendly this way, but I assume that 
anybody who wants to print this thing knows how to invert an image.

Furthermore I noticed some typos in the kernel module so please find a 
patch attached.

> The very first thing would be to find out what USB endpoints the xbox 
> remote receiver has. The MC68HC908 has the following:
> endpoint 0    interrupt type, control endpoint (all devices have this)
> endpoint 1    interrupt type, in
> endpoint 2    interrupt type, in/out
> Each endpoint is either interrupt, bulk or isochronous type. Also it is 
> either in (device to pc) or out (pc to device) or both. The IR-Boy uses 
> endpoint 1 to send its data. So the xbox remote must have something 
> similar in order for the MC68HC908 to mimic it.

I am new to usb stuff but it seems that xbox remote usb dongle is 
interrupt driven. I didn't found anything like bulk or isochronous 
transfers. I will seek into it the coming weeks.

I found some drivers and a discussion. It seems that there are two 
solutions:
a) LIRC 0.6.6 - uses the module usb-xboxir.o to handle the usb part and
xir.o to handle the LIRC part
b) LIRC -0.7 - somebody saw that xbox remote LIRC driver has great 
similarities with ATIusb driver and incorporated both in a single 
driver. I wasn't able to locate this driver however.

> Assuming this turns out ok, then one must find out what format the xbox 
> remote uses for the data and then encode the raw IR data in that format. 
> Currently we have it easy in IR-Boy since we just measure the raw pulse 
> lengths and send them to LIRC to decode.

I found the following comment in the usb-xboxir.c
-------------
/*  USB callback completion handler
  *  Code in transfer_buffer is received as six unsigned chars
  *  Example PLAY=00 06 ea 0a 40 00
  *  The command is located in byte[2], the rest are ignored.
  *  Key position is byte[4] bit0 (7-0 format) 0=down, 1=up
  *  All other bits are unknown / now required.
  */
static void usb_xboxir_irq(struct urb *urb)
{...

I also have the table for the possible values of byte[2].
I think it is relevant. Am I completely missing the target here?

> If these two problems can be solved then it's only a matter of modifying 
> the descriptors in usbcore.c to match.

I am confident that it is possible especially if I don't hit computer 
size or memory side limitations in the MCU.

One last question. What exactly are we receiving from tsop1738 and what 
we transmit to PC? You mentioned pulses and spaces. Can you elaborate a 
little? Is it that each button has its emitting frequency? is it a time 
based thing? What are the spaces? What happens with buttons pressed 
down? xmode2 draw coniniously.


        .Bill