Re: [linux-usb-devel] Question re hiddev

Re: [linux-usb-devel] Question re hiddev

[Gene Heskett]

On Friday 09 March 2007, Adam Kropelin wrote:
>Gene Heskett wrote:
>> On Thursday 08 March 2007, Gene Heskett wrote:
>>> Greetings;
>>>
>>> Belkin is being non-responsive to requests for updated drivers for
>>> their line of UPS's, all of which now have a USB port which is the
>>> Belkin recommended way to talk to these things.
>>>
>>> Unforch, the belkin supplied *nix stuff was last compiled on an rh5.2
>>> machine using gcc-2.7.2, so there has been some bitrot.
>>>
>>> I believe the problem to be that when their version of upsd is
>>> trying to open the /dev/name its given, it is assuming and hard
>>> coded to do the ioctl's to set the ports speed in baudrate, width of
>>> word, parity etc.
>>>
>>> Getting failure messages for that, it retrys the open until it has
>>> 1024 links to /dev/hiddev0 according to an lsof|grep hiddev0, all of
>>> which presumably have failed so it never actually opens the
>>> /dev/hiddev0 port in r/w mode successfully.
>>>
>>> I can, from a shell, 'cat' the data from this port, its not very fast
>>> taking about 8-10 seconds to output all the integers or bytes to
>>> constitute a complete screen update when translated by the gui into
>>> sensible data.
>>>
>>> My proposal, and I'll see if I can make a patch, is to add to the
>>> hiddev.c code, stubs for these otherwise useless functions that do
>>> nothing but return a 0 indicating success so that these legacy
>>> drivers can make use of a port whose data is just fine but fails
>>> these configuration things that don't mean squat to hiddev anyway.
>>>
>>> Would this effort at making legacy drivers who think they are
>>> using /dev/ttySx, work with /dev/hiddev constitute an acceptable
>>> reason for such a patch to hiddev.c?
>>
>> Its been about a day now, and no one has commented.  Am I an idiot or
>> ??
>
>I think you fundamentally misunderstand hiddev. It's an interface to HID
>devices, which are not (NOT!) byte streams of the sort you'd get on
>/dev/ttySx. hiddev speaks in specific structures via read/write/ioctl as
>detailed in Documentation/usb/hiddev.txt. Any application which is
>making tty ioctls to set baud rate, etc. will never work (unmodified)
>with hiddev.
>
>Your Belkin UPS may follow the USB HID class spec for Power Devices, in
>which case a suite like NUT will be able to handle it with their
>USB-generic driver.
>
>--Adam

I *think* I had the nut daemon working a couple of days ago, it at least 
ran without getting a tummy ache and upchucking into the logs.  But as 
for using that data usefully, nuts docs might as well be written in 
swahili.  It also doesn't seem to have a gui like the belkin programs 
give.  Or I don't know how to set it up to use a gui.  Either is a strong 
possibility...

If anyone else has it working, please speak up.  The ups is a Belkin 
F6C-1500, with some more adjectives appended that have nothing to do with 
the electronics in it.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
UPS interrupted the server's power

Re: Question re hiddev

[Jiri Kosina]

On Tue, 13 Mar 2007, Robert Marquardt wrote:

> > as there are many Bluetooth devices with conform to HID specification
> Namely the Wii controller which is already happily used by many programmers
> through Windows HID API.

Hi Robert,

not only this piece of hardware, but many others - for example almost all 
Bluetooth keyboards and mice are capable of working both in HID and HCI 
modes, etc. The layer introduced in 2.6.20 gives them the possibility of 
using full reporting facilities of the HID layer.

> > There are still pending issues though, one of them being converting 
> > the HID layer to bus, so that individual device that don't wish the 
> > certain device to be handled by generic HID code, register on this HID 
> > bus and handle the HID events from given device in a unified way (for 
> > example current Wacom driver would use this facility, among other). As 
> > a bonus, this is going to shrink the hid_blacklist, which currently 
> > has to contain all devices for which there are specialized drivers.
> Ah, this means our iowarrior driver will be shortlived.

I don't think so. Firstly, it will take some time until the HID layer is 
converted to bus, as I have another things pending. Secondly, the 
iowarrior driver will still be needed to handle the HW-specific reports 
that won't be handled by the generic HID layer, it would only have to be 
changed to register through the HID bus.

> Do you know the Windows HID API? It would be nice to take it into 
> account so that a compatible API can be written. 

No, I don't know Windows HID api at all. Is it worth looking at?

> Mainly this needs a way to add a ReportID of 0x00 to reports from 
> devices without ReportIDs and access to the HID descriptor so the usages 
> can be extracted from a report.

Just a sidenote - this is in fact what I am currently implementing also 
for the new hidraw userspace interface.

Thanks,

-- 
Jiri Kosina