Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Omen (Apex 350) wrong keycodes #13

Open
Yuuki-rei opened this issue Nov 29, 2021 · 4 comments
Open

Omen (Apex 350) wrong keycodes #13

Yuuki-rei opened this issue Nov 29, 2021 · 4 comments

Comments

@Yuuki-rei
Copy link

Hello.
I'm working on daily driving linux and your tool seemed like the perfect (and kind of only, haha) option to get my keyboard running.

The board is a rebranded Apex 350 by HP and shows as
ID 1038:120a SteelSeries ApS
in lsusb and
SteelSeries SteelSeries Apex 350 HP Omen
in evtest

At first it wasn't recognized because the reported id doesn't match any of the ones in the program, but after adding it manually to steelseries.txt it seemed to work fine when testing with the lights.

The problem arises when trying to actually use the extra keys; they're all over the place (MX6, 7 and 8 are vol up, down and mute respectively, and M5 is sleep, for example).

Checking with evtest, the keyboard seems to be reporting the correct scans as listed in the hwdb files, but they're sending the wrong codes.
Some examples:
M9-12 and L1-4 all send keycode 240
M1-4 send 136, 177, 178 and 176 respectively instead of 148-151

I dug around the files a little looking for an offset of some kind or something, but I'm not really a programmer, so I don't really understand how the program works or what I'm even potentially looking for.

Any ideas on what I could try?
I can provide any further information I might've missed or is otherwise required.

@AstroSnail
Copy link
Owner

Hi.
Thank you for using apexctl. I forget a lot that I'm not the only one who uses it. :P

The keys are all over the place, probably because the default udev configuration and default xkb configuration don't properly handle the apex's extra keys. udev is the system that converts the keyboard's raw scan-codes into key-codes, and xkb is the system that converts key-codes into key-symbols (they both do a lot more than this, but this is what's important to apexctl). udev and xkb are part of your linux distribution, and are separate from apexctl.

This repository provides a udev configuration to fix the key-codes. When you build apexctl, it also generates a 00-apex.hwdb file which contains this configuration. Installing apexctl should install this configuration as well, and automatically notify udev to load it, so that the key-codes are correct after installing.

If you're seeing errors when installing apexctl (using the command sudo make install), then please tell me, and I can ask more questions to try to fix it.

If I completely missed the mark on the problem behind your issue, then also please tell me xd

@Yuuki-rei
Copy link
Author

Yuuki-rei commented Dec 1, 2021

Hi again. Thanks to you for creating the tool. Saved me some bucks if I can get the kb I already have working, hehe.

Also, sorry it took me a bit to reply; been a bit caught up with work.
You did kind of miss the mark there (I think).

All 4 files get installed correctly via sudo make install. Here's the terminal's output:

misc/install.sh

  • apex_install
  • install -D -m0755 -- apexctl /usr/local/sbin/apexctl
  • install -D -m0644 -- 00-apexctl.rules /etc/udev/rules.d/90-apexctl.rules
    v+ [ n = y ]
  • install -D -m0644 -- 00-apex.hwdb /etc/udev/hwdb.d/90-apex.hwdb
  • [ y = y ]
  • install -D -m0644 -- 00-apex.conf /etc/X11/xorg.conf.d/90-apex.conf
  • [ y = y ]
  • udevadm hwdb --update
  • udevadm trigger

I executed udevadm hwdb --update and trigger manually, then went to the directories to confirm the files were there and their contents seem to be fine too.
Despite this, evtest still returns the wrong codes for extra keys instead of the ones listed in the .hwdb file... example:

.hwdb content says:

KEYBOARD_KEY_0700ed=232

but evtest returns

Event: time 1638399486.462951, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700ed
Event: time 1638399486.462951, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1638399486.462951, -------------- SYN_REPORT ------------
Event: time 1638399486.512959, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700ed
Event: time 1638399486.512959, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1638399486.512959, -------------- SYN_REPORT ------------

So the .hwdb file is indicating to trigger code 232 when receiving keyscan 0700ed, but the system actually triggers code 115.

FWIW, I'm running KDE under Mint, which I hear could be causing some weird issues in general.
Also, when executing evtest, it shows "SteelSeries Apex 350 HP Omen" on both event3 and event5, but event5 doesn't really do anything if I pick it, it just shows the supported events and says "Testing... (interrupt to exit)".

@AstroSnail
Copy link
Owner

Sorry for the late reply, I'm also a bit caught up.

Ok, so if I'm looking at the information you sent correctly, then it looks like the hwdb file is being installed, but udev doesn't acknowledge its existence.

I don't know what's going on, but I think one possibility is that udev is expecting its configuration files to be elsewhere. Another possibility is that linux mint uses a different version of systemd that parses the configuration in an incompatible way.

I can't check what exactly is wrong right now, but it might be useful if you could get the systemd version (systemctl --version) and find if any default hwdb files are installed anywhere else (find /etc -name '*.hwdb')

@Yuuki-rei
Copy link
Author

Hi there. No worries.
I went ahead and did what you suggested. There aren't any more .hwdb files in /etc/ , but it found a bunch of them in /usr/lib/udev/ so I tried putting the 90-apex.hwdb file there and doing udevadm hwdb --update && udevadm trigger again, but still no change in the behavior.

systemctl --version returns:

systemd 245 (245.4-4ubuntu3.13)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants