Keyboard printing 66666

I have successfully compiled and installed this driver but the keyboard still prints 66666 when I open a virtual console. What might cause this?

Distro: Linux Mint 17.2 64 bit Linux kernel version: 3.16

Just adjust the volume spinner and it will stop. Would be nice to have a real fix, but that works without driver as well.

edit: this driver fixes the problem for me. Make sure the driver is being loaded: a) the M keys should be picked up in xev (they are not with default kernel driver) b) usb-devices should show this driver being used instead of something like usbhid ie not the following:

T:  Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=046d ProdID=c24d Rev=80.00
S:  Manufacturer=Logitech
S:  Product=Logitech G710 Keyboard
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=400mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid                                                                       
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

I've just got myself a Logitech G710+, since it's very similar to the Microsoft Sidewinder X4. I'm planning to extend sidewinderd (https://github.com/tolga9009/sidewinderd) by this beautiful keyboard. Haven't done enough research yet, but I think most of the stuff this driver does, is better done in complete userspace (using hidraw and or hiddev), without messing around with kernel and sysfs.

However, I'd like to get the "666" fix upstream. The kernel part is non-HID conformant and will have a very hard time getting accepted in it's current state. I'd like to focus on the "666" issue and push that upstream first, as it is a bug and needs a workaround / quirk.

Can you give me detailed information about the issue and how it has been fixed in this implementation?

For some odd reason, I can't reproduce the "666" bug. I've just tried out Arch Linux live media with kernel 4.2.5 and kernel 3.12 booting in UEFI mode, both working without any issue. I've bought my Logitech G710+ yesterday, maybe there has been a new revision? Or this bug occurs with specific motherboards / chipsets.

//Edit: This was part of a discussion in #22 and it is planned for beeing merged into 4.4. You can read Jiri Kosina's (HID maintainer) response here: http://www.spinics.net/lists/linux-input/msg42186.html. Looks like good news. I will work on the sidewinderd implementation and keep you updated.

Cheers, Tolga

I got it pushed upstream and should be in 4.4-rc4: https://github.com/torvalds/linux/commit/0d51571d51ea8eb72b903b2a4f3f43a38e7bc718. Excited!

Also you can see my fork of this driver and further discussion in mailing list about upstreaming a larger portion https://www.mail-archive.com/linux-input@vger.kernel.org/msg20518.html. Sounds like going forward I am looking to implement it similarly to the corsair driver that was already accepted. It would seem like a good idea to work together on some sort of user-space application (or patches to existing applications) to handle the M1-3 key states like new lock keys.

My g710+ is currently out of my possession, but once I have it back I'll get back to work on driver stuff. Sounds like it would definitely be a good idea to to collaborate on the user-space part. Keep in mind many fully featured key binding applications exist and would simply need the addition of macro recording triggered from key and picking up lock keys to function. Without digging into what you have done.

Good work at pushing the "666" fix upstream! By any chance, do you know what HID_QUIRKS_NOGET does exactly (any drawbacks?)? Couldn't find out after searching the web for quite some time. I'd be thankful for this!

I've looked into that conversation and I also walked through hid-corsair.c. In my opinion, we should have a standard way of handling such things in kernel space. What and how much should we do in kernel space? Fixing bugs like "666" is absolutely fine or exposing LEDs, but when it comes to handling profile switches, macro keys, things can get really complicated.

Problem is, when we have our own implementation for each and every keyboard out there, user-space programs have a hard time handling these keyboards. We end up having a user-space program per device instead of one for many (keeping it maintainable). So we need to discuss about a standard way.

The Corsair exposes it's LEDs, handles profile switching & setting profile LEDs in kernel space (which is a big fault imho!) and uses BTN_TRIGGER_HAPPY[N] for exposing its macro keys. However, profile switching doesn't affect the macro keys in any way, so why handle profile switches in kernel space in the first place?

