C/C linux-usb Mailing list: Em Wed, 18 May 2016 08:52:28 -0600 Wade Berrier <wberrier@xxxxxxxxx> escreveu: > On May 14 20:29, Wade Berrier wrote: > > On Wed Apr 27 21:07, Sean Young wrote: > > > On Mon, Apr 25, 2016 at 09:16:51PM -0600, Wade Berrier wrote: > > > > On Apr 25 18:15, Sean Young wrote: > > > > > On Sun, Apr 24, 2016 at 10:06:33PM -0600, Wade Berrier wrote: > > > > > > Hello, > > > > > > > > > > > > I have a mceusb compatible transceiver that only seems to work with > > > > > > certain computers. I'm testing this on centos7 (3.10.0) and fedora23 > > > > > > (4.4.7). > > > > > > > > > > > > The only difference I can see is that the working computer shows > > > > > > "using uhci_hcd" and the non working shows "using xhci_hcd". > > > > > > > > > > > > Here's the dmesg output of the non-working version: > > > > > > > > > > > > --------------------- > > > > > > > > > > > > [ 217.951079] usb 1-5: new full-speed USB device number 10 using xhci_hcd > > > > > > [ 218.104087] usb 1-5: device descriptor read/64, error -71 > > > > > > [ 218.371010] usb 1-5: config 1 interface 0 altsetting 0 endpoint 0x1 has an invalid bInterval 0, changing to 32 > > > > > > [ 218.371019] usb 1-5: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 32 > > > > > > > > > > That's odd. Can you post a "lsusb -vvv" of the device please? > > > > > > > > > > > > > Sure. > > > > > > > > ------------------- > > > > > > > > Bus 002 Device 009: ID 1784:0006 TopSeed Technology Corp. eHome Infrared Transceiver > > > > Device Descriptor: > > > > bLength 18 > > > > bDescriptorType 1 > > > > bcdUSB 2.00 > > > > bDeviceClass 0 > > > > bDeviceSubClass 0 > > > > bDeviceProtocol 0 > > > > bMaxPacketSize0 8 > > > > idVendor 0x1784 TopSeed Technology Corp. > > > > idProduct 0x0006 eHome Infrared Transceiver > > > > bcdDevice 1.02 > > > > iManufacturer 1 TopSeed Technology Corp. > > > > iProduct 2 eHome Infrared Transceiver > > > > iSerial 3 TS004RrP > > > > bNumConfigurations 1 > > > > Configuration Descriptor: > > > > bLength 9 > > > > bDescriptorType 2 > > > > wTotalLength 32 > > > > bNumInterfaces 1 > > > > bConfigurationValue 1 > > > > iConfiguration 0 > > > > bmAttributes 0xa0 > > > > (Bus Powered) > > > > Remote Wakeup > > > > MaxPower 100mA > > > > Interface Descriptor: > > > > bLength 9 > > > > bDescriptorType 4 > > > > bInterfaceNumber 0 > > > > bAlternateSetting 0 > > > > bNumEndpoints 2 > > > > bInterfaceClass 255 Vendor Specific Class > > > > bInterfaceSubClass 255 Vendor Specific Subclass > > > > bInterfaceProtocol 255 Vendor Specific Protocol > > > > iInterface 0 > > > > Endpoint Descriptor: > > > > bLength 7 > > > > bDescriptorType 5 > > > > bEndpointAddress 0x01 EP 1 OUT > > > > bmAttributes 3 > > > > Transfer Type Interrupt > > > > Synch Type None > > > > Usage Type Data > > > > wMaxPacketSize 0x0020 1x 32 bytes > > > > bInterval 0 > > > > > > That's wrong indeed. It might be interesting to see if there is anything > > > in the xhci debug messages with (in Fedora 23): > > > > > > echo "file xhci*.c +p" > /sys/kernel/debug/dynamic_debug/control > > > echo "file mceusb.c +p" > /sys/kernel/debug/dynamic_debug/control > > > > > > And then plug in the receiver, and try to send IR to it with a remote. > > > You should have quite a few kernel messages in the journal. > > > > Here's the output after enabling the debug options, plugging in the > > receiver, running lircd, and pressing some remote buttons: > > > > [snip] > > > > > I'm not sure what to look for... ? > > > > > > > > > Endpoint Descriptor: > > > > bLength 7 > > > > bDescriptorType 5 > > > > bEndpointAddress 0x81 EP 1 IN > > > > bmAttributes 3 > > > > Transfer Type Interrupt > > > > Synch Type None > > > > Usage Type Data > > > > wMaxPacketSize 0x0020 1x 32 bytes > > > > bInterval 0 > > > > Device Status: 0x0001 > > > > Self Powered > > > > > > > > ------------------- > > > > > > > > Also, here's a link to a response on the lirc list: > > > > > > > > https://sourceforge.net/p/lirc/mailman/message/35039126/ > > > > > > That seems suggest that mode2 works but lirc does not. It would be nice > > > if that could be narrowed down a bit. > > > > That message above links to some other threads describing the issue. > > Here's a post with a patch that supposedly works: > > > > http://www.gossamer-threads.com/lists/mythtv/users/587930 > > > > No idea if that's the "correct" way to fix this. > > > > I'll be trying that out and then report back... > > Indeed, this patch does fix the issue: > > ---------------------- > > diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c > index 31ccdcc..03321d4 100644 > --- a/drivers/usb/core/config.c > +++ b/drivers/usb/core/config.c > @@ -247,7 +247,7 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum, > /* For low-speed, 10 ms is the official minimum. > * But some "overclocked" devices might want faster > * polling so we'll allow it. */ > - n = 32; > + n = 10; > break; > } > } else if (usb_endpoint_xfer_isoc(d)) { > > > ---------------------- > > Is this change appropriate to be pushed upstream? Where to go from > here? This issue is at the USB core. So, it should be reported to the linux-usb mailing list. The people there should help about how to proceed to get this fixed upstream. Regards, Mauro Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
