Re: [libhid-discuss] Windows support?

[Xiaofan Chen]

Long post.

On Thu, Mar 27, 2008 at 11:38 PM, Charles Lepple [EMAIL PROTECTED] wrote:
 Xiaofan Chen wrote:
  Wait a moment, I remember someone has ported libhid to Win32
  in libusb-win32 mailing list. You may want to contact him (Rob Krakora).
  http://permalink.gmane.org/gmane.comp.lib.libusb.devel.windows/1476

 Please post back to this list with your findings. I don't have a Windows
 machine to test with, and nobody has really given me any concrete
 suggestions on ways to patch libhid so that it will work with
 libusb-win32.

Ok, I got the source code and I an build it with the free Visual C++.Net
Express 2005.

I do not have a good HID device to test this port. Anyway, just running
the first example here. It seems to work.

G:\USB\libusb_winusb\libhidwin32\libhid-0.2.16\libhid\Debugdir libhid.*
08/19/2007  03:36 PM   102,400 libhid.dll
08/19/2007  03:36 PM   403 libhid.dll.embed.manifest
08/19/2007  03:36 PM   468 libhid.dll.embed.manifest.res
08/19/2007  03:36 PM   385 libhid.dll.intermediate.manifest
08/19/2007  03:36 PM 3,613 libhid.exp
08/19/2007  03:36 PM   416,960 libhid.ilk
08/19/2007  03:36 PM 6,632 libhid.lib
08/19/2007  03:36 PM   478,208 libhid.pdb

G:\USB\libusb_winusb\libhidwin32\libhid-0.2.16\libhid\Debugdir *.exe
08/06/2007  01:51 AM40,960 test.exe
08/06/2007  01:51 AM40,960 test2.exe

G:\USB\libusb_winusb\libhidwin32\libhid-0.2.16\libhid\Debugtest2
 NOTICE_PRINT: hid_init(): libhid 0.2.16.0.0 is being initialized.
  TRACE_PRINT: hid_init(): initialising USB subsystem...
  TRACE_PRINT: hid_init(): scanning for USB busses...
  TRACE_PRINT: hid_init(): scanning for USB devices...
 NOTICE_PRINT: hid_init(): successfully initialised HID library.
  TRACE_PRINT: hid_new_HIDInterface(): creating a new HIDInterface instance...
  TRACE_PRINT: hid_force_open(): forcefully opening a device interface according
 to matching criteria...
  TRACE_PRINT: hid_get_usb_handle(): acquiring handle for a USB device...
  TRACE_PRINT: hid_find_usb_device(): enumerating USB busses...
  TRACE_PRINT: hid_find_usb_device(): enumerating USB devices on bus bus-0...
  TRACE_PRINT: hid_find_usb_device(): inspecting USB device bus-0/\\.\libusb0-00
01--0x04d8-0...
  TRACE_PRINT: hid_compare_usb_device(): comparing match specifications to USB d
evice...
  TRACE_PRINT: hid_compare_usb_device(): inspecting vendor ID...
  TRACE_PRINT: hid_compare_usb_device(): no match on vendor ID.
  TRACE_PRINT: hid_compare_usb_device(): inspecting product ID...
  TRACE_PRINT: hid_compare_usb_device(): no match on product ID.
  TRACE_PRINT: hid_compare_usb_device(): no custom matching function supplied.
 NOTICE_PRINT: hid_find_usb_device(): vendor 0x04d8 of USB device bus-0/\\.\libu
sb0-0001--0x04d8-0 does not match 0x05ac.
WARNING_PRINT: hid_find_usb_device(): no matching USB device found.
hid_force_open failed with return code 7

G:\USB\libusb_winusb\libhidwin32\libhid-0.2.16\libhid\Debugtest
 NOTICE_PRINT: hid_init(): libhid 0.2.16.0.0 is being initialized.
  TRACE_PRINT: hid_init(): initialising USB subsystem...
  TRACE_PRINT: hid_init(): scanning for USB busses...
  TRACE_PRINT: hid_init(): scanning for USB devices...
 NOTICE_PRINT: hid_init(): successfully initialised HID library.
  TRACE_PRINT: hid_new_HIDInterface(): creating a new HIDInterface instance...
  TRACE_PRINT: hid_force_open(): forcefully opening a device interface according
 to matching criteria...
  TRACE_PRINT: hid_get_usb_handle(): acquiring handle for a USB device...
  TRACE_PRINT: hid_find_usb_device(): enumerating USB busses...
  TRACE_PRINT: hid_find_usb_device(): enumerating USB devices on bus bus-0...
  TRACE_PRINT: hid_find_usb_device(): inspecting USB device bus-0/\\.\libusb0-00
