Re: [linux-usb-devel] hiddev

2007-08-10 Thread Jiri Kosina
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 this index is?

Please refer to USB specification.

The string descriptor indexes are fully optional and are referenced by the 
other descriptors (device descriptors, configuration descriptors, etc). So 
the valid range differs from device to device and depends of how much of 
the descriptor information has available the corresponding string (human 
readable) representation.

-- 
Jiri Kosina

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev

2007-08-10 Thread Folkert van Heusden
Hi,

In linux/Documentation/usb/hiddev.txt I read the following:

 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?


Thank you,

Folkert van Heusden

-- 
MultiTail is een flexibele tool voor het volgen van logfiles en
uitvoer van commando's. Filteren, van kleur voorzien, mergen,
'diff-view', etc. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev

2007-08-10 Thread Folkert van Heusden
   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 specification.
 The string descriptor indexes are fully optional and are referenced by the 
 other descriptors (device descriptors, configuration descriptors, etc). So 
 the valid range differs from device to device and depends of how much of 
 the descriptor information has available the corresponding string (human 
 readable) representation.

Yes I understood that. I needed this info to investigate an USB device
for which no documentation exists. But I think I found the information
that I need:
in linux/drivers/usb/core/message.c there's the following code snippet:
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(USB_DT_STRING  8) + index, langid, buf, size,

That means that index may not be bigger then 255 as else it would garble the
value of 'USB_DT_STRING  8'.


Folkert van Heusden

-- 

Multitail - gibkaja utilita po sledovaniju log-fajlov i vyvoda
kommand. Fil'trovanie, raskrašivanie, slijanie, vizual'noe sravnenie,
i t.d.  http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] HIDDEV larger request buffer

2006-04-10 Thread Michael Downey
I am currently looking at using a MegTek USB insertion reader and I have
run into a problem with the current hiddev.  The card reader returns a
338 byte Input report on the interrupt in channel everytime a card is
inserted.  The data contains basically all the information needed from
the card.  The problem is that this one report is seen as 338 usage
references.  So hiddev tries to build all the events for this report but
wraps it's buffer as it only allocates space for 64.  I increased
HIDDEV_BUFFER_SIZE to 512 and everything worked correctly.

My question is whether there would be any issue with increasing the
HIDDEV_BUFFER_SIZE to 512?  I realize that this causes us to use 24 *
512 bytes instead of 24 * 64 bytes.  Is there any specific reason for
only allocating 64 or was it just a nice power of 2 number?  The main
reason why we overflow this buffer is that we report a seperate event
for every report count on each usage.  So in the case of this card
reader there are three usages with a report count of 110.  So each of
these usages cause 110 seperate events to be generated.  If we could
somehow pack all the similar data into a single buffer then this device
would only generate 11 events per insert instead of 338.  This would
mean making changes to the file access structures which would likely
break things for other people.

If no one has issues I will submit a patch to just up the
HIDDEV_BUFFER_SIZE to 512 from 64.


Michael Downey



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] HIDDEV documentation and info

2006-04-05 Thread Michael Downey
I'm currently looking at developing a way to interface with a couple of
HID devices.  Specifically a bill acceptor and a swipe card reader. 
Both devices are detected and picked up by the hiddev kernel module, but
as far as I can see the hiddev doesn't provide everything I need to get
full support for these devices.  I am also finding it difficult to find
anything documentation on the HIDDEV api.   I found the
Documentation/usb/hiddev.txt and that provides some info but I was
hoping to get a more detailed example of how to use it.  I also looked
at the hiddev.c source and noticed that the write function just returns
-EINVAL.  So does this mean that you can't write at all, or is there
something else that picks up that functionality?

I've also seen the libhid library but it is a GPL library so it wouldn't
work for me.  If there isn't a good way to do this using hiddev then my
only other option is implementing the whole thing using just libusb.

Any help would be appreciated,


Michael Downey



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev - __s32 value to small?

2005-11-03 Thread Guenther . Obrist
Hi! 
I am working on a hid under Linux Suse and i want to communicate with it. it 
is working under Windows, I have to adapt it also for Linux. I was able to 
read out some device infos, but I have some problem with sending and 
recieving data from the device.
I wrote a little c-program to handle a communication. I don't get any error 
messages from the ioctl()  but there happen strange things:

My stdout:
/***
ewien-134:/home/ogu1234/knx# ./knx4
Vendor_ID:0x03eb   Product: 0x0001  Version: 1.0.4.
1 Application,   Location: 1, devnum: 2, ifnum: 0

Senden...
knx_send 1
 report_id=0, report_type= 2
knx_send vor for-Schleife: uindex:0 - rc:0
value = 5
knx_send vor for-Schleife: uindex:1 - rc:0
value = ffb1
knx_send vor for-Schleife: uindex:2 - rc:0
value = 4
knx_send vor for-Schleife: uindex:3 - rc:0
value = 1f
knx_send vor for-Schleife: uindex:4 - rc:0
value = 50
knx_send 6
send = 0
...gesendet...fd closed
/*

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

Could you help me?

Greetings from Vienna
Günther


***
ProgrammCode***
***
#include fcntl.h
#include unistd.h
#include sys/ioctl.h
#include asm/types.h



#ifndef HID_MAX_USAGES
#define HID_MAX_USAGES 1024
#endif

#include linux/hiddev.h

int getUsageCode_Out0( int );
int match_fail( const char*, short );
int fd, version;

struct hiddev_devinfo device_info;

#define READ_BUFFER_LENGTH 5

/* File-global */

unsigned long usageCode;



/*
 * In:      report  - The report buffer (always 64
bytes), including 
record_ID
 *          fd      - The file descriptor as delivered
by init()
 * Out:     -
 *
 * Returns: 0 if ok, or the error code of a failed
ioctl() call

 */

