Reword trigger options: `This Android device` | `Any input device`

[GfEW]

Have you checked if an issue already exists for this problem?

• Nobody else has reported this problem before

Preface: Before backing down to v3.2.1-foss, I'm leaving a few issues, including the one below, to further improvement of the app.

The Problem

The wording This device has always puzzled me. In my view, it poses more questions than it answers, as opposed to the input device names/IDs that are offered each as a separate option. The ambiguous term "device" doesn't help, either. E. g., "Does This device prevent those maps from working when imported on another phone?"

Currently, the user has to look up the guide or conduct experiments to find out.

Suggested Solution

Offer to choose between

• This Android device
• All input devices
• device names/IDs

Doing so would be clearer, and fit available width.

On a side note, prepending the own ID of the current Android device (if Settings -> Show device IDs enabled) with its name would also help to ease understanding of available options.

App version

v4.0.5-foss 247

Device model and manufacturer

diverse

Extra info

• My device is rooted

[jambl3r]

Thanks for this. 'This device' currently refers to the device that the trigger was recorded from, e.g. the particular keyboard that you pressed the key on to record it. If you connected another keyboard and pressed the equivalent key, your key map would not be triggered. 'Any device' matches any valid input device sending the same keycode or scancode.

[GfEW]

Thanks for your reply.

Side note:

Despite its first person voice, this report is not primarily meant as a support request. Even if I, for one, was confident (by now) to know exactly what those check boxes do, I'd consider the wording improvable - users shouldn't need to trial and err, nor to consult the docs or seek online help, to make sense of a trigger key's device options.

On topic:

• (I)

  'This device' currently refers to the device that the trigger was recorded from, e.g. the particular keyboard that you pressed the key on to record it

At some point, that was my idea of it, too.

However, later I read at https://keymapper.app/user-guide/keymaps/#key-device :

• (A)
  The default device is 'this device', which means the Android device that you've installed Key Mapper on.

Which of (I) or (A) is true? IIUC, they can't be both.

Today, I've conducted more systematic tests (still in v4.0.5-foss 247). Procedure and results follow below.

With a Bluetooth keyboard connected:

1. Press "Tap to record trigger", type e. g. Alt+F11 (i. e. Alt_down,F11_down,F11_up,Alt_up, sticking below with whichever Alt key side you choose), and add some action - for the sake of this test e. g. toggle flashlight -, then save the map and type the trigger.
   --> Nothing happens.
2. Tap the map to edit it, and fix the order of trigger keys so Alt comes before F11, then save the map and type the trigger.
   --> Flashlight is toggled, as expected.
3. Tap the map to edit it, and change the Trigger key options of both keys to This device, then save the map and type the trigger.
   --> Nothing happens. This violates both, (A) and (I).
4. Tap the map to edit it, and change the Trigger key options of both keys to the one constant unnamed ID that's always there (just below Any device), then save the map and type the trigger.
   --> Nothing happens. Should it?
5. Repeat 3. and 4. in one of the formerly supported proper keyboard apps like Key Mapper Hacker's Keyboard (opened via notification or by disconnecting the Bluetooth keyboard).
   --> Nothing happens. This doesn't seem to support (A).
6. Repeat 3. and 4. in the AOSP software keyboard. (This, if not 5. already, requires to disconnect the Bluetooth keyboard.)
   --> Nothing happens. This doesn't seem to support (A).
7. Connect a different Bluetooth keyboard, and repeat 3. and 4. at it.
   --> Nothing happens. (This contradicts (A) and is no surprise, given the result of 3.)
8. Transfer the test maps from 3. and 4. to another Android device, connect the original Bluetooth keyboard (used in 1.-4.) there, and type the trigger.
   --> I haven't tested this, but the results of 3. and 4. suggest it wouldn't work, either.

So, what do

• This device
• unnamed ID (the persistent one that's different from the Bluetooth keyboard's, and not contained in the output of e. g. adb shell 'for c in "settings list "{system,secure,global} getprop printenv; do eval "${c}" | sed -Ee "s/^/${c}:/"; done')

really mean?

Apparently, my understanding of those options is still very incomplete, and I'm not particularly slow-witted. ;)

Should you prefer the above to be filed as proper bugs, please let me know. I just can't tell for sure which of those tests fail only due to SDK level mismatch.

[jambl3r]

Despite its first person voice, this report is not primarily meant as a support request. Even if I, for one, was confident (by now) to know exactly what those check boxes do, I'd consider the wording improvable - users shouldn't need to trial and err, nor to consult the docs or seek online help, to make sense of a trigger key's device options.

You're right of course - My reply was a note that intended to help you short term, the issue remains open because I intend to solve the root cause of the confusion :)

