On Thu, 8 Sep 2011 10:05:10 -0400 David Michael <fedora.dm0@xxxxxxxxx> wrote: > Hi, > > On Wed, Sep 7, 2011 at 2:48 PM, <simon@xxxxxxxxxxxxx> wrote: > > Are you sure that the dead zone is being applied in the device itself, and > > not by the '/dev/input/js0' system? > > Sorry if I wasn't clear; it is /dev/input/jsX that loses data. > Reading /dev/hidrawX gives results across the entire 0x000-0x3FF range > as I would expect. > > I had actually been reading /dev/hidrawX to get at this data without > issue until a few weeks ago when support was added to /dev/input/jsX. > This dead zone became apparent in my applications immediately after I > tried to switch. > Long delay to look at that, sorry. I verified the input event system was OK too with: $ evtest /dev/input/event7 | egrep 'code (59|60|61)' All values up to 1023 are received. > > You could also try to completely disable the 'dead zone' on the joystick > > sub-system. > > Are you referring to the JSIOCSCORR ioctl operation here? Perhaps I > could use this directly in my applications to ensure the > accelerometers' values are more precise whenever they are run. I > still think too much information is lost with the default setting and > new js_corr values should be considered for these axes, but the ioctl > call should solve the issue in my case. > So David, did you solve this way? I read in Documentation/input/joystick-api.txt that JSIOCSCORR should not be used in a normal programs, only in calibration software. Then I tried jstest-gtk and I was able to get all the values via the joystick device too setting minimum and maximum values respectively to 0 and 1023. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
Attachment:
pgpm9WaOWtPfV.pgp
Description: PGP signature
