Mapping cut/copy/paste scan codes

Is it possible to map custom key-code on UHK keys?

I’m trying to map XF86Copy, XF86Cut, XF86Paste (scan codes 141, 145, 143) to keys on Mod+xcv combinations, but there is no such options in the Agent’s list of available keys.

Any suggestions on how could I achieve that?

1 Like

Yep, see https://ultimatehackingkeyboard.com/blog/2021/10/31/production-progress-spare-parts-bonanza-new-agent-release#custom-scancodes

How are those key codes different from using Ctrl-xcv combo’s? Is there any advantage? Where can you find a list of all those special codes (I assume that is for Windows only)?

1 Like

In linux terminal ctrl+c is interrupting the working program, so I have to use ctrl+shift+c to copy, but ctrl+shift+c in Chome launches debug console. This is annoying, so I’m looking for a common solution for both programs.

kareltucek, thanks, for help.

2 Likes

Ah, that makes sense. Are those codes linux only or is there something similar for windows?

I’m not sure about Windows, I’ve been using Linux the last 12 years.

So far, the copy/paste binding solution is not always working as expected, depends on application implementation. For example, chrome page copy/paste works, but address bar doesn’t.

Totally agree! It feels so annoying and clunky! I will apply this solution, thanks.

I never realised this discrepancy for Ctrl-Shift-x/c/v between Terminal and Chrome could be solved this way. Makes so much sense! Thanks for enlightening me.

What format did you end up using for these? I’m also a Linux user and was unable to get B141, M141, or S141 to perform a copy action

Actually, I configured this tool GitHub - samvel1024/kbct: Keyboard keycode mapping utility for Linux supporting layered configuration to mitigate the issue I posted.
I mapped: mod + x/c/v as F13, F14, F15 and mapped them to cut/copy/paste via kbct.

So I’ve just tried to do the same with UHK agent, but it seems that neither of B141, M141, S141 worked correctly.

I’m using xev program to get scan codes, when I map key to B141, xev prints different code:

KeyRelease event, serial 34, synthetic NO, window 0x7800001,
    root 0x28c, subw 0x0, time 78862559, (-137,683), root:(1307,707),
    state 0x0, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

This one is the output I get for correctly mapped copy key (via kbct tool)

KeyRelease event, serial 34, synthetic NO, window 0x7800001,
    root 0x28c, subw 0x0, time 78899465, (-172,913), root:(1272,937),
    state 0x0, keycode 141 (keysym 0x1008ff57, XF86Copy), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

p.s. S141 / M141 - codes have not even trigger any event in xev.

I will shed some light on this.

The trouble is that keycodes are not scancodes.

The correct scancodes are 123, 124, 125. Or, from UHK source code:

        #define HID_KEYBOARD_SC_CUT                               0x7B
        #define HID_KEYBOARD_SC_COPY                              0x7C
        #define HID_KEYBOARD_SC_PASTE                             0x7D

The way I understand it:

  • Scancodes are a keyboard-sided abstraction. Different keyboards may use different scancode sets, just as there are (or historically were) various layouts with a lot of strange (and nowadays extinct) keys. (Not sure how many such different scancode sets are in use nowadays.)

    Also, on a single keyboard, same scancodes may have different meaning depending on modifiers, according to the host OS language map. (Such as the NEO2 layout with its 6 layers.).

  • Keycodes on the other hand are an OS abstraction. Since scancodes of different keyboards / scancode sets / scancode mappings / different keymap layers have different meanings, OS needs to translate them into some unambiguous “key action” enum - the keycode. Needless to say, different OSes may use different keycode abstractions. (Again, I have no idea if there is some open standard shared by OSes, but I guess not.)

2 Likes