Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 07:24:48PM -0700, Lars Eggert wrote: Bernd, Bernd Walter wrote: What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? it says this: usbd_setup_pipe: dev=0xc3f9d980 iface=0xc3efbaa0 ep=0xc3f192c8 pipe=0xdb936974 ugenwrite: transfer 5 bytes usbd_intr_transfer: start transfer 5 bytes usbd_intr_transfer: transferred 0 usbd_intr_transfer: error=13 Can you please do this again with additionaly hw.usb.ohci.debug=10 set. error=13 makes me believe that this could be a OHCI driver problem. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd Walter wrote: Can you please do this again with additionaly hw.usb.ohci.debug=10 set. error=13 makes me believe that this could be a OHCI driver problem. Here you go: Sep 30 08:49:49 host192 kernel: usbd_setup_pipe: dev=0xc3f66c00 iface=0xc3ee5e80 ep=0xc3eee458 pipe=0xdd0a3974 Sep 30 08:49:49 host192 kernel: ohci_open: pipe=0xc4b89780, addr=5, endpt=2 (1) Sep 30 08:49:49 host192 kernel: ohci_setintr: pipe=0xc4b89780 Sep 30 08:49:49 host192 kernel: ohci_setintr: ival=10 npoll=8 Sep 30 08:49:49 host192 kernel: ohci_setintr: best=10(7..15) bestbw=0 Sep 30 08:49:49 host192 kernel: ohci_setintr: returns 0xc4b89780 Sep 30 08:49:49 host192 kernel: ohci_device_control type=0x02, request=0x01, wValue=0x, wIndex=0x0002 len=0, addr=5, endpt=0 Sep 30 08:49:49 host192 kernel: ohci_device_request: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e700) at 0x008e2700: addr=5 endpt=0 maxp=8 flags=82005LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1e40 headflags=8e1e40 headp=0x008e1e40 nexted=0x008e2720 Sep 30 08:49:49 host192 kernel: TD(0xc3f6de40) at 008e1e40: f2e0SETTOGGLE delay=7 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908e00 nexttd=0x008e1db0 be=0x00908e07 Sep 30 08:49:49 host192 kernel: TD(0xc3f6ddb0) at 008e1db0: f330IN,TOG1,SETTOGGLE delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x008e1e70 be=0x Sep 30 08:49:49 host192 kernel: TD(0xc3f6de70) at 008e1e70: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: ugenwrite: transfer 5 bytes Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: start transfer 5 bytes Sep 30 08:49:49 host192 kernel: ohci_device_intr_transfer: xfer=0xc56c4900 len=5 flags=0 priv=0 Sep 30 08:49:49 host192 kernel: ohci_device_intr_transfer: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e6c0) at 0x008e26c0: addr=5 endpt=2 maxp=8 flags=82105LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1f90 headflags=8e1f90 headp=0x008e1f90 nexted=0x008e2f00 Sep 30 08:49:49 host192 kernel: TD(0xc3f6df90) at 008e1f90: f030IN delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908d00 nexttd=0x008e1db0 be=0x00908d04 Sep 30 08:49:49 host192 kernel: TD(0xc3f6ddb0) at 008e1db0: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: transferred 0 Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: error=13 Sep 30 08:49:49 host192 kernel: ohci_device_control type=0x02, request=0x01, wValue=0x, wIndex=0x0002 len=0, addr=5, endpt=0 Sep 30 08:49:49 host192 kernel: ohci_device_request: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e700) at 0x008e2700: addr=5 endpt=0 maxp=8 flags=82005LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1e70 headflags=8e1e70 headp=0x008e1e70 nexted=0x008e2720 Sep 30 08:49:49 host192 kernel: TD(0xc3f6de70) at 008e1e70: f2e0SETTOGGLE delay=7 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908e00 nexttd=0x008e1f90 be=0x00908e07 Sep 30 08:49:49 host192 kernel: TD(0xc3f6df90) at 008e1f90: f330IN,TOG1,SETTOGGLE delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x008e1e40 be=0x Sep 30 08:49:49 host192 kernel: TD(0xc3f6de40) at 008e1e40: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: ohci_device_intr_close: pipe=0xc4b89780 nslots=4 pos=10 Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
Hi,
I'm trying to get the USB RF remote control that comes with some ATI
Wonder cards to do something meaningful under -current.
It shows up as an X10 Wireless Technology Inc USB Receiver with three
devices: /dev/ugen0, and the corresponding input (/dev/ugen0.1) and
output endpoints (/dev/ugen/0.2). Also see the attached usbctl output.
Simply reading from the input endpoint /dev/ugen0.1 doesn't work.
This page (http://remotew.free.fr/linux_en.htm) points at the Gatos
project, which has a Linux driver (ati_remote) that seems to make the
remote show up as a USB keyboard:
http://sourceforge.net/project/showfiles.php?group_id=12629
That driver sends a couple of magic bytes to the device during
initialization. I'm trying to do the same from userland:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
int main(int argc, char *argv[]) {
int out = open(/dev/ugen0.2, O_WRONLY);
if (out == -1) {
perror(ugen0.2);
goto done;
}
if (write(out, init1, sizeof init1) == -1) {
perror(write init1);
goto done;
}
if (write(out, init2, sizeof init2) == -1) {
perror(write init1);
goto done;
}
done:
close(out);
}
Really simply. Here's what happens when I run it:
write init1: Input/output error
it feels like I'm missing something extremely obvious, but I'm new to
the USB internals. The two endpoints are interrupt endpoints. I'm not
sure what that signifies, but I heard writing to them on -stable is
broken, but on -current it should work.
Any ideas?
Thanks,
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
DEVICE addr 2
DEVICE descriptor:
bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0
bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x0bc7 idProduct=0x0004 bcdDevice=100
iManufacturer=1(X10 Wireless Technology Inc) iProduct=2(USB Receiver)
iSerialNumber=0() bNumConfigurations=1
CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1
bConfigurationValue=1 iConfiguration=0() bmAttributes=80 bMaxPower=2 mA
INTERFACE descriptor 0:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=0
bInterfaceProtocol=0 iInterface=0()
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in
bmAttributes=interrupt wMaxPacketSize=8 bInterval=10
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out
bmAttributes=interrupt wMaxPacketSize=8 bInterval=10
current configuration 1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
Hi,
I'm trying to get the USB RF remote control that comes with some ATI
Wonder cards to do something meaningful under -current.
It shows up as an X10 Wireless Technology Inc USB Receiver with three
devices: /dev/ugen0, and the corresponding input (/dev/ugen0.1) and
output endpoints (/dev/ugen/0.2). Also see the attached usbctl output.
Simply reading from the input endpoint /dev/ugen0.1 doesn't work.
This page (http://remotew.free.fr/linux_en.htm) points at the Gatos
project, which has a Linux driver (ati_remote) that seems to make the
remote show up as a USB keyboard:
http://sourceforge.net/project/showfiles.php?group_id=12629
That driver sends a couple of magic bytes to the device during
initialization. I'm trying to do the same from userland:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
int main(int argc, char *argv[]) {
int out = open(/dev/ugen0.2, O_WRONLY);
if (out == -1) {
perror(ugen0.2);
goto done;
}
if (write(out, init1, sizeof init1) == -1) {
perror(write init1);
goto done;
}
if (write(out, init2, sizeof init2) == -1) {
perror(write init1);
goto done;
}
done:
close(out);
}
Really simply. Here's what happens when I run it:
write init1: Input/output error
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
it feels like I'm missing something extremely obvious, but I'm new to
the USB internals. The two endpoints are interrupt endpoints. I'm not
sure what that signifies, but I heard writing to them on -stable is
broken, but on -current it should work.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd,
Bernd Walter wrote:
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
Relatively. It's in the Linux driver, and I've used a Windows USB
snooper to verify that ATI's Windows driver writes the same two chunks.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
I'm away from that machine until later, I'll make sure to send the
output when I get back.
The Linux driver is actually pretty short. Here's the source:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/ati_remote/ati_remote.c?annotate=1.9
The init packets get written at line 440.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
Ah. Yes, this is with ehci coupled to ohci. Should I try to disable ehci
for now?
Thanks,
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 03:32:28PM -0700, Lars Eggert wrote:
Bernd,
Bernd Walter wrote:
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
Relatively. It's in the Linux driver, and I've used a Windows USB
snooper to verify that ATI's Windows driver writes the same two chunks.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
I'm away from that machine until later, I'll make sure to send the
output when I get back.
The Linux driver is actually pretty short. Here's the source:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/ati_remote/ati_remote.c?annotate=1.9
The init packets get written at line 440.
Mmm - looks you are right, but your init data seems to be different.
0x8001 vs 0x8003 and 0x8007.
Interesting is the calculation of transfer_buffer_length in
send_packet(), which would result in 4 for init1 and 8 for init2.
I interpret this that the last byte from init1 doesn't get written
and your packets don't fit into that sheme.
The source looks very confusing to me, but maybe that because of my
current localtime()...
The Windows log could help as it's at least readable and familar.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
Ah. Yes, this is with ehci coupled to ohci. Should I try to disable ehci
for now?
Unless it's a high speed device ohci takes care for it anyway,
but I doubt that a remote control device is high speed.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
On Sun, 21 Sep 2003, Lars Eggert wrote: I'm trying to get the USB RF remote control that comes with some ATI Wonder cards to do something meaningful under -current. Can I recommend the use of libusb for the abstracting of the USB layer? It would allow your driver/interface to work on all FreeBSD, Linux and Solaris. I've found the graphics/s10sh port to be really useful as an example of libusb's usage... Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd, Bernd Walter wrote: What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? it says this: usbd_setup_pipe: dev=0xc3f9d980 iface=0xc3efbaa0 ep=0xc3f192c8 pipe=0xdb936974 ugenwrite: transfer 5 bytes usbd_intr_transfer: start transfer 5 bytes usbd_intr_transfer: transferred 0 usbd_intr_transfer: error=13 (This is with ehci disabled.) Mmm - looks you are right, but your init data seems to be different. 0x8001 vs 0x8003 and 0x8007. I think the only difference is that I prepended the 0x80 directly, which the Linux driver fudges in front in send_packet. Interesting is the calculation of transfer_buffer_length in send_packet(), which would result in 4 for init1 and 8 for init2. I interpret this that the last byte from init1 doesn't get written and your packets don't fit into that sheme. I think they do, see the Windows dump. The source looks very confusing to me, but maybe that because of my current localtime()... No, it's not :-) After I reading that driver, I know why I like the BSD sources. The Windows log could help as it's at least readable and familar. It's attached, in whatever format snoopy (http://sourceforge.net/projects/usbsnoop/) saves it. It shows two writes with this data: TransferBuffer: 0x0005 (5) length : 80 01 00 20 14 TransferBuffer: 0x0008 (8) length : 80 01 00 20 14 20 20 20 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute USBLog1.usblog Description: Binary data smime.p7s Description: S/MIME Cryptographic Signature
