KbDemo not working, Mac OSX Catalina

Bugs & Features
1

Mac OSX Catalina 10.15.3, MacBook Pro (15-inch, 2017), Matlab 2019b

I searched the forum for a thread on the topic, but didn’t find one … apologies if I overlooked something. And I’m aware that using the toolbox with Catalina is not a good idea … sorry.

When running KbDemo and I press a key, there’s no response (except the key being printed in the Matlab command window). I can only exit by Ctrl-C.
Output looks as follows (I pressed fghj):

    1 of 4.  Testing KbCheck and KbName: press a key to see its number.
    Press the escape key to proceed to the next demo.
    fghj
    Operation terminated by user during KbCheck (line 271)

    In KbDemo>KbDemoPart1 (line 107)
        [ keyIsDown, seconds, keyCode ] = KbCheck;

    In KbDemo (line 81)
    KbDemoPart1;

The same happens when running KbPressWait, apparently the key strokes are not registered by KbCheck at all.

Running KbQueueDemo gives an error message:

    >> KbQueueDemo
    1 of 6.  Testing KbQueueCheck and KbName: press a key to see its number.
    Press the escape key to proceed to the next demo.
    INTERNAL PSYCHTOOLBOX ERROR
    	error:                PsychError_system
    	general description:  Error reported by a system call
    	specific description: Failed to create event queue for detecting key press.
    	module name:          PsychHID
    	subfunction call:     KbQueueCreate
    	file name:            /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/OSX/PsychHID/PsychHIDStandardInterfaces.c
    	function name:        PsychHIDOSKbQueueCreate
    	line number:          982
    Error using PsychHID
    See error message printed above.

    Error in KbQueueCreate (line 211)
      PsychHID('KbQueueCreate', deviceNumber);

    Error in KbQueueDemo>KbQueueDemoPart1 (line 81)
    KbQueueCreate(deviceIndex);

    Error in KbQueueDemo (line 45)
      KbQueueDemoPart1(deviceIndex);

And the output of PsychHIDTest is the following:

    PsychHIDTest
    Making a list of all your HID-compliant devices. ...

    You have 7 low level HID-compliant devices:
    device 1: Keyboard, , , 0 inputs, 0 outputs
    device 2: Page: 0xff00, Usage: 0xf, , Keyboard Backlight, 0 inputs, 0 outputs
    device 3: Mouse, , Apple Internal Keyboard / Trackpad, 0 inputs, 0 outputs
    device 4: Page: 0xff00, Usage: 0xb, , Apple Internal Keyboard / Trackpad, 5 inputs, 0 outputs
    device 5: Page: 0xff00, Usage: 0xd, , Apple Internal Keyboard / Trackpad, 16 inputs, 64 outputs
    device 6: Page: 0xff00, Usage: 0x3, , Apple Internal Keyboard / Trackpad, 108 inputs, 0 outputs
    device 7: Keyboard, , Apple Internal Keyboard / Trackpad, 0 inputs, 0 outputs

Calling KbPressWait with any of the suitable device numbers does not make a difference.
Any help would be appreciated.

2 Likes
2

It’s the latest Apple security bullshit. Sometime when you used Matlab or KbCheck first, it told you something about access to some input methods or whatever being denied. Somewhere in the system settings, under security, there is some tab or whatever, where you can select Matlab and give it permission to use some low level keyboard input, or something. I don’t remember from the top of my head, but by default the trainwreck now denies us the low level input device access we need, unless you set an exception there. After that, keyboard input registers again.

3

Many thanks! Found it! It’s system setting, security, and then you have to add Matlab to the keyboard input monitoring. It works now again!

By the way, I stumbled into that same stupid security thingie before when using the webcam with Matlab, it took a while until the Matlab guys figured out how to handle this correctly.

I really should switch to Linux … oh well …

1 Like
4

Hello, I am sorry, but I have a similar issue. I added Matlab to the keyboard input monitoring.
kbdemo works until the fourth step. In the last step, I am not able to move (with right and left arrows) anything.

I have the same problem in two of my experiments. The scripts run, but I am unable to govern them. It seems that it doesn’t recognised the inputs.

Do you have any suggestions?
Further, in security setting I allowed dowloaded app from anywhere.

Thank you for the help

5

Can’t reproduce this on the MBP 2017. KbDemo works just fine here on macOS 10.15.3, Matlab R2019b, with latest PTB 3.0.16.

What machine is this? What keyboard? I assume the arrow keys also don’t work if you try them in stages 1-3 of KbDemo? Other keys broken?

I can’t give you much hope here. Working around the utter shitshow that is Catalina’s HID keyboard input layer required some optimizations / hacks. While they make performance bearable again, there was some likelihood it could break some keyboards. So far, no such case was reported, but maybe your machine/keyboard is the lucky patient zero here.

