linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marty Plummer <netz.kernel@gmail.com>
To: linux-input@vger.kernel.org
Subject: Assistance in remapping keys with no scancode in kernel module
Date: Thu, 12 Nov 2015 19:59:21 -0600	[thread overview]
Message-ID: <564543F9.9000109@gmail.com> (raw)


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

             reply	other threads:[~2015-11-13  1:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13  1:59 Marty Plummer [this message]
2015-11-13  9:54 ` Assistance in remapping keys with no scancode in kernel module Clément Vuchener
2015-11-13 16:17   ` Marty Plummer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564543F9.9000109@gmail.com \
    --to=netz.kernel@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).