Automatic, Device Specific Profiles

[nfarrar]

When I'm at my desk, I use an external keyboard & mouse. I use Karabiner-Elements to remap left-option to left-command and left-command to left-option.

I don't want this applied to the internal keyboard though. I see the devices tab, in the GUI, but am not sure how to apply the profile to a specific device. Wasn't able to find any examples of doing this. Is it possible?

Here's basic configuration I'm using:

{
    "global": {
        "check_for_updates_on_startup": true,
        "show_in_menu_bar": true,
        "show_profile_name_in_menu_bar": false
    },
    "profiles": [
        {
            "devices": [],
            "fn_function_keys": {
                "f1": "display_brightness_decrement",
                "f10": "mute",
                "f11": "volume_decrement",
                "f12": "volume_increment",
                "f2": "display_brightness_increment",
                "f3": "mission_control",
                "f4": "launchpad",
                "f5": "illumination_decrement",
                "f6": "illumination_increment",
                "f7": "rewind",
                "f8": "play_or_pause",
                "f9": "fastforward"
            },
            "name": "Default profile",
            "selected": true,
            "simple_modifications": {},
            "virtual_hid_keyboard": {
                "caps_lock_delay_milliseconds": 0,
                "keyboard_type": "ansi"
            },
            "name": "Default profile",
            "selected": true,
            "simple_modifications": {
                "left_command": "left_option",
                "left_option": "left_command"
            }
        }
    ]
}

[starsy]

@nfarrar check out this fork: https://github.com/starsy/Karabiner-Elements

[tonylegrone]

@starsy, I came here looking for the same functionality. Your fork works great!

[levity]

@starsy is it true that device-specific key modifications are not supported in the non-forked version, even by editing karabiner.json directly?

[starsy]

@levity that's true. original KBE doesn't have device-specific key modification capability.

[lavelle]

@starsy is there any plan to merge your fork back into master?

[dguo]

@lavelle, he has #756 open. I'm also looking forward to when it gets merged.

[starsy]

@lavelle @dguo

Yes, i opened a pull request quite long ago, @tekezo didn't respond to it. I think there could be several reasons, as @tekezo not sending any words, this is my pure guess:

• The change itself is big in terms both code size and scope. There are several thousands of lines of change, from PreferenceWindow to KarabinerKit to libkrb to device_grabber to console_user_server, from ObjectiveC to C to C++, the only thing not touched is the kernel module. It is difficult to review so much code change at one time and to merge w/o a throughout review is risky and not responsible for the large KBE user groups.
• The configuration file format requires a change which introduce a backward compatibility issue to the wide user groups again. The initial KBE's config file has no per device key mapping support in design -- this is quite strange because it is there in the old KB feature set. I have to change the config file format in a non-backward compatible way to support it, hmmm @tekezo i would like to blame this to you. 😞
• @tekezo maintains a very nice suite of unit test cases for his code as quality guarantee. But due to a wide spectrum of changes, especially the changes in device_grabber and its low level dependencies, many of the C/C++ function interfaces has been changed, which breaks the unit test suite. i haven't decided to update them due to the workload and the necessity. But if @tekezo is willing to accept the pull request, i would be glad to extend the change to unit test suite.
• Code style. when you look deep into the code, @tekezo has his very own taste in how to write C++ code. the whole device_grabber and user_console_server is composed purely by .hpp, which means both the class/function definitions and implementations are put in header files. this is definitely debatable with certain limitations like long build time -- not be able to do parallel compiling, the cross-reference class types across header files is cumbersome or impossible. Thus I introduced a few new .cpp files to address these challenges, however it apparently broke @tekezo 's code style purity and paradigms.
• KBE is obviously @tekezo 's own baby when looking at the contribution history. There is no other significant contributors to the project, @tekezo may just want to keep his total ownership on this, which is understandable.

So I have created this fork as https://github.com/starsy/Karabiner-Elements , the "master" branch is for stable release and the "follow" branch keeps tracking and following KBE original's change, in case one day @tekezo would like to accept it, it can be done quickly. The stable release and pre-built packages can be found in "Release" section. Once the recently added complex configuration in KBE original is stabilized, I would like to review the difficulty and necessity to extend this highly demanded feature to it.

[lavelle]

Cool, thats good to know, thanks for the update @starsy.

I've started using your fork and it works perfectly for me. Hopefully we'll see it make its way to master eventually but in the meantime i can keep using the fork. Thanks for creating such a useful tool!

[dguo]

And thanks for being so detailed and considerate, @starsy!

[caseymhunt]

@nfarrar I have the exact same requirement. I need a certain remapping to function on my external (bluetooth) keyboard but not to my internal MBP keyboard.

I also require that Caps Lock remapping (hyperkey) work for both keyboards which precludes me from using your fork @starsy though it does look elegant.

[starsy]

@caseymhunt you can configure Caps Lock remapping for both keyboards with this fork.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.