The advice stands to not use Apples overpriced and defective toys for research, and if one must do so, stay the hell away from macOS Catalina, which reached a whole new level of low-level brokenness in a long string of increasingly broken macOS versions.

6

Thank you for you quick reply.

What machine is this? What keyboard? I assume the arrow keys also don’t work if you try them in stages 1-3 of KbDemo? Other keys broken?

It’s a MBP 2018 with Italian keyboard. Yes, arrow keys don’t work with stages 1-3. No the other keys are working. I tried also using shift command.

Yes, probably it is better to not use Catalina…
Thank you for your attention.

7

Update:

I tried KbDemo with two different MBPs. One is a MBP 2011 with: HighSierra OS, an English keyboard, Matlab 2019b, PTB 3.0.16; the second one, instead, is a MBP 2010 with: Catalina 10.15.1 OS, Italian keyboard and Matlab 2019b, PTB 3.0.16.
In both of them Kbdemo works correctly, thus, I don’t really know what could be problem in the MBP 2018 (Catalina 10.15-3, Matlab2019a and PTB 3.0.16).

8

Me neither. I assume you meant MBP 2019 with 10.15.1, as the MBP 2010 does not work with Catalina.

Apart from hw differences, it could be the Catalina version (possible) or Matlab version (unlikely). As PTB’s keyboard handling is independent of Matlab (execpt for GetChar), Matlab is not likely to cause such a specific problem. But Apples trainwrecks have different bugs in each release, so maybe it is the difference between 10.15.1 and 10.15.3.

You could also try if use of Keyboard queues goes better for some weird reason, e.g., KbQueueCreate/Start/KbEventGet etc., as a workaround.

9

Me neither. I assume you meant MBP 2019 with 10.15.1, as the MBP 2010 does not work with Catalina.

No, it’s a MBP2010. We forced the upgrade to Catalina in order to check if the problem is the Italian keyboard.