int knx_send( const char report[5], int fd  )
{
    int rc = 0, uindex; 
    // send output report
    struct hiddev_usage_ref uref;
    struct hiddev_report_info rinfo;

    // always send 5 bytes, assume 0x01 (report_id) is
prepended
    uref.report_id = 0x00;//*report++;  // report_id
byte: special treatment
    uref.report_type = HID_REPORT_TYPE_OUTPUT;
    
    uref.field_index = 0x00;

    // uref.usage_code = 0xFFA10005;
    uref.usage_code = usageCode;

    for( uindex = 0; uindex  5; uindex++ )
    {
    uref.usage_index = uindex;
    uref.value = *report++;
    printf(knx_send vor for-Schleife: uindex:%d -
rc:%d\n, uindex,rc);
    printf(value = %-12x\n, uref.value);
    if( (rc=ioctl( fd, HIDIOCSUSAGE, uref )) != 0 )
    {
printf(knx_send fehler 1: uindex:%d - rc:%d\n,
uindex,rc);
        return rc;
    }
    
    
    }

    rinfo.report_type = HID_REPORT_TYPE_OUTPUT;

    rinfo.report_id =  0x00;

    rinfo.num_fields = 1;
    if( (rc=ioctl( fd, HIDIOCSREPORT, rinfo )) != 0 )
    {
    printf(knx_send fehler 2);
    return rc;

    }
    printf(knx_send 6\n);
    return 0;
}


/*
 * In:      device path  - Typically,
/dev/usb/hiddev0
 *          vendorId     - 4 hex digits passed as a
string, e.g. 2c58
 *          productId    - 4 hex digits passed as a
string, see above
 *          versionId    - 4 hex digits passed as a
string, see above
 * Out:     -
 *
 * Returns: A valid file descriptor as returned by
open(), or  0 on 
error
 */

