On Saturday 10 March 2007, Jiri Kosina wrote: >On Thu, 8 Mar 2007, Gene Heskett wrote: >> 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. > >Hi Gene, > >first, sorry for replying with some delay, it took some time until I > have hit your message in my mail backlog. >(btw your private message to me bounced because you have combined the > two addressess of mine - two possibilities are [EMAIL PROTECTED] or >[EMAIL PROTECTED], there is no [EMAIL PROTECTED] :) ). > I started with the address David gave me, sorry.
>> 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. > >Do I understand it correctly that the upsd you have is trying to issue >some insane ioctl() calls on the hiddev interface, and when it naturally >fails, it keeps retrying forever? Until there are 1024 opens showing in an lsof output. >> 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? > >So these broken programs think that while talking to hiddev device, they >are in fact receiving data from serial port, right? I believe that to be the case, this code is very old and moldy. >Actually it would be quite nasty (but not impossible) to put such tweaks >into the hiddev code - wouldn't it be easier to patch these applications >to simply not issue the braindamaged ioctl()s to hiddev? Or you don't > have access to source code of these? Its proprietary code, supplied by Belkin, either on their web page, or on the cd that comes with it. No src's available, but I am beating on their tech support on a daily basis, but I'm not getting through to anybody who can do a 2*2 and get 4. The answers I'm getting seem to indicate they are only getting 3, even for very large values of 2. :) Their last reply said my 3 week old unit had been out of warranty since 2002, and my reply was in that case my card will reject the charge by Monday afternoon latest. AKA they are being jerks. And never once has the software I've been squawking about been acknowledged in the reply. But I'm gonna play duck here, and nibble them to death. There is a rather huge case statement in hiddev.c. Is it possible to expand this even further so that these illegal ioctls are acked with a return 0, making this old moldy code happy in thinking its talking to a uart based serial port when it tries to set the baud rates and such? Thanks Jiri. -- 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) Celebrate Hannibal Day this year. Take an elephant to lunch. ------------------------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
