* Re: linux kernel HID problem with Saitek X52 Pro Flight System
[not found] ` <bfb1bb1f0909071047h1a4cbc3dx175f89ecedc3555d@mail.gmail.com>
@ 2009-09-08 17:42 ` Jiri Kosina
2009-09-08 17:58 ` Dmitry Torokhov
[not found] ` <bfb1bb1f0909081304y708b037bw1c82288d6457c254@mail.gmail.com>
0 siblings, 2 replies; 22+ messages in thread
From: Jiri Kosina @ 2009-09-08 17:42 UTC (permalink / raw)
To: Sergey Kolesnikov, linux-input, Dmitry Torokhov, Tim Cole, Tim Gardner
[ added some CCs
In short -- Sergey has problem with his joystick not being properly
handled starting with 2.6.30 kernel (it used to work with 2.6.29 and
older). The problem is that joydev is not created. ]
On Mon, 7 Sep 2009, Sergey Kolesnikov wrote:
> Here goes /proc/bus/input/devices dump (VID/PID included):
>
> I: Bus=0003 Vendor=06a3 Product=0762 Version=0111
> N: Name="Saitek Saitek X52 Pro Flight Control System"
> P: Phys=usb-0000:00:1d.7-6.3/input0
> S: Sysfs=/devices/pci0000:00/0000:00:1d.7/usb7/7-6/7-6.3/7-6.3:1.0/input/input10
> U: Uniq=
> H: Handlers=event6
> B: EV=1b
> B: KEY=7f ffffffff00000000 0 0 0 0
> B: ABS=3000003007f
> B: MSC=10
If I got my math right, this means that the KEY bitmask includes digitizer
BTN_DIGI/BTN_TOOL_PEN, right?
Sergey, I believe that reverting commit d07a9cba6b (you can do so using
git revert d07a9cba6b) will fix your joystick, is that correct?
> This could be compared to device successfully identified as joystick:
>
> I: Bus=0003 Vendor=06a3 Product=5f0d Version=0110
> N: Name="Saitek PLC Saitek P2600 Rumble Force Pad"
> P: Phys=usb-0000:00:1d.7-6.4/input0
> S: Sysfs=/devices/pci0000:00/0000:00:1d.7/usb7/7-6/7-6.4/7-6.4:1.0/input/input11
> U: Uniq=
> H: Handlers=js0 event7
> B: EV=1b
> B: KEY=fff00000000 0 0 0 0
> B: ABS=300c3
> B: MSC=10
Yup, this device doesn't have BTN_DIGI in its keymask, so it's not
blacklisted by joydev_blacklist[] entry.
It will be also interesting to obtain HID debugging output (*) from the
time the device gets plugged in, so that we can check why is mapping of
BTN_DIGI established and to check whether it makes any sense. What kind of
joystick is that?
(*) configure the kernel with CONFIG_HID_DEBUG set, modprobe the 'hid'
device with 'debug=2' parameter, plug the device in, and send the dmesg
output.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-09-08 17:42 ` linux kernel HID problem with Saitek X52 Pro Flight System Jiri Kosina
@ 2009-09-08 17:58 ` Dmitry Torokhov
2009-09-08 18:02 ` Jiri Kosina
[not found] ` <bfb1bb1f0909081304y708b037bw1c82288d6457c254@mail.gmail.com>
1 sibling, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-09-08 17:58 UTC (permalink / raw)
To: Jiri Kosina
Cc: Sergey Kolesnikov, linux-input, Tim Cole, Tim Gardner,
Amit Kucheria, Stefan Bader
On Tue, Sep 08, 2009 at 07:42:02PM +0200, Jiri Kosina wrote:
>
> [ added some CCs
>
> In short -- Sergey has problem with his joystick not being properly
> handled starting with 2.6.30 kernel (it used to work with 2.6.29 and
> older). The problem is that joydev is not created. ]
>
>
> On Mon, 7 Sep 2009, Sergey Kolesnikov wrote:
>
> > Here goes /proc/bus/input/devices dump (VID/PID included):
> >
> > I: Bus=0003 Vendor=06a3 Product=0762 Version=0111
> > N: Name="Saitek Saitek X52 Pro Flight Control System"
> > P: Phys=usb-0000:00:1d.7-6.3/input0
> > S: Sysfs=/devices/pci0000:00/0000:00:1d.7/usb7/7-6/7-6.3/7-6.3:1.0/input/input10
> > U: Uniq=
> > H: Handlers=event6
> > B: EV=1b
> > B: KEY=7f ffffffff00000000 0 0 0 0
I find it doubtful that the device actually has 39 buttons...
> > B: ABS=3000003007f
> > B: MSC=10
>
> If I got my math right, this means that the KEY bitmask includes digitizer
> BTN_DIGI/BTN_TOOL_PEN, right?
>
> Sergey, I believe that reverting commit d07a9cba6b (you can do so using
> git revert d07a9cba6b) will fix your joystick, is that correct?
While this will get Sergey's joystick back I think that HID should be
more careful in assigning the BTN_* events. Right now it starts at a
certain type and goes forward without checking if range (joystick,
gamepad, etc) is exhausted or not.
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-09-08 17:58 ` Dmitry Torokhov
@ 2009-09-08 18:02 ` Jiri Kosina
0 siblings, 0 replies; 22+ messages in thread
From: Jiri Kosina @ 2009-09-08 18:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Sergey Kolesnikov, linux-input, Tim Cole, Tim Gardner,
Amit Kucheria, Stefan Bader
On Tue, 8 Sep 2009, Dmitry Torokhov wrote:
> > > Here goes /proc/bus/input/devices dump (VID/PID included):
> > >
> > > I: Bus=0003 Vendor=06a3 Product=0762 Version=0111
> > > N: Name="Saitek Saitek X52 Pro Flight Control System"
> > > P: Phys=usb-0000:00:1d.7-6.3/input0
> > > S: Sysfs=/devices/pci0000:00/0000:00:1d.7/usb7/7-6/7-6.3/7-6.3:1.0/input/input10
> > > U: Uniq=
> > > H: Handlers=event6
> > > B: EV=1b
> > > B: KEY=7f ffffffff00000000 0 0 0 0
>
> I find it doubtful that the device actually has 39 buttons...
Yup, a little bit strange :) That's why I asked Sergey to provide more
details about the device.
> > > B: ABS=3000003007f
> > > B: MSC=10
> >
> > If I got my math right, this means that the KEY bitmask includes digitizer
> > BTN_DIGI/BTN_TOOL_PEN, right?
> >
> > Sergey, I believe that reverting commit d07a9cba6b (you can do so using
> > git revert d07a9cba6b) will fix your joystick, is that correct?
>
> While this will get Sergey's joystick back I think that HID should be
> more careful in assigning the BTN_* events. Right now it starts at a
> certain type and goes forward without checking if range (joystick,
> gamepad, etc) is exhausted or not.
Let's see the Min/Max values from the HID report descriptor Sergey will
hopefully provide.
This was mainly heads-up, that there is hardware out there which is
affected by this patch.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
[not found] ` <bfb1bb1f0909081304y708b037bw1c82288d6457c254@mail.gmail.com>
@ 2009-09-08 20:49 ` Dmitry Torokhov
2009-09-08 22:43 ` Jiri Kosina
1 sibling, 0 replies; 22+ messages in thread
From: Dmitry Torokhov @ 2009-09-08 20:49 UTC (permalink / raw)
To: Sergey Kolesnikov
Cc: Jiri Kosina, linux-input, Tim Cole, Tim Gardner, Amit Kucheria,
Stefan Bader
On Wed, Sep 09, 2009 at 12:04:44AM +0400, Sergey Kolesnikov wrote:
> 2009/9/8 Jiri Kosina <jkosina@suse.cz>
>
> >
> > Sergey, I believe that reverting commit d07a9cba6b (you can do so using
> > git revert d07a9cba6b) will fix your joystick, is that correct?
> >
> >
> Yes, reverting this commit helps.
> I've tried jstest and succeeded to change the state of each available
> button/axis.
>
> May be there is another way to distinguish between such joysticks and
> digitizers?
>
No, Saitek should not used digitizer's buttons, the same way it should
not use standard keyboard keys (KEY_A, KEY_B, etc).
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
[not found] ` <bfb1bb1f0909081304y708b037bw1c82288d6457c254@mail.gmail.com>
2009-09-08 20:49 ` Dmitry Torokhov
@ 2009-09-08 22:43 ` Jiri Kosina
2009-12-10 17:31 ` Stefan Bader
1 sibling, 1 reply; 22+ messages in thread
From: Jiri Kosina @ 2009-09-08 22:43 UTC (permalink / raw)
To: Sergey Kolesnikov
Cc: linux-input, Dmitry Torokhov, Tim Cole, Tim Gardner,
Amit Kucheria, Stefan Bader
[-- Attachment #1: Type: TEXT/PLAIN, Size: 603 bytes --]
On Wed, 9 Sep 2009, Sergey Kolesnikov wrote:
> Yes, reverting this commit helps. I've tried jstest and succeeded to
> change the state of each available button/axis.
Thanks for verifying.
> May be there is another way to distinguish between such joysticks and
> digitizers?
Well, first I'll need the report descriptor dump (i.e. the HID debugging
output, see one of the previous mails), to see how the device is
presenting itself to the system. And then possibly fix the input mapping
in HID code, so that we don't infringe on mappings of different device
classes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-09-08 22:43 ` Jiri Kosina
@ 2009-12-10 17:31 ` Stefan Bader
2009-12-11 14:18 ` Tim Cole
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Bader @ 2009-12-10 17:31 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Sergey Kolesnikov, linux-input, Dmitry Torokhov, Tim Cole
Jiri Kosina wrote:
> On Wed, 9 Sep 2009, Sergey Kolesnikov wrote:
>
>> Yes, reverting this commit helps. I've tried jstest and succeeded to
>> change the state of each available button/axis.
>
> Thanks for verifying.
>
>> May be there is another way to distinguish between such joysticks and
>> digitizers?
>
> Well, first I'll need the report descriptor dump (i.e. the HID debugging
> output, see one of the previous mails), to see how the device is
> presenting itself to the system. And then possibly fix the input mapping
> in HID code, so that we don't infringe on mappings of different device
> classes.
>
I know this is quite a long time ago now, but has there be any outcome
on how to handle those joysticks?
-Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-10 17:31 ` Stefan Bader
@ 2009-12-11 14:18 ` Tim Cole
2009-12-11 14:24 ` Stefan Bader
0 siblings, 1 reply; 22+ messages in thread
From: Tim Cole @ 2009-12-11 14:18 UTC (permalink / raw)
To: Stefan Bader; +Cc: Jiri Kosina, Sergey Kolesnikov, linux-input, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Thu, 2009-12-10 at 18:31 +0100, Stefan Bader wrote:
> I know this is quite a long time ago now, but has there be any outcome
> on how to handle those joysticks?
Haven't heard anything in a while... I'm really kind of frustrated,
since this originally shook out of the attempt to fix the problem where
tablets are detected as non-functional joysticks which is a major pain
to me personally. But that evidently can't be fixed until these
joysticks report themselves properly...
-Tim
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-11 14:18 ` Tim Cole
@ 2009-12-11 14:24 ` Stefan Bader
2009-12-11 23:02 ` Tim Cole
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Bader @ 2009-12-11 14:24 UTC (permalink / raw)
To: Tim Cole; +Cc: Jiri Kosina, Sergey Kolesnikov, linux-input, Dmitry Torokhov
Tim Cole wrote:
> On Thu, 2009-12-10 at 18:31 +0100, Stefan Bader wrote:
>> I know this is quite a long time ago now, but has there be any outcome
>> on how to handle those joysticks?
>
> Haven't heard anything in a while... I'm really kind of frustrated,
> since this originally shook out of the attempt to fix the problem where
> tablets are detected as non-functional joysticks which is a major pain
> to me personally. But that evidently can't be fixed until these
> joysticks report themselves properly...
>
> -Tim
The problem moved though. For the older kernels it was the tablets that
were incorrectly detected as joysticks. But that patch of you went upstream
and now it is the one joystick model that does not work.
In our tree we reverted the patch in Jaunty, but with Karmic we have the other
behavior. So in essence, someone is always complaining. :-P
-Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-11 14:24 ` Stefan Bader
@ 2009-12-11 23:02 ` Tim Cole
2009-12-12 2:00 ` Anssi Hannula
0 siblings, 1 reply; 22+ messages in thread
From: Tim Cole @ 2009-12-11 23:02 UTC (permalink / raw)
To: Stefan Bader; +Cc: Jiri Kosina, Sergey Kolesnikov, linux-input, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Fri, 2009-12-11 at 15:24 +0100, Stefan Bader wrote:
> The problem moved though. For the older kernels it was the tablets that
> were incorrectly detected as joysticks. But that patch of you went upstream
> and now it is the one joystick model that does not work.
> In our tree we reverted the patch in Jaunty, but with Karmic we have the other
> behavior. So in essence, someone is always complaining. :-P
I know what you mean, but well -- ideally we want to converge on the
correct behavior. Otherwise we'll just keep spinning and things stay
broken.
To my view, blacklisting a joystick which (wrongly) reports itself as a
digitizer tablet is an improvement over creating broken joystick devices
for anything that reports itself as a tablet. From that position we can
fix the problem with the single device reporting the wrong device type
and then everyone can be happy.
-Tim
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-11 23:02 ` Tim Cole
@ 2009-12-12 2:00 ` Anssi Hannula
2009-12-12 4:44 ` Dmitry Torokhov
0 siblings, 1 reply; 22+ messages in thread
From: Anssi Hannula @ 2009-12-12 2:00 UTC (permalink / raw)
To: Tim Cole
Cc: Stefan Bader, Jiri Kosina, Sergey Kolesnikov, linux-input,
Dmitry Torokhov
Tim Cole wrote:
> On Fri, 2009-12-11 at 15:24 +0100, Stefan Bader wrote:
>> The problem moved though. For the older kernels it was the tablets that
>> were incorrectly detected as joysticks. But that patch of you went upstream
>> and now it is the one joystick model that does not work.
>> In our tree we reverted the patch in Jaunty, but with Karmic we have the other
>> behavior. So in essence, someone is always complaining. :-P
>
> I know what you mean, but well -- ideally we want to converge on the
> correct behavior. Otherwise we'll just keep spinning and things stay
> broken.
>
> To my view, blacklisting a joystick which (wrongly) reports itself as a
> digitizer tablet is an improvement over creating broken joystick devices
> for anything that reports itself as a tablet. From that position we can
> fix the problem with the single device reporting the wrong device type
> and then everyone can be happy.
As far as I understood, we do not yet know why the joystick gets
assigned digitizer keys, as the HID debug information requested has not
been provided. We do not know for sure what the joystick itself reports
or whether it is wrong or not.
--
Anssi Hannula
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-12 2:00 ` Anssi Hannula
@ 2009-12-12 4:44 ` Dmitry Torokhov
2009-12-14 10:31 ` Stefan Bader
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-12-12 4:44 UTC (permalink / raw)
To: Anssi Hannula
Cc: Tim Cole, Stefan Bader, Jiri Kosina, Sergey Kolesnikov, linux-input
On Sat, Dec 12, 2009 at 04:00:50AM +0200, Anssi Hannula wrote:
> Tim Cole wrote:
> > On Fri, 2009-12-11 at 15:24 +0100, Stefan Bader wrote:
> >> The problem moved though. For the older kernels it was the tablets that
> >> were incorrectly detected as joysticks. But that patch of you went upstream
> >> and now it is the one joystick model that does not work.
> >> In our tree we reverted the patch in Jaunty, but with Karmic we have the other
> >> behavior. So in essence, someone is always complaining. :-P
> >
> > I know what you mean, but well -- ideally we want to converge on the
> > correct behavior. Otherwise we'll just keep spinning and things stay
> > broken.
> >
> > To my view, blacklisting a joystick which (wrongly) reports itself as a
> > digitizer tablet is an improvement over creating broken joystick devices
> > for anything that reports itself as a tablet. From that position we can
> > fix the problem with the single device reporting the wrong device type
> > and then everyone can be happy.
>
> As far as I understood, we do not yet know why the joystick gets
> assigned digitizer keys, as the HID debug information requested has not
> been provided. We do not know for sure what the joystick itself reports
> or whether it is wrong or not.
>
Well, the thing is reported ot have 39 buttons... HID simply starts at
BTN_TRIGGER and goes form there.
39 buttons.. sheesh.. maybe we need to reclassify it as a keyboard and
be done with it ;)
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-12 4:44 ` Dmitry Torokhov
@ 2009-12-14 10:31 ` Stefan Bader
2009-12-14 17:36 ` Dmitry Torokhov
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Bader @ 2009-12-14 10:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Anssi Hannula, Tim Cole, Jiri Kosina, Sergey Kolesnikov, linux-input
Dmitry Torokhov wrote:
> On Sat, Dec 12, 2009 at 04:00:50AM +0200, Anssi Hannula wrote:
>> Tim Cole wrote:
>>> On Fri, 2009-12-11 at 15:24 +0100, Stefan Bader wrote:
>>>> The problem moved though. For the older kernels it was the tablets that
>>>> were incorrectly detected as joysticks. But that patch of you went upstream
>>>> and now it is the one joystick model that does not work.
>>>> In our tree we reverted the patch in Jaunty, but with Karmic we have the other
>>>> behavior. So in essence, someone is always complaining. :-P
>>> I know what you mean, but well -- ideally we want to converge on the
>>> correct behavior. Otherwise we'll just keep spinning and things stay
>>> broken.
>>>
>>> To my view, blacklisting a joystick which (wrongly) reports itself as a
>>> digitizer tablet is an improvement over creating broken joystick devices
>>> for anything that reports itself as a tablet. From that position we can
>>> fix the problem with the single device reporting the wrong device type
>>> and then everyone can be happy.
>> As far as I understood, we do not yet know why the joystick gets
>> assigned digitizer keys, as the HID debug information requested has not
>> been provided. We do not know for sure what the joystick itself reports
>> or whether it is wrong or not.
>>
>
> Well, the thing is reported ot have 39 buttons... HID simply starts at
> BTN_TRIGGER and goes form there.
>
> 39 buttons.. sheesh.. maybe we need to reclassify it as a keyboard and
> be done with it ;)
>
This might be an overly naive approach (or call it thinking loudly)...
It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
moved to the 0x210 region, but would it be a solution to have a block
of additional joystick buttons there and check on assigning buttons to
a joystick, whether it traverses over to GAMEPAD and in that case skip
to the additional block?
-Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-14 10:31 ` Stefan Bader
@ 2009-12-14 17:36 ` Dmitry Torokhov
2009-12-15 12:58 ` Jiri Kosina
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-12-14 17:36 UTC (permalink / raw)
To: Stefan Bader
Cc: Anssi Hannula, Tim Cole, Jiri Kosina, Sergey Kolesnikov, linux-input
On Mon, Dec 14, 2009 at 11:31:46AM +0100, Stefan Bader wrote:
> Dmitry Torokhov wrote:
> > On Sat, Dec 12, 2009 at 04:00:50AM +0200, Anssi Hannula wrote:
> >> Tim Cole wrote:
> >>> On Fri, 2009-12-11 at 15:24 +0100, Stefan Bader wrote:
> >>>> The problem moved though. For the older kernels it was the tablets that
> >>>> were incorrectly detected as joysticks. But that patch of you went upstream
> >>>> and now it is the one joystick model that does not work.
> >>>> In our tree we reverted the patch in Jaunty, but with Karmic we have the other
> >>>> behavior. So in essence, someone is always complaining. :-P
> >>> I know what you mean, but well -- ideally we want to converge on the
> >>> correct behavior. Otherwise we'll just keep spinning and things stay
> >>> broken.
> >>>
> >>> To my view, blacklisting a joystick which (wrongly) reports itself as a
> >>> digitizer tablet is an improvement over creating broken joystick devices
> >>> for anything that reports itself as a tablet. From that position we can
> >>> fix the problem with the single device reporting the wrong device type
> >>> and then everyone can be happy.
> >> As far as I understood, we do not yet know why the joystick gets
> >> assigned digitizer keys, as the HID debug information requested has not
> >> been provided. We do not know for sure what the joystick itself reports
> >> or whether it is wrong or not.
> >>
> >
> > Well, the thing is reported ot have 39 buttons... HID simply starts at
> > BTN_TRIGGER and goes form there.
> >
> > 39 buttons.. sheesh.. maybe we need to reclassify it as a keyboard and
> > be done with it ;)
> >
>
> This might be an overly naive approach (or call it thinking loudly)...
> It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
> moved to the 0x210 region, but would it be a solution to have a block
> of additional joystick buttons there and check on assigning buttons to
> a joystick, whether it traverses over to GAMEPAD and in that case skip
> to the additional block?
>
That's what we have to do I guess... I wonder how many keycodes will we
need so we won't have to split the region again? Will they come up with
70 buttons next time?
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-14 17:36 ` Dmitry Torokhov
@ 2009-12-15 12:58 ` Jiri Kosina
2009-12-15 13:17 ` Stefan Bader
0 siblings, 1 reply; 22+ messages in thread
From: Jiri Kosina @ 2009-12-15 12:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Mon, 14 Dec 2009, Dmitry Torokhov wrote:
> > This might be an overly naive approach (or call it thinking loudly)...
> > It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
> > moved to the 0x210 region, but would it be a solution to have a block
> > of additional joystick buttons there and check on assigning buttons to
> > a joystick, whether it traverses over to GAMEPAD and in that case skip
> > to the additional block?
>
> That's what we have to do I guess... I wonder how many keycodes will we
> need so we won't have to split the region again? Will they come up with
> 70 buttons next time?
Yup, I am not able to come up with anything more clever either.
I can do that easily ... any suggestions for button names? :)
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-15 12:58 ` Jiri Kosina
@ 2009-12-15 13:17 ` Stefan Bader
2009-12-17 1:29 ` Jiri Kosina
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Bader @ 2009-12-15 13:17 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
Jiri Kosina wrote:
> On Mon, 14 Dec 2009, Dmitry Torokhov wrote:
>
>>> This might be an overly naive approach (or call it thinking loudly)...
>>> It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
>>> moved to the 0x210 region, but would it be a solution to have a block
>>> of additional joystick buttons there and check on assigning buttons to
>>> a joystick, whether it traverses over to GAMEPAD and in that case skip
>>> to the additional block?
>> That's what we have to do I guess... I wonder how many keycodes will we
>> need so we won't have to split the region again? Will they come up with
>> 70 buttons next time?
>
> Yup, I am not able to come up with anything more clever either.
>
> I can do that easily ... any suggestions for button names? :)
>
#define BTN_TRIGGER_HAPPY01 0x210
...
#define BTN_TRIGGER_HAPPY40 0x238
:-P Assuming 40 additional buttons should be crazy enough (but I know
this has been said before about other things).
-Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-15 13:17 ` Stefan Bader
@ 2009-12-17 1:29 ` Jiri Kosina
2009-12-17 1:38 ` Dmitry Torokhov
0 siblings, 1 reply; 22+ messages in thread
From: Jiri Kosina @ 2009-12-17 1:29 UTC (permalink / raw)
To: Stefan Bader
Cc: Dmitry Torokhov, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Tue, 15 Dec 2009, Stefan Bader wrote:
> >>> This might be an overly naive approach (or call it thinking loudly)...
> >>> It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
> >>> moved to the 0x210 region, but would it be a solution to have a block
> >>> of additional joystick buttons there and check on assigning buttons to
> >>> a joystick, whether it traverses over to GAMEPAD and in that case skip
> >>> to the additional block?
> >> That's what we have to do I guess... I wonder how many keycodes will we
> >> need so we won't have to split the region again? Will they come up with
> >> 70 buttons next time?
> >
> > Yup, I am not able to come up with anything more clever either.
> >
> > I can do that easily ... any suggestions for button names? :)
> >
> #define BTN_TRIGGER_HAPPY01 0x210
> ...
> #define BTN_TRIGGER_HAPPY40 0x238
>
> :-P Assuming 40 additional buttons should be crazy enough (but I know
> this has been said before about other things).
Dmitry, do you have any preference here yourself?
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-17 1:29 ` Jiri Kosina
@ 2009-12-17 1:38 ` Dmitry Torokhov
2009-12-18 15:10 ` Jiri Kosina
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-12-17 1:38 UTC (permalink / raw)
To: Jiri Kosina
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Thu, Dec 17, 2009 at 02:29:55AM +0100, Jiri Kosina wrote:
> On Tue, 15 Dec 2009, Stefan Bader wrote:
>
> > >>> This might be an overly naive approach (or call it thinking loudly)...
> > >>> It would probably break a lot of stuff when the JOYSTICK/TRIGGER block
> > >>> moved to the 0x210 region, but would it be a solution to have a block
> > >>> of additional joystick buttons there and check on assigning buttons to
> > >>> a joystick, whether it traverses over to GAMEPAD and in that case skip
> > >>> to the additional block?
> > >> That's what we have to do I guess... I wonder how many keycodes will we
> > >> need so we won't have to split the region again? Will they come up with
> > >> 70 buttons next time?
> > >
> > > Yup, I am not able to come up with anything more clever either.
> > >
> > > I can do that easily ... any suggestions for button names? :)
> > >
> > #define BTN_TRIGGER_HAPPY01 0x210
> > ...
> > #define BTN_TRIGGER_HAPPY40 0x238
> >
> > :-P Assuming 40 additional buttons should be crazy enough (but I know
> > this has been said before about other things).
>
> Dmitry, do you have any preference here yourself?
>
"Trigger happy" sounds fine.
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-17 1:38 ` Dmitry Torokhov
@ 2009-12-18 15:10 ` Jiri Kosina
2009-12-18 17:49 ` Dmitry Torokhov
0 siblings, 1 reply; 22+ messages in thread
From: Jiri Kosina @ 2009-12-18 15:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Wed, 16 Dec 2009, Dmitry Torokhov wrote:
> > > #define BTN_TRIGGER_HAPPY01 0x210
> > > ...
> > > #define BTN_TRIGGER_HAPPY40 0x238
> > >
> > > :-P Assuming 40 additional buttons should be crazy enough (but I know
> > > this has been said before about other things).
> >
> > Dmitry, do you have any preference here yourself?
>
> "Trigger happy" sounds fine.
OK, so how about something along the lines below?
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: handle joysticks with large number of buttons
Current HID code doesn't properly handle HID joysticks which have
larger number of buttons than what fits into current range reserved
for BTN_JOYSTICK.
One such joystick reported to not work properly is Saitek X52 Pro
Flight System.
We can't extend the range to fit more buttons in, because of backwards
compatibility reasons.
Therefore this patch introduces a new BTN_TRIGGER_HAPPY range, and
uses these to map the buttons which are over BTN_JOYSTICK limit.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-input.c | 7 ++++++-
include/linux/input.h | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5862b0f..dad7aae 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -198,7 +198,12 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
switch (field->application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110; break;
- case HID_GD_JOYSTICK: code += 0x120; break;
+ case HID_GD_JOYSTICK:
+ if (code <= 0xf)
+ code += BTN_JOYSTICK;
+ else
+ code += BTN_TRIGGER_HAPPY;
+ break;
case HID_GD_GAMEPAD: code += 0x130; break;
default:
switch (field->physical) {
diff --git a/include/linux/input.h b/include/linux/input.h
index 7be8a65..7c54287 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -597,6 +597,48 @@ struct input_absinfo {
#define KEY_CAMERA_FOCUS 0x210
+#define BTN_TRIGGER_HAPPY 0x220
+#define BTN_TRIGGER_HAPPY1 0x220
+#define BTN_TRIGGER_HAPPY2 0x221
+#define BTN_TRIGGER_HAPPY3 0x222
+#define BTN_TRIGGER_HAPPY4 0x223
+#define BTN_TRIGGER_HAPPY5 0x224
+#define BTN_TRIGGER_HAPPY6 0x225
+#define BTN_TRIGGER_HAPPY7 0x226
+#define BTN_TRIGGER_HAPPY8 0x227
+#define BTN_TRIGGER_HAPPY9 0x228
+#define BTN_TRIGGER_HAPPY10 0x229
+#define BTN_TRIGGER_HAPPY11 0x22a
+#define BTN_TRIGGER_HAPPY12 0x22b
+#define BTN_TRIGGER_HAPPY13 0x22c
+#define BTN_TRIGGER_HAPPY14 0x22d
+#define BTN_TRIGGER_HAPPY15 0x22e
+#define BTN_TRIGGER_HAPPY16 0x22f
+#define BTN_TRIGGER_HAPPY17 0x230
+#define BTN_TRIGGER_HAPPY18 0x231
+#define BTN_TRIGGER_HAPPY19 0x232
+#define BTN_TRIGGER_HAPPY20 0x233
+#define BTN_TRIGGER_HAPPY21 0x234
+#define BTN_TRIGGER_HAPPY22 0x235
+#define BTN_TRIGGER_HAPPY23 0x236
+#define BTN_TRIGGER_HAPPY24 0x237
+#define BTN_TRIGGER_HAPPY25 0x238
+#define BTN_TRIGGER_HAPPY26 0x239
+#define BTN_TRIGGER_HAPPY27 0x23a
+#define BTN_TRIGGER_HAPPY28 0x23b
+#define BTN_TRIGGER_HAPPY29 0x23c
+#define BTN_TRIGGER_HAPPY30 0x23d
+#define BTN_TRIGGER_HAPPY31 0x23e
+#define BTN_TRIGGER_HAPPY32 0x23f
+#define BTN_TRIGGER_HAPPY33 0x240
+#define BTN_TRIGGER_HAPPY34 0x241
+#define BTN_TRIGGER_HAPPY35 0x242
+#define BTN_TRIGGER_HAPPY36 0x243
+#define BTN_TRIGGER_HAPPY37 0x244
+#define BTN_TRIGGER_HAPPY38 0x245
+#define BTN_TRIGGER_HAPPY39 0x246
+#define BTN_TRIGGER_HAPPY40 0x247
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.5.6
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-18 15:10 ` Jiri Kosina
@ 2009-12-18 17:49 ` Dmitry Torokhov
2009-12-22 13:31 ` Jiri Kosina
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-12-18 17:49 UTC (permalink / raw)
To: Jiri Kosina
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Fri, Dec 18, 2009 at 04:10:21PM +0100, Jiri Kosina wrote:
> On Wed, 16 Dec 2009, Dmitry Torokhov wrote:
>
> > > > #define BTN_TRIGGER_HAPPY01 0x210
> > > > ...
> > > > #define BTN_TRIGGER_HAPPY40 0x238
> > > >
> > > > :-P Assuming 40 additional buttons should be crazy enough (but I know
> > > > this has been said before about other things).
> > >
> > > Dmitry, do you have any preference here yourself?
> >
> > "Trigger happy" sounds fine.
>
> OK, so how about something along the lines below?
>
How about we move trigger happy further towards the 0x2ff limit?
Also, do we clamp the bit numbers at KEY_MAX? Otherwise looks good,
please push through your tree.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-18 17:49 ` Dmitry Torokhov
@ 2009-12-22 13:31 ` Jiri Kosina
2009-12-23 18:55 ` Dmitry Torokhov
0 siblings, 1 reply; 22+ messages in thread
From: Jiri Kosina @ 2009-12-22 13:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Fri, 18 Dec 2009, Dmitry Torokhov wrote:
> > > > > #define BTN_TRIGGER_HAPPY01 0x210
> > > > > ...
> > > > > #define BTN_TRIGGER_HAPPY40 0x238
> > > > >
> > > > > :-P Assuming 40 additional buttons should be crazy enough (but I know
> > > > > this has been said before about other things).
> > > >
> > > > Dmitry, do you have any preference here yourself?
> > >
> > > "Trigger happy" sounds fine.
> >
> > OK, so how about something along the lines below?
>
> How about we move trigger happy further towards the 0x2ff limit?
Sure, no problem. Just tell me the range you'd be comfortable with, and
I'll apply a patch using that range.
> Also, do we clamp the bit numbers at KEY_MAX?
Good point. I'll update all the map_*() macros in a separate patch and add
range overflow checks.
> Otherwise looks good, please push through your tree.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-22 13:31 ` Jiri Kosina
@ 2009-12-23 18:55 ` Dmitry Torokhov
2010-01-04 11:17 ` Jiri Kosina
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Torokhov @ 2009-12-23 18:55 UTC (permalink / raw)
To: Jiri Kosina
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Tue, Dec 22, 2009 at 02:31:49PM +0100, Jiri Kosina wrote:
> On Fri, 18 Dec 2009, Dmitry Torokhov wrote:
>
> > > > > > #define BTN_TRIGGER_HAPPY01 0x210
> > > > > > ...
> > > > > > #define BTN_TRIGGER_HAPPY40 0x238
> > > > > >
> > > > > > :-P Assuming 40 additional buttons should be crazy enough (but I know
> > > > > > this has been said before about other things).
> > > > >
> > > > > Dmitry, do you have any preference here yourself?
> > > >
> > > > "Trigger happy" sounds fine.
> > >
> > > OK, so how about something along the lines below?
> >
> > How about we move trigger happy further towards the 0x2ff limit?
>
> Sure, no problem. Just tell me the range you'd be comfortable with, and
> I'll apply a patch using that range.
>
How about we start with 0x2c0 - it will give us a buffer of another 20
to pad with and if that range is not enough that means we need to come
up with a new story for supporing such joysticks...
--
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: linux kernel HID problem with Saitek X52 Pro Flight System
2009-12-23 18:55 ` Dmitry Torokhov
@ 2010-01-04 11:17 ` Jiri Kosina
0 siblings, 0 replies; 22+ messages in thread
From: Jiri Kosina @ 2010-01-04 11:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stefan Bader, Anssi Hannula, Tim Cole, Sergey Kolesnikov, linux-input
On Wed, 23 Dec 2009, Dmitry Torokhov wrote:
> > > > > "Trigger happy" sounds fine.
> > > >
> > > > OK, so how about something along the lines below?
> > >
> > > How about we move trigger happy further towards the 0x2ff limit?
> >
> > Sure, no problem. Just tell me the range you'd be comfortable with, and
> > I'll apply a patch using that range.
> >
>
> How about we start with 0x2c0 - it will give us a buffer of another 20
> to pad with and if that range is not enough that means we need to come
> up with a new story for supporing such joysticks...
I have applied the patch below to my tree.
Thanks.
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: handle joysticks with large number of buttons
Current HID code doesn't properly handle HID joysticks which have
larger number of buttons than what fits into current range reserved
for BTN_JOYSTICK.
One such joystick reported to not work properly is Saitek X52 Pro
Flight System.
We can't extend the range to fit more buttons in, because of backwards
compatibility reasons.
Therefore this patch introduces a new BTN_TRIGGER_HAPPY range, and
uses these to map the buttons which are over BTN_JOYSTICK limit.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [for the input.h part]
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-input.c | 7 ++++++-
include/linux/input.h | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5862b0f..dad7aae 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -198,7 +198,12 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
switch (field->application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110; break;
- case HID_GD_JOYSTICK: code += 0x120; break;
+ case HID_GD_JOYSTICK:
+ if (code <= 0xf)
+ code += BTN_JOYSTICK;
+ else
+ code += BTN_TRIGGER_HAPPY;
+ break;
case HID_GD_GAMEPAD: code += 0x130; break;
default:
switch (field->physical) {
diff --git a/include/linux/input.h b/include/linux/input.h
index 7be8a65..7c54287 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -597,6 +597,48 @@ struct input_absinfo {
#define KEY_CAMERA_FOCUS 0x210
+#define BTN_TRIGGER_HAPPY 0x2c0
+#define BTN_TRIGGER_HAPPY1 0x2c0
+#define BTN_TRIGGER_HAPPY2 0x2c1
+#define BTN_TRIGGER_HAPPY3 0x2c2
+#define BTN_TRIGGER_HAPPY4 0x2c3
+#define BTN_TRIGGER_HAPPY5 0x2c4
+#define BTN_TRIGGER_HAPPY6 0x2c5
+#define BTN_TRIGGER_HAPPY7 0x2c6
+#define BTN_TRIGGER_HAPPY8 0x2c7
+#define BTN_TRIGGER_HAPPY9 0x2c8
+#define BTN_TRIGGER_HAPPY10 0x2c9
+#define BTN_TRIGGER_HAPPY11 0x2ca
+#define BTN_TRIGGER_HAPPY12 0x2cb
+#define BTN_TRIGGER_HAPPY13 0x2cc
+#define BTN_TRIGGER_HAPPY14 0x2cd
+#define BTN_TRIGGER_HAPPY15 0x2ce
+#define BTN_TRIGGER_HAPPY16 0x2cf
+#define BTN_TRIGGER_HAPPY17 0x2d0
+#define BTN_TRIGGER_HAPPY18 0x2d1
+#define BTN_TRIGGER_HAPPY19 0x2d2
+#define BTN_TRIGGER_HAPPY20 0x2d3
+#define BTN_TRIGGER_HAPPY21 0x2d4
+#define BTN_TRIGGER_HAPPY22 0x2d5
+#define BTN_TRIGGER_HAPPY23 0x2d6
+#define BTN_TRIGGER_HAPPY24 0x2d7
+#define BTN_TRIGGER_HAPPY25 0x2d8
+#define BTN_TRIGGER_HAPPY26 0x2d9
+#define BTN_TRIGGER_HAPPY27 0x2da
+#define BTN_TRIGGER_HAPPY28 0x2db
+#define BTN_TRIGGER_HAPPY29 0x2dc
+#define BTN_TRIGGER_HAPPY30 0x2dd
+#define BTN_TRIGGER_HAPPY31 0x2de
+#define BTN_TRIGGER_HAPPY32 0x2df
+#define BTN_TRIGGER_HAPPY33 0x2e0
+#define BTN_TRIGGER_HAPPY34 0x2e1
+#define BTN_TRIGGER_HAPPY35 0x2e2
+#define BTN_TRIGGER_HAPPY36 0x2e3
+#define BTN_TRIGGER_HAPPY37 0x2e4
+#define BTN_TRIGGER_HAPPY38 0x2e5
+#define BTN_TRIGGER_HAPPY39 0x2e6
+#define BTN_TRIGGER_HAPPY40 0x2e7
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.5.6
^ permalink raw reply related [flat|nested] 22+ messages in thread
end of thread, other threads:[~2010-01-04 11:17 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bfb1bb1f0909061357m4006a61co1c1b4dfa483b947b@mail.gmail.com>
[not found] ` <alpine.LNX.2.00.0909071731120.23856@wotan.suse.de>
[not found] ` <bfb1bb1f0909071047h1a4cbc3dx175f89ecedc3555d@mail.gmail.com>
2009-09-08 17:42 ` linux kernel HID problem with Saitek X52 Pro Flight System Jiri Kosina
2009-09-08 17:58 ` Dmitry Torokhov
2009-09-08 18:02 ` Jiri Kosina
[not found] ` <bfb1bb1f0909081304y708b037bw1c82288d6457c254@mail.gmail.com>
2009-09-08 20:49 ` Dmitry Torokhov
2009-09-08 22:43 ` Jiri Kosina
2009-12-10 17:31 ` Stefan Bader
2009-12-11 14:18 ` Tim Cole
2009-12-11 14:24 ` Stefan Bader
2009-12-11 23:02 ` Tim Cole
2009-12-12 2:00 ` Anssi Hannula
2009-12-12 4:44 ` Dmitry Torokhov
2009-12-14 10:31 ` Stefan Bader
2009-12-14 17:36 ` Dmitry Torokhov
2009-12-15 12:58 ` Jiri Kosina
2009-12-15 13:17 ` Stefan Bader
2009-12-17 1:29 ` Jiri Kosina
2009-12-17 1:38 ` Dmitry Torokhov
2009-12-18 15:10 ` Jiri Kosina
2009-12-18 17:49 ` Dmitry Torokhov
2009-12-22 13:31 ` Jiri Kosina
2009-12-23 18:55 ` Dmitry Torokhov
2010-01-04 11:17 ` Jiri Kosina
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).