01--0x04d8-0...
  TRACE_PRINT: hid_compare_usb_device(): comparing match specifications to USB d
evice...
  TRACE_PRINT: hid_compare_usb_device(): inspecting vendor ID...
  TRACE_PRINT: hid_compare_usb_device(): match on vendor ID: 0x04d8.
  TRACE_PRINT: hid_compare_usb_device(): inspecting product ID...
  TRACE_PRINT: hid_compare_usb_device(): match on product ID: 0x0033.
  TRACE_PRINT: hid_compare_usb_device(): calling custom matching function...
  TRACE_PRINT: hid_compare_usb_device(): match on custom matching function.
 NOTICE_PRINT: hid_find_usb_device(): found a matching USB device bus-0/\\.\libu
sb0-0001--0x04d8-0.
  TRACE_PRINT: hid_force_open(): claiming USB device bus-0/\\.\libusb0-0001--0x0
4d8-0.
WARNING_PRINT: hid_os_force_claim(): code not tested on the Darwin platform!
  TRACE_PRINT: hid_os_force_claim(): claiming USB device bus-0/\\.\libusb0-0001-
-0x04d8-0...
WARNING_PRINT: hid_os_force_claim(): failed to claim USB device bus-0/\\.\libusb
0-0001--0x04d8-0...
 NOTICE_PRINT: hid_force_open(): successfully claimed USB device bus-0/\\.\libus
b0-0001--0x04d8-0.
  TRACE_PRINT: hid_init_parser(): initialising the HID parser for USB Device bus
-0/\\.\libusb0-0001

Re: [libhid-discuss] Correct Library?

[Xiaofan Chen]

On Fri, May 23, 2008 at 10:52 PM, Charles Lepple [EMAIL PROTECTED] wrote:

 Ideally this would work like this:

 * application asks libhid for a list of HID devices
 ** libhid asks [ libusb | Windows HID API ] for a list of HID devices

I think this is the ideal way and should be the way forward.
Actually libusb-win32 1.0 will add HID backend and WinUSB
backedn so that it wraps native HID API and WinUSB API
to libusb-win32 API. However it is not working yet and the
svn version has not been updated for quite some time (9 months).
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/

 Also, there was some discussion on the libusb-win32 list about making
 libhid compile under Windows. I don't have a working Windows
 development environment where I can test this, but I understand that
 there was a bit of global search-and-replace in libhid to get things
 to compile. I haven't had the time to find the minimal set of changes
 necessary, though.

Rob Krakora has a version of libhid for Win32 using libusb-win32.
I think it can only serve as a temporary solution. It is much better
to use native HID API under Windows (or Mac OS X) for libhid.

Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss

Re: [libhid-discuss] How to use libhid-detach-device to detach kernel hid driver for a composite device

[Xiaofan Chen]

On Sat, Oct 25, 2008 at 3:13 AM, Charles Lepple [EMAIL PROTECTED] wrote:
 On Oct 24, 2008, at 11:41 AM, Xiaofan Chen wrote:

 Reference:
 http://forum.microchip.com/tm.aspx?m=364987

 The signal-to-noise ratio of that thread is pretty low. What are we looking
 at?

Post 14, 19 and 20 in the thread.


 I have a keyboard which posts as a USB composite device. To dump
 the hid report descriptor under Linux, I need to detach the kernel hid
 driver
 in order to use lsusb -vvv to dump the HID report descriptor. Somehow
 libhid-detach-device can only detach the first interface (interface 0).

 Is it possible to patch it to be able to detach other interfaces?
 I am not a real programmer though...

 See
 http://libhid.alioth.debian.org/doc/hid__opening_8c.html#1ca48853ebe890459271bdb99b8aaac6

 The second parameter to hid_force_open() is the interface number.


