Assistance in remapping keys with no scancode in kernel module

Assistance in remapping keys with no scancode in kernel module

[Marty Plummer]

[-- Attachment #1.1: Type: text/plain, Size: 2167 bytes --]

Greetings

Having recently purchased a Logitech G105 Gaming Keyboard(046d:c248) I've began
the process of reverse engineering the effects of the proprietery Logitech
Gaming Software (hereafter LGS) on the device to enable its full potential in
linux, using a number of tools (usbmon, hid-debug, virtual machines) to follow
the actions and logic used.

As of right now, I've discovered the following:
1. That the macro key remapping (either as standard keyboard keys or full macros)
   occurs in software and is not stored on the device itself (as opposed to
   other Logitech GSeries devices).

2. That keys G1-6 keys (hereafter GKeys) default to functioning as F1-6 until a
   certain set of packets are sent to it from LGS or otherwise, after which the
   F1-6 functionality ends.

3. Before the F# keys are disabled, the GKeys sends hid reports on interface 0
   identical to 'normal' F# keys and special reports on interface 1, with no
   scancode, of three bytes in size, on one hid usage, ff00.0003 (vendor defined)
   after the F# keys are disabled only the reports on interface 1 remain.

4. The M1-3 and MR keys (hereafter MKeys) send no reports on interface 0 at all,
   and reports on the same usage (ff00.0003) as the GKeys.

5. One can easily determine which GKeys and MKeys are being pressed via bitwise
   logic, as the three bytes follow a consistant pattern of:

   >03 gg mm
   where 03 is constant, gg is a value indicating the depressed GKeys (0x01 << n-1)
   AND'd together and mm is a value indicating the depressed MKeys (0x01 << n-1),
   also AND'd together, where MR is treated as M4.

6. Absolutely no standard scancode/keycode/etc is reported for these keys (as
   detectable by evtest, xev, showkeys, etc).


My current dilemma is how one is to transform this data into something usable,
as the fact they all report on the same usage there is no simple way I can find
to remap these keys.

If anyone has any insight on this matter, please assist.

Information on these reports and raw usbmon logs can be found at
https://github.com/GSeriesDev/gseries-tools/g105

	Regards,
		Marty Plummer


[-- Attachment #1.2: 0xC030918D.asc --]
[-- Type: application/pgp-keys, Size: 3170 bytes --]

[-- Attachment #1.3: 0xC030918D.asc --]
[-- Type: application/pgp-keys, Size: 3168 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Assistance in remapping keys with no scancode in kernel module

[Clément Vuchener]

On Thu, Nov 12, 2015 at 07:59:21PM -0600, Marty Plummer wrote:
> Greetings
> 
> Having recently purchased a Logitech G105 Gaming Keyboard(046d:c248) I've began
> the process of reverse engineering the effects of the proprietery Logitech
> Gaming Software (hereafter LGS) on the device to enable its full potential in
> linux, using a number of tools (usbmon, hid-debug, virtual machines) to follow
> the actions and logic used.
> 
> As of right now, I've discovered the following:
> 1. That the macro key remapping (either as standard keyboard keys or full macros)
>    occurs in software and is not stored on the device itself (as opposed to
>    other Logitech GSeries devices).
> 
> 2. That keys G1-6 keys (hereafter GKeys) default to functioning as F1-6 until a
>    certain set of packets are sent to it from LGS or otherwise, after which the
>    F1-6 functionality ends.
> 
> 3. Before the F# keys are disabled, the GKeys sends hid reports on interface 0
>    identical to 'normal' F# keys and special reports on interface 1, with no
>    scancode, of three bytes in size, on one hid usage, ff00.0003 (vendor defined)
>    after the F# keys are disabled only the reports on interface 1 remain.
> 
> 4. The M1-3 and MR keys (hereafter MKeys) send no reports on interface 0 at all,
>    and reports on the same usage (ff00.0003) as the GKeys.
> 
> 5. One can easily determine which GKeys and MKeys are being pressed via bitwise
>    logic, as the three bytes follow a consistant pattern of:
> 
>    >03 gg mm
>    where 03 is constant, gg is a value indicating the depressed GKeys (0x01 << n-1)
>    AND'd together and mm is a value indicating the depressed MKeys (0x01 << n-1),
>    also AND'd together, where MR is treated as M4.
> 
> 6. Absolutely no standard scancode/keycode/etc is reported for these keys (as
>    detectable by evtest, xev, showkeys, etc).
> 
> 
> My current dilemma is how one is to transform this data into something usable,
> as the fact they all report on the same usage there is no simple way I can find
> to remap these keys.

You will have to parse these reports yourself by implementing the raw_event op and generate the appropriate input events. I think you also need to declare the keys you will be using in the input_configured op. You should be able to find a lot of examples for that in the existing HID drivers.

> 
> If anyone has any insight on this matter, please assist.
> 
> Information on these reports and raw usbmon logs can be found at
> https://github.com/GSeriesDev/gseries-tools/g105
> 
> 	Regards,
> 		Marty Plummer
> 

> pub  4096R/C030918D 2015-10-13 keybase.io/the_netz <the_netz@keybase.io>
> sub  4096R/9FB3AD35 2015-10-13 [expire : 2025-10-10]
> 

> pub  4096R/C030918D 2015-10-13 keybase.io/the_netz <the_netz@keybase.io>
> sub  4096R/9FB3AD35 2015-10-13 [expire : 2025-10-10]



--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Assistance in remapping keys with no scancode in kernel module

[Marty Plummer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/13/2015 03:54 AM, Clément Vuchener wrote:
> On Thu, Nov 12, 2015 at 07:59:21PM -0600, Marty Plummer wrote:

>
> You will have to parse these reports yourself by implementing the raw_event op
> and generate the appropriate input events. I think you also need to declare the
> keys you will be using in the input_configured op. You should be able to find
> a lot of examples for that in the existing HID drivers.
>
Hrm. I've grepped for the raw_event and have been looking at it, and will check
for input_configured as well. See, I've been looking at your hid-corsair driver,
but that seems to be a bit simpler as they all report on separate usages unlike
my situation. Would it be out of the question to ask for a particular driver to
look at that is more similar to my situation?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWRg0ZAAoJEHWEtN3AMJGNxhAP/0neYJIkEkgBwn5l5CVV3pWl
0QU5/ND7rZNuTp+HYXQHzU7SFTGOqbSvhFwWYXXvDupNp+tYwngcvN84EnO6PKZG
qgelkzLXExecVGqRH4rqQPrOsP8GeaZcTOrLdTe6ItWzB9QigGf19LLDo4O86ph3
0V1Sqt3ozsipROt7P7zu5DF7MNNNgx8mel1M8J+EHaTF84WJ9gUK4sD2MQKAmbAA
/jVdqoPpbEI6tBbQeiBB4u+qZm17Y4/jVDpJ6WZTn0/y/4M0yEZ97cxOK0YIuVhu
0UevZCAD1EX0/uwe4dTbG4K5Bti3+PYaHFPr/J6OU7Eicr0NKpetiF/iYju0UOpM
a1d4fOrd2Q8MQWvPCU7O0xVfPx03xe+55fqqYQGCos6oiB797BI9KFchIwcR+doo
id9bO/WHF46ZrNXlbXWLbFAAu9+qsq76BaLrqT8q8H6FKwqvHcak5dOMs74B5bb6
rG8bhF3bw1sGuRRQbbIRiMzYucGhO2bx7sr0tKOOOREm9gLPSLkWEntjV5jxg5wV
6OPCfGJGp2RlEc4/6Ff0hZwIcqDvFAZBBiN0l+fJdM9VciwsOxG1ShBfQ0BLUAp+
PTLWDJt6ptm95qnkIycmIbNa/8p8zEzwdZHFXQrCagXc9rrQo8h7MuOXuLbuKJQt
tOORVLzi7lFlDMQCmQTv
=NEuA
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html