The default device is 'this device', which means the Android device that you've installed Key Mapper on.

I was mistaken, and this is what it is supposed to mean. I think 'This Android device' is an improvement.

Press "Tap to record trigger", type e. g. Alt+F11 (i. e. Alt_down,F11_down,F11_up,Alt_up, sticking below with whichever Alt key side you choose), and add some action - for the sake of this test e. g. toggle flashlight -, then save the map and type the trigger.
--> Nothing happens.

This is currently intended behaviour. The order of the 'up' events is what determines the order in the list. This situation where nothing happens but the user expected it to (because they replicated their trigger exactly after recording) can be 'solved' with #591 'together in any order' being the default option.

Tap the map to edit it, and change the Trigger key options of both keys to This device, then save the map and type the trigger.
--> Nothing happens. This violates both, (A) and (I).

I don't quite see how this violates (A)? The trigger is coming from the keyboard, not the Android device (because I assume the device does not have keyboard keys on it, just volume buttons etc.). This also applies to the tests 5, 6 and 7.

Tap the map to edit it, and change the Trigger key options of both keys to the one constant unnamed ID that's always there (just below Any device), then save the map and type the trigger.
--> Nothing happens. Should it?

I don't think so. If you don't recognise the device it probably isn't the keyboard. You probably don't need to worry about unnamed ID, it'll be some weird device that you are unlikely to be inputting anything from anyway.

Transfer the test maps from 3. and 4. to another Android device, connect the original Bluetooth keyboard (used in 1.-4.) there, and type the trigger.
--> I haven't tested this, but the results of 3. and 4. suggest it wouldn't work, either.

Assuming the device is set to either 'Any device' or the device that you recorded the trigger from originally (the keyboard), they should work.

[jambl3r]

I think I like
Any device -> Any input device
This device -> This Android device

[GfEW]

the issue remains open because I intend to solve the root cause of the confusion :)

Much appreciated.

I was mistaken, and this is what it is supposed to mean.

If there wasn't enough evidence for the confusion at hand, this one should do. ;)

This is currently intended behaviour. The order of the 'up' events is what determines the order in the list.

That doesn't make sense to me, because the behaviour encountered in step 1 is inconsistent:

• recording learns "up" events
• triggering acts on "down" events.

I think that whichever way KeyMapper chooses, it should stick with it, to ensure recorded triggers are immediately functional without manual reordering. (This worked fine in 3.2.1.)

This situation [...] can be 'solved' with #591 'together in any order' being the default option.

Whilst ignoring the order of trigger keys would "cover up" the inconsistency discussed above, it might better be resolved (if it exists on A11+).

The trigger is coming from the keyboard, not the Android device (because I assume the device does not have keyboard keys on it, just volume buttons etc.). This also applies to the tests 5, 6 and 7.

I see. So This device doesn't refer to "This Android device" as a receiver (1), but rather to the "internal input hardware on this Android device"!

(1)

That's what I've thought was meant by quote (A), but it turns out to be another misinterpretation. Actually, Android device specific maps would make sense, in order to separate them from those maps that are enabled on all your Android devices.

I've re-run tests 1, 2, 3, 5, 6 and 7 on an Android device that features an internal hardware keyboard (aside from the BT keyboard used to record the trigger), and indeed, test 3 gives a different result there: when the trigger key options are changed to This device, the map works at the internal HW keyboard.

This spawns another side note ...

The online doc quote "The default device is 'this device'" appears to be correct only as far as the trigger is recorded from an internal HW keyboard/button (not sure about USB).

probably don't need to worry about unnamed ID, it'll be some weird device that you are unlikely to be inputting anything from anyway

You may be right. KeyMapper doesn't even show any unnamed ID on the other Android device, which is why I couldn't perform test 4 there.

Assuming the device is set to either 'Any device' or the device that you recorded the trigger from originally (the keyboard), they should work.

Yeah, Any device is what I'm generally using; transferring those maps across Android devices has always worked for me.

Test 8. intends to show whether This device (or the unnamed ID) could possibly mean the BT keyboard from which the trigger was recorded. IIUC, we agree by now that's not the case unless you record from internal hardware.

To summarize,

1. still looks like a bug to me
2. (OK)
3. This device works on internal input hardware
4. unnamed ID is most likely a device specific quirk
5. software keyboards don't seem to trigger any map (and can't be used for recording, either)
6. same as 5.
7. This device mappings correctly fail with other BT keyboards
8. This device mappings should work on different Android devices if the original BT keyboard (which was used to record the trigger) is connected there.

[GfEW]

I think I like Any device -> Any input device This device -> This Android device

Agreed. I've changed the title accordingly.