Distinguish CAT S22 Flip function buttons

[70mg]

Developer TODO (don't remove)

• create new branch. put issue number at start of name
• update documentation
• merge and delete branch (don't squash because want commit history to see why I made changes)

The CAT S22 Flip* has an orange button on its left side, and a button labeled with a 🕪 to the left of its keypad. Currently, these are interpreted as the same button by key-mapper (unknown keycode 0 (This device)). It would be useful if they could be distinguished by KeyMapper, enabling distinct functions.

The output of adb shell getevent -lq yields distinct values for each button, which I'm guessing implies that distinguishing them is possible.

Orange side button
/dev/input/event1: EV_MSC MSC_SCAN 00000023
/dev/input/event1: EV_KEY KEY_NUMERIC_B DOWN
/dev/input/event1: EV_SYN SYN_REPORT 00000000
/dev/input/event1: EV_MSC MSC_SCAN 00000023
/dev/input/event1: EV_KEY KEY_NUMERIC_B UP
/dev/input/event1: EV_SYN SYN_REPORT 00000000

🕪 button
/dev/input/event1: EV_MSC MSC_SCAN 00000010
/dev/input/event1: EV_KEY KEY_MICMUTE DOWN
/dev/input/event1: EV_SYN SYN_REPORT 00000000
/dev/input/event1: EV_MSC MSC_SCAN 00000010
/dev/input/event1: EV_KEY KEY_MICMUTE UP
/dev/input/event1: EV_SYN SYN_REPORT 00000000

I appreciate not many people will have this device to hand, so I am of course on hand to help test or provide any additional information.

*The CAT S22 Flip is sold with a version of Android Go which comes with software for mapping these buttons. However, this is unavailable to users running a custom ROM on the device, making KeyMapper a great alternative. The device has become fairly popular among people wanting a "dumbphone" experience, but not wanting to ditch Android. A popular reason for wanting to install a custom ROM (e.g. LineageOS) is to de-google the device. KeyMapper is currently being recommended on the most popular and useful forum post on how to install LineageOS on the CAT S22 Flip.

p.s. KeyMapper is great, thank you!

[kamilkrzyskow]

Thanks for the detailed write up @70mg. I was able to find this issue thanks to the unknown keycode 0 remark 💪
I didn't know about such a handy tool adb shell getevent -lq 🤯 🙏

I recently bought the Samsung Trio 500, and I'm using it with a Poco X3 NFC. The keyboard has orange (seems like the color is causing the issue 😆) buttons that can be configured to do certain tasks on Samsung devices. So I thought I can just remap them using the app. However, all special buttons are read as keycode 0, and using the command above I've checked that all of the buttons have a unique scan code.

I've searched around and found a related issue #761 which is the main tracking Issue for scan code differentiation. I've asked about it on the Discord, and this feature isn't a short-term priority and would likely have to wait for a couple of months to be implemented.

I've noticed that #761 focuses on the ability to choose the source of the button input, like being able to choose either the key code or scan code. But in our case a fallback would be enough, if the keycode is 0, so KEY_UNKNOWN then use the scan code.

I've made a fork with some changes that appear to work on my device. Currently the max key code number is ~300, so I add 1000 to the scan code to be out of the range of possible key codes.

Here is the branch:

• https://github.com/kamilkrzyskow/KeyMapper/tree/fix/scancode-fallback

Trimmed Diff

+++ b/app/src/main/java/io/github/sds100/keymapper/system/accessibility/BaseAccessibilityServiceController.kt
@@ -310,10 +310,19 @@ abstract class BaseAccessibilityServiceController(
+
+                // Fallback to scanCode when keyCode is unknown
+                val code: Int = if (event.keyCode == KeyEvent.KEYCODE_UNKNOWN) {
+                    // Add 1000 to go past possible keyCode values
+                    event.scanCode + 1000
+                } else {
+                    event.keyCode
+                }
+
                 coroutineScope.launch {
                     outputEvents.emit(
                         ServiceEvent.RecordedTriggerKey(
-                            event.keyCode,
+                            code,
                             event.device,
                             detectionSource,
                         ),
// ...
-                consume = keyMapController.onKeyEvent(event)
+                // Fallback to scanCode when keyCode is unknown
+                val eventProxy: MyKeyEvent = if (event.keyCode == KeyEvent.KEYCODE_UNKNOWN) {
+                    // Add 1000 to go past possible keyCode values
+                    event.copy(keyCode = event.scanCode + 1000)
+                } else {
+                    event
+                }
+
+                consume = keyMapController.onKeyEvent(eventProxy)

                 if (!consume) {
-                    consume = rerouteKeyEventsController.onKeyEvent(event)
+                    consume = rerouteKeyEventsController.onKeyEvent(eventProxy)
                 }

If you want to test it you can download the artifact from here, it's the CI variant with a different keystore, so I'm assuming that none of the previously saved settings will work, so make sure to make a backup of everything, as you might have to remove your previous app ✌

• https://github.com/kamilkrzyskow/KeyMapper/actions/runs/13946490060

Attaching the artifact here, as the CI will remove it in the future: keymapper-2.8.4-ci.1.zip

SEO: How well does the Samsung Trio 500 work with smartphones other than Samsung? How to remap the app button on Samsung Trio 500?

---

EDIT:

After some more testing and configuration of buttons I've noticed that some buttons, despite having a unique scan code inside of the adb command above, they result in the same scan code inside the app.

/dev/input/event8: EV_MSC       MSC_SCAN             00070028
/dev/input/event8: EV_KEY       KEY_ENTER            UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0071 <-- APP1 button has scan code 240 (1240)
/dev/input/event8: EV_KEY       KEY_UNKNOWN          DOWN
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0071
/dev/input/event8: EV_KEY       KEY_UNKNOWN          UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0072 <-- APP2 button has scan code 431 (1431)
/dev/input/event8: EV_KEY       KEY_DISPLAYTOGGLE    DOWN     <-- Despite being detected as KEY_DISPLAYTOGGLE it's KEY_UNKNOWN inside the app
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0072
/dev/input/event8: EV_KEY       KEY_DISPLAYTOGGLE    UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0073 <-- APP3 button has scan code 592 (1592)
/dev/input/event8: EV_KEY       KEY_BRIGHTNESS_MIN   DOWN     <-- Despite being detected as KEY_BRIGHTNESS_MIN it's KEY_UNKNOWN inside the app
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0073
/dev/input/event8: EV_KEY       KEY_BRIGHTNESS_MIN   UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0302 <-- AppDrawer button has scan code 240 (1240)
/dev/input/event8: EV_KEY       KEY_UNKNOWN          DOWN
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0302
/dev/input/event8: EV_KEY       KEY_UNKNOWN          UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0301 <-- BurgerMenu button has scan code 240 (1240)
/dev/input/event8: EV_KEY       KEY_UNKNOWN          DOWN
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c0301
/dev/input/event8: EV_KEY       KEY_UNKNOWN          UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c006e <-- DeX button has scan code 240 (1240)
/dev/input/event8: EV_KEY       KEY_UNKNOWN          DOWN
/dev/input/event8: EV_SYN       SYN_REPORT           00000000
/dev/input/event8: EV_MSC       MSC_SCAN             000c006e
/dev/input/event8: EV_KEY       KEY_UNKNOWN          UP
/dev/input/event8: EV_SYN       SYN_REPORT           00000000

[sds100]

@kamilkrzyskow That's a smart way of working around it... this is a very quick patch that could be stop-gap solution for now? I think you're correct and Key Mapper should automatically be smart and use the scan code as a fallback if the key code is unkonwn. The user wouldn't have to configure anything but instead of "Unknown key code" we could show "Unknown button, scan code: 123" or something?

[kamilkrzyskow]

So in general the solution turned out to not be so great as I thought / wanted it to be.
The scanCode is more akin to scamCode, as it's not the raw representation but still a sort of keyCode mapping.

Looking at the odd behaviour of the buttons I've noticed that all buttons marked with EV_KEY KEY_UNKNOWN have the same 240 scan code on the Smart Trio 500, so in my case the code change almost didn't do anything.

The saving grace in my case are the APP2 / APP3 special buttons, which both have their own unique EV_KEY signatures KEY_DISPLAYTOGGLE and KEY_BRIGHTNESS_MIN. However, both of these actions don't do anything on my phone / have no mapping to Android key codes, so the KeyMapper app detects it finally as KeyEvent.KEYCODE_UNKNOWN marked as 0, so in this case the code change did help.

I've researched a bit with ChatGPT / Deepseek etc. and there is no other API that can get better results without root access.
I never used Shizuku, but maybe it would be possible to inject the adb getevent results from Shizuku to the KeyMapper hmm 🤔

I'll probably stick it out with this keyboard. I've returned the previous one and after further research this was the best one within my budget. The only competition was the Logitech K380S, the S is important, but it has circular buttons and a vertical enter key, so probably too cumbersome to use for me. However it has Fn-lock which I thought isn't so important, as I can just remap the special button keys (oh how ignorant I was 😞), but now I see that locking the keys to F1-F12 would be way easier to handle...

---

this is a very quick patch that could be stop-gap solution for now?

So given my rant above, yes sure, it should work in case of OPs issue as both buttons do have unique EV_KEY signatures, so the code change should help. I'll make a PR later this week, as it's not ready now ✌️

but instead of "Unknown key code" we could show "Unknown button, scan code: 123" or something?

I don't think that's necessary, as injecting (scanCode + 1000) into keyCode works seamlessly, works with backup/restore too.
However, if you want to indicate this is a makeshift solution, "in the future the scanCode handling will change" then maybe a Toast or a dialog alert similar to the one displayed after pressing 2 buttons for the trigger would be a better option?

[sds100]

I'll await your PR. See #1394, I want to see if i can somehow use Shizuku to intercept input events at the kernel level... its theoretically possible to detect because getevent has permission, I would just write my own getevent. The holy grail would be being able to consume the input events but I need to learn how that works in Linux.