So we can patch the file libhid-detach-device to have one more parameter
to do the job. Thanks for the hints.
http://libhid.alioth.debian.org/doc/libhid-detach-device_8c-source.html#l00011

Regards,
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss

Re: [libhid-discuss] error sending control message

[Xiaofan Chen]

On Wed, Feb 4, 2009 at 9:44 AM, Charles Lepple clep...@ghz.cc wrote:
 On Feb 3, 2009, at 3:25 PM, Brent Bushnell wrote:

 For what it's worth, we're having the same issue with a magnetic
 stripe reader from ID Innovations.Of special interest also, is
 that the report descriptors are unavailable.

 Apologies if you've been down this road already, but lsusb won't be
 able to see the report descriptors unless you have detached the
 kernel's usbhid driver from the interface(s). This is done
 automatically in usb_force_open(), and only stays in effect until you
 unplug the device. There is also a libhid-detach-device program in
 libhid*/src/ that will do just that.


I believe libhid-detach-device only detaches the first interface.

Here is a better method by Alan Stern.
http://www.nabble.com/How-to-dump-HID-report-descriptor-under-Linux-td19609562.html

Regards,
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Does libhid require a driver installation on windows?

[Xiaofan Chen]

On Wed, Mar 11, 2009 at 4:51 PM, Gabriel Rossetti
gabriel.rosse...@arimaz.com wrote:

 On 4/11/07, Stephan Meyer wrote:
/  On 4/10/07, Xiaofan wrote:
 //  The thing is that you need to uninstall the kernel HID driver and
 //  use the libusb-win32 device driver for this kind of HID device. This
 //  significantly reduces the usability of libusb-win32 for HID device
 //  under Windows. Yet many USB device disguise them as HID device
 //  just to avoid writing a device driver.
 // 
 //  Just wondering if it is possible to use an alternative backend
 //  (Windows HID apli) and make libusb a wrapper on top of it.
 //  I understand then it should perhaps be called libhid-win32 then.
 //
 // This sounds like a great idea! I'll add a native HID backend to the
 // next version of the DLL. It should be possible to implement most of
 // libusb's features on top of Windows' hid.dll such as open, close,
 // interrupt-read/write and basic control messages. The rest can be
 // emulated/simulated.
 /

 (http://lists.alioth.debian.org/pipermail/libhid-discuss/2007-April/000136.html)

 I searched both libhid's and libusb's websites and I found nothing
 concerning this, does anyone know what the current status is? Does a
 driver have to be installed to use libhid on windows? Also, what is the
 difference/advantage with using libhid in comparison with directly using
 libusb's hid support?

You can try out the SVN version of libsub-win32 1.0. Last time
I tried it out, it has the HID backend (along with WinUSB backend
and the libusb-win32 device driver backend). It could find the device,
but interrupt read/write did not work.

The SVN version:
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb1/

It seems to me that this has not been updated for a while. So I guess
it is still not working. But Stephan mentioned that he would try to
finish this with this year.

libhid is right now based on libusb.

Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Talking to an HID device from user account in Linux

[Xiaofan Chen]

2009/3/31 Ali Asad asad@gemalto.com:
 As I understand it, the use of libhid requires root access in order to
 read-write from the device, right? This is how I have tested my application.
 Is there another way to talk to the HID device so that root access is not
 required? If so what would I need to do from my application, and more
 importantly, what would the end-user have to do on their Linux machines in
 order to run this application? I am targeting the Ubuntu distribution.


You need to use udev rules.
Ubuntu is quite consistent in terms of udev rules.
http://piklab.wiki.sourceforge.net/USB+Port+Problems

Regards,
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] problems with libhid and Oregon Scientific weather station WMRS203 (interrupt read)

[Xiaofan Chen]

On Tue, Jul 28, 2009 at 1:42 PM, Jordi
Puigsegurjordi.puigse...@gmail.com wrote:
 I am trying to use libhid to acces a Oregon Scientific weather station
 (model WMRS200). It is recognised as a hid device.
 Using code similar to test_hid.c and with ideas borrowed from the following
 web page:  Linux Oregon Scientific WMR100 I am able to force open it, but
 cannot read the information from the interrupt...

 What am I doing wrong? The system is a Ubuntu Jaunty. If there is any other
 information I can provide, please let me know.

