macOS 26.4 Beta: built-in keyboard events no longer reach DriverKit virtual HID layer – ecosystem-wide breakage

Question

Created 1d

Replies 1

Boosts 0

Participants 2

macOS 26.4 Beta appears to have changed how built-in MacBook keyboard events are routed through IOHIDSystem. Third-party virtual HID devices loaded via DriverKit no longer receive events from the built-in keyboard. External keyboards are unaffected. This is already confirmed across multiple users:

https://github.com/pqrs-org/Karabiner-Elements/issues/4402

One possible lead (from LLM-assisted code analysis, not independently verified): this could be related to a security policy referred to as com.apple.iohid.protectedDeviceAccess, which may block IOHIDDeviceOpen for the Apple Internal Keyboard via SPI transport (AppleHIDTransportHIDDevice). A "GamePolicy" check in IOHIDDeviceClass.m that gates HID device access could be involved. This is a hint, not a confirmed root cause.

The impact goes well beyond a single project. Keyboard remapping on macOS is a thriving ecosystem — used for accessibility, ergonomics, developer productivity, and multilingual input. This is one of macOS's strengths as a platform. Many professionals specifically choose Mac because this level of customization is possible. If this capability is being removed without an alternative, it would significantly diminish what makes macOS attractive for power users and developers.

Is this an intentional architectural change to the input event pipeline for built-in keyboards, or a beta regression? If intentional, what is the recommended alternative for developers?

Boost

Answer 1

DTS Engineer OP

Apple

1h

macOS 26.4 Beta appears to have changed how built-in MacBook keyboard events are routed through IOHIDSystem. Third-party virtual HID devices loaded via DriverKit no longer receive events from the built-in keyboard.

As a small side note here, I have no idea why anyone is using DriverKit to create virtual HID devices. CoreHID provides its own virtual device API which, as far as I can tell, should be able to do everything you could do with a virtual device created through DriverKit. It's possible I've overlooked some limitation (and, if so, please let me know!) but as far as I can tell a number of products have chosen a much more difficult implementation without any real benefit.

https://developer.apple.com/documentation/corehid/hidvirtualdevice

External keyboards are unaffected. This is already confirmed across multiple users:

I'd normally ask you to file a bug on this but the engineering team is aware of the issue, so I don't think additional bugs are necessary in this particular case.

https://github.com/pqrs-org/Karabiner-Elements/issues/4402

...

Is this an intentional architectural change to the input event pipeline for built-in keyboards, or a beta regression?

I can't formally comment on our future plans, but I'd recommend testing this again on the next seed release.

If intentional, what is the recommended alternative for developers?

The most obvious alternative would be CGEventTap, but I'm not sure if that would entirely replace everything device seizer provides.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0