If we now look at the Logitech G710+. Important questions are: does pressing buttons send HID events? Actually yes, but the wrong ones. It sends out HID events for KEY_1 - KEY_6. We need to send a packet, so it sends out the correct ones (this could actually be done in kernel space!). Does pressing M1 - M3 send out HID events? The HID events don't need to be standard compliant or represent a key / button specified in linux/input.h. We can catch non-standard HID events in user-space, so no need to mess around with that in kernel.

Remember, that we don't want to extend / change HID specification (else we could just add KEY_GKEY[N] in input.h and be fine). As long as the Logitech G710+ is sending out any HID events on keypress, we're fine in user-space. We don't even need to use 3rd party libraries like libusb. The kernel modules hidraw and hiddev are everything we need; they actually are designed for this kind of stuff.

TL;DR: we should only add things into kernel space, which are needed in order to avoid using dirty hacks or 3rd party, low-level libraries in user-space. This includes the "666" fix (already pushed upstream) and setting up the specific HID packet, so pressing G1 - G6 keys don't send out KEY_1 - KEY_6. Exposing LEDs might also be a good idea (eventhough not really needed). But everything else should take place in user-space (like profile handling, M1 - M3 as modifiers, macros and stuff).

About user-land tools: I'm always trying not to reinvent the weel. But sometimes, we need new solutions. I couldn't find a feature-complete, easy-to-use, low-level macro tool. There are TONS of macro tools for Linux, but the vast majority of them requires X server to run (argh!). This is why I've come up with a low-level solution using uinput. It is display server- and desktop environment-independent, lightweight and resource-friendly.

Except auto profile switching and a GUI (both features I'm working on), it's already on par with Microsoft's Windows drivers in terms of features (like macro record (including delays) and macro playback, so we have a solid ground to work on. Currently, it's a bit messy and needs refactoring, but since it's a rather small program, it should not be a big problem.

I totally support @tolga9009 's way instead of hardcoding M1-4 as modifiers. Moreover sending Mx down/up keypresses around Gx keypresses could get messy when other keypresses happen simultaneously.

@bestouff My approach was not to hard-code modifiers. Instead I was following corsair/this driver the keys are mapped to keycodes in kernel, but not necessarily directly to modifiers. I did that with xmodmap. Although as I mentioned in mailing list email emitting modifiers at kernel level has its benefits in that it is transparent to existing tools without the need for the user to modify configuration via xmodmap or similar.

@tolga9009 approach is definitely a solid one and perhaps the best. The one downside to not mapping things in a consistent way at the kernel level is the requirement for a non-X based (lower-level and generic) way of picking up the keys. If done at the kernel level any existing applications can pick it up (especially if done as modifiers either hardcoded or xmodmap). For instance Plasma 5's built in shortcuts tool can be used as I demoed in video. Doing things in user-space has the drawback that we have to build everything from scratch.

Handling profile switching and lighting up the led is trivial to do at the kernel level (as my driver does) and if exposed in a standard way (either as modifiers, sys file, or lock key added to hid interface) could be handled by any level macro/shortcut tool instead of requiring low level access. Additionally, the keys themselves could be utilized even without utilizing the modifiers.

We both agree that leds should be exposed in kernel-space. So if anything I will focus on continuing my reworking of led support to follow proper implementation that corsair driver uses. I already have it partially done. Just need my keyboard back. :)

We might ponder the other half a bit more as it seems we are forced to reinvent the wheel if we do everything in user-space.

@boombatower I understand your approach. But the problem is, you're trying to find a workaround in kernel-space for compatibility with current user-space apps. KDE Plasma 5 is not proprietary and has a huge community. I'm sure with a good design, we can have profiles built-in into the shortcut tool, or fork it.

I'm trying to think about an efficient design on both ends, kernel-space and user-space; not about compability issues with current user-space apps, which haven't been designed with gaming keyboards in mind. If they need to be extended (or worked around), so be it.