Google found the following and maybe they can help.
1) Oregon WMR200 Driver (Under Dev.), using libusb 0.1.12
http://www.sdic.ch/innovation/contributions

2) You can also try this thread
http://www.weather-watch.com/smf/index.php?topic=28307.msg226828
http://www.weather-display.com/downloadfiles/WeatherDlinux.zip


-- 
Xiaofan http://mcuee.blogspot.com

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Misunderstanding input and output paths

[Xiaofan Chen]

I will probably start with something simpler and
to understand the various concept of HID device,
Input/Output/Feature report and report IDs.

In the first glance, the device has multiple
report IDs. You can use Control Transfer
to set and get various reports. You can also
use Interrupt transfer for the Input/Output report.

The Windows program can of course help.

For a simpler HID device and how to use
libusb to control it, you can refer to the following
links.

Jan Axelson's generic HID firmware and Host
software and my simple libsub based program to drive
it under Linux/Windows/BSDs.
http://www.lvr.com/hidpage.htm
http://www.microchip.com/forums/tm.aspx?m=340898

I've added report ID support to the firmware and
have the corresponding libusb-1.0 based host software.
(tested under Linux, Windows and FreeBSD 8).
http://code.google.com/p/picusb/downloads/list
http://picusb.googlecode.com/files/Firmware_generic_hid.zip
http://picusb.googlecode.com/files/libusb1_lvrhid8.c

If you can, get Jan Axelson's USB Complete book
and have some good understand about USB and HID.



-- 
Xiaofan http://mcuee.blogspot.com

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] retrieving large HID descriptor bytes

[Xiaofan Chen]

On Wed, Jun 16, 2010 at 1:34 AM, stone mike vrspace1...@yahoo.com.tw wrote:
  Report Descriptors:
    ** UNAVAILABLE **

What if you do not use libhid, but use the vanilla usbutils (lsusb -vvv)?
You need to detach the kernel HID driver first. To do that, you
can use libhid-detach-device.

--
Xiaofan http://mcuee.blogspot.com

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] retrieving large HID descriptor bytes

[Xiaofan Chen]

On Thu, Jun 17, 2010 at 9:39 AM, mike stone vrspace1...@yahoo.com.tw wrote:
 What if you do not use libhid, but use the vanilla usbutils (lsusb -vvv)?
 You need to detach the kernel HID driver first. To do that, you
 can use libhid-detach-device.

     Thanks,  lsusb can get Report Descriptors, libhid-detach-device has a ...
 hid_force_open failed with return code 16 message.

That is not a real problem. Probably the kernel driver is already
detached. So lsusb is indeed okay.

As for your original problem, maybe you can try Charles' suggestion.
I am not familiar with the inner working of libhid myself.

-- 
Xiaofan http://mcuee.blogspot.com

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] HID vs. vendor specific class

[Xiaofan Chen]

On Thu, Jul 22, 2010 at 10:51 AM, John Parsons jfpars...@fastmail.fm wrote:

 The product is a proximity sensor, and is built around a Microchip
 PIC18F14K50, their low cost 20-pin device with USB connection.  Though
 this device is not exactly human interactive, I initially planned to
 release this as a HID because it only transfers a few bytes of data, HID
 routines are included in Microchip's example code libraries, all OS's
 come with HID drivers, and it seems very simple to implement, at least
 on Windows.

I have mixed feeling with HID, I like HID. But I also agree with Peter
Stuge that at current situation, generic HID may not be a very good
solution for cross-platform application.

With libusb-1.0 Windows backend, HID device can be used with
libusb-1.0 API. Linux is also okay since you have the capability to
detach the kernel driver. The only main issue is with Mac OS X.
You need to write a codeless kext to prevent the kernel from
claim the HID device.

So I have created an feature request for libusb-1.0 Mac OS X HID backend.
http://www.libusb.org/ticket/33

If that is done, I think generic HID device will be good for most
applications require cross-OS support. Okay, here I only mention
the three major OS in the market. But FreeBSD 8.0+ will also be
good since they have libusb-1.0 compatible API which seems to
work for generic HID device as well.

