Re: [PATCH 1/3] properly report a single frame rate of 60 FPS
Fixed, sorry for the noise. One more question: Martin and I would also
like to see these patches in the 4.4 longterm kernel; do we have to
submit them separately, or will Greg KH pick them up eventually?
Thanks & best regards, Florian
On 13.05.2016 11:53, Hans Verkuil wrote:
> On 05/13/2016 08:41 PM, Florian Echtler wrote:
>> The device hardware is always running at 60 FPS, so report this both via
>> PARM_IOCTL and ENUM_FRAMEINTERVALS.
>
> Florian, can you post these three patches to linux-media as well? These are
> all V4L2 related
> so they should be reviewed there.
>
> By posting to linux-media these pathes will automatically turn up in
> patchwork, that way
> they won't be forgotten.
>
> Regards,
>
> Hans
>
>>
>> Signed-off-by: Martin Kaltenbrunner
>> Signed-off-by: Florian Echtler
>> ---
>> drivers/input/touchscreen/sur40.c | 17 +++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/sur40.c
>> b/drivers/input/touchscreen/sur40.c
>> index 880c40b..fcc5934 100644
>> --- a/drivers/input/touchscreen/sur40.c
>> +++ b/drivers/input/touchscreen/sur40.c
>> @@ -788,6 +788,16 @@ static int sur40_vidioc_fmt(struct file *file, void
>> *priv,
>> return 0;
>> }
>>
>> +static int sur40_ioctl_parm(struct file *file, void *priv,
>> +struct v4l2_streamparm *p)
>> +{
>> +if (p->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
>> +p->parm.capture.timeperframe.numerator = 1;
>> +p->parm.capture.timeperframe.denominator = 60;
>> +}
>> +return 0;
>> +}
>> +
>> static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
>> struct v4l2_fmtdesc *f)
>> {
>> @@ -814,13 +824,13 @@ static int sur40_vidioc_enum_framesizes(struct file
>> *file, void *priv,
>> static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
>> struct v4l2_frmivalenum *f)
>> {
>> -if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
>> +if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_GREY)
>> || (f->width != sur40_video_format.width)
>> || (f->height != sur40_video_format.height))
>> return -EINVAL;
>>
>> f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
>> -f->discrete.denominator = 60/(f->index+1);
>> +f->discrete.denominator = 60;
>> f->discrete.numerator = 1;
>> return 0;
>> }
>> @@ -880,6 +890,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops
>> = {
>> .vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
>> .vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
>>
>> +.vidioc_g_parm = sur40_ioctl_parm,
>> +.vidioc_s_parm = sur40_ioctl_parm,
>> +
>> .vidioc_enum_input = sur40_vidioc_enum_input,
>> .vidioc_g_input = sur40_vidioc_g_input,
>> .vidioc_s_input = sur40_vidioc_s_input,
>>
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
[PATCH 1/3] properly report a single frame rate of 60 FPS
The device hardware is always running at 60 FPS, so report this both via
PARM_IOCTL and ENUM_FRAMEINTERVALS.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 880c40b..fcc5934 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -788,6 +788,16 @@ static int sur40_vidioc_fmt(struct file *file, void *priv,
return 0;
}
+static int sur40_ioctl_parm(struct file *file, void *priv,
+ struct v4l2_streamparm *p)
+{
+ if (p->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ p->parm.capture.timeperframe.numerator = 1;
+ p->parm.capture.timeperframe.denominator = 60;
+ }
+ return 0;
+}
+
static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
@@ -814,13 +824,13 @@ static int sur40_vidioc_enum_framesizes(struct file
*file, void *priv,
static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
struct v4l2_frmivalenum *f)
{
- if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+ if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_GREY)
|| (f->width != sur40_video_format.width)
|| (f->height != sur40_video_format.height))
return -EINVAL;
f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
- f->discrete.denominator = 60/(f->index+1);
+ f->discrete.denominator = 60;
f->discrete.numerator = 1;
return 0;
}
@@ -880,6 +890,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
.vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
+ .vidioc_g_parm = sur40_ioctl_parm,
+ .vidioc_s_parm = sur40_ioctl_parm,
+
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] lower poll interval to fix occasional FPS drops to ~56 FPS
The framerate sometimes drops below 60 Hz if the poll interval is too high.
Lowering it to the minimum of 1 ms fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index fcc5934..7b1052a1 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -126,7 +126,7 @@ struct sur40_image_header {
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
-#define POLL_INTERVAL 4
+#define POLL_INTERVAL 1
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] fix occasional oopses on device close
Closing the V4L2 device sometimes triggers a kernel oops.
Present patch fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 7b1052a1..38ebb24 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -448,7 +448,7 @@ static void sur40_process_video(struct sur40_state *sur40)
/* return error if streaming was stopped in the meantime */
if (sur40->sequence == -1)
- goto err_poll;
+ return;
/* mark as finished */
new_buf->vb.vb2_buf.timestamp = ktime_get_ns();
@@ -736,6 +736,7 @@ static int sur40_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ vb2_wait_for_all_buffers(vq);
sur40->sequence = -1;
/* Release all active buffers */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sur40] Videobuf2 and/or DMA?
On 15.12.2014 04:24, Alan Stern wrote: > On Fri, 12 Dec 2014, Florian Echtler wrote: >> thanks - good to know for sure. AFAICT if I want to transfer bulk >> messages using DMA, I can't just use kalloc and usb_bulk_msg, but need >> usb_alloc_coherent, usb_fill_bulk_urb and usb_submit_urb, correct? > That's not right. kmalloc and usb_bulk_msg will make use of DMA if the > host controller driver supports it. In fact, they don't get any choice > in the matter; the host controller driver is what makes the decision > about whether to use DMA. Oh, OK, thanks for clearing that up. > Are you maybe using the wrong words? For instance, are you confusing > "DMA" with "consistent" (or "coherent") mappings? That's entirely possible :-) Although I did read the DMA-API-HOWTO, it may very well be that I'm confusing things due to lack of experience. To put my original question differently: I want to make sure no unnecessary memory copies of the image data are done by the driver. From my understanding, this involves using DMA to fill the buffer with data and one of the videobuf2 mechanisms to get suitable buffers which are accessible from user space. >> Also, can you suggest any documentation regarding the relation between >> videobuf2 and DMA? > Not me. Other people like Laurent Pinchart have worked on video over > USB. OK, I will talk to him directly. Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [sur40] Videobuf2 and/or DMA?
Hello Alan, On 11.12.2014 20:36, Alan Stern wrote: > On Sun, 7 Dec 2014, Florian Echtler wrote: >> - Can I always use DMA on the USB side (for bulk transfers), or does >> this in any way require support from the USB device's hardware? (I'm >> guessing no, but a definite answer would be great.) > DMA requires hardware support in the USB host controller, not in the > USB device. Most current USB host controllers support DMA; only a few > of the oldest ones don't. thanks - good to know for sure. AFAICT if I want to transfer bulk messages using DMA, I can't just use kalloc and usb_bulk_msg, but need usb_alloc_coherent, usb_fill_bulk_urb and usb_submit_urb, correct? Also, can you suggest any documentation regarding the relation between videobuf2 and DMA? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[sur40] Videobuf2 and/or DMA?
Hello everyone, I'm preparing to finally add support for the raw sensor video stream to my driver for the SUR40 touchscreen. However, after an extensive amount of Googling, I'm still not clear on the relationship between DMA transfers, the USB core and the videobuf2 framework. Specifically, I'd like to know: - Can I always use DMA on the USB side (for bulk transfers), or does this in any way require support from the USB device's hardware? (I'm guessing no, but a definite answer would be great.) - Regardless of the USB side of things, can I use the videobuf2 framework without _having_ to use DMA? That way, I could get a basic driver running without DMA and switch later when it's convenient and/or the speedup is justified. Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: Debugging XHCI hardware issues?
Hello Paul, On 19.12.2013 00:40, Paul Zimmerman wrote: >> The exact same code works when the device is attached to the NEC >> controller (transferring 33792 bytes per ISO packet as requested), but >> fails on the Intel controller (transferring only 11264 bytes, exactly >> 1/3 of the requested size). > What are the values from the ISO endpoint's Endpoint descriptor and > SuperSpeed Endpoint Companion descriptor? Here's the relevant lsusb output: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 10 Mult2 > If the Mult value is 2 (bits 1:0 of the Companion descriptor's bmAttributes > field) and the Intel controller is treating it as 0 for some reason, that > would give you 1/3 of the requested size. > Or perhaps it is a throughput issue; if the bInterval is 1, then 33792 > bytes every 128us is a pretty high data rate. Perhaps the Intel controller > can't keep up. Both assumptions are true for this descriptor. I've also found that when plugging the Kinect into the NEC controller (which works), there's an additional message in the kernel log: Dec 18 09:28:02 flunder kernel: [23267.972204] usb 6-1: Parent hub missing LPM exit latency info. Power management will be impacted. This message doesn't appear with the Intel controller. I'm not sure if this is somehow related to the device caps - lsusb shows: Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 22 bNumDeviceCaps 2 SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x00 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000c Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat2047 micro seconds USB 2.0 Extension Device Capability: bLength 7 bDescriptorType16 bDevCapabilityType 2 bmAttributes 0x0002 Link Power Management (LPM) Supported Device Status: 0x0001 Self Powered > Do you have USB debugging enabled (CONFIG_USB_DEBUG=y) in the kernel > config? With the latest kernels that should cause the xHCI driver to print > debug messages to the dmesg log. In earlier kernels you also have to enable > CONFIG_USB_XHCI_HCD_DEBUGGING. No, it's a stock Ubuntu kernel ATM. Thanks for the hint, I'll rebuild a custom one with those flags enabled. > Do you have a USB bus analyzer? That should show you exactly what is going > on. If not, maybe you can capture a usbmon trace. I don't know anything > about usbmon, but Alan Stern might be able to help with that. I don't have access to a hardware bus analyzer. Would usbmon help in that case? I thought usbmon logs the submitted URBs, but not necessarily what the host controller actually sends out? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Debugging XHCI hardware issues?
Hello again, we've made some progress getting large SuperSpeed ISO transfers for the new Kinect to work. As it turns out, the central issue here was which XHCI controller the device is connected to. I have two different HCs, one from Intel and one from NEC. According to lspci, these are: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)) 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) The exact same code works when the device is attached to the NEC controller (transferring 33792 bytes per ISO packet as requested), but fails on the Intel controller (transferring only 11264 bytes, exactly 1/3 of the requested size). I don't have enough background knowledge to decide if this is some sort of hardware issue, missing hardware feature or rather related to the XHCI driver. Can somebody suggest a direction for further investigation? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
SuperSpeed ISO transfer returning EINVAL?
Hello everyone, I'm experimenting with the Kinect v2 on Linux (using libusbx-1.0.17). I've noticed that when trying to replicate the ISO transfers observed on Windows (8 packets of 0x8400 bytes each), I'm getting back -EINVAL from the usbfs IOCTL. For background info, I'm attaching a Wireshark dissection of the packet in question (as observed on Windows) and the lsusb -v output for the Kinect v2 itself. When I use a lower packet size, e.g. 0x4000, everything seems to work (although some data is obviously missing due to the reduced transfer size). A packet size of 0x6000 still seems to work spuriously, although I'm now getting a lot of -ENOMEM errors. This happens on 3.8 as well as on 3.11 (Ubuntu LTS kernels). usbfs_snoop doesn't help much here; I'm just seeing the USBDEVFS_SUBMITURB IOCTL being acknowledged in my syslog. Does somebody have any suggestions as to what the EINVAL actually means here, and how to fix this? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL Bus 004 Device 005: ID 045e:02c4 Microsoft Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 9 idVendor 0x045e Microsoft Corp. idProduct 0x02c4 bcdDevice1.00 iManufacturer 1 Microsoft iProduct2 Xbox NUI Sensor iSerial 4 016592534347 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 214 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 36mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 19 Transfer TypeInterrupt Synch Type None Usage Type Feedback wMaxPacketSize 0x0040 1x 64 bytes bInterval 14 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84
Re: Trying to develop a Pixelsense kernel driver
On 22.08.2013 17:22, Florian Echtler wrote: > On 22.08.2013 16:49, Alan Stern wrote: >> On Thu, 22 Aug 2013, Florian Echtler wrote: >>> Userspace version: >>> // for control commands >>> usb_control_msg(handle, 0xC0, cmd, 0x00, index, (char*)buf, len, 1000); >>> Kernel version: >>> // for control commands >>> #define surface_command(dev, command, index, buffer, size) >>> usb_control_msg (dev->usbdev, usb_rcvctrlpipe (dev->usbdev, 0), >>> command, USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_IN, 0x00, >>> index, buffer, size, 1000) >> This isn't equivalent to the userspace version. Here the recipient is >> USB_RECIP_ENDPOINT, but in the userspace version it is >> USB_RECIP_DEVICE. To put it another way, here the bRequestType value >> is 0xC2 and there it is 0xC0. > Great, thanks for spotting this. I thought I had correctly interpreted > the original value with respect to the kernel constants - apparently not. > Once I work up the nerve to give it another try with the updated driver, > I'll report back. As promised, I did fix this in the prototype driver and for the first time, it didn't behave eratically or trash the firmware EEPROM. So I think I'm finally back on track for a working, non-dangerous input driver which I should presumably submit to linux-in...@vger.kernel.org when done? Thanks again for your help, Alan! Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: Trying to develop a Pixelsense kernel driver
Hello Alan, thanks for the quick response. On 22.08.2013 16:49, Alan Stern wrote: > On Thu, 22 Aug 2013, Florian Echtler wrote: >> So even though userspace and kernel driver look like they perform >> exactly the same operations on the device, there must be some difference >> I don't understand - perhaps libusb does some kind of internal error >> handling which the kernel doesn't do? >> >> Userspace version: >> >> // for control commands >> usb_control_msg(handle, 0xC0, cmd, 0x00, index, (char*)buf, len, 1000); >> >> Kernel version: >> >> // for control commands >> #define surface_command(dev, command, index, buffer, size) >> usb_control_msg (dev->usbdev, usb_rcvctrlpipe (dev->usbdev, 0), >> command, USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_IN, 0x00, >> index, buffer, size, 1000) > > This isn't equivalent to the userspace version. Here the recipient is > USB_RECIP_ENDPOINT, but in the userspace version it is > USB_RECIP_DEVICE. To put it another way, here the bRequestType value > is 0xC2 and there it is 0xC0. Great, thanks for spotting this. I thought I had correctly interpreted the original value with respect to the kernel constants - apparently not. >> // for bulk data transfer >> result = usb_bulk_msg (surface->usbdev, >> usb_rcvbulkpipe (surface->usbdev, 0x86), >> surface->bulk_in_buffer, 512, &bulk_read, 1000); > > This is equivalent to the version above. OK. >> Can anybody venture a guess what kind of functional difference there is >> between these code snippets? > > It's hard to say exactly. Probably one of the control messages will > work and the other one won't. The (wrong?) control messages in the kernel still work (in the sense that they don't trigger any detectable errors during the init sequence). However, as mentioned above, after a few loads and unloads of the kernel driver, the firmware EEPROM is trashed. (Which leads to some speculation about the quality of said firmware, regardless of my poor driver writing skills.) Once I work up the nerve to give it another try with the updated driver, I'll report back. Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Trying to develop a Pixelsense kernel driver
Hello everyone, I recently wanted to pick up again on developing a kernel input driver for the Microsoft Pixelsense (formerly Surface 2.0). I already have a working user space driver (see also [1]). However - just like last year [2] - I quickly ran into an issue with a corrupted device firmware after some brief experimentation with the kernel driver, while the user space driver didn't and doesn't show any such issues. This happened on two separate Pixelsense devices, with different kernel versions. So even though userspace and kernel driver look like they perform exactly the same operations on the device, there must be some difference I don't understand - perhaps libusb does some kind of internal error handling which the kernel doesn't do? Userspace version: // for control commands usb_control_msg(handle, 0xC0, cmd, 0x00, index, (char*)buf, len, 1000); // for bulk data transfer uint8_t buffer[512]; result = usb_bulk_read( handle, 0x86, (char*)(buffer), sizeof(buffer), 1000 ); Kernel version: // for control commands #define surface_command(dev, command, index, buffer, size) usb_control_msg (dev->usbdev, usb_rcvctrlpipe (dev->usbdev, 0), command, USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_IN, 0x00, index, buffer, size, 1000) // for bulk data transfer result = usb_bulk_msg (surface->usbdev, usb_rcvbulkpipe (surface->usbdev, 0x86), surface->bulk_in_buffer, 512, &bulk_read, 1000); Can anybody venture a guess what kind of functional difference there is between these code snippets? Thanks & BR, Florian [1] https://github.com/floe/surface-2.0/ [2] http://floe.butterbrot.org/matrix/hacking/surface/brick.html -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
USB3 vs. Kinect
Hello everyone, I'm seeing some slightly weird behavior when connecting a Kinect (USB 2 device with internal hub) to my Dell Latitude E6430 (running stock Ubuntu kernel 3.2.0-34-generic). There are two different cases: - When I plug the Kinect into an USB2 port on the docking station, I get the following dmesg output: [201144.969188] usb 3-4.3: new high-speed USB device number 60 using xhci_hcd [201144.985800] hub 3-4.3:1.0: USB hub found [201144.985873] hub 3-4.3:1.0: 3 ports detected [201145.751418] usb 3-4.3.2: new full-speed USB device number 61 using xhci_hcd [201154.691061] usb 3-4.3.1: new high-speed USB device number 62 using xhci_hcd [201154.711867] xhci_hcd :00:14.0: Not enough bandwidth. Proposed: 1774, Max: 1607 [201154.711876] xhci_hcd :00:14.0: Not enough bandwidth [201154.711889] usb 3-4.3.1: can't set config #1, error -12 [201156.223637] usb 3-4.3.3: new high-speed USB device number 63 using xhci_hcd [201156.243596] xhci_hcd :00:14.0: Not enough bandwidth. Proposed: 2663, Max: 1607 [201156.243603] xhci_hcd :00:14.0: Not enough bandwidth [201156.243616] usb 3-4.3.3: can't set config #1, error -12 - When I plug the Kinect into an USB3 port directly on the laptop, I get the following dmesg output: [202217.163493] usb 3-1: new high-speed USB device number 76 using xhci_hcd [202217.180254] hub 3-1:1.0: USB hub found [202217.180326] hub 3-1:1.0: 3 ports detected [202217.997613] usb 3-1.2: new full-speed USB device number 77 using xhci_hcd [202219.530207] usb 3-1.1: new high-speed USB device number 78 using xhci_hcd [202221.062705] usb 3-1.3: new high-speed USB device number 79 using xhci_hcd So apparently xhci_hcd is not happy with the internal hub over USB 2.0 - does anybody have an idea what might cause this? Thanks! Florian -- SENT FROM MY DEC VT50 TERMINAL -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
