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] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Oct 2015 12:00:50 +0100
From:	Olivier Scherler <oscherler@...ink.ch>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Michele Baldessari <michele@...syn.org>, linux-usb@...r.kernel.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

Hi,

> On 24 oct. 2015, at 22:11, Jiri Kosina <jikos@...nel.org> wrote:
> 
> On Sat, 24 Oct 2015, Michele Baldessari wrote:
> 
>> The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
>> to have the two distinct joysticks working.
>> 
>> Before the change:
>> $ jstest /dev/input/js0
>> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
>> ...
>> $ jstest /dev/input/js1
>> jstest: No such file or directory
>> 
>> After the change:
>> $ jstest /dev/input/js0
>> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
>> ...
>> $ jstest /dev/input/js1
>> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
>> ...
>> 
>> Signed-off-by: Michele Baldessari <michele@...syn.org>
> 
> Adding Oliver to CC.
> 
> Oliver, how come that you didn't need this while working on the inigial 
> Xin-Mo Dual Arcade support?

Because I didn’t mind whether the controller announced itself as two joysticks with two axes each, or one joystick with four axes. In the software I use it for (a MAME for the Raspberry Pi), I can map a single device’s buttons and axes to several players.

I’m a bit surprised with this, though:

> $ jstest /dev/input/js0
> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)

because in my case I had four axes, at least using evtest (I don’t remember if I tried jstest as well).

What bothered me at the time, though, is that even though the custom driver was made as a kernel module, an entry had to be added in the hid_have_special_driver table in hid-core.c for the kernel to use it, which means, if I understand properly, that the kernel still needs recompiling. Is that normal?

Best regards,
Olivier

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