int knx_init( char* device_path, 
      const char* vendorId, 
      const char* productId,
      const char* versionId )
{
    struct hiddev_devinfo device_info;
    int fd = open ( device_path, O_RDWR );
    if (fd  0) {
printf(open() failed, check the connection to the
device\n);
exit(1); 
    }

    if (ioctl (fd, HIDIOCGDEVINFO, device_info) |
ioctl (fd, HIDIOCGVERSION, version) ==-1) {
close(fd);
printf(GDEVINFO failed\n);
    }
    printf( Vendor_ID:0x%04hx   Product: 0x%04hx 
Version: %d.%d.%d.\n, device_info.vendor,
device_info.product, version  16, (version  8) 
0xff, version  0xff);
    printf(%i Application%s,  ,
device_info.num_applications, 
(device_info.num_applications==1?:s));
    printf( Location: %d, devnum: %d, ifnum: %d\n,
device_info.busnum, device_info.devnum,
device_info.ifnum);






    if (getUsageCode_Out0( fd )  0) {
printf(getusageCode_Out0 kleiner 0\n);
return -8;
    }
    
    printf(Ausgabe);


    if (*vendorId != 0 || *productId != 0 ||
*versionId != 0) {
/*
 * If vendorID, productId, or versionId provided:
 *    Check if device matches them!
 */
printf(if abfrage: 

[linux-usb-devel] hiddev - __s32 value to small?

2005-11-03 Thread Guenther . Obrist
Hi! 
I am working on a hid under Linux Suse and i want to communicate with it. it 
is working under Windows, I have to adapt it also for Linux. I was able to 
read out some device infos, but I have some problem with sending and 
recieving data from the device.
I wrote a little c-program to handle a communication. I don't get any error 
messages from the ioctl()  but there happen strange things:

My stdout:
/***
ewien-134:/home/ogu1234/knx# ./knx4
Vendor_ID:0x03eb   Product: 0x0001  Version: 1.0.4.
1 Application,   Location: 1, devnum: 2, ifnum: 0

Senden...
knx_send 1
 report_id=0, report_type= 2
knx_send vor for-Schleife: uindex:0 - rc:0
value = 5
knx_send vor for-Schleife: uindex:1 - rc:0
value = ffb1
knx_send vor for-Schleife: uindex:2 - rc:0
value = 4
knx_send vor for-Schleife: uindex:3 - rc:0
value = 1f
knx_send vor for-Schleife: uindex:4 - rc:0
value = 50
knx_send 6
send = 0
...gesendet...fd closed
/*

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

Could you help me?

Greetings from Vienna
Günther


***
ProgrammCode***
***
#include fcntl.h
#include unistd.h
#include sys/ioctl.h
#include asm/types.h



#ifndef HID_MAX_USAGES
#define HID_MAX_USAGES 1024
#endif

#include linux/hiddev.h

int getUsageCode_Out0( int );
int match_fail( const char*, short );
int fd, version;

struct hiddev_devinfo device_info;

#define READ_BUFFER_LENGTH 5

/* File-global */

unsigned long usageCode;



/*
 * In:      report  - The report buffer (always 64
bytes), including 
record_ID
 *          fd      - The file descriptor as delivered
by init()
 * Out:     -
 *
 * Returns: 0 if ok, or the error code of a failed
ioctl() call

 */

int knx_send( const char report[5], int fd  )
{
    int rc = 0, uindex; 
    // send output report
    struct hiddev_usage_ref uref;
    struct hiddev_report_info rinfo;

    // always send 5 bytes, assume 0x01 (report_id) is
prepended
    uref.report_id = 0x00;//*report++;  // report_id
byte: special treatment
    uref.report_type = HID_REPORT_TYPE_OUTPUT;
    
    uref.field_index = 0x00;

    // uref.usage_code = 0xFFA10005;
    uref.usage_code = usageCode;

    for( uindex = 0; uindex  5; uindex++ )
    {
    uref.usage_index = uindex;
    uref.value = *report++;
    printf(knx_send vor for-Schleife: uindex:%d -
rc:%d\n, uindex,rc);
    printf(value = %-12x\n, uref.value);
    if( (rc=ioctl( fd, HIDIOCSUSAGE, uref )) != 0 )
    {
printf(knx_send fehler 1: uindex:%d - rc:%d\n,
uindex,rc);
        return rc;
    }
    
    
    }

    rinfo.report_type = HID_REPORT_TYPE_OUTPUT;

    rinfo.report_id =  0x00;

    rinfo.num_fields = 1;
    if( (rc=ioctl( fd, HIDIOCSREPORT, rinfo )) != 0 )
    {
    printf(knx_send fehler 2);
    return rc;

    }
    printf(knx_send 6\n);
    return 0;
}


/*
 * In:      device path  - Typically,
/dev/usb/hiddev0
 *          vendorId     - 4 hex digits passed as a
string, e.g. 2c58
 *          productId    - 4 hex digits passed as a
string, see above
 *          versionId    - 4 hex digits passed as a
string, see above
 * Out:     -
 *
 * Returns: A valid file descriptor as returned by
open(), or  0 on 
error
 */

int knx_init( char* device_path, 
      const char* vendorId, 
      const char* productId,
      const char* versionId )
{
    struct hiddev_devinfo device_info;
    int fd = open ( device_path, O_RDWR );
    if (fd  0) {
printf(open() failed, check the connection to the
device\n);
exit(1); 
    }

    if (ioctl (fd, HIDIOCGDEVINFO, device_info) |
ioctl (fd, HIDIOCGVERSION, version) ==-1) {
close(fd);
printf(GDEVINFO failed\n);
    }
    printf( Vendor_ID:0x%04hx   Product: 0x%04hx 
Version: %d.%d.%d.\n, device_info.vendor,
device_info.product, version  16, (version  8) 
0xff, version  0xff);
    printf(%i Application%s,  ,
device_info.num_applications, 
(device_info.num_applications==1?:s));
    printf( Location: %d, devnum: %d, ifnum: %d\n,
device_info.busnum, device_info.devnum,
device_info.ifnum);






    if (getUsageCode_Out0( fd )  0) {
printf(getusageCode_Out0 kleiner 0\n);
return -8;
    }
    
    printf(Ausgabe);


    if (*vendorId != 0 || *productId != 0 ||
*versionId != 0) {
/*
 * If vendorID, productId, or versionId provided:
 *    Check if device matches them!
 */
printf(if abfrage: 

Re: [linux-usb-devel] hiddev - __s32 value to small?

2005-11-03 Thread Laurent Pinchart
 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  )
 {
     struct hiddev_usage_ref uref;
[..]
     uref.value = *report++;
[..]

report is declared as char*, which is a signed 8-bits value. 0xb1 is thus 
interpreted as -79, which is assigned to uref.value. uref.value is a signed 
32-bits value, and thus -79 is encoded as a 32 bits signed integer, which 
gives 0xffb1.

Laurent Pinchart


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev - __s32 value to small?

2005-11-03 Thread Guenther . Obrist
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_ref
 
  int knx_send( const char report[5], int fd  )
  {
      struct hiddev_usage_ref uref;

 [..]

      uref.value = *report++;

 [..]

 report is declared as char*, which is a signed 8-bits value. 0xb1 is thus
 interpreted as -79, which is assigned to uref.value. uref.value is a signed
 32-bits value, and thus -79 is encoded as a 32 bits signed integer, which
 gives 0xffb1.

 Laurent Pinchart


 ---
 SF.Net email is sponsored by:
 Tame your development challenges with Apache's Geronimo App Server.
 Download it for free - -and be entered to win a 42 plasma tv or your very
 own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
 ___
 linux-usb-devel@lists.sourceforge.net
 To unsubscribe, use the last form field at:
 https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


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?

-- 
Günther Obrist
[EMAIL PROTECTED]
Moeller Gebäudeautomation KG
Scheydgasse 42, 1215 Wien
AUT Entwicklung Wien


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev - __s32 value to small?

2005-11-03 Thread Laurent Pinchart
 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


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev question

2005-06-09 Thread Johannes Berg

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 data from =(
 


Ah, sorry (The apple trackpad in question is in no way HID compliant)

Have you checked if your events make it to userspace via the event 
devices /dev/input/eventX when you compile in evdev support?


johannes


---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20

___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev question

2005-06-08 Thread Jeff Lange
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 hid
module is inserted (e.g. a USB keyboard is attached to the system) I
can no longer use the libusb interface because it says the endpoint is
busy.  So I've been playing around with the /dev/usb/hiddevX
interface, but haven't been able to make too much sense of the output.
 my read() will get data (not the right amount, and not every time)
when I send it from the device, but it's not in any format I can
discern.

  Is using the hiddev interface even the correct approach for doing
this?  Does anyone have any suggestions on how I can get this to work?

FYI, I'm developing on a SuSE 9.0 box with a 2.4.21 kernel.  I don't
have the luxury of using a 2.6 kernel, as the customer requires SuSE
9.0

Thanks.
-Jeff


---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r 
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev question

2005-06-08 Thread Johannes Berg
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 device if
you don't want to comply with the HID standard? Apple does that as well
with the new powerbook's touchpad, but I can't see why you would do
this.
If you don't, the hid driver won't grab your endpoint and all will be
happy.

johannes


signature.asc
Description: This is a digitally signed message part


Re: [linux-usb-devel] hiddev question

2005-06-08 Thread Ken Cobler

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 hid
module is inserted (e.g. a USB keyboard is attached to the system) I
can no longer use the libusb interface because it says the endpoint is
busy.  So I've been playing around with the /dev/usb/hiddevX
interface, but haven't been able to make too much sense of the output.
my read() will get data (not the right amount, and not every time)
when I send it from the device, but it's not in any format I can
discern.

 Is using the hiddev interface even the correct approach for doing
this?  Does anyone have any suggestions on how I can get this to work?

FYI, I'm developing on a SuSE 9.0 box with a 2.4.21 kernel.  I don't
have the luxury of using a 2.6 kernel, as the customer requires SuSE
9.0

Thanks.
-Jeff

 



I developed a user application that used the hiddev (Suse 9.0).Just 
opened /dev/usb/hiddev0.  Then I just sent and received HID reports.


The only problem that I noticed with Suse 9.0 (or Linux 2.4 kernel), is 
it throws away what it considers duplicate reports.  My device was a USB 
credit card reader.  If someone swiped a card twice, the second swipe 
was being tossed by the kernel.  I have a patch to try to see if it 
clears it up.


Ken Cobler



---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20

___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] hiddev: input report duplicate elimination causes trouble

2005-03-31 Thread Boris Shingarov
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) {
   if (!value[n])
   continue;
} else {
   if (value[n] == field-value[n])
continue;
}
I think this is completely bogus: it compares the value to the
one stored from the previous report, and throws away the report
if the value is the same.  The fix is simply to remove that code.
We have been using this approach in production for almost a year
now, and it did not cause any problems.
What I am surprised to hear, though, is that 2.6 is not working
for you.  The experience has been exactly the opposite for me.
2.6.6, 2.6.9, 2.6.10, all work like a charm for us, and 2.4.21
to 29 proved to cause all kinds of pain.  In general, I'd
describe my experience with HID in 2.4 as doesn't work.  Did
you try inserting debug printk()'s in early stages of input
report processing to see if you are getting any USB transfers
at all, or the report gets lost somewhere in the hid-land?
Regards,
Boris Shingarov
Development Manager, Linux systems
CRYPTOCard Corp.
340 March Road, Suite 600
Kanata, ON K2K 2E2
Toll Free: (800) 307-7042
Int'l: +1-613-599-2441
mailto: [EMAIL PROTECTED]
http://www.cryptocard.com


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev: input report duplicate elimination causes trouble

2005-03-29 Thread Boris Shingarov
Hi,
Does anybody know the reason why hid input report caching /
duplicate elimination is really needed?  That is, if a HID
device sends a report with the same absolute value twice, the
second report gets swallowed in hid_input_field().  Similarly,
relative values of zero never make it through to the userland
client.
Is there a compelling reason why we must have this?  The problem
I have with this, is that there are several devices broken by
this behavior.  There is Bug 1048 in the Linux Bugzilla
(http://bugzilla.kernel.org/show_bug.cgi?id=1048)
which was opened in 2003 and is still in the New state;
there is a proposed fix attached by the original reporter, but
so far nobody has commented on it neither negatively nor
positively.
We distribute the patch with our USB-attached hardtoken
initializers which we make, but it would be interesting to
completely understand all parties' concerns and agree on an
official solution.
Boris

---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Hiddev vs Evdev PLEASE HELP

2004-08-18 Thread bastgiraud
hello,
 
I have a problem with my device who works under linux with usb.
I have read 'the USB HID for Linux USB' of Brad Hards which had really help above all 
the part entitled the hid device interface'.
Nevertheless I can't write on dev/usv/hiddev0, I don't know why.
 
So, I am interested in the event interface but I 'd like to know if the evdev is 
restrictive compared to hiddev for the SPEED and the QUANTITY of data exchanged.

DO ADVANTAGE  INCONVENIENTS between hiddev and evdev exist???
 
Could I write on my device with evdev or hiddev???,
 
B GIRAUD
  


---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink  Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] [HIDDEV] Fix boundary checks for GUSAGE/SUSAGE

2004-06-04 Thread Herbert Xu
On Thu, May 06, 2004 at 08:15:15PM +1000, herbert wrote:
 
 The current code is applying the maxusage limit to GUSAGE/SUSAGE.  This
 is incorrect as the number of values is stored in field-report_count,
 not field-maxusage.  The USB phone from www.virbiage.com is one device
 where report_count exceeds maxusage.

I've remove the changes unrelated to the boundary check.  Please let me
know if you have any problems with this patch.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
= drivers/usb/input/hiddev.c 1.49 vs edited =
--- 1.49/drivers/usb/input/hiddev.c 2004-05-29 07:08:23 +10:00
+++ edited/drivers/usb/input/hiddev.c   2004-06-04 20:02:29 +10:00
@@ -638,15 +638,18 @@
goto inval;
 
field = report-field[uref-field_index];
-   if (uref-usage_index = field-maxusage)
-   goto inval;
-
-   if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
-   if (uref_multi-num_values = HID_MAX_USAGES || 
-   uref-usage_index = field-maxusage || 
-  (uref-usage_index + uref_multi-num_values) = 
field-maxusage)
+   if (cmd == HIDIOCGCOLLECTIONINDEX) {
+   if (uref-usage_index = field-maxusage)
goto inval;
-   }
+   } else if (uref-usage_index = field-report_count)
+   goto inval;
+   else if ((cmd == HIDIOCGUSAGES ||
+ cmd == HIDIOCSUSAGES) 
+(uref-usage_index + uref_multi-num_values =
+ field-report_count ||
+ uref-usage_index + uref_multi-num_values 
+ uref-usage_index))
+   goto inval;
}
 
switch (cmd) {


[linux-usb-devel] [HIDDEV] Fix boundary checks for GUSAGE/SUSAGE

2004-05-06 Thread Herbert Xu
Hi:

The current code is applying the maxusage limit to GUSAGE/SUSAGE.  This
is incorrect as the number of values is stored in field-report_count,
not field-maxusage.  The USB phone from www.virbiage.com is one device
where report_count exceeds maxusage.

The following patch corrects the check for 2.6.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: drivers/usb/input/hiddev.c
===
RCS file: 
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/input/hiddev.c,v
retrieving revision 1.1.1.12
diff -u -r1.1.1.12 hiddev.c
--- a/drivers/usb/input/hiddev.c5 Apr 2004 09:49:36 -   1.1.1.12
+++ b/drivers/usb/input/hiddev.c14 Apr 2004 10:07:25 -
@@ -575,33 +575,11 @@
 
return 0;
 
-   case HIDIOCGUCODE:
-   if (copy_from_user(uref, (void *) arg, sizeof(*uref)))
-   return -EFAULT;
-
-   rinfo.report_type = uref-report_type;
-   rinfo.report_id = uref-report_id;
-   if ((report = hiddev_lookup_report(hid, rinfo)) == NULL)
-   return -EINVAL;
-
-   if (uref-field_index = report-maxfield)
-   return -EINVAL;
-
-   field = report-field[uref-field_index];
-   if (uref-usage_index = field-maxusage)
-   return -EINVAL;
-
-   uref-usage_code = field-usage[uref-usage_index].hid;
-
-   if (copy_to_user((void *) arg, uref, sizeof(*uref)))
-   return -EFAULT;
-
-   return 0;
-
case HIDIOCGUSAGE:
case HIDIOCSUSAGE:
case HIDIOCGUSAGES:
case HIDIOCSUSAGES:
+   case HIDIOCGUCODE:
case HIDIOCGCOLLECTIONINDEX:
if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
if (copy_from_user(uref_multi, (void *) arg, 
@@ -617,7 +595,8 @@
uref-report_type == HID_REPORT_TYPE_INPUT)
return -EINVAL;
 
-   if (uref-report_id == HID_REPORT_ID_UNKNOWN) {
+   if (cmd != HIDIOCGUCODE 
+   uref-report_id == HID_REPORT_ID_UNKNOWN) {
field = hiddev_lookup_usage(hid, uref);
if (field == NULL)
return -EINVAL;
@@ -631,28 +610,34 @@
return -EINVAL;
 
field = report-field[uref-field_index];
-   if (uref-usage_index = field-maxusage)
-   return -EINVAL;
-
-   if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
-   if (uref_multi.num_values = HID_MAX_USAGES || 
-   uref-usage_index = field-maxusage || 
-  (uref-usage_index + uref_multi.num_values) = 
field-maxusage)
+   if (cmd == HIDIOCGUCODE ||
+   cmd == HIDIOCGCOLLECTIONINDEX) {
+   if (uref-usage_index = field-maxusage)
return -EINVAL;
-   }
+   } else if (uref-usage_index = field-report_count)
+   return -EINVAL;
+   else if ((cmd == HIDIOCGUSAGES ||
+ cmd == HIDIOCSUSAGES) 
+(uref-usage_index + uref_multi.num_values =
+ field-report_count ||
+ uref-usage_index + uref_multi.num_values 
+ uref-usage_index))
+   return -EINVAL;
}
 
switch (cmd) {
case HIDIOCGUSAGE:
uref-value = field-value[uref-usage_index];
-   if (copy_to_user((void *) arg, uref, sizeof(*uref)))
-   return -EFAULT;
-   return 0;
+   break;
 
case HIDIOCSUSAGE:
field-value[uref-usage_index] = uref-value;
return 0;
 
+   case HIDIOCGUCODE:
+   uref-usage_code = field-usage[uref-usage_index].hid;
+   break;
+
case HIDIOCGCOLLECTIONINDEX:
return 
field-usage[uref-usage_index].collection_index;
case HIDIOCGUSAGES:
@@ -670,6 +655,8 @@
return 0;
}
 
+   if (copy_to_user((void *) arg, uref, 

[linux-usb-devel] [HIDDEV] Fix boundary checks for GUSAGE/SUSAGE

2004-04-14 Thread Herbert Xu
Hi:

The current code is applying the maxusage limit to GUSAGE/SUSAGE.  This
is incorrect as the number of values is stored in field-report_count,
not field-maxusage.  The USB phone from www.virbiage.com is one device
where report_count exceeds maxusage.

The following patch corrects the check for 2.6.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: drivers/usb/input/hiddev.c
===
RCS file: 
/home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/usb/input/hiddev.c,v
retrieving revision 1.1.1.12
diff -u -r1.1.1.12 hiddev.c
--- a/drivers/usb/input/hiddev.c5 Apr 2004 09:49:36 -   1.1.1.12
+++ b/drivers/usb/input/hiddev.c14 Apr 2004 10:07:25 -
@@ -575,33 +575,11 @@
 
return 0;
 
-   case HIDIOCGUCODE:
-   if (copy_from_user(uref, (void *) arg, sizeof(*uref)))
-   return -EFAULT;
-
-   rinfo.report_type = uref-report_type;
-   rinfo.report_id = uref-report_id;
-   if ((report = hiddev_lookup_report(hid, rinfo)) == NULL)
-   return -EINVAL;
-
-   if (uref-field_index = report-maxfield)
-   return -EINVAL;
-
-   field = report-field[uref-field_index];
-   if (uref-usage_index = field-maxusage)
-   return -EINVAL;
-
-   uref-usage_code = field-usage[uref-usage_index].hid;
-
-   if (copy_to_user((void *) arg, uref, sizeof(*uref)))
-   return -EFAULT;
-
-   return 0;
-
case HIDIOCGUSAGE:
case HIDIOCSUSAGE:
case HIDIOCGUSAGES:
case HIDIOCSUSAGES:
+   case HIDIOCGUCODE:
case HIDIOCGCOLLECTIONINDEX:
if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
if (copy_from_user(uref_multi, (void *) arg, 
@@ -617,7 +595,8 @@
uref-report_type == HID_REPORT_TYPE_INPUT)
return -EINVAL;
 
-   if (uref-report_id == HID_REPORT_ID_UNKNOWN) {
+   if (cmd != HIDIOCGUCODE 
+   uref-report_id == HID_REPORT_ID_UNKNOWN) {
field = hiddev_lookup_usage(hid, uref);
if (field == NULL)
return -EINVAL;
@@ -631,28 +610,34 @@
return -EINVAL;
 
field = report-field[uref-field_index];
-   if (uref-usage_index = field-maxusage)
-   return -EINVAL;
-
-   if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
-   if (uref_multi.num_values = HID_MAX_USAGES || 
-   uref-usage_index = field-maxusage || 
-  (uref-usage_index + uref_multi.num_values) = 
field-maxusage)
+   if (cmd == HIDIOCGUCODE ||
+   cmd == HIDIOCGCOLLECTIONINDEX) {
+   if (uref-usage_index = field-maxusage)
return -EINVAL;
-   }
+   } else if (uref-usage_index = field-report_count)
+   return -EINVAL;
+   else if ((cmd == HIDIOCGUSAGES ||
+ cmd == HIDIOCSUSAGES) 
+(uref-usage_index + uref_multi.num_values =
+ field-report_count ||
+ uref-usage_index + uref_multi.num_values 
+ uref-usage_index))
+   return -EINVAL;
}
 
switch (cmd) {
case HIDIOCGUSAGE:
uref-value = field-value[uref-usage_index];
-   if (copy_to_user((void *) arg, uref, sizeof(*uref)))
-   return -EFAULT;
-   return 0;
+   break;
 
case HIDIOCSUSAGE:
field-value[uref-usage_index] = uref-value;
return 0;
 
+   case HIDIOCGUCODE:
+   uref-usage_code = field-usage[uref-usage_index].hid;
+   break;
+
case HIDIOCGCOLLECTIONINDEX:
return 
field-usage[uref-usage_index].collection_index;
case HIDIOCGUSAGES:
@@ -670,6 +655,8 @@
return 0;
}
 
+   if (copy_to_user((void *) arg, uref, 

[linux-usb-devel] hiddev - read

2004-03-10 Thread Martin Kneppe
I have a problem reading from my hid-device using the hid module.

I managed to send commands to the device using the CSREPORT and
CSUSAGE, but i cant seem to get the information back from the device.

As i have writen the firmware myself, i know that the device responds to command 
through
endpoint 0 (Control) and sends data back using endpoint 1(INT). The size of endpoint1 
is 6byte.
But i cant seem to get these 6 bytes (or any) from the hiddev, just report using 
CGREPORT, with 2byte-size.
How do i access the interrupt-transfer ?
I tried using the read() as described in hiddev.txt, but it only blocks/timeouts.

Is there any documentation/howto/example for reading from the hiddev ?
I also looked at the ups.c but couldn't get it to work for me.

I searched the net and the mailling-list archive, but didn't find anything useful.

Martin




the entry in /proc/bus/usb/devices is:
T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1234 ProdID=1234 Rev= 0.01
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   6 Ivl=10ms

and i send a command to the device using :

 fd=open(/dev/usb/hiddev0,O_RDWR);
  struct hiddev_usage_ref uref;
  struct hiddev_report_info rinfo;
  uref.report_type=HID_REPORT_TYPE_OUTPUT;
  uref.report_id=HID_REPORT_ID_FIRST;
  uref.field_index=0;
  uref.usage_index=0;
  uref.usage_code=0x01;
  uref.value=a;
  ioctl(fd,HIDIOCSUSAGE,uref)
  uref.usage_index=1;
  uref.value=b;
  ioctl(fd,HIDIOCSUSAGE,uref)
  rinfo.report_type=HID_REPORT_TYPE_OUTPUT;
  rinfo.report_id=HID_REPORT_ID_FIRST;
  rinfo.num_fields=1;
  ioctl(fd,HIDIOCSREPORT,rinfo)

and the read I tried:


hiddev_event *buffer;
read(fd,buffer,sizeof(hiddev_event));

-timeout
or 


void read_data(fd)
{
  struct hiddev_usage_ref uref;
  struct hiddev_report_info rinfo;
  struct hiddev_field_info finfo;
  struct  hiddev_string_descriptor sdesc;
  static  charstr[256];


  int nret,i;
  ioctl(fd,HIDIOCINITREPORT,0);
  rinfo.report_type = HID_REPORT_TYPE_INPUT;
  rinfo.report_id = HID_REPORT_ID_FIRST  ;
  ioctl( fd, HIDIOCGREPORTINFO, rinfo);
  finfo.report_type = rinfo.report_type;
  finfo.report_id = rinfo.report_id;
  finfo.field_index = 0;
  ioctl(fd, HIDIOCGFIELDINFO, finfo);
  for (i=0;i(int)finfo.maxusage;i++)
{
  uref.report_type = finfo.report_type;
  uref.report_id = finfo.report_id;
  uref.field_index = 0;
  uref.usage_index = i;
  ioctl(fd, HIDIOCGUCODE, uref);
  printf(%d = %x\n,uref.value);
}
}

-nothing useful.



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev HIDIOCGREPORT not blocking in 2.6?

2004-01-17 Thread Adam Kropelin
I've noticed in 2.6 kernels that HIDIOCGREPORT does not wait for io
completion before returning to the caller. This creates a few unpleasant
issues for userspace:

First, code sequences such as...

ioctl(fd, HIDIOCGREPORT, rinfo);
ioctl(fd, HIDIOCGUSAGE, uinfo);
ioctl(fd, HIDIOCGSTRING, sdesc);

...that used to work in 2.4 now fail in 2.6 if the device takes more
than a few milliseconds to respond to HIDIOCGREPORT. (I'm seeing this
issue on APC UPSes, FWIW.)

Second, userspace code can easily flood the kernel with control messages
since the kernel provides no backpressure. The result is a lot of
hid-core.c: control queue full errors and lost reports.

2.6 hid-core.c appears to submit the request and return immediately.
Although the 2.4 code differs significantly, I traced the call path to
usb-core.c, which seems to block with a timeout, so the code supports my
userspace observation. (Assuming I didn't misread it.)

Finally, my questions...

Is HIDIOCGREPORT in 2.6 intended to be non-blocking? If so, what is the
recommended userspace method for determining when the report has been
retrieved? If not, is the patch below an appropriate fix or should
hid_submit_report() be made to block instead?

Thanks in advance...
--Adam


--- linux-2.6.1/drivers/usb/input/hid.h Tue Jun 17 19:49:55 2003
+++ linux-2.6.1-adk/drivers/usb/input/hid.h Sat Jan 17 16:16:31 2004
@@ -448,6 +448,7 @@
 void hid_submit_report(struct hid_device *, struct hid_report *, unsigned char dir);
 void hid_init_reports(struct hid_device *hid);
 int hid_find_report_by_usage(struct hid_device *hid, __u32 wanted_usage, struct 
hid_report **report, int type);
+int hid_wait_io(struct hid_device* hid);
 
 
 #ifdef CONFIG_HID_FF
--- linux-2.6.1/drivers/usb/input/hiddev.c  Sun Jan 11 12:05:10 2004
+++ linux-2.6.1-adk/drivers/usb/input/hiddev.c  Sat Jan 17 16:16:50 2004
@@ -509,6 +509,7 @@
return -EINVAL;
 
hid_submit_report(hid, report, USB_DIR_IN);
+   hid_wait_io(hid);
 
return 0;
 



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] hiddev patch : disable hiddev support for MGE UPSs

2003-12-16 Thread arnaud . quette


Hi folks,

following my recent posts on libusb-devel and hidups, here's
a patch to disable hiddev support for MGE UPSs. It only
declares VID/PID as QUIRK_IGNORE in hid-core's blacklist.
This simply prevent hiddev to be loaded when plugging
an MGE UPS.

As always, due to my brain damaged Notes mailer, the patch is
not attached, but can be found at:
http://www.mgeups.com/opensource/projects/newhidups/patch-kernel_newhidups

Patch for other Mfrs will follow with the support for those in newhidups.

Please, apply on 2.4/2.6.

Arnaud




---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] HIDDEV questions

2003-10-28 Thread Jiang Zhang
Hi, all

Greetings.

I am trying to program a USB GPS device through HIDDEV interface on 
Linux.  I believe the  device is built upon Cypress CY7C64013 full speed 
USB-to-Serial chip and it shows as a generic HID device when plugged 
in.  It require a feature report with char[5] data to change settings.

On Windows,  I successfully did my work with WriteFile/ReadFile on 
hiddev driver interface. However, I found that Linux USB HIDDEV 
interface only accept signed integer as report data. I tried two ways 
but neither of them worked:

1. send these char[5] in two integer with two HIDIOCSUSAGE calls
2. with 5 HIDIOCSUSAGE calls to pass in int( char ) values
I searched the list and saw several people had similar questions about 
sending char array data to hiddev device. If there are walk-rounds, 
could you please share your knowledge?
Or is there any other ways should I approach in order to access the 
device on Linux?  A USB driver that bypass the HID layer? devfs?

If I start the device on windows with my program, it will continue to 
send GPS data when I reboot the computer into Linux. However, reading 
from the device with linux-hiddev event interface has problems, too.  
This device returns a 32 bytes input report. I tried to rebuild the 
structure with returned values of multiple  hiddev_event structures, but 
found out that some data showed up  in the hid field randomly.

I attached the device information and my ugly testing program based the 
evtest.c and ups.c at the end. If anyone kindly has suggestions or 
comments, please  let me know.  Thanks a lot!

Tested system:  kernel  2.4.22 and 2.6.0-test9   on Redhat 9 system

= program output 
hiddev driver version is 1.0.4
HID: vendor 0x1163 product 0x100 version 0x4 applications [1]: ffa1
HID: bus: 4 devnum: 2 ifnum: 0
HID device name: DeLorme Publishing DeLorme USB Earthmate
Reports of type Input (1):
 Report id: 0 (1 fields)
   Field: 0: app: ffa1 phys  flags 2 (1 usages) unit 0 exp 0
 Usage: ffa1 val 0
Reports of type Output (2):
 Report id: 0 (1 fields)
   Field: 0: app: ffa1 phys  flags 2 (1 usages) unit 0 exp 0
 Usage: ffa2 val 0
Reports of type Feature (3):
 Report id: 0 (1 fields)
   Field: 0: app: ffa1 phys  flags 2 (1 usages) unit 0 exp 0
 Usage: ffa3 val 129
= usb devfs info ===
T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1163 ProdID=0100 Rev= 0.04
S:  Manufacturer=DeLorme Publishing
S:  Product=DeLorme USB Earthmate
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl=6ms
E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=6ms
 lsusb -vv output: ==
Bus 004 Device 002: ID 1163:0100 DeLorme Publishing, Inc.
Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   1.00
 bDeviceClass0 Interface
 bDeviceSubClass 0
 bDeviceProtocol 0
 bMaxPacketSize0 8
 idVendor   0x1163 DeLorme Publishing, Inc.
 idProduct  0x0100
 bcdDevice0.04
 iManufacturer   1 DeLorme Publishing
 iProduct2 DeLorme USB Earthmate
 iSerial 0
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   41
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  4
   bmAttributes 0x80
   MaxPower  100mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   2
 bInterfaceClass 3 Human Interface Devices
 bInterfaceSubClass  0 No Subclass
 bInterfaceProtocol  0 None
 iInterface  0
   HID Device Descriptor:
 bLength 9
 bDescriptorType33
 bcdHID   1.00
 bCountryCode0
 bNumDescriptors 1
 bDescriptorType34 Report
 wDescriptorLength  37
cannot get report descriptor
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1 IN
   bmAttributes3
 Transfer TypeInterrupt
 Synch Type   none
   wMaxPacketSize 32
   bInterval   6
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x02  EP 2 OUT
   bmAttributes3
 Transfer TypeInterrupt
 Synch Type   none
   wMaxPacketSize 32
   bInterval   6
 Language IDs: (length=4)
0409 English(US)
/*
 * $Id: evtest.c,v 1.10 

[linux-usb-devel] hiddev changes between 2.4.18 and 2.4.20 ?

2003-08-09 Thread Julien Boibessot
Hi !

I haven written a small prog to handle a HID keyboard (standard mouse +
keyboard + special keys/sliders) we are developping. Mouse and keyboard are
managed by X, special keys are handled through hiddev by my small prog.
This prog reads report from hiddev ( we have 3 In-Endpoints on our keyboard)
using following code:

.
if( read( mFileDescriptor, buffer, USIF_REPORT_SIZE )  0 )
{
readReport();
}
.
// PUBLIC METHODS 
// Read the incoming report. Iterate through all field and all usage to find
if a value has been changed
// return true if no error occured else false
bool MyDevice::readReport(void)
{
bool reportChanged = false;
struct hiddev_usage_ref usageRef;
struct hiddev_field_info fieldInfo;

//cout  Reading report!  endl;
// Fill in structure needed by Hiddev Ioctl cmd
fieldInfo.report_type = HID_REPORT_TYPE_INPUT;
fieldInfo.report_id   = HID_REPORT_ID_FIRST;
usageRef.report_type  = HID_REPORT_TYPE_INPUT;
usageRef.report_id= HID_REPORT_ID_FIRST;

// Get number of usages for given Field
fieldInfo.field_index = mUsbReportFieldId;
if( ioctl( mFileDescriptor, HIDIOCGFIELDINFO, fieldInfo )  0 )
perror();
else
{
usageRef.field_index = mUsbReportFieldId;
// Iterate through all usage and get values
for ( unsigned int i = 0; i  min(fieldInfo.maxusage,
mNumberOfUsbUsage); i++ )
{
usageRef.usage_index = i;
if( ioctl( mFileDescriptor, HIDIOCGUSAGE, usageRef )  0 )
perror();
else
{
// if new value then save it in the mControlsValueReport
if( mpCurrentValue[i].value != usageRef.value )
{
mpCurrentValue[i].value = usageRef.value;
mpCurrentValue[i].haschanged = true;
reportChanged = true;
}
}
 }
}

return reportChanged;
}



First remark: on 2.4.20 I had to take care of fieldInfo.maxusage field
because it DOESN'T return the correct value our device is intended to return
(on 2.4.18 kernel this value is OK)
Does anyone knows why ???


For sending informations to our device (to light on/off leds), we are using
control endpoint and SendReport:

.
// Send commands to Usif through USB
void MyDevice::SendReport()
{

   if( ioctl(fd, HIDIOCINITREPORT, NULL)0)
perror(Init:);

   rinfo.report_type = HID_REPORT_TYPE_OUTPUT;
   rinfo.report_id   = HID_REPORT_ID_FIRST;

   ret = ioctl(fd, HIDIOCGREPORTINFO, rinfo);
   if( ret  0 )
perror(Rep:);

   printf(led: %d \n,rinfo.num_fields);

   finfo.report_type = HID_REPORT_TYPE_OUTPUT;
   finfo.report_id =  HID_REPORT_ID_FIRST;
   finfo.field_index = 0;
   if( ioctl(fd, HIDIOCGFIELDINFO, finfo)  0 )
perror(Field:);
printf(num fields %d, report id %d, max usage %d, value: %d  \n\n,
rinfo.num_fields, finfo.report_id,finfo.maxusage, uref.value);
}
.

On 2.4.18, no problemo: num_fields is set to 1 (I have one output field in
my device report) and HIDIOCFIELDINFO is working (doesn't return any error).
On 2.4.20, num_fields is set to 0 (??) and so when I try
to do a HIDIOCFIELDINFO perror signals me a Field: Invalid Argument
error

I'm lost
Can somebody help me ?? What happened to hiddev / hidcore between 2.4.18 and
2.4.20 ??

Thanks !
(sorry for C/C++ code mix)

Julien Boibessot



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] HIDDEV + UPS

2003-07-01 Thread David Brownell
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:
7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32
7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32
Translation:  an ep0 (control) OUT request stalled, so the device
with address 4 on port 3 of that transaction translating hub
supposedly left its transaction translator (TT) in a state that
needed to be cleared out.  But that TT didn't cooperate, maybe
because the wrong data was sent in the clear tt request; the
spec was not completely clear there.  (Repeats.)  Someone who
knows hubs better than I do should take a look.
This would be a 2.5 kernel.  There's something not quite right
in how the Transaction Translator (TT) state gets cleared
when certain errors come up ... it always seems to generate
messages.  But I've never seen it matter, despite what the
spec says those TT hubs need.
Does this happen if you don't use EHCI ... say, by hooking
this UPS up directly to a root hub, instead of through a
USB 2.0 hub?  Folk have had plenty of APC problems that don't
relate to that particular funky USB 2.0 feature.

7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
7drivers/usb/core/file.c: looking for a minor, starting at 0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32
I get those same error messages in my log when I try to open the hiddev 
for the UPS.
That looking for a minor suggests that whatever the problem was,
it got better...
- Dave



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] HIDDEV + UPS

2003-07-01 Thread Wes Janzen


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:
7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32
7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32


Translation:  an ep0 (control) OUT request stalled, so the device
with address 4 on port 3 of that transaction translating hub
supposedly left its transaction translator (TT) in a state that
needed to be cleared out.  But that TT didn't cooperate, maybe
because the wrong data was sent in the clear tt request; the
spec was not completely clear there.  (Repeats.)  Someone who
knows hubs better than I do should take a look.
This would be a 2.5 kernel.  There's something not quite right
in how the Transaction Translator (TT) state gets cleared
when certain errors come up ... it always seems to generate
messages.  But I've never seen it matter, despite what the
spec says those TT hubs need.
Does this happen if you don't use EHCI ... say, by hooking
this UPS up directly to a root hub, instead of through a
USB 2.0 hub?  Folk have had plenty of APC problems that don't
relate to that particular funky USB 2.0 feature.
Well, I don't get any message now...but it still doesn't work.  It 
doesn't say what hiddev device it is attached to when I connect it, but 
if I loop through all 16 trying to open them, the open fails on every 
one.  I thought it used to tell me which hiddev it was using when I 
connected it before, but maybe that was kernel 2.5.69.  I'm using 2.5.73 
now.

I'm able to connect to it in windows, so at least I know it is capable 
of connecting. 


7drivers/usb/host/ehci-q.c: clear tt 00:0a.2-3 p3 buffer, a4 ep0
7drivers/usb/core/file.c: looking for a minor, starting at 0
3drivers/usb/core/hub.c: usb-00:0a.2-3 clear tt 1 (0040) error -32
I get those same error messages in my log when I try to open the 
hiddev for the UPS.


That looking for a minor suggests that whatever the problem was,
it got better...
- Dave



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


[linux-usb-devel] Hiddev, the continuing story.

2001-06-18 Thread EJ

Hello,

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.

The feature description says that I should send two bytes in a feature
report. According to the specifications of the device, sending (0x01,
0x00) in the report should result in the Max X coordinate being
returned in the feature report.
If I look at the data that is submitted in hid_submit_out, it contains
the values I've set.
However, sending the report itself ends with an EPIPE.

From the BeOS developer I've heard that the report should also include
the report_id. Is that true, and, if so, is that automatically added?
(I was unsuccesful in following usb_submit_urb into the quadruple
indirection it contains).

I've attached the code that sets the two entries in the report, maybe
I'm overlooking something simple...

Thanx a lot,
EJ

   FEATURE(2)[FEATURE] 
 Field(0) 
   Physical(Digitizers.Stylus) 
   Usage(2) 
 Digitizers.003f 
 Digitizers.0040 
   Logical Minimum(0) 
   Logical Maximum(255) 
   Report Size(8) 
   Report Count(2) 
   Report Offset(0) 
   Flags( Variable Absolute ) 


/* Get the report information first */
memset(rinfo, 0, sizeof(rinfo));
memset(uref, 0, sizeof(uref));
rinfo.report_id = 2;
rinfo.report_type = HID_REPORT_TYPE_FEATURE;
if ((retval = ioctl(fd, HIDIOCGREPORTINFO, rinfo))  0)
goto error;

fprintf(stdout, Report (%d,%d)\n, rinfo.report_type,rinfo.report_id);
if (get_report(fd, rinfo)0)
goto error;

/* Get the first usage, and then set it to cmd */
uref.report_type = rinfo.report_type;
uref.report_id = rinfo.report_id;
uref.field_index = 0;
uref.usage_index = 0;
if (get_usage(fd, uref)0)
goto error;
fprintf(stdout, Report (%d,%d)\n, uref.report_type,uref.report_id);

uref.value = cmd;

if (set_usage(fd, uref)0)
goto error;

/* Get and set the second usage */
uref.usage_index = 1;
if (get_usage(fd, uref)0)
goto error;

uref.value = arg;
if (set_usage(fd, uref)0)
goto error;

/* Finalize the report */
if (set_report(fd, rinfo)0)
goto error;


___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel