Karabiner-elements: Automatic, Device Specific Profiles

Created on 23 Jun 2017  路  12Comments  路  Source: pqrs-org/Karabiner-Elements

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"
            }
        }
    ]
}
stale

Most helpful comment

@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.

All 12 comments

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

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

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

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

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

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

@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.

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!

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

@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.

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

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

krasnovpro picture krasnovpro  路  3Comments

impala75 picture impala75  路  3Comments

baurmatt picture baurmatt  路  3Comments

PSalant726 picture PSalant726  路  3Comments

Joilence picture Joilence  路  3Comments