Re: [PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-26 Thread Ioan-Adrian Ratiu
Hi

On Mon, 26 Sep 2016, Benjamin Tissoires  wrote:
> Thanks for the patch series. I am not against it, but I'd rather see the
> commit message of this one amended, and the second patch changed.

Sorry if I came out too aggresive (I'll amend), I'm just annoyed that I
had to spend a weekend night digging through this crap because my fiancee
came crying to me that her gamepad stopped working after a kernel update.

>
> On Sep 26 2016 or thereabouts, Ioan-Adrian Ratiu wrote:
>> This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
>> because the "fix" is bogus. That report descriptor is different in
>
> I am pretty sure this "fix" works for many. You seem to have a different
> hardware (generation probably) that makes the "fix" to fail for you.
> The issue is more that the manufacturer doesn't bother to reallocate a
> new PID for the new device when they change something in it, so please
> don't blame the author of the fix (which I am not).

We don't actually know that it's a new generation of hardware without a
new PID and I really doubt manufacturers are *that* stupid, they should
at least have increased the device revision number, but... China.

>
>> hardware (see below) and it's the way the hardware works, it can't be
>
> Well, it's kind of hard to compare the lsusb output to the fixup in the
> kernel. I'd like to know what changed, but I can't...
>
>> fixed at this level because it reuses axes by design.
>
> It can be fixed in hid-dr. See my comments on the next patch.

Thanks, I'll try to add an input mapping in the driver. However if
indeed there are different hardware with the same PID and this "fix" is
for another issue than the one I'm having then I'd really rather not
revert this if possible to not break other people's hardware. But I also
can't keep it because it breaks my hardware.

Does anyone have any suggestions what to do in this case?

>
>> 
>> What this change tried to fix is a regression caused by commit 20aef664f139
>
> As mentioned in your next patch in the series, the correct commit id is
> 79346d620e9de87912de73337f6df8b7f9a46888

Thanks, this was a slip-up on my part.

>
>> ("HID: input: force generic axis to be mapped to their user space axis") by
>> working around the problem and trying to change the report descriptor in
>> hid-dr, which obviously can't work and introduces more breakage because it
>> adds another unnecessary layer of multiplexing/indirection, making the
>> dragonrise gamepad practically unusable in userspace.
>
> Not sure who you are blaming here. Is it me (the author of 79346d620e or
> the author of the fix in hid-dr)? If it's me, I agree, the patch was a
> little too aggressive, though I must say only one hardware maker has
> such a crappy device that we need to care of. So this is why I just let
> the patch in place without trying to have a better solution.
>
> If the blame is on the author of the hid-dr, I must say that I find the
> tone of this paragraph quite aggressive for nothing. Your device is
> different than the one that was used for the original fix, so it breaks.
> But I can guarantee you that the fix works for the intended device (I
> happen to have one I tested recently). So please blame the hardware
> maker, not the people involved in the community who are doing their
> best.

I'm not assigning blame because it's counterproductive. Of course, I
agree if we are to find a scapegoat it's the crappy manufacturers
because they make the crappy hardware with crappy or no Linux support
(btw I am in no way affiliated with dragonrise or any other vendor).

The only thing that annoys me is that this known hid-input kernel
regression has been ignored for all this time, leaving users like me
dead in the watter with a broken driver upon kernel update.

>
>> 
>> This needs to be fixed where the regression was initially introduced in
>> hid-input (the next patch does this).
>
> Actually, again, I tend to disagree :)
> I'll go more in details in the next patch.
>
> Cheers,
> Benjamin
>
>> 
>> Here's the descriptor taken directly from the device via lsusb:
>> HID Device Descriptor:
>>   bLength 9
>>   bDescriptorType33
>>   bcdHID   1.10
>>   bCountryCode   33 US
>>   bNumDescriptors 1
>>   bDescriptorType34 Report
>>   wDescriptorLength 101
>>   Report Descriptor: (length is 101)
>> Item(Global): Usage Page, data= [ 0x01 ] 1
>> Generic Desktop Controls
>> Item(Local ): Usage, data= [ 0x04 ] 4
>> Joystick
>> Item(Main  ): Collection, data= [ 0x01 ] 1
>> Application
>> Item(Main  ): Collection, data= [ 0x02 ] 2
>> Logical
>> Item(Global): Report Size, data= [ 0x08 ] 8
>> Item(Global): Report Count, data= [ 0x05 

Re: [PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-26 Thread Ioan-Adrian Ratiu
Hi

On Mon, 26 Sep 2016, Benjamin Tissoires  wrote:
> Thanks for the patch series. I am not against it, but I'd rather see the
> commit message of this one amended, and the second patch changed.

Sorry if I came out too aggresive (I'll amend), I'm just annoyed that I
had to spend a weekend night digging through this crap because my fiancee
came crying to me that her gamepad stopped working after a kernel update.

>
> On Sep 26 2016 or thereabouts, Ioan-Adrian Ratiu wrote:
>> This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
>> because the "fix" is bogus. That report descriptor is different in
>
> I am pretty sure this "fix" works for many. You seem to have a different
> hardware (generation probably) that makes the "fix" to fail for you.
> The issue is more that the manufacturer doesn't bother to reallocate a
> new PID for the new device when they change something in it, so please
> don't blame the author of the fix (which I am not).

We don't actually know that it's a new generation of hardware without a
new PID and I really doubt manufacturers are *that* stupid, they should
at least have increased the device revision number, but... China.

>
>> hardware (see below) and it's the way the hardware works, it can't be
>
> Well, it's kind of hard to compare the lsusb output to the fixup in the
> kernel. I'd like to know what changed, but I can't...
>
>> fixed at this level because it reuses axes by design.
>
> It can be fixed in hid-dr. See my comments on the next patch.

Thanks, I'll try to add an input mapping in the driver. However if
indeed there are different hardware with the same PID and this "fix" is
for another issue than the one I'm having then I'd really rather not
revert this if possible to not break other people's hardware. But I also
can't keep it because it breaks my hardware.

Does anyone have any suggestions what to do in this case?

>
>> 
>> What this change tried to fix is a regression caused by commit 20aef664f139
>
> As mentioned in your next patch in the series, the correct commit id is
> 79346d620e9de87912de73337f6df8b7f9a46888

Thanks, this was a slip-up on my part.

>
>> ("HID: input: force generic axis to be mapped to their user space axis") by
>> working around the problem and trying to change the report descriptor in
>> hid-dr, which obviously can't work and introduces more breakage because it
>> adds another unnecessary layer of multiplexing/indirection, making the
>> dragonrise gamepad practically unusable in userspace.
>
> Not sure who you are blaming here. Is it me (the author of 79346d620e or
> the author of the fix in hid-dr)? If it's me, I agree, the patch was a
> little too aggressive, though I must say only one hardware maker has
> such a crappy device that we need to care of. So this is why I just let
> the patch in place without trying to have a better solution.
>
> If the blame is on the author of the hid-dr, I must say that I find the
> tone of this paragraph quite aggressive for nothing. Your device is
> different than the one that was used for the original fix, so it breaks.
> But I can guarantee you that the fix works for the intended device (I
> happen to have one I tested recently). So please blame the hardware
> maker, not the people involved in the community who are doing their
> best.

I'm not assigning blame because it's counterproductive. Of course, I
agree if we are to find a scapegoat it's the crappy manufacturers
because they make the crappy hardware with crappy or no Linux support
(btw I am in no way affiliated with dragonrise or any other vendor).

The only thing that annoys me is that this known hid-input kernel
regression has been ignored for all this time, leaving users like me
dead in the watter with a broken driver upon kernel update.

>
>> 
>> This needs to be fixed where the regression was initially introduced in
>> hid-input (the next patch does this).
>
> Actually, again, I tend to disagree :)
> I'll go more in details in the next patch.
>
> Cheers,
> Benjamin
>
>> 
>> Here's the descriptor taken directly from the device via lsusb:
>> HID Device Descriptor:
>>   bLength 9
>>   bDescriptorType33
>>   bcdHID   1.10
>>   bCountryCode   33 US
>>   bNumDescriptors 1
>>   bDescriptorType34 Report
>>   wDescriptorLength 101
>>   Report Descriptor: (length is 101)
>> Item(Global): Usage Page, data= [ 0x01 ] 1
>> Generic Desktop Controls
>> Item(Local ): Usage, data= [ 0x04 ] 4
>> Joystick
>> Item(Main  ): Collection, data= [ 0x01 ] 1
>> Application
>> Item(Main  ): Collection, data= [ 0x02 ] 2
>> Logical
>> Item(Global): Report Size, data= [ 0x08 ] 8
>> Item(Global): Report Count, data= [ 0x05 ] 5
>> 

Re: [PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-26 Thread Benjamin Tissoires
Thanks for the patch series. I am not against it, but I'd rather see the
commit message of this one amended, and the second patch changed.

On Sep 26 2016 or thereabouts, Ioan-Adrian Ratiu wrote:
> This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
> because the "fix" is bogus. That report descriptor is different in

I am pretty sure this "fix" works for many. You seem to have a different
hardware (generation probably) that makes the "fix" to fail for you.
The issue is more that the manufacturer doesn't bother to reallocate a
new PID for the new device when they change something in it, so please
don't blame the author of the fix (which I am not).

> hardware (see below) and it's the way the hardware works, it can't be

Well, it's kind of hard to compare the lsusb output to the fixup in the
kernel. I'd like to know what changed, but I can't...

> fixed at this level because it reuses axes by design.

It can be fixed in hid-dr. See my comments on the next patch.

> 
> What this change tried to fix is a regression caused by commit 20aef664f139

As mentioned in your next patch in the series, the correct commit id is
79346d620e9de87912de73337f6df8b7f9a46888

> ("HID: input: force generic axis to be mapped to their user space axis") by
> working around the problem and trying to change the report descriptor in
> hid-dr, which obviously can't work and introduces more breakage because it
> adds another unnecessary layer of multiplexing/indirection, making the
> dragonrise gamepad practically unusable in userspace.

Not sure who you are blaming here. Is it me (the author of 79346d620e or
the author of the fix in hid-dr)? If it's me, I agree, the patch was a
little too aggressive, though I must say only one hardware maker has
such a crappy device that we need to care of. So this is why I just let
the patch in place without trying to have a better solution.

If the blame is on the author of the hid-dr, I must say that I find the
tone of this paragraph quite aggressive for nothing. Your device is
different than the one that was used for the original fix, so it breaks.
But I can guarantee you that the fix works for the intended device (I
happen to have one I tested recently). So please blame the hardware
maker, not the people involved in the community who are doing their
best.

> 
> This needs to be fixed where the regression was initially introduced in
> hid-input (the next patch does this).

Actually, again, I tend to disagree :)
I'll go more in details in the next patch.

Cheers,
Benjamin

> 
> Here's the descriptor taken directly from the device via lsusb:
> HID Device Descriptor:
>   bLength 9
>   bDescriptorType33
>   bcdHID   1.10
>   bCountryCode   33 US
>   bNumDescriptors 1
>   bDescriptorType34 Report
>   wDescriptorLength 101
>   Report Descriptor: (length is 101)
> Item(Global): Usage Page, data= [ 0x01 ] 1
> Generic Desktop Controls
> Item(Local ): Usage, data= [ 0x04 ] 4
> Joystick
> Item(Main  ): Collection, data= [ 0x01 ] 1
> Application
> Item(Main  ): Collection, data= [ 0x02 ] 2
> Logical
> Item(Global): Report Size, data= [ 0x08 ] 8
> Item(Global): Report Count, data= [ 0x05 ] 5
> Item(Global): Logical Minimum, data= [ 0x00 ] 0
> Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
> Item(Global): Physical Minimum, data= [ 0x00 ] 0
> Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
> Item(Local ): Usage, data= [ 0x30 ] 48
> Direction-X
> Item(Local ): Usage, data= [ 0x31 ] 49
> Direction-Y
> Item(Local ): Usage, data= [ 0x32 ] 50
> Direction-Z
> Item(Local ): Usage, data= [ 0x32 ] 50
> Direction-Z
> Item(Local ): Usage, data= [ 0x35 ] 53
> Rotate-Z
> Item(Main  ): Input, data= [ 0x02 ] 2
> Data Variable Absolute No_Wrap Linear
> Preferred_State No_Null_Position Non_Volatile 
> Bitfield
> Item(Global): Report Size, data= [ 0x04 ] 4
> Item(Global): Report Count, data= [ 0x01 ] 1
> Item(Global): Logical Maximum, data= [ 0x07 ] 7
> Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
> Item(Global): Unit, data= [ 0x14 ] 20
> System: English Rotation, Unit: Degrees
> Item(Local ): Usage, data= [ 0x39 ] 57
> Hat Switch
> Item(Main  ): Input, data= [ 0x42 ] 66
> Data Variable Absolute 

Re: [PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-26 Thread Benjamin Tissoires
Thanks for the patch series. I am not against it, but I'd rather see the
commit message of this one amended, and the second patch changed.

On Sep 26 2016 or thereabouts, Ioan-Adrian Ratiu wrote:
> This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
> because the "fix" is bogus. That report descriptor is different in

I am pretty sure this "fix" works for many. You seem to have a different
hardware (generation probably) that makes the "fix" to fail for you.
The issue is more that the manufacturer doesn't bother to reallocate a
new PID for the new device when they change something in it, so please
don't blame the author of the fix (which I am not).

> hardware (see below) and it's the way the hardware works, it can't be

Well, it's kind of hard to compare the lsusb output to the fixup in the
kernel. I'd like to know what changed, but I can't...

> fixed at this level because it reuses axes by design.

It can be fixed in hid-dr. See my comments on the next patch.

> 
> What this change tried to fix is a regression caused by commit 20aef664f139

As mentioned in your next patch in the series, the correct commit id is
79346d620e9de87912de73337f6df8b7f9a46888

> ("HID: input: force generic axis to be mapped to their user space axis") by
> working around the problem and trying to change the report descriptor in
> hid-dr, which obviously can't work and introduces more breakage because it
> adds another unnecessary layer of multiplexing/indirection, making the
> dragonrise gamepad practically unusable in userspace.

Not sure who you are blaming here. Is it me (the author of 79346d620e or
the author of the fix in hid-dr)? If it's me, I agree, the patch was a
little too aggressive, though I must say only one hardware maker has
such a crappy device that we need to care of. So this is why I just let
the patch in place without trying to have a better solution.

If the blame is on the author of the hid-dr, I must say that I find the
tone of this paragraph quite aggressive for nothing. Your device is
different than the one that was used for the original fix, so it breaks.
But I can guarantee you that the fix works for the intended device (I
happen to have one I tested recently). So please blame the hardware
maker, not the people involved in the community who are doing their
best.

> 
> This needs to be fixed where the regression was initially introduced in
> hid-input (the next patch does this).

Actually, again, I tend to disagree :)
I'll go more in details in the next patch.

Cheers,
Benjamin

> 
> Here's the descriptor taken directly from the device via lsusb:
> HID Device Descriptor:
>   bLength 9
>   bDescriptorType33
>   bcdHID   1.10
>   bCountryCode   33 US
>   bNumDescriptors 1
>   bDescriptorType34 Report
>   wDescriptorLength 101
>   Report Descriptor: (length is 101)
> Item(Global): Usage Page, data= [ 0x01 ] 1
> Generic Desktop Controls
> Item(Local ): Usage, data= [ 0x04 ] 4
> Joystick
> Item(Main  ): Collection, data= [ 0x01 ] 1
> Application
> Item(Main  ): Collection, data= [ 0x02 ] 2
> Logical
> Item(Global): Report Size, data= [ 0x08 ] 8
> Item(Global): Report Count, data= [ 0x05 ] 5
> Item(Global): Logical Minimum, data= [ 0x00 ] 0
> Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
> Item(Global): Physical Minimum, data= [ 0x00 ] 0
> Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
> Item(Local ): Usage, data= [ 0x30 ] 48
> Direction-X
> Item(Local ): Usage, data= [ 0x31 ] 49
> Direction-Y
> Item(Local ): Usage, data= [ 0x32 ] 50
> Direction-Z
> Item(Local ): Usage, data= [ 0x32 ] 50
> Direction-Z
> Item(Local ): Usage, data= [ 0x35 ] 53
> Rotate-Z
> Item(Main  ): Input, data= [ 0x02 ] 2
> Data Variable Absolute No_Wrap Linear
> Preferred_State No_Null_Position Non_Volatile 
> Bitfield
> Item(Global): Report Size, data= [ 0x04 ] 4
> Item(Global): Report Count, data= [ 0x01 ] 1
> Item(Global): Logical Maximum, data= [ 0x07 ] 7
> Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
> Item(Global): Unit, data= [ 0x14 ] 20
> System: English Rotation, Unit: Degrees
> Item(Local ): Usage, data= [ 0x39 ] 57
> Hat Switch
> Item(Main  ): Input, data= [ 0x42 ] 66
> Data Variable Absolute 

[PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-25 Thread Ioan-Adrian Ratiu
This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
because the "fix" is bogus. That report descriptor is different in
hardware (see below) and it's the way the hardware works, it can't be
fixed at this level because it reuses axes by design.

What this change tried to fix is a regression caused by commit 20aef664f139
("HID: input: force generic axis to be mapped to their user space axis") by
working around the problem and trying to change the report descriptor in
hid-dr, which obviously can't work and introduces more breakage because it
adds another unnecessary layer of multiplexing/indirection, making the
dragonrise gamepad practically unusable in userspace.

This needs to be fixed where the regression was initially introduced in
hid-input (the next patch does this).

Here's the descriptor taken directly from the device via lsusb:
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 101
  Report Descriptor: (length is 101)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x04 ] 4
Joystick
Item(Main  ): Collection, data= [ 0x01 ] 1
Application
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x05 ] 5
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x35 ] 53
Rotate-Z
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Report Size, data= [ 0x04 ] 4
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Global): Logical Maximum, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
Item(Global): Unit, data= [ 0x14 ] 20
System: English Rotation, Unit: Degrees
Item(Local ): Usage, data= [ 0x39 ] 57
Hat Switch
Item(Main  ): Input, data= [ 0x42 ] 66
Data Variable Absolute No_Wrap Linear
Preferred_State Null_State Non_Volatile Bitfield
Item(Global): Unit, data= [ 0x00 ] 0
System: None, Unit: (None)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x0c ] 12
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Global): Usage Page, data= [ 0x09 ] 9
Buttons
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
Button 1 (Primary)
Item(Local ): Usage Maximum, data= [ 0x0c ] 12
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Main  ): End Collection, data=none
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 

