TIP: Resolving Big Sur Accessibility, Security, and Other Issues

Keyboard Maestro back to version 4.x should operate fine in general on Big Sur and Keyboard Maestro itself has no known problems with Big Sur. Keyboard Maestro from version 9.1 is also native for Intel and Apple Silicon.

Big Sur probably continues to suffer from the variety of bugs and issues that Mojave/Catalina have, which are documented at:

As they are confirmed to still exist in Big Sur, I'll copy them below here.

XKey Devices do not work with Keyboard Maestro in Big Sur

There appears to be an incompatibility between Big Sur and XKey devices such that the "value" component of their key events is no longer 1-4 bytes (holding a number), but is inexplicably 32 bytes. PI Engineering are looking in to the issue, and hopefully so is Apple.

Accessibility:

You will have to ensure you enable Accessibility for both Keyboard Maestro and Keyboard Maestro Engine. If you have any troubles with accessibility (eg typing keystrokes, selecting menus, copy/paste, etc), you need to toggle the accessibility permissions (System Preferences, Security & Privacy, Privacy, Accessibility) for Keyboard Maestro and Keyboard Maestro Engine off and then on again.

This especially happens if you already have Keyboard Maestro and upgrade the system. This is rather infuriating, as the checkboxes clearly show permission, so anyone would assume that means they have permission, but the system is actually lying, and you have to toggle the checkboxes off and on again to grant permission - who would even think to try that? This has remained a bug through Mojave and Catalina and now also confirmed in Big Sur.

Window positions of Alerts and Prompt For User Input windows

As described (BUG — Input Window Shifts Downward in v9.1 on Big Sur), Alerts and Prompt For User Input will move vertically each time they are opened in Big Sur. This has been reported as a bug to Apple.

Start Screen Saver does not work

In Mojave and later, the AppleScript command to retrieve the current screen saver may return screen saver "", which is invalid, in which case the Keyboard Maestro action, which is essentially

tell application "System Events" to start current screen saver

will fail. Interestingly, on a fresh install of Big Sur, current screen saver works and returns a valid screen saver, so my guess is that this is some sort of update issue where the preference is no set correctly (although changing the Screen Saver preference does not resolve the issue).

Login Window action does not work

Unfortunately, Apple has removed the CGSession tool that is used to lock the screen and return to the Login Window. I will look for a workaround, but currently I don’t know of an alternative.

Regarding Big Sur. I am running Big Sur 11.01 . The X key 16 is recognised under USB devices. if only I knew how to get KM to recognise it.

Apple T2 Bus:

Host Controller Driver: AppleUSBVHCIBCE

Headset:

Product ID: 0x8103
Vendor ID: 0x05ac (Apple Inc.)
Version: 2.06
Serial Number: 000000000000
Manufacturer: Apple
Location ID: 0x80200000

Apple T2 Controller:

Product ID: 0x8233
Vendor ID: 0x05ac (Apple Inc.)
Version: 2.01
Serial Number: 0000000000000000
Manufacturer: Apple Inc.
Location ID: 0x80100000

As mentioned, the problem is that the key event data is corrupted, so that the value (which should have the value of the key press) is 32 bytes long, instead of 1-4 bytes containing a number. The reason for this is some incompatibility between Big Sur and XKeys which is happening at a very low level.

Total noob here experiencing the same issue. I've created a bandaid by sending remote triggers from another computer - and plugging my xkeys modules into that, but it's not elegant. Any suggestion on where I should keep my eyes peeled for an update on this should it ever come? Would it likely be attached to an OS update?

If you send support@stairways.com an email and just say you are having trouble with XK devices in Big Sur, I'll send you my canned response, and then when a solution presents itself I'll try to email all the folks I have sent responses to.

The solution could be any one of:

  • An update to OSX to fix the issue.
  • An update to the XK device firmware to fix the issue.
  • An update to Keyboard Maestro to try to work around the issue somehow.

I can see the data coming in in the event, so it is technically possible for me to handle it, but because the data is not in any kind of reasonable format I don't have any way to make it work in general, or to make it robust against the issue being fixed, or to make it work in both pre and post Big Sur, so the last option is currently unlikely without some seriously custom hack which is not the idea of the USB Device Key trigger.

Hi, Thanks so much for this info. I thought that I was perhaps the only person having issues with my X-key device.

I'm curious what is in the 32 bytes Big Sur is sending - just random hash? I'm traveling and didn't bring my XK (since it doesn't work!) but if there's a consistent way to parse the bigger field and suss out which key is pressed, it seems worth it in the interim. A lot of us have your product because we have PI's product...

Here's a dirty hack to get to the Login Window until there's a better replacement for CGSession. Adjust the coordinates as needed.

Here's a Login Window macro using AppleScript to click the Control Center User menu.

tell application "System Events"
	tell its application process "ControlCenter"
		tell its menu bar 1
			click its menu bar item "User"
		end tell
		
		tell its window "Control Center"
			tell its group 1
				set btns to its buttons
				repeat with btn in btns
					if name of btn = "Login Window..." then
						click btn
					end if
				end repeat
			end tell
		end tell
	end tell
end tell
1 Like

2 posts were split to a new topic: MATLAB crashing when something is copied

Thanks. Excluding Matlab from the keyboard history fixed the problem.

But when I open the debugging window and copy text, nothing appears in the window, but the window is working, since firing a macro brings up the correct buttons. Any clues on how to see the flavors in the debugger window in case I want to delve deeper.

I did notify Matlab and got this reply:

Thanks a lot for the information and bringing this issue into our attention!

There is an enhancement task created for this issue and our developers are actively working on it. I am sorry about the inconvenience that caused. It should be resolved in the future releases. Thanks!

1 Like

Good to hear the MATLAB folks are working to resolve the issue.

If you disabled the history, then the debugging wont see the clipboard, so I presume that was the issue. Otherwise the clipboard debugger should appear as soon as something is copied.