BTW, despite the name libhid, I think libhid is not really meant
for generic HID device. Its strong point is the HID report parser.
For generic HID device, you do not really need libhid, rather generic
libusb-1.0 will be easier.

 But I want Mac and Linux app writers to be able to use this product with
 the same ease as Windows app writers.  Peter Stuge makes a strong case
 for vendor-specific class devices.  I am willing to go that route, but
 could use some help getting started.  Pointers to resources would be
 appreciated... something like USB vendor specific classes for dummies!

It is very easy to convert an HID based generic device to a vendor specific
device on the firmware side. Basically you just need to modify the descriptor to
remove the HID class specific descriptor, and you have a vendor specific device.

On the host side, the HID IN/OUT report can normally be converted to
interrupt in/out transfer. The HID feature report can easily be converted
to generic control transfer. If you use libusb, it is not that difficult.


-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] HID vs. vendor specific class

[Xiaofan Chen]

On Thu, Jul 22, 2010 at 1:32 PM, Xiaofan Chen xiaof...@gmail.com wrote:
 BTW, despite the name libhid, I think libhid is not really meant
 for generic HID device. Its strong point is the HID report parser.
 For generic HID device, you do not really need libhid, rather generic
 libusb-1.0 will be easier.

Another potential solution for cross-platform HID API. The Linux
support is based on hidraw which is quite new under Linux and
seems still not as mature. But the Windows and Mac codes are
based on native HID API. So this could be a good alternative
to libhid and libusb for generic HID device.
http://github.com/signal11/hidapi


-- 
Xiaofan http://sourceforge.net/projects/libusb-win32/

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Multiple duplicate interfaces?

[Xiaofan Chen]

On Mon, Oct 4, 2010 at 3:09 AM, Peter Stuge pe...@stuge.se wrote:
 I haven't tried HIDAPI that Peter mentioned, but it sounds like it
 might offer a more portable solution.

 Indeed. With libusb there is still the matter of kernel drivers. The
 Windows support in libusb-1.0 tries to fake it on top of the HID API
 but I don't really think that's a good approach.

 HIDAPI on the other hand is tailored specifically for HID, on Win
 Mac Linux, works *with* the kernel drivers instead of against them,
 is simpler (less generic) than libusb, and I think the best solution
 for byte level communication with HID class devices.


HIDAPI under Windows and Mac OS X are using the native
HID API. Theoretically it should work with USB HID device and
Bluethooth HID device.

Under Linux, the default is to use libusb-1.0 (USB only). But
it can also be used with hidraw kernel driver. The hidraw kernel
driver backend for HIDAPI is only for very recent kernel version
and the hidraw driver may still need some further work. The good
thing about it is that it works with Bluetooth HID device.

Combining the HIDAPI and the libhid HID parser may be
an interesting work. If the GPL license of the HID parser
is a problem for some users, then another more liberal
license of HID parser needs to be written.



-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] HIDAPI license (was Re: unable to include hid.h in C++)

[Xiaofan Chen]

On Sat, Oct 30, 2010 at 7:53 AM, Charles Lepple clep...@ghz.cc wrote:

 http://github.com/signal11/hidapi/blob/master/LICENSE.txt mentions
 GPL as an option.


HIDAPI can be used under one of three licenses, which is very liberal.

1. The GNU Public License, version 3.0, in LICENSE-gpl3.txt
2. A BSD-Style License, in LICENSE-bsd.txt.
3. The more liberal original HIDAPI license. LICENSE-orig.txt


-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

[libhid-discuss] libhid 0.2.16 Windows Port Download

[Xiaofan Chen]

I just dug out the libhid 0.2.16 Windows port from Rob Krakora
just in case some people in this list is interested.
The original zip file is for VS2005. I also provide the zip
file with updated 2008 projects.

http://code.google.com/p/picusb/downloads/list

I have not really did much tests so YMMV.

-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Inconsistency while reading data from the usb device

[Xiaofan Chen]

On Fri, Dec 10, 2010 at 1:48 AM, shiva vadla shiva...@gmail.com wrote:
 Just a guess, what if you reset the hid interface before closing
 the interface?


 Thanks for the response. I have just tried that, but I still see the same
 issue. Any suggestions?


