Re: Question re hiddev

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel