Avoid hidraw usage?

[GoogleCodeExporter]

Is there any way to change the code of the library to avoid hidraw usage? My 
device is running on old version of linux (2.6.22), where hidraw is not 
supported.

Original issue reported on code.google.com by and7ey@gmail.com on 8 Sep 2011 at 7:50

[GoogleCodeExporter]

ok, found the way at hidapi/README

Original comment by and7ey@gmail.com on 11 Sep 2011 at 3:27

[GoogleCodeExporter]

i am having the same issue. I am running 2.6.16. I couldnt find anything in 
hipapi/README to avoid hidraw usage. Can you help me?

Original comment by srkrish...@gmail.com on 21 Sep 2011 at 12:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Correct path is cpp/hidapi/linux/README.TXT

Try to change hid.c to hid-libusb.c in the main Makefile (cpp/build/linux).

Which device you are trying to compile that for?

Original comment by and7ey@gmail.com on 21 Sep 2011 at 3:01

[GoogleCodeExporter]

Linux 2.6.16 is over *six* years old.  Even if we were to fix the library to 
avoid hid usage, which is entirely possible, this is an ancient kernel.  Please 
use a modern system.

Original comment by pnau...@gmail.com on 21 Sep 2011 at 3:49

[GoogleCodeExporter]

In some cases this is not possible, unfortunately.
My router's firmware uses this old version of linux since new version doesn't 
work with WiFi driver and sources of that driver are closed. 

Original comment by and7ey@gmail.com on 21 Sep 2011 at 3:58

[GoogleCodeExporter]

You are trying to have it both ways.  If you use old vendor-supplied firmware, 
you are going to have problems.  I can say that from multiple first-hand 
experience.  Asking the openzwave developers to support your ancient system is 
a bit silly.

So, you have a couple of choices:

* Use a modern embedded distro (e.g, OpenWrt)
* Use better hardware with a fully open system
* Update openzwave yourself to not required support of those modern parts, and 
send some patches.  But you are likely to run into other issues still.

If you really need to do the last option, it should be a simple matter of 
#ifdefs and makefile flags.

Original comment by pet...@candicontrols.com on 21 Sep 2011 at 7:03

[GoogleCodeExporter]

and7ey did you ever get this sorted out? I'm trying to get open-zwave running 
on an ASUS RT-N16 with DD-WRT running kernel 2.6.24.111.

Original comment by calebesk...@gmail.com on 14 Jan 2013 at 6:38

[GoogleCodeExporter]

calebeskurdal, unfortunately, no. I had to use z-connector instead.

Original comment by and7ey@gmail.com on 15 Jan 2013 at 4:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello all,
I am having some troubles with the way hidController.cpp is implemented.

First thing the vendorId and productId are hard coded for a specific controller 
from a specific vendor if you want to use usblib with another product  from a 
different vendor then you have to modify the reference provided in 
hidcontroller.cpp file.

Logically those vendorId productId should come from a list of recognized 
controller and compared with listed device returned by udev.

Then the hid means Human Input Device ! normally usb device attached to hidraw 
are keyboard mouse, drawing tablets etc.. in short what allows the use to 
interact with a computer. 
So why should a z-wave modem static controller be identified by udev as a 
device that would be depending on HID and attached to hidraw?

For instance udev on my arch linux (lastest kernel /udev from 1 day ago update) 
the Z-Wave controller I use is referenced as a Communicator device type not as 
a Human Interface Device device type. So it is attached to the usb tree and not 
to the hid tree in udev.

I agree that having this usbcontroller is a great thing, but it should be more 
flexible and allow auto detection of hardware like it is intended to do.

Original comment by shada...@gmail.com on 27 Feb 2015 at 6:23

[GoogleCodeExporter]

The HIDController code is for Controllers that implement the HID instead of 
Serial interface. There were several older controllers that do this, but I've 
not seen any recent controllers use it. 

It defaults to the only HID controller that was released (TrickleStar) but is 
modifiable via the ManagerAPI Class, so its not "Hardcoded" just defaulted. 

Since you controller is using the Communication class then use the Serial API. 
Your assumptions about its capabilities are incorrect. :)

If you are using a USB controller that emulates the Serial interface 
(/dev/ttyUSB* etc) then you should be using the Serial Interface instead (the 
default).

Original comment by jus...@dynam.ac on 2 Mar 2015 at 1:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Justin thank you for your reply.
The goal of HId interface in openzwave is more clear now.

Ofcourse ideally I would like to get the openzwave library talking to udev to 
auto detect the zwave controller and retrieve the port that the library should 
use. 

but it s alot of work for something that will eventually work.

 While letting the user seek and provide the communication port to use in openzwave library will always work.

Original comment by shada...@gmail.com on 2 Mar 2015 at 3:50

[GoogleCodeExporter]

No need to get so complicated. Just create a udev rule that maps your 
Controller to a static device node. (/dev/zwave for example)

Something like this:

ACTION=="remove", GOTO="zwave_controller"
SUBSYSTEM=="usb-serial" ATTRS{idVendor}=="XXXX" ATTRS{idProduct}=="XXXX" 
SYMLINK+="zwave" 
LABEL="zwave_controller"

You probably have to modify the ATTRS entries to match your ZWave Controller, 
or add different attributes, but the concept is the same. 

Original comment by jus...@dynam.ac on 3 Mar 2015 at 2:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi justin, I ended doing exactly this. if my symlink udev port doesn t exists 
and the udev rule file doesn t exists then I create it with the proper idVendor 
and idProduct match for my zwave controller.

you can retreive idVendor and idProduct with udevadm info -a -n /dev/ttyUSB0 | 
grep idProduct or idVendor. 

Thank you again.

Original comment by shada...@gmail.com on 12 Mar 2015 at 3:46