> > > HIDIOCGSTRING - struct hiddev_string_descriptor (read/write) Gets a
> > > string descriptor from the device. The caller must fill in the "index"
> > > field to indicate which descriptor should be returned.
> > Can you please tell me in what range this index is?
>
> Please refer to USB spec
On Fri, 10 Aug 2007, Folkert van Heusden wrote:
> > HIDIOCGSTRING - struct hiddev_string_descriptor (read/write) Gets a
> > string descriptor from the device. The caller must fill in the "index"
> > field to indicate which descriptor should be returned.
> Can you please tell me in what range thi
> Hey,,thank you for the help. But what you told me I already knew. My
> question now is, how can I give a byte like 0xb1 to the device? Have I to
> split it up,or have I to adapt the hiddev.h?
You can't modify hiddev.h.
uref.value = (unsigned char)*report++;
should do the job.
Laurent Pinchart
Am Donnerstag, 3. November 2005 15:27 schrieben Sie:
> > The second value is on ffb1 and not on b1, that must be because value
> > is defined as __s32, or not? How can I modify this in linux, because I
> > think it is not enough to adapt the hiddev.h and set "_u32 value" in the
> > hiddev_usage
> The second value is on ffb1 and not on b1, that must be because value
> is defined as __s32, or not? How can I modify this in linux, because I
> think it is not enough to adapt the hiddev.h and set "_u32 value" in the
> hiddev_usage_ref
> int knx_send( const char report[5], int fd )
> {
Jeff Lange wrote:
Johannes, the device is fully HID
compliant, it is just a vendor defined usage. The reason for this was
to make Windows driver a lot easier to write. I think I'm just going
to have to write my own kernel driver for this thing and create a char
dev that my app can read the dat
Ken,
I too am writing a USB MSR =). Johannes, the device is fully HID
compliant, it is just a vendor defined usage. The reason for this was
to make Windows driver a lot easier to write. I think I'm just going
to have to write my own kernel driver for this thing and create a char
dev that my a
Jeff Lange wrote:
Hi all,
I'm developing a simple USB device that reports itself as a HID
device, and uses interrupt transfers to send about 250 bytes of data
whenever an event occurs on the device. I've managed to communicate
with it and get the data using libusb, but I've found that if the
On Wed, 2005-06-08 at 12:37 -0400, Jeff Lange wrote:
> I'm developing a simple USB device that reports itself as a HID
> device, and uses interrupt transfers to send about 250 bytes of data
> whenever an event occurs on the device.
Why do you do this as opposed to *not* identifying as a HID dev
Hi Ken,
If you look at the bug filed in the Linux Kernel Bugzilla
(http://bugzilla.kernel.org/show_bug.cgi?id=1048),
there is an explanation of the problem and a proposed patch.
In hid-core.c, in function hid_input_field(), there is the
following code:
if (field->flags & HID_MAIN_ITEM_RELATIVE) {
David Brownell wrote:
Wes Janzen wrote:
I can't seem to open the hiddev device... The driver appears to
install and the APC UPS is listed in lsusb with the driver HID, but I
can't open it.
I suspect it is caused by this:
<7>drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
<3>
Wes Janzen wrote:
I can't seem to open the hiddev device... The driver appears to install
and the APC UPS is listed in lsusb with the driver HID, but I can't open
it.
I suspect it is caused by this:
<7>drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
<3>drivers/usb/core/hub.c: us
> From: Jackson Chan <[EMAIL PROTECTED]>
> Date: Mon, 9 Jun 2003 11:57:36 -0600
> > I have been trying to solve this problem for a long time and any help
> > would be greatly appreciated.
In such case you would be well advised to stop being a jerk
and cross-post the same stupid question everywher
> Thanx to the help of gregkh I've figured out that the feature reports
> I tried to generate are generating an EPIPE, which is a babble, which
> means that I'm babbeling. Which is true.
It'd be really nice if babbling were consistently EOVERFLOW,
with EPIPE reserved exclusively for stall. OHCI
On Fri, Jun 08, 2001 at 07:43:31AM +1000, root wrote:
> While running a descriptor dump (code attached) on my USB speakers with
> the hiddev ioctl()s in 2.4.5-ac7, I hit the following oops using JE's
> UHCI. Repeatable on this HCD, not tried on OHCI or GA's UHCI.
>
> >>EIP; Before first
15 matches
Mail list logo