[PATCH 1/2] Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"

2016-09-25 Thread Ioan-Adrian Ratiu
This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...")
because the "fix" is bogus. That report descriptor is different in
hardware (see below) and it's the way the hardware works, it can't be
fixed at this level because it reuses axes by design.

What this change tried to fix is a regression caused by commit 20aef664f139
("HID: input: force generic axis to be mapped to their user space axis") by
working around the problem and trying to change the report descriptor in
hid-dr, which obviously can't work and introduces more breakage because it
adds another unnecessary layer of multiplexing/indirection, making the
dragonrise gamepad practically unusable in userspace.

This needs to be fixed where the regression was initially introduced in
hid-input (the next patch does this).

Here's the descriptor taken directly from the device via lsusb:
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode   33 US
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 101
  Report Descriptor: (length is 101)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x04 ] 4
Joystick
Item(Main  ): Collection, data= [ 0x01 ] 1
Application
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x05 ] 5
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x32 ] 50
Direction-Z
Item(Local ): Usage, data= [ 0x35 ] 53
Rotate-Z
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Report Size, data= [ 0x04 ] 4
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Global): Logical Maximum, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [ 0x3b 0x01 ] 315
Item(Global): Unit, data= [ 0x14 ] 20
System: English Rotation, Unit: Degrees
Item(Local ): Usage, data= [ 0x39 ] 57
Hat Switch
Item(Main  ): Input, data= [ 0x42 ] 66
Data Variable Absolute No_Wrap Linear
Preferred_State Null_State Non_Volatile Bitfield
Item(Global): Unit, data= [ 0x00 ] 0
System: None, Unit: (None)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x0c ] 12
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Global): Usage Page, data= [ 0x09 ] 9
Buttons
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
Button 1 (Primary)
Item(Local ): Usage Maximum, data= [ 0x0c ] 12
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
(null)
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Physical Maximum, data= [ 0x01 ] 1
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main  ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile 
Bitfield
Item(Main  ): End Collection, data=none
Item(Main  ): Collection, data= [ 0x02 ] 2
Logical
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x07 ] 7
Item(Global): Physical Maximum, data= [