Sorry I have no idea. Maybe you want to ask in the Linux usb mailing
list cause I do not think this is a libhid/libusb issue, but rather a
usb device issue. They will probably ask you to provide the
usbmon log or things like that.


--
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] libhid + swig - c#

[Xiaofan Chen]

On Sun, Apr 10, 2011 at 6:56 AM, Charles Lepple clep...@ghz.cc wrote:
 On Apr 8, 2011, at 1:25 PM, Rudolf Muehlbauer wrote:
 I am wondering what the current status of libhid is. Is it still
 maintained, used? The last svn commit was back in 2008.

 I have been recommending that people consider HIDAPI instead. It seems to be
 much better at the cross-platform goal than libhid, since libusb isn't
 always the best solution. (On the other hand, I haven't tried HIDAPI myself.
 Maybe someone else on the list has.)

I tried HIDAPI a bit and it is quite good. On the other hand, it does
not have enough bindings and the packaging of it is not that great.
It has great potentials though.
http://www.signal11.us/oss/hidapi/

 I am interested to use it in a project written with Mono/C#. Is it much
 of a hassle to generate the C# bindings?

 It would certainly be a to me, since I don't know C#. If you have used SWIG
 before, I imagine it would not be that difficult. I suspect the biggest
 hurdle would be wrapping libusb for use in C#.

Travis Robinson (current developers of libusb-win32) is also the developer
of libusbdotnet, a great C# bindings for libusb. It works under Linux
and Mac OS X with Mono, but only with libusb-1.0. For Windows, it
works with libusb-1.0, WinUSB and libusb-win32.
http://libusbdotnet.sourceforge.net/V2/Index.html

 Actually, if you don't need the hidparser library (i.e. you know the report
 structures), there is not much to libhid. Look at the source for the
 functions which you would use - they are mostly error-checking.



-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

[libhid-discuss] Invitation to connect on LinkedIn

[Xiaofan Chen]

LinkedIn




   
I'd like to add you to my professional network on LinkedIn.

- Xiaofan

Xiaofan Chen
Staff Engineer at Rockwell Automation 
Singapore

Confirm that you know Xiaofan Chen
https://www.linkedin.com/e/v4w2a4-gr1w3ws4-1t/isd/3781282545/wp8Mspsk/


 
-- 
(c) 2011, LinkedIn Corporation___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Invitation to connect on LinkedIn

[Xiaofan Chen]

On Sun, Aug 7, 2011 at 6:49 PM, Xiaofan Chen xiaof...@gmail.com wrote:

 LinkedIn

 I'd like to add you to my professional network on LinkedIn.

Please ignore this. I accidentally click a yes... Sorry!


--
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] USB libhid is writing to PIC but errors out reading from it.

[Xiaofan Chen]

On Mon, Nov 14, 2011 at 6:46 PM, Daniel Yount facto...@yahoo.com wrote:
 Using Linux 3.x kernel and debian 6.0 stable distro.

 USB flash program 1.3
 http://code.google.com/p/mphidflash/

 libhid 0.2.16

 I have installed a Generic HID bootloader  and a basic p18F2455 circuit
 setup for reading and writing USB data.
 20mhz crystal no LEDs one jumper for bootloader mode and a switch for
 reset., nothing special.

If you download the latest Microchip USB stack, there is an HIDAPI
based cross-platform HID bootloader, you may want to try that one,
it works for me whereas mphidflash did not seem to work for me
(PIC18F87J50 USB PIM) last time I tried it.


-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Trying to repair a program using libhid to configure an Ultimarc Joystick

[Xiaofan Chen]

On Wed, Mar 25, 2015 at 11:43 AM, Andrew Silverman
andre...@microsoft.com wrote:
 I’m having some trouble understanding how to set up the
 destination bits correctly for requesttype/request – When I looked at the
 USB 2 spec tables that describe these, they just don’t seem to correspond in
 a sensible way to the values the original author was using, and so I’m a bit
 lost.


Ref: Ch7 of the HID spec should be good for you.
http://www.usb.org/developers/hidpage/HID1_11.pdf

Some cheat codes for you, from Linux USB developer
Alan Stern. It might help you to translate HID report
read/write to control IN/OUT transfer.

