Assistance in remapping keys with no scancode in kernel module
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:
Quoted 1 line
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
Quoted 33 lines · Marty Plummer
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:
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 10 lines
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/g105Regards,
Marty Plummer
Quoted 6 lines
pub 4096R/C030918D 2015-10-13 keybase.io/the_netz <[email protected]> sub 4096R/9FB3AD35 2015-10-13 [expire : 2025-10-10]
pub 4096R/C030918D 2015-10-13 keybase.io/the_netz <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Quoted 8 lines · Clément Vuchener
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_eventop and generate the appropriate input events. I think you also need to declare the keys you will be using in theinput_configuredop. 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html