Apart from hw differences, it could be the Catalina version (possible) or Matlab version (unlikely). As PTB’s keyboard handling is independent of Matlab (execpt for GetChar), Matlab is not likely to cause such a specific problem. But Apples trainwrecks have different bugs in each release, so maybe it is the difference between 10.15.1 and 10.15.3.`

At the moment I am not able to force the update to Catalina 10.15.3 and to test this hypothesis.

10

update:
We have installed the last Catalina update 10.15.4 and now Kbdemo is working well.
Probably there is something wrong in Catalina 10.15.3.

thanks for the assistance

11

I had been been running Catalina and MATLAB 2019B without too many problems for a while (make sure you’re on 2019B–earlier MATLAB versions are not compatible with Catalina, at least not nominally/you take your life into your hands if you do). I did have a problem after installing the most recent update 5 for 2019B that PTB’s KbCheck stopped being able to take input from the keyboard. I was able to fix it by quitting MATLAB, going into Mac System Preferences → Security & Privacy → Input Monitoring and unchecking MATLAB, restarting MATLAB, quitting MATLAB again, and re-checking MATLAB in Input Monitoring. Not sure if every quit/restart of MATLAB in that sequence is strictly necessary–these are just the exact steps that worked for me. Basically it looks like either MATLAB or the Mac had forgotten that I had granted keyboard access to MATLAB in the past, so I just re-did it. KbCheck working normally now.

I know MATLAB have had some hiccups adjusting to Catalina–things like MATLAB hanging on startup, that kind of thing. Each MATLAB update gets a little better.

I tend to trust Apple’s judgment calls when it comes to security measures given that I’ve never needed to worry about viruses and such. Personally I also like the feeling that nothing can use my laptop’s camera unless I’ve explicitly clicked to say it can. I don’t know much (anything) about the technical details, of course–I just know that I’ve never had a security-related issue under Apple, and that feels like a good track record to me.

1 Like
12

So basically a totally broken security UI workflow in Apples latest macOS Vista trainwreck. That’s not a Matlab bug for sure. It’s a sign of poor operating system engineering that a piece of standard userspace application software that is not close to system level would need to frequently adjust to a new OS version. From the category “Only in the magic world of Apple”.

I’m pretty sure the only way to be sure your camera can’t spy on you on any OS + hw combo is to put a sticker over it. And disconnect the microphone with some physical switch. Apple macOS btw. just had this very recently fixed major security flaw wrt. camera spying revealed:

https://news.ycombinator.com/item?id=22766138

13

Thanks for all the experiences. I have the same problem but mine seems harder to fix. My Macbook Pro 2019, Mojave, Matlab 2018a, cannot detect any input from the keyborad. But, the esc button is on the touchbar of Mac 2019, and esc could be detected! I went through the remedie in the page, and go into Mac System Preferences → Security & Privacy, there was no Input Monitoring option here. I looked up, found Catalina has this option, so I update my system to Catalina, which is a huge mistake.
Now I have Input Monitoring option in Security & Privacy, but not a single APP appears on the right column. According to Mac support, that means no APP has claimed that authority. So it seems the claim by PTB does not count as a claim by Matlab?
Also, I experience huge sychoronization failure now compared to with Mojave even when the full screen is used:
INFO: PTB’s Screen(‘Flip’, 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 99 times out of a total of 244 flips during this session.
If not use a full screen, the number is 100% of the totoal of flips.

So what do I do? Should I just reqind to rewind to Mojava to at least get my sychronization back?
Thanks a lot!

14

Downgrading to Mojave seems like a good idea. It is generally less broken than Catalina. Maybe the reason Mojave didn’t take keyboard input is because KbCheck selected the wrong default keyboard, e.g., because Apple may have screwed up something there for the MBP 2019 models in new ways. Touchbar models are especially frelled, and ESC is part of the touchbar “keyboard”, and we have special workaround code in place to just deal with that gimmick. A KbWait(-1) would try to query all keyboards, or trying KbWait(deviceIndex) with all deviceIndex values reported by GetKeyboardIndices, or looking at the output of PsychHID(‘Devices’) would help.

That said, i upgraded my MBP 2017 to Catalina 10.15.6, and it sort of survived the upgrade, and KbCheck’s with Matlab R2019b work fine. And Matlab shows up in the Preferences → Security & Privacy, Input Monitoring list, as it should. Have you tried all the non-sensical steps others had to do, like uninstalling Matlab, reinstalling it, etc.? There were multiple threads here on the forum.

What you report are performance problems though, not sync failure, unless it aborted with “SYNC FAILURE” errors or warnings? 99 out of 244 flips missed is very poor performance, but not sync failure. Apart from that, you must install the proper PsychtoolboxKernelDriver to be able to judge if timing properly works or not. Depending on the model of MBP 2019 that may be impossible, as our current driver only supports up to AMD Polaris gpu’s, not AMD Vega or later.

15

Hi Mario,
Thanks a lot for your reply! I tried some steps, the outcome was non-sensical, too. But I’d still put it here for someone’s refernce.
I first used KbWait(-1) or put a device number in the bracket. But now neither of the keyboard could be detected. I then uninstalling Matlab 2018a and then install it again. Now Matlab still didn’t appear in Preferences → Security & Privacy, Input Monitoring list, but KbWait(-1) worked well. The bad performance did not change. I would probably downgrade to Mojave.

I would like to know what happens about the missed flips: Previously I thought the missed frames were totaly omitted but the previous and next frames were shown at the time they are supposed to be shown. The previous frame stayed on the screen for 2 frames’ duration and then begins the frame after the missed one. Now since I have quite a lot missed flips, I noticed it was not the case. My motion stimuli move in a abnormaly slow way. Since I set the presentation to end at a full cycle, the stimuli did not reach the end of the cycle before they finished. That means, the missed frames will be tried to show again in the next flip, right? If the 2nd flip is missed, the real presentation will be 1-1-2-3, not 1-1-3-4?
But on the other hand, how would that explain some frames are never shown? Now with such a poor performance, a one-frame flash never appear in all trials.

Thanks for your help!

16

So KbWait etc. works fine now?

Either Matlab shows in that “Input Monitoring” list or KbCheck etc. can’t work. Unless ofc. that security GUI is also broken and omits info, who knows? Or you run Matlab from a Terminal in matlab -nodesktop mode, then Terminal would show up in that list. Maybe rebooting would be a good idea.

You didn’t mention your specific hardware configuration, graphics card, display setup etc., or PTB version. I assume you are on the very latest PTB 3.0.16 beta, as we mandate before you even try to get help here. Recent PTB is also needed for the KbCheck et al. functions to cope with new input bugs introduced by the Catalina shit pile. If you were on an older PTB without the workarounds, KbCheck’s and such might be more than 50x slower than on Mojave, in the >100 msecs range, and that would slow every script with keyboard input down.

The order with, e.g., a missed 2nd flip would be 1-1-2-3, iow. the first frame would show 2 refresh cycles, but no frame would be omitted from presentation.

It’s important to first test with our scripts like PerceptualVBLSyncTest, VBLSyncTest etc., to rule out coding bugs in your scripts.

Ofc. if this is not just poor performance, but some new Catalina graphics driver bugs, anything is possible. Only the properly installed and working PsychtoolboxKernelDriver can give more diagnostic feedback.

17

Hi Han,

Did you ever figure out a solution or why this was happening on Mojave? I am operating on Mojave OS currently, and a script with a Psychtoolbox task that was working perfectly fine is no longer working on my Mojave OS with the most recent Psychtoolbox OS. Meanwhile, the task runs fine on MATLAB R2018b and the Psychtoolbox version 3.0.15. It seems that it’s similar to your issue as the task doesn’t proceed early on during a KbQueueWait() command as it appears it cannot receive any key inputs and can’t proceed. Did you experience a similar issue? If so, how did you resolve?