I agree on exposing an interface to easily access LEDs is trivial and should be done in kernel-space. This just adds a feature with no drawbacks. Even if that interface is exposed, a user-space app is free to use that interface or use it's own methods (like hidraw).

Handling profile switching on the other hand might be trivial to do in kernel-space, but it has its drawbacks. One drawback is, that even if user-space apps are setting LEDs via sysfs, they get overwritten as soon as the user presses M1 - M3.

Scenario 1: we have profile-switching directly in kernel-space:

Profile 1 is active and M1 LED is turned on.
Our user-space app doesn't look up the active profile in sysfs (like current Plasma 5 shortcut tool). If the user presses G1, a unique keycode is emitted, _independent_ of active profile.
When the user switches the profile, M2 LED lights up. Now, pressing G1 is still outputting the same keycode, eventhough M2 is active. Not good design. He needs a script / another user-space program, to workaround that problem. We can't solve this in kernel-space.

Scenario 2: we don't have profile-switching in kernel-space, but expose an interface for user-space apps to act with LEDs:

No LEDs are active (also default behaviour under Windows, if Logitech drivers aren't installed).
G1 - G6 emit their unique keycodes. Pressing M1 - M3 also emit keycodes, but they don't trigger LEDs.
The user can assign shortcuts to those keys, but he is aware, that his G710+ doesn't has full functionality, since LEDs aren't showing up. He can have access to extended features with additional scripts / user-space apps.
He installs one user-space app. M1 lights up and he immediately knows, that his keyboard now has full feature-set. It's a better design.

So, in both scenarios, the user has the same feature-set first and needs to extend it by 3rd party tools. However, the design of the second scenario is better. And it is actually more efficient, because we don't need to parse for active profile in sysfs for each G1 - G6 keypress. We just keep track of profiles in an int variable - more lightweight and more efficient for the same job.

Also, we're not restricting power-users and developers. They are free to do whatever they want. They can write small scripts, which light up some LEDs for incoming E-Mails, or they extend the standard profile count of 3 to 4, by reusing MR as profile 4.

Of course, developers could also achieve this by editing / blocking the kernel module; but I think you will agree that having a minimal kernel-space and using scripts / user-space apps win in terms of simplicity, flexibility and efficiency.

TL;DR handling profile-switches and exposing an ABI for active profiles in kernel-space doesn't have any advantages over doing it in user-space - we need to handle something in user-space anyway. It even has drawbacks.

Also, parsing actual profile via sysfs isn't less low-level than setting LEDs via sysfs. We don't need to go more low-level than this.

I've talked to the developer of hid-corsair.c. The Corsair K90 is acting a bit different. You cannot set LEDs using packets over USB; it's handled on hardware. That is why he chose that design. He will also need user-space to handle advanced stuff.

Our hardware is different. We have options. And in my opinion, we should choose the path, that is most efficient and gives most freedom. And that is:

magic packet via kernel-space, so G1 - G6 don't emit KEY_1 - KEY_6 anymore
expose LEDs (M1 - M3, MR and backlight) via sysfs ABI (we both agree on that)
don't handle profiles / profile-switching in kernel-space (let the user-space handle it)
let G1 - G6 emit keycodes
let M1 - M3 and MR emit keycodes

Cheers, Tolga

//Edited

Your kernel-space example does not accurately represent the best options.

easily have a variable to disable kernel space control of leds (either sysfs or compile time)
not necessary emitting same keycodes for G1, or using modifiers. Not bad even if we do since existing applications will just ignore active M1-3 like they do without the driver and see just G1-6. With modifiers this works transparently.
with any of the kernel-space approaches user-space can keep track of profile instead of having to read it every time
- listen for M1-3 keycode and read sysfs profile into variable (or base directly off key event)...same thing

for example we could:

keep track of profile in sysfs and led
emit double keycodes (modifier + G1-6) or unique codes for each combination

user-space can still:

directly access profile (and set) via sysfs
controll leds (and disable kernel space)
access all events

Everything can be accomplished the same with either approach. The disadvantage to pure user-space approach is that there is no hope for existing applications without patching them all and having to change them over to hidraw or similar which would be a rather large change. With kernel-space handling (of a variety of methods) the user-space handling is either a) completely transparent with no changes, or b) trivial to change. In both kernel-space approaches user-space can fully extends and gain access to all events just as if done entirely through hidraw...or even still using hidraw.

