Re: [RFC] [BUG?] Sixaxis Value Ranges

On Thu, 8 Sep 2011 10:05:10 -0400
David Michael [off-list ref] wrote:

Hi,

On Wed, Sep 7, 2011 at 2:48 PM,  [off-list ref] wrote:

quoted

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.

quoted

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?