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
The device hardware is always running at 60 FPS, so report this both via
PARM_IOCTL and ENUM_FRAMEINTERVALS.
Signed-off-by: Martin Kaltenbrunner <mo...@yuri.at>
Signed-off-by: Florian Echtler <f...@butterbrot.org>
---
drivers/input/touchscreen/sur40.c | 17 +++--
1 file
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 <mo...@yuri.at>
Signed-off-by: Florian Echtler <f...@butterbrot.org>
---
drivers/input/touchscreen/sur40.c | 2 +-
1 fil
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
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
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
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).
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
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
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
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
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
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
13 matches
Mail list logo