I do indeed like the your user-space approach, but at the same time it seems like we are needlessly forcing all user-space applications to require a major refactoring (away form X or other input to hidraw) for no real gain. Additionally, if these drivers are shipped with the kernel users will be able to use all the existing applications that are shipped by default with no additional components necessary.

If we are going for a pure implementation I agree with the suggestion on the mailing list that the hid interface should be modified to include the M1-3 keys are new lock keys (ie like num lock/cap lock) so they are included in each event, but again I am not sure there is any real benefit. Just a lot more work both in kernel-space to make the change and to all user-space applications.

The alternative approach may (or may not be) as eloquent depending on your view point, but does not break/change the interface and fits into the existing paradigm. Kinda like Linus never wanting to break user-space...rightfully so.

EDIT: Perhaps we should summarize some of this into kernel list and open some discussions on existing applications for input?

We can do everything in kernel-space, but the question is, will it get accepted? I highly doubt, that the Linux kernel guys will break standards and introduce new, non-standard modifier keys, just we can "hack" around some tools.

Emitting unique keycodes for each combination of Mx + Gy keys won't get accepted in kernel, I guarantee. You have to distinguish between physical keys and logical keys. Only physical keys should emit keycodes. Else, what would you do with a Sidewinder X6? 30 macro keys, 3 profiles. 90 unique keycodes for each combination? And the Corsair K95? We don't even have enough placeholder keycodes (like BTN_TRIGGER_HAPPY[1-40]). This is a _bad_ idea.

We don't need any hidraw / low-level access, I think I've confused you with my earlier post. hidraw is needed, if you're attempting a user-space only approach. To make it clear: I'm not thinking or planning a user-space only approach here. Just trying to figure out a sweet spot from both, user-space and kernel-space perspective.

In user-space, you're free to do anything you want. In kernel-space, you don't have that freedom (as long as you plan to get it upstream). We can't do everything we imagine. This includes M1 - M3 as modifiers. Definitely not going to be accepted (as long as the maintainers aren't drunk or half asleep). So you could indeed introduce a modifier key approach with an additional user-space app, acting as a layer. This could be done very lightweight and probably even just with small scripts.

I wasn't talking about M1 - M3 as lock keys (Num Lock, Scroll Lock and Caps Lock are lock keys, no need to break standards and introduce our own lock keys), but as normal keys, like G1 - G6. What to do with them, is up to the user-space. But in the first place, they are just keys, emitting keycodes on press.

We're probably talking about too much theory, misunderstanding and confusing each other. I think we should simply start coding and see, which approach is better. Luckily, this is not a multi-thousand lines project, so code-wise, I think we can both handle it on our own. I'm gonna work on it in a few days (probably around 18th, 19th December).

Cheers, Tolga

Hi,

I wanted to update you guys on this topic. I've worked on the kernel module and got LEDs working with linux/leds.h, but I've quit shortly after implementing it. Kernel development is very frustrating for different reasons. But that's not the topic here.

In the meantime, I've added Logitech G710+ support to https://github.com/tolga9009/sidewinderd. Everything is working: profile switching, LEDs, macro playback and macro recording (feature-parity with Windows, besides GUI). If anyone is interested in having a working solution right now: give it a shot.

@boombatower I wish you good luck. If you're interested in the kernel code I've written so far, let me know. I'm quitting kernel development again (for the second time) and focus on improving sidewinderd.

Cheers, Tolga

Wattos / logitech-g710-linux-driver

Keyboard printing 66666 #18