Standard device requests

RQtype Req Value Index Length
--
  0 1 dev-feat 0 0 Clear device feature
  0 3 dev-feat 0 0 Set device feature
  0 5 address 0 0 Set device address
  0 9 config-value 0 0 Set configuration
  1 b altsetting intf 0 Set interface
  1 1 intf-feat intf 0 Clear interface feature
  1 3 intf-feat intf 0 Set interface feature
  2 1 ep-feat ep 0 Clear endpoint feature
  2 3 ep-feat ep 0 Set endpoint feature
 80 0 0 0 2 Get device status
 80 6 descr-type/ 0/ len Get descriptor
index lang-ID
 80 8 0 0 1 Get configuration
 81 0 0 intf 2 Get interface status
 81 a 0 intf 1 Get interface (altsetting)
 82 0 0 ep 2 Get endpoint status

Device features: 0 = self-powered, 1 = remote wakeup
Interface features: None
Endpoint features: 0 = halt
Descriptor types: 1 = device, 2 = config, 3 = string, (4 = interface,
5 = endpoint), 6 = device qualifier, 7 = other-speed config

HID class requests

RQtype Req Value Index Length
--
 21 9 report-type/ID intf len Set report
 21 a duration/ID intf 0 Set idle
 21 b proto intf 0 Set protocol
 81 6 descr-type/set intf len Get class descriptor
 a1 1 report-type/ID intf len Get report
 a1 2 0/ID intf 1 Get idle
 a1 3 0 intf 1 Get protocol

Report type: 1 = input, 2 = output, 3 = feature
Descriptor type: 21 = HID, 22 = Report, 23 = Physical
Protocol: 0 = boot, 1 = report

-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Trying to repair a program using libhid to configure an Ultimarc Joystick

[Xiaofan Chen]

On Wed, Mar 25, 2015 at 12:12 PM, Andrew Silverman
andre...@microsoft.com wrote:
 What I don't really understand is the 0x43/0xC3 bytes for requesttype
 and the E9/EA/EB values in request. (Assuming that I am correctly 
 understanding
 those param mappings in the existing calls to usb_control_msg, anyway.)
 I can't seem to find anything in the description of USB control messages that
 makes those values make sense.

The requests from 0x40 to 0x43 (and 0x80 to 0x83) are specifically defined
as vendor messages, where the vendor can assign any meaning they want.

So you have to carry out reverse engineering to try to understand.

Ref: USB 2.0 Specification Chapter 9.
http://www.usb.org/developers/docs/usb20_docs/


9.3 USB Device Requests

All USB devices respond to requests from the host on the device’s Default
Control Pipe. These requests are made using control transfers. The request
and the request’s parameters are sent to the device in the Setup packet.
The host is responsible for establishing the values passed in the fields
listed in Table 9-2. EverySetup packet has eight bytes.

Table 9-2. Format of Setup Data

Offset: 0
Field: bmRequestType
Size: 1
Value: Bitmap

Characteristics of request:
D7: Data transfer direction
0 = Host-to-device
1 = Device-to-host
D6...5: Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
D4...0: Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4...31 = Reserved


-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Re: [libhid-discuss] Can libhid be used to create a "virtual" Bluetooth device?

[Xiaofan Chen]

On Thu, Feb 9, 2017 at 3:48 AM, Chip Wachob  wrote:
> Hello,
>
> Very new to Linux and USB/BT.
>
> I have an interest in making a PC running Linux (specifically Ubuntu 16.04
> LTS) appear to be a BT device which other BT-enabled devices can pair with.
> I am most interested in having the PC appear to be a BT-enabled keyboard and
> transmit keypresses on the keyboard to the paired device.
>
> The PC has a USB BT dongle which I would use to accomplish this task.
>
> Is this something that can be done using libhid?
>
> If so, could you point me towards example code?

I am quite sure libhid can not do that.

> If not, is there another library that would be better suited for my task?

No idea. I believe this will be a difficult task. You may want to
ask in the linux-bluetooth mailing list.

http://vger.kernel.org/vger-lists.html#linux-bluetooth

> Thank you in advance for your time,


-- 
Xiaofan

___
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/