Re: linux kernel HID problem with Saitek X52 Pro Flight System

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

[ 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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Stefan Bader]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Tim Cole]

[-- 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 --]

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Stefan Bader]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Tim Cole]

[-- 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 --]

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Anssi Hannula]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Stefan Bader]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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.

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Stefan Bader]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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.

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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.

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Dmitry Torokhov]

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

Re: linux kernel HID problem with Saitek X52 Pro Flight System

[Jiri Kosina]

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