linux-kernel - Re: HID device calibration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 8 Aug 2012 11:45:30 +0000 (UTC)
From:	Tigran <tigran.avanesov@....lu>
To:	linux-kernel@...r.kernel.org
Subject: Re: HID device calibration - how to override mapping?



Enrico Mattea <ocirne94 <at> gmail.com> writes:

> 
> Hi el es, thank you for your answer.
> 
> Il 13/01/2012 18:09, el es ha scritto:
> >
> > released - halfway - pressed
> > 0 - (-32767)<->  (32767) - 0
> > but does it happen in reverse order when releasing pedal ?
> 
> Yes, it does - perfect reverse order.
> > seems the interpretation of this is up to the application really,
> > but /if/ the -32767 to 32767 change happens all around the 'halfway'
> > spot, maybe it is (in the app. engine) interpreted as 'change'
> > and it's effect applied to 'car engine' not directly, but integrated
> > (time-integral function applied) first ?
> I don't think that the change is interpreted, because the clutch value 
> seems to be computed directly, i.e. applying the app. calibration value 
> on the the axis value received from the kernel;
> even if I'm not completely familiar with the app.'s code, the attached 
> code snippet is the interested part of the clutch handler of the app, 
> and it doesn't seem to have any other function applied.
> > I'd say, for the clutch simulation it's the /change-in-time/ that
> > matters, not the /exact/ value; so no 'static' calibration is
> > ever going to be relevant (bar maybe the device telling us when the
> > pedal is fully pressed or fully released - in case app is not tracking
> > it)
> I agree, but trying to calibrate the axis produces the 'jump' effect 
> also on the clutch value, so that either the first half of the axis 
> isn't taken into account, or it produces full clutch already at halfway, 
> and then value 0 after the halfway spot.
> 
> Thank you for your support,
> Ocirne
> 
> Attachment (clutch.cpp): text/x-c++src, 431 bytes

Hi, 

Do you try to make work your pedal with torcs or speed dreams?
Looks like yes... 
I had the same issue with fanatec porche 911 gt2.

I contacted HID driver maintainer, but since for now we don't have a proper
solution (i.e. fixing HID driver), I had to do a dirty thing in the source code.

Replace the fragment you attached in drivers/human/human.cpp with

        switch (cmd[CMD_CLUTCH].type) {
                case GFCTRL_TYPE_JOY_AXIS:
                        clutch = joyInfo->ax[cmd[CMD_CLUTCH].val];

                        // dirty stuff, sorry
                        if (clutch  <= 0) clutch = -clutch;
                        else clutch = 2.0 - clutch;
                        clutch /= 2.0;
                        car->_clutchCmd = fabs(cmd[CMD_CLUTCH].pow *
                                                pow(fabs(clutch),
                                                1.0f / cmd[CMD_CLUTCH].sens));
                        break;

and it should work... without calibration

Regards,
Tigran


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/