PTB, macOS and MATLAB 2019b

[iandol]

Hi Mario, this is just some feedback on macOS Catalina and PTB (clean install running on a MacBook Pro Retina, 15-inch, Mid 2015, hybrid GPUs inc. AMD Radeon R9 M370X). I disabled SIP and the (new unsigned) kernel driver installs and works as long as SIP remains disabled, but does not work if SIP is then reenabled. Fair enough, Apple have made clear their position on kernel extensions, and suggestion to move over to DriverKit, and this means projects that do not have resources to constantly rewrite their drivers will require SIP to be disabled for use.

Anyway, even with SIP disabled and the kext working, PTB Screen does not currently run with an internal error being generated (verbosity=10 log):

>> clear all; sca
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #1 (Revision 1) established.
PTB-INFO: Disconnecting from kernel driver instance #1 for detected Intel GPU for safety reasons. setenv('PSYCH_ALLOW_DANGEROUS', '1') to override.
>> VBLSyncTest

ans =

     0

PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 720 x 450, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1920 x 1200, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 1024 x 640, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 840 x 525, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 2880 x 1800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 2560 x 1600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 2048 x 1280, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1024 x 768, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 800 x 600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 640 x 480, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-INFO: Retina display. Enabling panel fitter for scaled Retina compatibility mode.

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Aug  5 2019).
PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: Always using Cocoa for fullscreen windows to work around graphics driver bugs in OSX.
PTB-INFO: Presentation timing precision is not yet known for this configuration on most machines. Check your results.
INTERNAL PSYCHTOOLBOX ERROR
    error:                PsychError_InvalidWindowRecord
    general description:  An Invalid window record was referenced.
    module name:          Screen
    subfunction call:     WindowKind
    file name:            /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/Common/Screen/WindowHelpers.c
    function name:        PsychCheckIfWindowRecordIsValid
    line number:          61
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
Error using Screen
See error message printed above.

Error in sca (line 22)
    if Screen('WindowKind', win) == 1

Error in VBLSyncTest (line 668)
    sca;

Other functions like GetSecs et al., do seem to work.

[kleinerm]

Does the old signed driver still work with sip? The old one should be totally sufficient for that gpu. DriverKit btw. would not be a solution, it only covers a small subset of drivers, nothing in the gpu or low level area.

The fun thing about your error message here is that there isn't any code-path that could cause it afaics, so this blowup is pretty wicked. It suggests that OpenWindow somehow silently failed? But any execution path in OpenWindow that leads to failure would also print at least one error message before that internal psychtoolbox error.

So no idea what's happening here, unless the Screen mex file itself is somehow corrupted.

[iandol]

Yes, the old driver can load with SIP enabled, but the AMD GPU is not available and the error is the same:

>> sca
INTERNAL PSYCHTOOLBOX ERROR
    error:                PsychError_InvalidWindowRecord
    general description:  An Invalid window record was referenced.
    module name:          Screen
    subfunction call:     WindowKind
    file name:            /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/Common/Screen/WindowHelpers.c
    function name:        PsychCheckIfWindowRecordIsValid
    line number:          61
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 1
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
Error using Screen
See error message printed above.

Error in sca (line 22)
    if Screen('WindowKind', win) == 1

>> clear all
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 1
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-INFO: Activity state of AppNap is: Activities selected by PTB.
PTB-INFO: Reenabling AppNap et al. ... Make it so!
>> sca
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.
PTB-INFO: Disconnecting from kernel driver instance #0 for detected Intel GPU for safety reasons. setenv('PSYCH_ALLOW_DANGEROUS', '1') to override.

I still have the same error as before, but only the Intel GPU is found (then disconnected) with the old KEXT.

[kleinerm]

That's weird. This AMD gpu should be supported by the driver since mid 2012. A reboot didn't make a difference? Anyway, the main problem you observe has nothing to do with the kernel driver. I assume it's a failure in 'Openwindow', but getting a fail in openwindow without printout of some error message pointing to the rough reason is not possible according to the code, so i don't have a clue how this can happen.

[kleinerm]

What happens if you use the attached evaluation version of Screen mex? It only runs PerceptualVBLSyncTest, VBLSyncTest and maybe Denis TestFlip script and only until about Monday.

Screen.mexmaci64.zip

[iandol]

Hi, that seems to run at least (though VBLSyncTest is wrongly sized by default, and sync errors of course):

>> clear all; sca; VBLSyncTest

======== Screen() for evaluation of macOS visual presentation timing fix   ========
======== For evaluation by the Pelli lab and collaborators only!           ========
======== Functionally limited to drawing of simple FillRect and DrawLine   ========
======== and restricted text drawing                                       ========
======== The function will cease to work at beginning of 30-September-2019 ========

PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.
PTB-INFO: Disconnecting from kernel driver instance #0 for detected Intel GPU for safety reasons. setenv('PSYCH_ALLOW_DANGEROUS', '1') to override.

ans =

     0

ans =

     0

PTB-INFO: Retina display. Enabling panel fitter for scaled Retina compatibility mode.

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Sep 23 2019).
PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: Current backbuffersize 2880 x 1800 versus display native size 2880 x 1800.
PTB-INFO: Installation of the PsychtoolboxKernelDriver is strongly recommended if you care about precise visual
PTB-INFO: onset timestamping or timing. See 'help PsychtoolboxKernelDriver' for installation instructions.

PTB-INFO: OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon R9 M370X OpenGL Engine :: 2.1 ATI-3.0.67
PTB-INFO: Renderer has 2048 MB of VRAM and a maximum 1811 MB of texture memory.
PTB-INFO: VBL startline = 1800 , VBL Endline = -1
PTB-INFO: Beamposition queries unsupported or defective on this system. Using basic timestamping as fallback.
PTB-INFO: Timestamps returned by Screen('Flip') will be therefore less robust and accurate.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.744784 ms [59.720088 Hz]. (59 valid samples taken, stddev=1.474042 ms.)
PTB-INFO: Small deviations between reported values are normal and no reason to worry.

WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?

----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----

One or more internal checks (see Warnings above) indicate that synchronization
of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.

This will seriously impair proper stimulus presentation and stimulus presentation timing!
Please read 'help SyncTrouble' for information about how to solve or work-around the problem.
You can force Psychtoolbox to continue, despite the severe problems, by adding the command
Screen('Preference', 'SkipSyncTests', 1); at the top of your script, if you really know what you are doing.

PTB-INFO: Psychtoolbox imaging pipeline starting up for window with requested imagingmode 33793 ...
PTB-INFO: Will use 8 bits per color component framebuffer for stimulus drawing.
PTB-INFO: Enabling panel fitter. Providing virtual framebuffer of 1440 x 900 pixels size.
PTB-INFO: Will use 8 bits per color component framebuffer for stimulus post-processing (if any).
The refresh interval reported by the operating system is 16.66667 ms.
PTB-WARNING: DrawText: Failed to load external drawtext plugin [dlopen(/Users/ian/Code/Psychtoolbox/Psychtoolbox/PsychBasic/PsychPlugins/libptbdrawtext_ftgl64.dylib, 10): Library not loaded: /opt/X11/lib/libfontconfig.1.dylib
  Referenced from: /Users/ian/Code/Psychtoolbox/Psychtoolbox/PsychBasic/PsychPlugins/libptbdrawtext_ftgl64.dylib
  Reason: image not found]. Retrying under generic name [libptbdrawtext_ftgl64.dylib].
PTB-WARNING: DrawText: Failed to load external drawtext plugin 'libptbdrawtext_ftgl64.dylib' [dlopen(libptbdrawtext_ftgl64.dylib, 10): image not found]. Reverting to legacy text renderer.
PTB-WARNING: DrawText: Functionality of Screen('DrawText') and Screen('TextBounds') may be limited and text quality may be impaired.
PTB-WARNING: DrawText: Type 'help DrawTextPlugin' at the command prompt to receive instructions for troubleshooting.

Measured refresh interval, as reported by "GetFlipInterval" is 16.74478 ms. (nsamples = 0, stddev = 0.00000 ms)
PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)!
PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers
PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard
PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better...
PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least.

ans =

    9.0000

INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 97 times out of a total of 605 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the 'when' argument of Screen('Flip', window [, when]);
INFO: If you called Screen('Flip', window); without the 'when' argument, this count is more of a ''mild'' indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least
INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

WARNING: This session of your experiment was run by you with the setting Screen('Preference', 'SkipSyncTests', 1).
WARNING: This means that some internal self-tests and calibrations were skipped. Your stimulus presentation timing
WARNING: may have been wrong. This is fine for development and debugging of your experiment, but for running the real
WARNING: study, please make sure to set Screen('Preference', 'SkipSyncTests', 0) for maximum accuracy and reliability.
PTB missed 90 out of 600 stimulus presentation deadlines.
One missed deadline is ok and an artifact of the measurement.
PTB completed 0 stimulus presentations before the requested target time.
Have a look at the plots for more details...
>> 

[kleinerm]

Weird. Can you retry what happens when the kernel driver is in use? Maybe first reboot and see if that makes the old signed driver work, go back to the unsigned driver if you must. Also, if you happen to have an external display, could you check how it behaves there? Also, as a repetition on internal and external display, what does a Screen('Preference','ConserveVRAM', 8192) do before running the test?

[kleinerm]

Btw. would do you mean with VBLSyncTest being "wrongly sized"?

[iandol]

The signed kext claims it is loaded (I did reboot before my previous comment, and have rebooted again), with SIP enabled:

➜ sudo kextstat -b PsychtoolboxKernelDriver
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  181    0 0xffffff7f8486a000 0xa000     0xa000     PsychtoolboxKernelDriver (1.1) 2DA457B8-5775-3657-9A67-1D6DAB2AC5AF <13 5 3>

but it never seems to find the dGPU...

Btw. would do you mean with VBLSyncTest being "wrongly sized"?

Sorry I wasn't more clear; this is a retina display and the panelfitter seems not to scale-up by default, placing the screen dimensions in the lower-left:

I am currently visiting my Dad in Italy and I don't have access to another machine or any external displays, I wont be able to test with an external until the second week of October.

---

OK, so now I've re-disabled SIP, and installed the unsigned KEXT again (where the dGPU can be accessed):

➜ csrutil status
System Integrity Protection status: disabled.
➜ sudo kextstat -b PsychtoolboxKernelDriver
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  154    0 0xffffff7f80f47000 0xb000     0xb000     PsychtoolboxKernelDriver (1.1) 58270C2C-EE97-39CB-9F05-DE25B85EF479 <13 5 3>

And rebooted. I'm not getting the OpenWindow error on the unsigned kext with your customised Screen.mexmaci64 either, log of VBLSyncTest output here:

https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-verbosity-10-no-conservevram-set

I see the same resizing issue with the unisgned kext as shown in the screenshot above.

Going back to the standard Screen.mexmaci64, and the OpenWindow error is still present:

>> !csrutil status
System Integrity Protection status: disabled.
>> !sudo kextstat -b PsychtoolboxKernelDriver
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  154    0 0xffffff7f80f47000 0xb000     0xb000     PsychtoolboxKernelDriver (1.1) 58270C2C-EE97-39CB-9F05-DE25B85EF479 <13 5 3>
>> clear screen; sca
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #1 (Revision 1) established.
PTB-INFO: Disconnecting from kernel driver instance #1 for detected Intel GPU for safety reasons. setenv('PSYCH_ALLOW_DANGEROUS', '1') to override.
>> Screen('Preference', 'Verbosity', 10);
>> VBLSyncTest
PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 720 x 450, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1920 x 1200, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 1024 x 640, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 840 x 525, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 2880 x 1800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 2560 x 1600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 2048 x 1280, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1024 x 768, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 800 x 600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 640 x 480, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-INFO: Retina display. Enabling panel fitter for scaled Retina compatibility mode.

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Aug  5 2019).
PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: Always using Cocoa for fullscreen windows to work around graphics driver bugs in OSX.
PTB-INFO: Presentation timing precision is not yet known for this configuration on most machines. Check your results.
INTERNAL PSYCHTOOLBOX ERROR
    error:                PsychError_InvalidWindowRecord
    general description:  An Invalid window record was referenced.
    module name:          Screen
    subfunction call:     WindowKind
    file name:            /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/Common/Screen/WindowHelpers.c
    function name:        PsychCheckIfWindowRecordIsValid
    line number:          61
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
Error using Screen
See error message printed above.

Error in sca (line 22)
    if Screen('WindowKind', win) == 1

Error in VBLSyncTest (line 678)
    sca;

---

ConserveVRAM == 8192

Here is standard Screen with ConserveVRAM=8192:

>> clear screen; sca
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 2
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 1
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
PTB-DEBUG: IOServiceClose() for driver instance 0 was successfull.
PTB-INFO: Activity state of AppNap is: Activities selected by PTB.
PTB-INFO: Reenabling AppNap et al. ... Make it so!
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.
PTB-INFO: Connection to Psychtoolbox kernel support driver instance #1 (Revision 1) established.
PTB-INFO: Disconnecting from kernel driver instance #1 for detected Intel GPU for safety reasons. setenv('PSYCH_ALLOW_DANGEROUS', '1') to override.
>> Screen('Preference', 'Verbosity', 10);
>> Screen('Preference','ConserveVRAM', 8192);
>> VBLSyncTest

ans =

     0

Tried to prepare a new configuration phase via PsychImaging('PrepareConfiguration'), but did not finalize the previous phase yet.
You must call the PsychImaging('OpenWindow', ...); command at least once to open an onscreen
window according to the provided settings, before you can specify settings for additional onscreen windows.

The most likely reason you see this error message is because your script aborted with some error
before it managed to open the onscreen window. In that case it is best practice to execute a 'clear all'
command at the Matlab/Octave prompt before you restart your script.

I will restart configuration now and forget the previously made PsychImaging('AddTask', ...); settings.
Warning: Tried to prepare a new configuration phase, but you did not finalize the previous phase yet! 
> In PsychImaging (line 1469)
  In VBLSyncTest (line 283) 

ans =

     0

PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 720 x 450, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1920 x 1200, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 1024 x 640, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 840 x 525, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 2880 x 1800, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 1440 x 900, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 2560 x 1600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 2048 x 1280, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1024 x 768, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 800 x 600, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 640 x 480, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 1680 x 1050, fps = 0.000000, depth = 24
PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 1280 x 800, fps = 0.000000, depth = 24
PTB-INFO: Retina display. Enabling panel fitter for scaled Retina compatibility mode.

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Aug  5 2019).
PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: Always using Cocoa for fullscreen windows to work around graphics driver bugs in OSX.
PTB-INFO: Presentation timing precision is not yet known for this configuration on most machines. Check your results.
INTERNAL PSYCHTOOLBOX ERROR
    error:                PsychError_InvalidWindowRecord
    general description:  An Invalid window record was referenced.
    module name:          Screen
    subfunction call:     WindowKind
    file name:            /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/Common/Screen/WindowHelpers.c
    function name:        PsychCheckIfWindowRecordIsValid
    line number:          61
PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0
PTB-ERROR: Tried to destroy invalid windowRecord. Screw up in init sequence?!? Skipped.
OwnerPID: 396
WindowLevel: 25  (ShieldingWindow 2147483629)
WindowOwnerName: TextInputMenuAgent
OwnerPID: 420
WindowLevel: 25  (ShieldingWindow 2147483629)
WindowOwnerName: BetterTouchTool
OwnerPID: 487
WindowLevel: 25  (ShieldingWindow 2147483629)
WindowOwnerName: Karabiner-Menu
OwnerPID: 1188
WindowLevel: 0  (ShieldingWindow 2147483629)
WindowName: MATLAB R2019b - academic use
OwnerPID: 939
WindowLevel: 0  (ShieldingWindow 2147483629)
OwnerPID: 564
WindowLevel: 0  (ShieldingWindow 2147483629)
OwnerPID: 1188
WindowLevel: 0  (ShieldingWindow 2147483629)
WindowName: Editor - /Users/ian/Code/Psychtoolbox/Psychtoolbox/PsychTests/VBLSyncTest.m
OwnerPID: 1157
WindowLevel: 0  (ShieldingWindow 2147483629)
Error using Screen
See error message printed above.

Error in sca (line 22)
    if Screen('WindowKind', win) == 1

Error in VBLSyncTest (line 678)
    sca;

And with your debug Screen mex:

https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-verbosity-10-log-with-conservevram-8192

[iandol]

Hm, it seems this is not a macOS update issue but a MATLAB 2019b one, as Peter sees the same error on 10.14:

https://groups.yahoo.com/neo/groups/psychtoolbox/conversations/topics/24068

[scarfelab]

Yes, I have not installed the Catalina beta. I have also tried freshly installing PTB. I didn't think this would help in any way, but just got a bit paranoid.

So on the exact same system 2019a works fine, 2019b throws the error.

I can't see anything obviously dumb I am doing.

Happy to provide any support in testing.

[kleinerm]

As mentioned on the forum it is a macOS Mojave bug - actually more like 2 separate bugs, in the past only triggered/fully affecting Octave, now also blowing up Matlab R2019b. The evaluation version of Screen posted in one of the above replies should fix it and did so here with Octave and on Ian's machine with R2019b. However that time limited eval version will stop working by the end of Sunday.

I hope to have a 2017 MacBookPro available for testing myself, hopefully by tomorrow if the parcel delivery service doesn't screw up or delay more than they already did. Hopefully with a working keyboard and without other hardware bugs like exploding batteries and all the other broken stuff that you nowadays pay for when you buy an iToy, as it is a used machine bought for me by Denis Pelli from eBay. Then we'll see. Could be useful to get more testing on different hardware, especially with external displays, once i'm done fighting with it.

[iandol]

Hi Pete,

Some of PTB's core functions have been ported to Python by Mario for PsychoPy , but the star of the show Screen did not get ported, not sure if it is planned or even feasible (it would be super awesome if it was).

Apart from PTB, perhaps I've been lucky but my iToys have been the most rock solid laptops I've ever owned, and compared to my PC laptops (even IBM/Lenovo thinkpads), have outlasted them all. But I do think Mario has good reason to be upset with Apple software-wise, they constantly move onto the next shiny software API and let everything else rot. macOS has clearly got progressively worse over the last 5 years or so, and I've for e.g. had to start rebooting my iMac every couple of weeks or so (the magic windows PC fix was never necessary on my macOS machines before). This rot has been widely discussed in the Mac development community. Microsoft has been getting better (WSL, who would ever have thought it, and Visual Studio Code is really a brilliant cross-platform open-source editor), and Linux kernel hardware compatibility and overall fragility is much improved. But on balance, I still prefer to use macOS day-to-day, while happily using Ubuntu for PTB (where it totally rocks, amazing timing stability), and falling back to Win 10 only where absolutely necessary.

Offtopic, but I'd be interested in any VR system you were developing. I am trying to develop a full immersive VR rig for non-human primates (360° treadmill + custom headset), I'll email you.

[scarfelab]

Hi,

I would be happy to chat. I deleted my original message as I replied via email and didn't realise that it automatically popped up on here.

P

[kleinerm]

So, here is a download link to a new version of Screen for Matlab on OSX for testing:

https://drive.google.com/open?id=1ydqFGgpjHGaWmlObsTzQBlZlQviEEVHB

This one works until end of next Saturday. It should be tested with the Psychtoolboxkerneldriver properly installed on your machine, ie. with a NVidia or AMD graphics card. However, if that isn't possible, just getting the normal PTB output is also of some use.

Intel gfx may work with the kernel driver, but needs you to execute setenv('PSYCH_ALLOW_DANGEROUS','1') before first invocation of the new Screen() to enable that. The "Dangerous" flag means there is a unknown, but non-zero probability it could crash your machine at the hardware level (ie. not an operating system crash) to the point where it needs to be completely unplugged from any power supply for minutes, which for a laptop with battery means a costly trip to your local Apple dealer. I regularly test on machines from the 2010 and 2012 era, and i never experienced such a crash, but i read about it in a bug-reporter - not related to PTB however, where it happened with some Haswell graphics chip ie. around ~2013 ish, and the hw malfunction was so bad it caused the network chip to malfunction as well and electrically jam a whole network segment and take the computers on a whole floor down due to some cascading network malfunction! So viewer discretion is advised :)

Anyway, the kicker is that this may fix at least the worst visual timing/timestamping problems on many broken Apple machines under at least macOS 10.12-10.14. Successfully tested so far are the MacBookPro 2010 under 10.13.6 High Sierra, and the MBP 2017 with AMD graphics under 10.12.6 Sierra and 10.14.6 Mojave, as well as a macMini 2012 under 10.14.6 Mojave. Would be interesting to know if it makes more machines + OS combos work ok'ish. This is work supposed to be done under a contract that is supposed to be paid by Denis Pelli, so the proper Screen() mex file will only be released if and when that contract is signed and the money paid. It only needs to work on two types of Apple machines with 10.14.6, but i hope it will help on many more combos.

Let me just say that my well known very low opinion about Apples OS engineering dropped to totally new levels of low during the so far over 180 hours of work dealing with this, now that i understand better all the impressive ways the screwed up to break timing that badly. I didn't think i could think worse of them, but they managed to convince me otherwise. So much screaming and shouting and swearing.

Anyway, testing feedback appreciated.

On Tue, Oct 1, 2019 at 12:43 AM Ian Max Andolina notifications@github.com wrote:

Hi Pete,

Some of PTB's core functions have been ported to Python by Mario for PsychoPy , but the star of the show Screen did not get ported, not sure if it is planned or even feasible (it would be super awesome if it was).

Apart from PTB, perhaps I've been lucky but my iToys have been the most rock solid laptops I've ever owned, and compared to my PC laptops (even IBM/Lenovo thinkpads), have outlasted them all. But I do think Mario has good reason to be upset with Apple software-wise, they constantly move onto the next shiny software API and let everything else rot. macOS has clearly got progressively worse over the last 5 years or so, and I've for e.g. had to start rebooting my iMac every couple of weeks or so (the magic windows PC fix was never necessary on my macOS machines before). This rot has been widely discussed in the Mac development community. Microsoft has been getting better (WSL, who would ever have thought it, and Visual Studio Code is really a brilliant cross-platform open-source editor), and Linux kernel hardware compatibility and overall fragility is much improved. But on balance, I still prefer to use macOS day-to-day, while happily using Ubuntu for PTB (where it totally rocks, amazing timing stability), and falling back to Win 10 only where absolutely necessary.

Offtopic, but I'd be interested in any VR system you were developing. I am trying to develop a full immersive VR rig for non-human primates (360° treadmill + custom headset), I'll email you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[scarfelab]

Cool, happy to test.

Are there any specific routines you would like run / output / verbosity levels etc.

P

On 22 Oct 2019, at 01:40, kleinerm notifications@github.com<mailto:notifications@github.com> wrote:

So, here is a download link to a new version of Screen for Matlab on OSX for testing:

https://drive.google.com/open?id=1ydqFGgpjHGaWmlObsTzQBlZlQviEEVHB

This one works until end of next Saturday. It should be tested with the Psychtoolboxkerneldriver properly installed on your machine, ie. with a NVidia or AMD graphics card. However, if that isn't possible, just getting the normal PTB output is also of some use.

Intel gfx may work with the kernel driver, but needs you to execute setenv('PSYCH_ALLOW_DANGEROUS','1') before first invocation of the new Screen() to enable that. The "Dangerous" flag means there is a unknown, but non-zero probability it could crash your machine at the hardware level (ie. not an operating system crash) to the point where it needs to be completely unplugged from any power supply for minutes, which for a laptop with battery means a costly trip to your local Apple dealer. I regularly test on machines from the 2010 and 2012 era, and i never experienced such a crash, but i read about it in a bug-reporter - not related to PTB however, where it happened with some Haswell graphics chip ie. around ~2013 ish, and the hw malfunction was so bad it caused the network chip to malfunction as well and electrically jam a whole network segment and take the computers on a whole floor down due to some cascading network malfunction! So viewer discretion is advised :)

Anyway, the kicker is that this may fix at least the worst visual timing/timestamping problems on many broken Apple machines under at least macOS 10.12-10.14. Successfully tested so far are the MacBookPro 2010 under 10.13.6 High Sierra, and the MBP 2017 with AMD graphics under 10.12.6 Sierra and 10.14.6 Mojave, as well as a macMini 2012 under 10.14.6 Mojave. Would be interesting to know if it makes more machines + OS combos work ok'ish. This is work supposed to be done under a contract that is supposed to be paid by Denis Pelli, so the proper Screen() mex file will only be released if and when that contract is signed and the money paid. It only needs to work on two types of Apple machines with 10.14.6, but i hope it will help on many more combos.

Let me just say that my well known very low opinion about Apples OS engineering dropped to totally new levels of low during the so far over 180 hours of work dealing with this, now that i understand better all the impressive ways the screwed up to break timing that badly. I didn't think i could think worse of them, but they managed to convince me otherwise. So much screaming and shouting and swearing.

Anyway, testing feedback appreciated.

On Tue, Oct 1, 2019 at 12:43 AM Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

Hi Pete,

Some of PTB's core functions have been ported to Python by Mario for PsychoPy , but the star of the show Screen did not get ported, not sure if it is planned or even feasible (it would be super awesome if it was).

Apart from PTB, perhaps I've been lucky but my iToys have been the most rock solid laptops I've ever owned, and compared to my PC laptops (even IBM/Lenovo thinkpads), have outlasted them all. But I do think Mario has good reason to be upset with Apple software-wise, they constantly move onto the next shiny software API and let everything else rot. macOS has clearly got progressively worse over the last 5 years or so, and I've for e.g. had to start rebooting my iMac every couple of weeks or so (the magic windows PC fix was never necessary on my macOS machines before). This rot has been widely discussed in the Mac development community. Microsoft has been getting better (WSL, who would ever have thought it, and Visual Studio Code is really a brilliant cross-platform open-source editor), and Linux kernel hardware compatibility and overall fragility is much improved. But on balance, I still prefer to use macOS day-to-day, while happily using Ubuntu for PTB (where it totally rocks, amazing timing stability), and falling back to Win 10 only where absolutely necessary.

Offtopic, but I'd be interested in any VR system you were developing. I am trying to develop a full immersive VR rig for non-human primates (360° treadmill + custom headset), I'll email you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRIN6AQ22DWSBTT2VI3QPZDYRA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4HHGI#issuecomment-544764825, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRJHMJG4JXP62AMDTT3QPZDYRANCNFSM4I2JMOXA.

[kleinerm]

VBLSyncTest or simply just a few seconds of PerceptualVBLSyncTest should do the trick. Screen Verbosity 5 is good enough, unless PTB complains about sync failures or other brokenness, then repeating with level 16 might be good. The important thing is that the PsychtoolboxKernelDriver is installed and used, so the beamposition query timestamping and various other low level checks and diagnostic work.

So far i have successfull test results on macOS 10.14.6 from the 15" Retina MBP 2017 with AMD gpu from myself and Denis, and from Denis also from the MBP 2015 with AMD, so if your MBP is a 2016 with AMD i wouldn't expect surprises, but then i also didn't expect to spend another 180 hours on top of the 70 hours i expected this to take, but Apple worked tirelessly over the last year to add another 180 hours of debugging fun -- so so many bugs, one more absurd and screaming "incompetence and neglicence" than the next.

On the Nvidia side i only have one data point from my old 2010 MBP under 10.13.6 and on the Intel side from the 2010 MBP 10.13.6, and 2012 macMini with 10.14.6. But then Apple and NVidia hate each other so much that there probably won't be a mac with NVidia gpu anymore, so maybe it doesn't matter. The Intel side would be interesting (macMini, MacBookAir, MacBook, lower end MacBookPro with single gpu) but as i said above, testing with Intel is special and not 100% risk free on modern machines, so if somebody is "feeling lucky(tm)", i happily take the results, but not the responsibility for potential damage. Without the PTB kernel driver, testing on Intel is not dangerous at all, it's just that the results are much less trusworthy when PTB can't run all the extra diagnostic unique to it, but results would probably be not totally useless.

Thanks.

On Tue, Oct 22, 2019 at 8:53 AM scarfelab notifications@github.com wrote:

Cool, happy to test.

Are there any specific routines you would like run / output / verbosity levels etc.

P

On 22 Oct 2019, at 01:40, kleinerm notifications@github.com<mailto:notifications@github.com> wrote:

So, here is a download link to a new version of Screen for Matlab on OSX for testing:

https://drive.google.com/open?id=1ydqFGgpjHGaWmlObsTzQBlZlQviEEVHB

This one works until end of next Saturday. It should be tested with the Psychtoolboxkerneldriver properly installed on your machine, ie. with a NVidia or AMD graphics card. However, if that isn't possible, just getting the normal PTB output is also of some use.

Intel gfx may work with the kernel driver, but needs you to execute setenv('PSYCH_ALLOW_DANGEROUS','1') before first invocation of the new Screen() to enable that. The "Dangerous" flag means there is a unknown, but non-zero probability it could crash your machine at the hardware level (ie. not an operating system crash) to the point where it needs to be completely unplugged from any power supply for minutes, which for a laptop with battery means a costly trip to your local Apple dealer. I regularly test on machines from the 2010 and 2012 era, and i never experienced such a crash, but i read about it in a bug-reporter - not related to PTB however, where it happened with some Haswell graphics chip ie. around ~2013 ish, and the hw malfunction was so bad it caused the network chip to malfunction as well and electrically jam a whole network segment and take the computers on a whole floor down due to some cascading network malfunction! So viewer discretion is advised :)

Anyway, the kicker is that this may fix at least the worst visual timing/timestamping problems on many broken Apple machines under at least macOS 10.12-10.14. Successfully tested so far are the MacBookPro 2010 under 10.13.6 High Sierra, and the MBP 2017 with AMD graphics under 10.12.6 Sierra and 10.14.6 Mojave, as well as a macMini 2012 under 10.14.6 Mojave. Would be interesting to know if it makes more machines + OS combos work ok'ish. This is work supposed to be done under a contract that is supposed to be paid by Denis Pelli, so the proper Screen() mex file will only be released if and when that contract is signed and the money paid. It only needs to work on two types of Apple machines with 10.14.6, but i hope it will help on many more combos.

Let me just say that my well known very low opinion about Apples OS engineering dropped to totally new levels of low during the so far over 180 hours of work dealing with this, now that i understand better all the impressive ways the screwed up to break timing that badly. I didn't think i could think worse of them, but they managed to convince me otherwise. So much screaming and shouting and swearing.

Anyway, testing feedback appreciated.

On Tue, Oct 1, 2019 at 12:43 AM Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

Hi Pete,

Some of PTB's core functions have been ported to Python by Mario for PsychoPy , but the star of the show Screen did not get ported, not sure if it is planned or even feasible (it would be super awesome if it was).

Apart from PTB, perhaps I've been lucky but my iToys have been the most rock solid laptops I've ever owned, and compared to my PC laptops (even IBM/Lenovo thinkpads), have outlasted them all. But I do think Mario has good reason to be upset with Apple software-wise, they constantly move onto the next shiny software API and let everything else rot. macOS has clearly got progressively worse over the last 5 years or so, and I've for e.g. had to start rebooting my iMac every couple of weeks or so (the magic windows PC fix was never necessary on my macOS machines before). This rot has been widely discussed in the Mac development community. Microsoft has been getting better (WSL, who would ever have thought it, and Visual Studio Code is really a brilliant cross-platform open-source editor), and Linux kernel hardware compatibility and overall fragility is much improved. But on balance, I still prefer to use macOS day-to-day, while happily using Ubuntu for PTB (where it totally rocks, amazing timing stability), and falling back to Win 10 only where absolutely necessary.

Offtopic, but I'd be interested in any VR system you were developing. I am trying to develop a full immersive VR rig for non-human primates (360° treadmill + custom headset), I'll email you.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRIN6AQ22DWSBTT2VI3QPZDYRA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4HHGI#issuecomment-544764825, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRJHMJG4JXP62AMDTT3QPZDYRANCNFSM4I2JMOXA.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[scarfelab]

Hi Mario,

I am running 10.15 Catalina. I have tired with Matlab 2019a and 2019b with the new screen function. Running with an external monitor.

(1) I disabled SIP - reported disabled (2) Rebooted (3) Replaced the screen mex (4) Installed the kernel driver, but this failed. Statement about the disk being read only. Even though SIP disabled. (5) Ran Setup Psychtoolbox

For 2019a: VBL sync test seems to work. Initially it did not, but I cannot replicate that now. However, running drift demo crashes. You get the PTB welcome screen, but scrambled with some red bars. This was the same crash I initially got with VBL sync test initially but can no longer replicate.

For 2019b: VBL sync test runs but in a distorted fashion. Picture attached. These are the same red bars as described above. DriftDemo fails in the same way as 2019a.

Output for all above with verbosity 16 below.

[cid:4673C02E-767A-4CCE-B210-321B5EF06333]

Matlab 2019a

Screen('Preference', 'Verbosity', 16)

======== Screen() for evaluation of macOS visual presentation timing fix ======== ======== For evaluation by the Pelli lab and collaborators only! ======== ======== Functionally limited to drawing of simple FillRect and DrawLine ======== ======== and restricted text drawing ======== ======== The function will cease to work at beginning of 27-October-2019 ========

ans =

 3

VBLSyncTest

ans =

 0

PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1600 x 900, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1600 x 900, fps = 60.000000, depth = 24

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Oct 21 2019). PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release. PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information. PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

Display screen [1]:

Optimal for timing: 1920x1080@1@d=4@60Hz

(now: 1920x1080@d=8@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG: Optimal mode for timing on screenId 1 at 8 bpc: 1920x1080@1@d=4@60Hz PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: Switching screenId 1 to optimal native mode 1920x1080@60Hz. PTB-INFO: Current backbuffersize 0 x 0 versus display native size 1920 x 1080. PTB-INFO: Using GLEW version 2.0.0 for automatic detection of OpenGL extensions... PTB-INFO: Installation of the PsychtoolboxKernelDriver is strongly recommended if you care about precise visual PTB-INFO: onset timestamping or timing. See 'help PsychtoolboxKernelDriver' for installation instructions. PTB-INFO: Fixed point precision integer framebuffer enabled. PTB-INFO: System Frame buffer provides 8 bits for red channel. PTB-INFO: System Frame buffer provides 8 bits for green channel. PTB-INFO: System Frame buffer provides 8 bits for blue channel. PTB-INFO: System frame buffer provides 8 bits for alpha channel, but effective alpha bits depends on imaging pipeline setup, if any. PTB-DEBUG: PPM file magic is P6 -> Ok

CREATOR: GIMP PNM Filter Version 1.1

PTB-DEBUG: Recognized splash image of 432 x 89 pixels, maxlevel 255. Loading...

OpenGL-Vendor / renderer / version are: ATI Technologies Inc. - AMD Radeon Pro 460 OpenGL Engine - 2.1 ATI-3.0.68

OpenGL-Extensions are: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

PTB-DEBUG: Not running on Mesa graphics library. PTB-DEBUG: Interrogating Low-level renderer capabilities for onscreen window with handle 10: Indicator variables: FBO's 1, ATI_texture_float 1, ARB_texture_float 1, Vendor ATI Technologies Inc., Renderer AMD Radeon Pro 460 OpenGL Engine. Indicator variables: maxcolorattachments = 8, maxrectangletexturesize = 16384, maxnativealuinstructions = 16384. GPU supports UYVY - YCrCb texture formats for optimized handling of video content. GPU supports non-power-of-two textures. Basic framebuffer objects with rectangle texture rendertargets supported --> RGBA8 rendertargets with blending. Framebuffer objects support fast blitting between each other. Framebuffer objects support anti-aliasing via multisampling. Hardware supports floating point textures of 16bpc and 32bpc float format. Assuming ATI R300 core or later: Hardware supports basic floating point framebuffers of 16bpc and 32bpc float format. Assuming ATI R500 or later (maxtexsize=16384): Hardware supports floating point blending on 16bpc float format. Hardware supports full 32 bit floating point precision shading. Assuming ATI R600 or later (Max native ALU inst. = 16384): Hardware supports floating point blending and filtering on 16bpc and 32bpc float formats. Assuming hardware supports native OpenGL primitive smoothing (points, lines). Float color value 0.5 -> fixed point reads back as 128 ==> Rounds. No compiled in support for OpenML OML_sync_control extension. PTB-DEBUG: Interrogation done.

PTB-INFO: You are using a multi-display setup (2 active displays): PTB-INFO: Please read 'help MultiDisplaySetups' for specific information on the Do's, Dont's, PTB-INFO: and possible causes of trouble and how to diagnose and resolve them.

PTB-DEBUG: glClear splash image top-left reference pixel: 255 255 255 PTB-INFO: Using OpenGL GL_TEXTURE_RECTANGLE_EXT extension for efficient high-performance texture mapping... PTB-INFO: Threshold Settings for successfull video refresh calibration are: maxStdDev = 0.200000 msecs, maxDeviation = 10.000000 %, minSamples = 50, maxDuration = 5.000000 secs.

PTB-DEBUG: Output of all acquired samples of calibration run follows: PTB-DEBUG: Sample 0: 0.000000 PTB-DEBUG: Sample 1: 0.027012 PTB-DEBUG: Sample 2: 0.016667 PTB-DEBUG: Sample 3: 0.016666 PTB-DEBUG: Sample 4: 0.016631 PTB-DEBUG: Sample 5: 0.016697 PTB-DEBUG: Sample 6: 0.016660 PTB-DEBUG: Sample 7: 0.016688 PTB-DEBUG: Sample 8: 0.016641 PTB-DEBUG: Sample 9: 0.016676 PTB-DEBUG: Sample 10: 0.016650 PTB-DEBUG: Sample 11: 0.016689 PTB-DEBUG: Sample 12: 0.016691 PTB-DEBUG: Sample 13: 0.016645 PTB-DEBUG: Sample 14: 0.016650 PTB-DEBUG: Sample 15: 0.016668 PTB-DEBUG: Sample 16: 0.016671 PTB-DEBUG: Sample 17: 0.016684 PTB-DEBUG: Sample 18: 0.016654 PTB-DEBUG: Sample 19: 0.016663 PTB-DEBUG: Sample 20: 0.016676 PTB-DEBUG: Sample 21: 0.016643 PTB-DEBUG: Sample 22: 0.016687 PTB-DEBUG: Sample 23: 0.016659 PTB-DEBUG: Sample 24: 0.016669 PTB-DEBUG: Sample 25: 0.016697 PTB-DEBUG: Sample 26: 0.016643 PTB-DEBUG: Sample 27: 0.016626 PTB-DEBUG: Sample 28: 0.016715 PTB-DEBUG: Sample 29: 0.016646 PTB-DEBUG: Sample 30: 0.016699 PTB-DEBUG: Sample 31: 0.016648 PTB-DEBUG: Sample 32: 0.016649 PTB-DEBUG: Sample 33: 0.016653 PTB-DEBUG: Sample 34: 0.016666 PTB-DEBUG: Sample 35: 0.016692 PTB-DEBUG: Sample 36: 0.016914 PTB-DEBUG: Sample 37: 0.016400 PTB-DEBUG: Sample 38: 0.016696 PTB-DEBUG: Sample 39: 0.016663 PTB-DEBUG: Sample 40: 0.016670 PTB-DEBUG: Sample 41: 0.016643 PTB-DEBUG: Sample 42: 0.016689 PTB-DEBUG: Sample 43: 0.016644 PTB-DEBUG: Sample 44: 0.016673 PTB-DEBUG: Sample 45: 0.016664 PTB-DEBUG: Sample 46: 0.016630 PTB-DEBUG: Sample 47: 0.016686 PTB-DEBUG: Sample 48: 0.016653 PTB-DEBUG: Sample 49: 0.016672 PTB-DEBUG: Sample 50: 0.016663 PTB-DEBUG: Sample 51: 0.016657 PTB-DEBUG: End of calibration data for this run...

PTB-INFO: OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon Pro 460 OpenGL Engine :: 2.1 ATI-3.0.68 PTB-INFO: Renderer has 4096 MB of VRAM and a maximum 3972 MB of texture memory. PTB-INFO: VBL startline = 1080 , VBL Endline = -1 PTB-INFO: Beamposition queries unsupported or defective on this system. Using basic timestamping as fallback. PTB-INFO: Timestamps returned by Screen('Flip') will be therefore less robust and accurate. PTB-INFO: Measured monitor refresh interval from VBLsync = 16.665446 ms [60.004394 Hz]. (50 valid samples taken, stddev=0.055746 ms.) PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz]. PTB-INFO: Small deviations between reported values are normal and no reason to worry. PTB-INFO: Support for fast OffscreenWindows enabled. PTB-DEBUG: Swaprequest too close to last swap vbl (0.000027 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000024 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000120 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000299 secs) or between forbidden scanline 1 and 50. Delaying... The refresh interval reported by the operating system is 16.66667 ms. PTB-DEBUG: Allocated unicode string: 88.000000 79.000000 88.000000 79.000000 88.000000 79.000000 32.000000 60.000000 51.000000 32.000000 88.000000 79.000000 88.000000 79.000000 88.000000 79.000000 32.000000 60.000000 51.000000 32.000000 102.000000 114.000000 101.000000 115.000000 104.000000 32.000000 105.000000 110.000000 116.000000 101.000000 114.000000 118.000000 97.000000 108.000000 46.000000 46.000000 46.000000 32.000000 84.000000 104.000000 105.000000 115.000000 32.000000 99.000000 97.000000 110.000000 32.000000 116.000000 97.000000 107.000000 101.000000 32.000000 117.000000 112.000000 32.000000 116.000000 111.000000 32.000000 50.000000 48.000000 32.000000 115.000000 101.000000 99.000000 111.000000 110.000000 100.000000 115.000000 46.000000 46.000000 46.000000 PTB-DEBUG: DrawText: Trying to load external text renderer plugin from following file: [ /Applications/Psychtoolbox/PsychBasic/PsychPlugins/libptbdrawtext_ftgl64.dylib ] Measured refresh interval, as reported by "GetFlipInterval" is 16.66545 ms. (nsamples = 0, stddev = 0.00000 ms) PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least.

ans =

9.0000

PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0 PTB-DEBUG: In PsychCleanupTextRenderer: Releasing text renderer plugin completely. Hookchain 'CloseOnscreenWindowPostGLShutdown' : Slot 0: Id='Shutdown window callback into PsychJavaSwingCleanup().' : Runtime-Function : Evalstring= PsychJavaSwingCleanup; PTB-DEBUG: PsychPipelineProcessMacros: cmd = PsychJavaSwingCleanup; Display screen [1]: (now: 1920x1080@d=4@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: screenId 1 in framebuffer format fixup mode. Reverting to system setting. PTB missed 1 out of 600 stimulus presentation deadlines. One missed deadline is ok and an artifact of the measurement. PTB completed 0 stimulus presentations before the requested target time. Have a look at the plots for more details…

Screen('Preference', 'Verbosity', 16)

======== Screen() for evaluation of macOS visual presentation timing fix ======== ======== For evaluation by the Pelli lab and collaborators only! ======== ======== Functionally limited to drawing of simple FillRect and DrawLine ======== ======== and restricted text drawing ======== ======== The function will cease to work at beginning of 27-October-2019 ========

ans =

 3

DriftDemo PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1600 x 900, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1600 x 900, fps = 60.000000, depth = 24

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Oct 21 2019). PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release. PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information. PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

Display screen [1]:

Optimal for timing: 1920x1080@1@d=4@60Hz

(now: 1920x1080@d=8@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG: Optimal mode for timing on screenId 1 at 8 bpc: 1920x1080@1@d=4@60Hz PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: Switching screenId 1 to optimal native mode 1920x1080@60Hz. PTB-INFO: Current backbuffersize 0 x 0 versus display native size 1920 x 1080. PTB-INFO: Using GLEW version 2.0.0 for automatic detection of OpenGL extensions... PTB-INFO: Installation of the PsychtoolboxKernelDriver is strongly recommended if you care about precise visual PTB-INFO: onset timestamping or timing. See 'help PsychtoolboxKernelDriver' for installation instructions. PTB-INFO: Fixed point precision integer framebuffer enabled. PTB-INFO: System Frame buffer provides 8 bits for red channel. PTB-INFO: System Frame buffer provides 8 bits for green channel. PTB-INFO: System Frame buffer provides 8 bits for blue channel. PTB-INFO: System frame buffer provides 8 bits for alpha channel, but effective alpha bits depends on imaging pipeline setup, if any. PTB-DEBUG: PPM file magic is P6 -> Ok

CREATOR: GIMP PNM Filter Version 1.1

PTB-DEBUG: Recognized splash image of 432 x 89 pixels, maxlevel 255. Loading...

OpenGL-Vendor / renderer / version are: ATI Technologies Inc. - AMD Radeon Pro 460 OpenGL Engine - 2.1 ATI-3.0.68

OpenGL-Extensions are: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

PTB-DEBUG: Not running on Mesa graphics library. PTB-DEBUG: Interrogating Low-level renderer capabilities for onscreen window with handle 10: Indicator variables: FBO's 1, ATI_texture_float 1, ARB_texture_float 1, Vendor ATI Technologies Inc., Renderer AMD Radeon Pro 460 OpenGL Engine. Indicator variables: maxcolorattachments = 8, maxrectangletexturesize = 16384, maxnativealuinstructions = 16384. GPU supports UYVY - YCrCb texture formats for optimized handling of video content. GPU supports non-power-of-two textures. Basic framebuffer objects with rectangle texture rendertargets supported --> RGBA8 rendertargets with blending. Framebuffer objects support fast blitting between each other. Framebuffer objects support anti-aliasing via multisampling. Hardware supports floating point textures of 16bpc and 32bpc float format. Assuming ATI R300 core or later: Hardware supports basic floating point framebuffers of 16bpc and 32bpc float format. Assuming ATI R500 or later (maxtexsize=16384): Hardware supports floating point blending on 16bpc float format. Hardware supports full 32 bit floating point precision shading. Assuming ATI R600 or later (Max native ALU inst. = 16384): Hardware supports floating point blending and filtering on 16bpc and 32bpc float formats. Assuming hardware supports native OpenGL primitive smoothing (points, lines). Float color value 0.5 -> fixed point reads back as 128 ==> Rounds. No compiled in support for OpenML OML_sync_control extension. PTB-DEBUG: Interrogation done.

PTB-INFO: You are using a multi-display setup (2 active displays): PTB-INFO: Please read 'help MultiDisplaySetups' for specific information on the Do's, Dont's, PTB-INFO: and possible causes of trouble and how to diagnose and resolve them.

PTB-DEBUG: glClear splash image top-left reference pixel: 255 255 255 PTB-INFO: Using OpenGL GL_TEXTURE_RECTANGLE_EXT extension for efficient high-performance texture mapping... PTB-INFO: Threshold Settings for successfull video refresh calibration are: maxStdDev = 0.200000 msecs, maxDeviation = 10.000000 %, minSamples = 50, maxDuration = 5.000000 secs.

PTB-DEBUG: Output of all acquired samples of calibration run follows: PTB-DEBUG: Sample 0: 0.000000 PTB-DEBUG: Sample 1: 0.030830 PTB-DEBUG: Sample 2: 0.016654 PTB-DEBUG: Sample 3: 0.016595 PTB-DEBUG: Sample 4: 0.016724 PTB-DEBUG: Sample 5: 0.016677 PTB-DEBUG: Sample 6: 0.016652 PTB-DEBUG: Sample 7: 0.016690 PTB-DEBUG: Sample 8: 0.016674 PTB-DEBUG: Sample 9: 0.016635 PTB-DEBUG: Sample 10: 0.016695 PTB-DEBUG: Sample 11: 0.016651 PTB-DEBUG: Sample 12: 0.016612 PTB-DEBUG: Sample 13: 0.016644 PTB-DEBUG: Sample 14: 0.016743 PTB-DEBUG: Sample 15: 0.016647 PTB-DEBUG: Sample 16: 0.016673 PTB-DEBUG: Sample 17: 0.016633 PTB-DEBUG: Sample 18: 0.016680 PTB-DEBUG: Sample 19: 0.016677 PTB-DEBUG: Sample 20: 0.016684 PTB-DEBUG: Sample 21: 0.016642 PTB-DEBUG: Sample 22: 0.016695 PTB-DEBUG: Sample 23: 0.016637 PTB-DEBUG: Sample 24: 0.016674 PTB-DEBUG: Sample 25: 0.016668 PTB-DEBUG: Sample 26: 0.016677 PTB-DEBUG: Sample 27: 0.016665 PTB-DEBUG: Sample 28: 0.016669 PTB-DEBUG: Sample 29: 0.016621 PTB-DEBUG: Sample 30: 0.016733 PTB-DEBUG: Sample 31: 0.016626 PTB-DEBUG: Sample 32: 0.016689 PTB-DEBUG: Sample 33: 0.016687 PTB-DEBUG: Sample 34: 0.016612 PTB-DEBUG: Sample 35: 0.016734 PTB-DEBUG: Sample 36: 0.016599 PTB-DEBUG: Sample 37: 0.016704 PTB-DEBUG: Sample 38: 0.016685 PTB-DEBUG: Sample 39: 0.016650 PTB-DEBUG: Sample 40: 0.016664 PTB-DEBUG: Sample 41: 0.016666 PTB-DEBUG: Sample 42: 0.016652 PTB-DEBUG: Sample 43: 0.016674 PTB-DEBUG: Sample 44: 0.016651 PTB-DEBUG: Sample 45: 0.016693 PTB-DEBUG: Sample 46: 0.016657 PTB-DEBUG: Sample 47: 0.016669 PTB-DEBUG: Sample 48: 0.016677 PTB-DEBUG: Sample 49: 0.016604 PTB-DEBUG: Sample 50: 0.016656 PTB-DEBUG: Sample 51: 0.016671 PTB-DEBUG: End of calibration data for this run...

PTB-INFO: OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon Pro 460 OpenGL Engine :: 2.1 ATI-3.0.68 PTB-INFO: Renderer has 4096 MB of VRAM and a maximum 3972 MB of texture memory. PTB-INFO: VBL startline = 1080 , VBL Endline = -1 PTB-INFO: Beamposition queries unsupported or defective on this system. Using basic timestamping as fallback. PTB-INFO: Timestamps returned by Screen('Flip') will be therefore less robust and accurate. PTB-INFO: Measured monitor refresh interval from VBLsync = 16.664817 ms [60.006660 Hz]. (50 valid samples taken, stddev=0.033126 ms.) PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz]. PTB-INFO: Small deviations between reported values are normal and no reason to worry. PTB-INFO: Support for fast OffscreenWindows enabled. PTB-DEBUG: Swaprequest too close to last swap vbl (0.000026 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000027 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0 Display screen [1]: (now: 1920x1080@d=4@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: screenId 1 in framebuffer format fixup mode. Reverting to system setting. Error using Screen Unknown or invalid subfunction name - Typo? Check spelling of the function name. (error state H)

Error in DriftDemo (line 90) tex(i)=Screen('MakeTexture', w, round(gray+inc*m)); %#ok

Matlab 2019b

Screen('Preference', 'Verbosity', 16)

======== Screen() for evaluation of macOS visual presentation timing fix ======== ======== For evaluation by the Pelli lab and collaborators only! ======== ======== Functionally limited to drawing of simple FillRect and DrawLine ======== ======== and restricted text drawing ======== ======== The function will cease to work at beginning of 27-October-2019 ========

ans =

 3

VBLSyncTest

ans =

 0

PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1600 x 900, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1600 x 900, fps = 60.000000, depth = 24

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Oct 21 2019). PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release. PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information. PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

Display screen [1]:

Optimal for timing: 1920x1080@1@d=4@60Hz

(now: 1920x1080@d=8@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG: Optimal mode for timing on screenId 1 at 8 bpc: 1920x1080@1@d=4@60Hz PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: Switching screenId 1 to optimal native mode 1920x1080@60Hz. PTB-INFO: Current backbuffersize 0 x 0 versus display native size 1920 x 1080. PTB-INFO: Using GLEW version 2.0.0 for automatic detection of OpenGL extensions... PTB-INFO: Installation of the PsychtoolboxKernelDriver is strongly recommended if you care about precise visual PTB-INFO: onset timestamping or timing. See 'help PsychtoolboxKernelDriver' for installation instructions. PTB-INFO: Fixed point precision integer framebuffer enabled. PTB-INFO: System Frame buffer provides 8 bits for red channel. PTB-INFO: System Frame buffer provides 8 bits for green channel. PTB-INFO: System Frame buffer provides 8 bits for blue channel. PTB-INFO: System frame buffer provides 8 bits for alpha channel, but effective alpha bits depends on imaging pipeline setup, if any. PTB-DEBUG: PPM file magic is P6 -> Ok

CREATOR: GIMP PNM Filter Version 1.1

PTB-DEBUG: Recognized splash image of 432 x 89 pixels, maxlevel 255. Loading...

OpenGL-Vendor / renderer / version are: ATI Technologies Inc. - AMD Radeon Pro 460 OpenGL Engine - 2.1 ATI-3.0.68

OpenGL-Extensions are: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

PTB-DEBUG: Not running on Mesa graphics library. PTB-DEBUG: Interrogating Low-level renderer capabilities for onscreen window with handle 10: Indicator variables: FBO's 1, ATI_texture_float 1, ARB_texture_float 1, Vendor ATI Technologies Inc., Renderer AMD Radeon Pro 460 OpenGL Engine. Indicator variables: maxcolorattachments = 8, maxrectangletexturesize = 16384, maxnativealuinstructions = 16384. GPU supports UYVY - YCrCb texture formats for optimized handling of video content. GPU supports non-power-of-two textures. Basic framebuffer objects with rectangle texture rendertargets supported --> RGBA8 rendertargets with blending. Framebuffer objects support fast blitting between each other. Framebuffer objects support anti-aliasing via multisampling. Hardware supports floating point textures of 16bpc and 32bpc float format. Assuming ATI R300 core or later: Hardware supports basic floating point framebuffers of 16bpc and 32bpc float format. Assuming ATI R500 or later (maxtexsize=16384): Hardware supports floating point blending on 16bpc float format. Hardware supports full 32 bit floating point precision shading. Assuming ATI R600 or later (Max native ALU inst. = 16384): Hardware supports floating point blending and filtering on 16bpc and 32bpc float formats. Assuming hardware supports native OpenGL primitive smoothing (points, lines). Float color value 0.5 -> fixed point reads back as 128 ==> Rounds. No compiled in support for OpenML OML_sync_control extension. PTB-DEBUG: Interrogation done.

PTB-INFO: You are using a multi-display setup (2 active displays): PTB-INFO: Please read 'help MultiDisplaySetups' for specific information on the Do's, Dont's, PTB-INFO: and possible causes of trouble and how to diagnose and resolve them.

PTB-DEBUG: glClear splash image top-left reference pixel: 255 255 255 PTB-INFO: Using OpenGL GL_TEXTURE_RECTANGLE_EXT extension for efficient high-performance texture mapping... PTB-INFO: Threshold Settings for successfull video refresh calibration are: maxStdDev = 0.200000 msecs, maxDeviation = 10.000000 %, minSamples = 50, maxDuration = 5.000000 secs.

PTB-DEBUG: Output of all acquired samples of calibration run follows: PTB-DEBUG: Sample 0: 0.000000 PTB-DEBUG: Sample 1: 0.030382 PTB-DEBUG: Sample 2: 0.016640 PTB-DEBUG: Sample 3: 0.016650 PTB-DEBUG: Sample 4: 0.016681 PTB-DEBUG: Sample 5: 0.016680 PTB-DEBUG: Sample 6: 0.016670 PTB-DEBUG: Sample 7: 0.016662 PTB-DEBUG: Sample 8: 0.016651 PTB-DEBUG: Sample 9: 0.016645 PTB-DEBUG: Sample 10: 0.016709 PTB-DEBUG: Sample 11: 0.016671 PTB-DEBUG: Sample 12: 0.016685 PTB-DEBUG: Sample 13: 0.016629 PTB-DEBUG: Sample 14: 0.016677 PTB-DEBUG: Sample 15: 0.016644 PTB-DEBUG: Sample 16: 0.016675 PTB-DEBUG: Sample 17: 0.016667 PTB-DEBUG: Sample 18: 0.016627 PTB-DEBUG: Sample 19: 0.016650 PTB-DEBUG: Sample 20: 0.016735 PTB-DEBUG: Sample 21: 0.016669 PTB-DEBUG: Sample 22: 0.016638 PTB-DEBUG: Sample 23: 0.016688 PTB-DEBUG: Sample 24: 0.016636 PTB-DEBUG: Sample 25: 0.016689 PTB-DEBUG: Sample 26: 0.016703 PTB-DEBUG: Sample 27: 0.016595 PTB-DEBUG: Sample 28: 0.016710 PTB-DEBUG: Sample 29: 0.016662 PTB-DEBUG: Sample 30: 0.016683 PTB-DEBUG: Sample 31: 0.016648 PTB-DEBUG: Sample 32: 0.016639 PTB-DEBUG: Sample 33: 0.016712 PTB-DEBUG: Sample 34: 0.016661 PTB-DEBUG: Sample 35: 0.016658 PTB-DEBUG: Sample 36: 0.016636 PTB-DEBUG: Sample 37: 0.016698 PTB-DEBUG: Sample 38: 0.016683 PTB-DEBUG: Sample 39: 0.016596 PTB-DEBUG: Sample 40: 0.016733 PTB-DEBUG: Sample 41: 0.016642 PTB-DEBUG: Sample 42: 0.016688 PTB-DEBUG: Sample 43: 0.016667 PTB-DEBUG: Sample 44: 0.016671 PTB-DEBUG: Sample 45: 0.016655 PTB-DEBUG: Sample 46: 0.016690 PTB-DEBUG: Sample 47: 0.016646 PTB-DEBUG: Sample 48: 0.016674 PTB-DEBUG: Sample 49: 0.016667 PTB-DEBUG: Sample 50: 0.016668 PTB-DEBUG: Sample 51: 0.016654 PTB-DEBUG: End of calibration data for this run...

PTB-INFO: OpenGL-Renderer is ATI Technologies Inc. :: AMD Radeon Pro 460 OpenGL Engine :: 2.1 ATI-3.0.68 PTB-INFO: Renderer has 4096 MB of VRAM and a maximum 3972 MB of texture memory. PTB-INFO: VBL startline = 1080 , VBL Endline = -1 PTB-INFO: Beamposition queries unsupported or defective on this system. Using basic timestamping as fallback. PTB-INFO: Timestamps returned by Screen('Flip') will be therefore less robust and accurate. PTB-INFO: Measured monitor refresh interval from VBLsync = 16.666171 ms [60.001786 Hz]. (50 valid samples taken, stddev=0.029099 ms.) PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz]. PTB-INFO: Small deviations between reported values are normal and no reason to worry. PTB-INFO: Support for fast OffscreenWindows enabled. PTB-DEBUG: Swaprequest too close to last swap vbl (0.000028 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000023 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000156 secs) or between forbidden scanline 1 and 50. Delaying... PTB-DEBUG: Swaprequest too close to last swap vbl (0.000611 secs) or between forbidden scanline 1 and 50. Delaying... The refresh interval reported by the operating system is 16.66667 ms. PTB-DEBUG: Allocated unicode string: 88.000000 79.000000 88.000000 79.000000 88.000000 79.000000 32.000000 60.000000 51.000000 32.000000 88.000000 79.000000 88.000000 79.000000 88.000000 79.000000 32.000000 60.000000 51.000000 32.000000 102.000000 114.000000 101.000000 115.000000 104.000000 32.000000 105.000000 110.000000 116.000000 101.000000 114.000000 118.000000 97.000000 108.000000 46.000000 46.000000 46.000000 32.000000 84.000000 104.000000 105.000000 115.000000 32.000000 99.000000 97.000000 110.000000 32.000000 116.000000 97.000000 107.000000 101.000000 32.000000 117.000000 112.000000 32.000000 116.000000 111.000000 32.000000 50.000000 48.000000 32.000000 115.000000 101.000000 99.000000 111.000000 110.000000 100.000000 115.000000 46.000000 46.000000 46.000000 PTB-DEBUG: DrawText: Trying to load external text renderer plugin from following file: [ /Applications/Psychtoolbox/PsychBasic/PsychPlugins/libptbdrawtext_ftgl64.dylib ] Measured refresh interval, as reported by "GetFlipInterval" is 16.66617 ms. (nsamples = 0, stddev = 0.00000 ms) PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least.

ans =

9.0000

PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0 PTB-DEBUG: In PsychCleanupTextRenderer: Releasing text renderer plugin completely. Hookchain 'CloseOnscreenWindowPostGLShutdown' : Slot 0: Id='Shutdown window callback into PsychJavaSwingCleanup().' : Runtime-Function : Evalstring= PsychJavaSwingCleanup; PTB-DEBUG: PsychPipelineProcessMacros: cmd = PsychJavaSwingCleanup;

INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline INFO: a total of 9 times out of a total of 605 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system) INFO: if you provided requested stimulus onset times with the 'when' argument of Screen('Flip', window [, when]); INFO: If you called Screen('Flip', window); without the 'when' argument, this count is more of a ''mild'' indicator INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ section at www.psychtoolbox.orghttp://www.psychtoolbox.org and the INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

Display screen [1]: (now: 1920x1080@d=4@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@60Hz 1344x1008@d=4@60Hz 1280x1024@d=8@60Hz 1280x1024@d=4@60Hz 1600x900@d=8@60Hz 1600x900@d=4@60Hz 800x450@2@d=8@60Hz 800x450@2@d=4@60Hz 1440x900@d=8@60Hz 1440x900@d=4@60Hz 720x450@2@d=8@60Hz 720x450@2@d=4@60Hz 1360x768@d=8@60Hz 1360x768@d=4@60Hz 1280x960@d=8@60Hz 1280x960@d=4@60Hz 1280x720@d=8@60Hz 1280x720@d=4@60Hz 1024x768@d=8@60Hz 1024x768@d=4@60Hz 1024x576@d=8@60Hz 1024x576@d=4@60Hz 848x480@d=8@60Hz 848x480@d=4@60Hz 800x600@d=8@60Hz 800x600@d=8@60Hz 800x600@d=8@56Hz 800x600@d=4@60Hz 800x600@d=4@60Hz 800x600@d=4@56Hz 640x480@d=8@60Hz 640x480@d=8@60Hz 640x480@d=4@60Hz 640x480@d=4@60Hz

PTB-DEBUG:PsychOSFixupFramebufferFormatForTiming: screenId 1 in framebuffer format fixup mode. Reverting to system setting. PTB missed 6 out of 600 stimulus presentation deadlines. One missed deadline is ok and an artifact of the measurement. PTB completed 0 stimulus presentations before the requested target time. Have a look at the plots for more details...

Screen('Preference', 'Verbosity', 16)

ans =

 3

DriftDemo PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 1024 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 800 x 600, fps = 56.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1280 x 960, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 1280 x 1024, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 848 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1360 x 768, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 1920 x 1080, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 640 x 480, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 800 x 600, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 1024 x 576, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 1344 x 1008, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1600 x 900, fps = 60.000000, depth = 24 PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1600 x 900, fps = 60.000000, depth = 24

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Oct 21 2019). PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release. PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information. PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

Display screen [1]:

Optimal for timing: 1920x1080@1@d=4@60Hz

(now: 1920x1080@d=8@60Hz) Allowed modes: 3840x2400@d=8@60Hz 3840x2400@d=4@60Hz 1920x1200@2@d=8@60Hz 1920x1200@2@d=4@60Hz 3360x2100@d=8@60Hz 3360x2100@d=4@60Hz 1680x1050@2@d=8@60Hz 1680x1050@2@d=4@60Hz 2880x1800@d=8@60Hz 2880x1800@d=4@60Hz 1440x900@2@d=8@60Hz 1440x900@2@d=4@60Hz 2560x1600@d=8@60Hz 2560x1600@d=4@60Hz 1280x800@2@d=8@60Hz 1280x800@2@d=4@60Hz 2560x1440@d=8@60Hz 2560x1440@d=4@60Hz 1280x720@2@d=8@60Hz 1280x720@2@d=4@60Hz 2048x1280@d=8@60Hz 2048x1280@d=4@60Hz 1024x640@2@d=8@60Hz 1024x640@2@d=4@60Hz 1920x1200@d=8@60Hz 1920x1200@d=4@60Hz 960x600@2@d=8@60Hz 960x600@2@d=4@60Hz 1920x1080@d=8@60Hz 1920x1080@d=8@60Hz 1920x1080@d=4@60Hz 1920x1080@d=4@60Hz 960x540@2@d=8@60Hz 960x540@2@d=8@60Hz 960x540@2@d=4@60Hz 960x540@2@d=4@60Hz 1680x1050@d=8@60Hz 1680x1050@d=4@60Hz 840x525@2@d=8@60Hz 840x525@2@d=4@60Hz 1600x1200@d=8@60Hz 1600x1200@d=4@60Hz 800x600@2@d=8@60Hz 800x600@2@d=4@60Hz 1344x1008@d=8@6

[iandol]

The google drive link is dead (I can only test this weekend...)

[stglasauer]

Hi all, I didn't carefully read all the messages, but I get the same error (see below) on Matlab R2019b (Update1) on Mac OSX 10.15 (on a MacBook Pro 15-inch, 2017) and on Mac OSX 10.14 (on a Mac Pro end 2013). On both machines it's working with older versions of Matlab (on the MacBook with 2018b, on the MacPro with 2017b). So the problem is not a Mac OSX problem, but apparently has something to do with Matlab 2019b.

Here's the error message:

PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.16 - Build date: Aug 5 2019). PTB-INFO: OS support status: OSX version 10.15 is not officially supported or tested at all for this release. PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information. PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

INTERNAL PSYCHTOOLBOX ERROR error: PsychError_InvalidWindowRecord general description: An Invalid window record was referenced. module name: Screen subfunction call: WindowKind file name: /Users/kleinerm/projects/OpenGLPsychtoolbox/Psychtoolbox-3/PsychSourceGL/Source/Common/Screen/WindowHelpers.c function name: PsychCheckIfWindowRecordIsValid line number: 61 Error using Screen See error message printed above.

Error in sca (line 22) if Screen('WindowKind', win) == 1

Error in DotDemo (line 290) sca;

Hope that helps, and many thanks to Mario and the whole team!

[kleinerm]

I replaced that one with an updated one to also deal with iMac specific macOS brokeness. Here's a new one, which should only make a difference on iMac's.

Screen.mexmaci64 https://drive.google.com/file/d/1b6MVF5iG2QTQpm6x45wYpfXsYsZ4uhGf/view?usp=drive_web

These are all evaluation copies with very limited feature set and limited lifetime. This one works until beginning 31st October.

By now Denis testing confirms this one works on macOS 10.14.6 - the only OS version that actually matters for the contract - on the MBP 2017 15 inch AMD and iMac 2014 5k Retina - the only machines that matter for the contract. It also works on an older MBP of Denis with AMD, a MacBook 2017 Retina with Intel gfx, a MBP 2010 with Intel and NVidia (this one on 10.13.6, as it is too old for 10.14.6), and a macMini 2012 with Intel on 10.13.6 and 10.14.6 iirc, and a few others.

So i'm somewhat confident that it should improve timing as much as possible, given the utter piece of garbage that current macOS is when it comes to visual stimulation timing. I found complete brokeness on all macOS versions since 10.12 on a variety of gpu's, even on ones where PTB's sync tests pass. The PsychoPy guys did some testing recently with hardware measurement equipment and confirm the brokenness on macOS.

Anyway, while more testing doesn't hurt in principle, it probably won't have any effect anymore in the near future.

@scarfelab Peter thanks for testing. However, 10.15. Catalina is a whole new level of brokenness when it comes to OpenGL, and not only OpenGL, at least as far as my testing with 10.15.0 on the 2017 MBP with AMD graphics goes so far. I've observed similar failures. I want to do one more test with the macMini 2012 tomorrow, to see if the latest graphics bugs only affect modern AMD or also Intel. I don't have immediate plans to look into Catalina improvements, given how painful and time consuming it was to get 10.11 - 10.14 sort of ok'ish fixed. This endeavour was another teaching moment for me: I shall never underestimate again just how incompetent Apples display graphics team is and what a time-sink to try to fix it up - should have asked for at least three times the money for this contract to cover the costs. I need a break from Apple OS'es for a while to get the blood pressure down again. Atm. i'm trying to turn the 2017 MBP into a half-way usable Laptop for running modern Linux, so i can get at least some use and joy out of it - at least as long as the keyboard doesn't break, the amount of dust it already collects scares me, as the next Apple repair shop is probably in Stuttgart and i read that the 2016 - 2018 models keyboards often don't even last a month without exchange if the wrong speck of dust comes close to them.

thanks, -mario

On Sat, Oct 26, 2019 at 4:18 AM Ian Max Andolina notifications@github.com wrote:

The google drive link is dead (I can only test this weekend...)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNRH6ZI23OK7OG3BRY3QQOSGZA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECJ5NLA#issuecomment-546559660, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNX3VLZIR4RUFLNKDDTQQOSGZANCNFSM4I2JMOXA .

[iandol]

I can't test on my Macbook Pro, but for my desktop iMac (Intel iGPU only) Screen at least now runs on 2019b, though it drops all frames (IFI is ~100ms). See log here FYI (macOS 10.15.0 + Matlab 2019b, KEXT installed and intel GPU warning overridden; I know none of this setup is part of your fix, it just provides a datapoint):

https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-intelgpu-imac-matlab2019b-macos10-15-log

[kleinerm]

Ian, thanks, but the PTB kernel driver wasn't used during your test. setenv('PSYCH_ALLOW_DANGEROUS','1'); needs to be used before first invocation of Screen - or a "clear all" is in order. I seem to remember that PTB kernel driver can't get installed into the regular /System/Library/Extensions/ but would need to go into something like /Volumes/Data/System/Library/Extensions iirc, because new Apple security bs. And apparently they want new extensions to go into something like /Library/Extensions/ now anyway - never tried it, but that /Volumes/... trick worked for me.

Having IFI of ~100 msecs was the best case scenario i observed on AMD with 10.15.: PTB didn't complain about timing/timestamping problems, so my fix worked on Catalina, visual display was correct, but performance was like 10 fps at most. That happened about half the time. The other half i got the same results, but additionally all stimuli were totally corrupted, looked like somebody scrambled them and then added some random noise and lines to it. This is yet another bug on top of the other bugs inherited from 10.11 - 10.14, freshly introduced into Catalina's OpenGL drivers. I hoped it would only be a AMD problem, but seems Intel is affected as well, hinting at not a simple bug but maximum level of incompetence in the higher level common OpenGL stack - just as i'd expect it from Apple by now, especially now that they declared they couldn't care less about OpenGL anymore.

On Mon, Oct 28, 2019 at 10:25 AM Ian Max Andolina notifications@github.com wrote:

I can't test on my Macbook Pro, but for my desktop iMac (Intel iGPU only) Screen at least now runs on 2019b, though it drops all frames (IFI is ~100ms). See log here FYI (macOS 10.15.0 + Matlab 2019b, KEXT installed and intel GPU warning overridden; I know none of this setup is part of your fix, it just provides a datapoint):

https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-intelgpu-imac-matlab2019b-macos10-15-log

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNUEIBPJ7NCR2ZVASE3QQ2VXBA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECMHFLY#issuecomment-546861743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNW6NEXKW5CYDH4ZZLDQQ2VXBANCNFSM4I2JMOXA .

[scarfelab]

Yes, I do not see this as surprising given that Apple have stated for some years now that OpenGL for them is depreciated.

Same with the kernel extension stuff. This has also been flagged up for some time now. So not surprising.

I cannot comment whether the above is “bs” or not. I don’t have the insight / knowledge.

It will be interesting to see where things go with Vulcan etc. OpenGL as it was looks to be on the way out generally (not just Apple) and it will be interesting to see what gains traction.

Happy to help in testing wherever needed.

On 28 Oct 2019, at 16:14, kleinerm notifications@github.com<mailto:notifications@github.com> wrote:

Ian, thanks, but the PTB kernel driver wasn't used during your test. setenv('PSYCH_ALLOW_DANGEROUS','1'); needs to be used before first invocation of Screen - or a "clear all" is in order. I seem to remember that PTB kernel driver can't get installed into the regular /System/Library/Extensions/ but would need to go into something like /Volumes/Data/System/Library/Extensions iirc, because new Apple security bs. And apparently they want new extensions to go into something like /Library/Extensions/ now anyway - never tried it, but that /Volumes/... trick worked for me.

Having IFI of ~100 msecs was the best case scenario i observed on AMD with 10.15.: PTB didn't complain about timing/timestamping problems, so my fix worked on Catalina, visual display was correct, but performance was like 10 fps at most. That happened about half the time. The other half i got the same results, but additionally all stimuli were totally corrupted, looked like somebody scrambled them and then added some random noise and lines to it. This is yet another bug on top of the other bugs inherited from 10.11 - 10.14, freshly introduced into Catalina's OpenGL drivers. I hoped it would only be a AMD problem, but seems Intel is affected as well, hinting at not a simple bug but maximum level of incompetence in the higher level common OpenGL stack - just as i'd expect it from Apple by now, especially now that they declared they couldn't care less about OpenGL anymore.

On Mon, Oct 28, 2019 at 10:25 AM Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

I can't test on my Macbook Pro, but for my desktop iMac (Intel iGPU only) Screen at least now runs on 2019b, though it drops all frames (IFI is ~100ms). See log here FYI (macOS 10.15.0 + Matlab 2019b, KEXT installed and intel GPU warning overridden; I know none of this setup is part of your fix, it just provides a datapoint):

https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-intelgpu-imac-matlab2019b-macos10-15-log

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNUEIBPJ7NCR2ZVASE3QQ2VXBA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECMHFLY#issuecomment-546861743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNW6NEXKW5CYDH4ZZLDQQ2VXBANCNFSM4I2JMOXA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRMP2RBCKXC5C4ND2DDQQ4FXRA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNOTTY#issuecomment-547023311, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRLGNMPYDWUHMVZS4NTQQ4FXRANCNFSM4I2JMOXA.

[iandol]

@kleinerm — I thought I had done a clear Screen, but anyway I've regenerated that log: https://gist.github.com/iandol/c33572380676ef23695ca69d942dfcd5#file-vblsynctest-kext-intelgpu-imac-matlab2019b-macos10-15-log — and it seems to be using the kernel driver (PTB-INFO: Connection to Psychtoolbox kernel support driver instance #0 (Revision 1) established.). And kextstat shows:

➜ kextstat -b PsychtoolboxKernelDriver
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  142    0 0xffffff7f80f47000 0xa000     0xa000     PsychtoolboxKernelDriver (1.1) 2DA457B8-5775-3657-9A67-1D6DAB2AC5AF <13 5 3>

I found that if I remount root (sudo mount -u -w /), this allows install of the kext into (now virtual) /system, my script to install the kernel driver is here: https://github.com/iandol/dotfiles/blob/master/bin/ptbkernel.sh

Anyway, I suspect that the very poor timing is actually something to do with a retina issue somewhere else, I see my whole desktop briefly resize into a 1/4 image before the PTB welcome screen (hard to catch with a screenshot), and the welcome screen looks as if it is sized for full retina mode (on this machine 2048×1152 is actually 4096×2304, welcome screen looks like it is displayed at 4096×2304), then the square of VBLSync now looks OK, then another flicker and again I see my desktop at 1/4 size before returning.

When running the GLView benchmark (which is windowed), up to OpenGL 4.1 it runs smoothly in macOS Catalina (as do OpenGL screensavers, though several have sizing issues too, performance is smooth):

[iandol]

BTW, If I disable the Hi-DPI backing plane (OpenGL thinks it is 2048×1152), I can run GLView fullscreen at ~970fps, when I enable Hi-DPI backing plane (OpenGL thinks it is 4096×2304), then framerate drops to ~190fps on this Intel iGPU iMac.

http://realtech-vr.com/admin/glview

[kleinerm]

Your latest test results with the PTB kernel driver look perfect wrt. timing/timestamping, confirming the current bug fix works on 10.15 as well. That performance and sometimes image quality sucks on the latest trainwreck is an unrelated new OpenGL bug. That also happens on non-Retina displays, e.g., my good ol' VGA CRT connected via USB-C -> HDMI -> DVI -> VGA adapter. And also in windowed mode. But PTB's way of using the display is more advanced and demanding than some standard OpenGL benchmark. I also seem to remember that some PTB demos ran just fine sometimes.

Anyway, it doesn't matter. Tracking this down will likely take lots of extra time, with no guarantee of success, so somebody will have to pay for the work time for fixing up 10.15. First payment for the current batch of bug fixes has to happen, so i can release those. Then i have tons of other work to do for a while to advance the real operating systems forward. I can only take so much exposure to macOS per year without losing it.

On Tue, Oct 29, 2019 at 4:50 AM Ian Max Andolina notifications@github.com wrote:

BTW, If I disable the Hi-DPI backing plane (OpenGL thinks it is 2048×1152), I can run GLView fullscreen at ~970fps, when I enable Hi-DPI backing plane (OpenGL thinks it is 4096×2304), then framerate drops to ~190fps on this Intel iGPU iMac.

http://realtech-vr.com/admin/glview

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNQAN2BGVCPFOQAOWTDQQ6XH7A5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPESMY#issuecomment-547244339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNTCICZRNVZBUZQTQ3LQQ6XH7ANCNFSM4I2JMOXA .

[kleinerm]

So i spent a few hours in the lab last night, among doing more useful things also testing the macMini 2012 with Intel HD 4000 IvyBridge gfx on Apples latest trainwreck. Graphics quality was fine, PTB's tests suggested timing was fine, but performance was slow. But the slowness doesn't seem to come from OpenGL, but from KbCheck taking massive amounts of time per invocation. If you remove KbCheck et al. from a test script, it runs fast again. Or RestrictKeysForKbCheck(KbName('q')); for example to only query one 'q' key. Seems not only their gfx/display department is filled with incompetents. Can you confirm this?

On Tue, Oct 29, 2019 at 9:07 PM Mario Kleiner mario.kleiner.de@gmail.com wrote:

Your latest test results with the PTB kernel driver look perfect wrt. timing/timestamping, confirming the current bug fix works on 10.15 as well. That performance and sometimes image quality sucks on the latest trainwreck is an unrelated new OpenGL bug. That also happens on non-Retina displays, e.g., my good ol' VGA CRT connected via USB-C -> HDMI -> DVI -> VGA adapter. And also in windowed mode. But PTB's way of using the display is more advanced and demanding than some standard OpenGL benchmark. I also seem to remember that some PTB demos ran just fine sometimes.

Anyway, it doesn't matter. Tracking this down will likely take lots of extra time, with no guarantee of success, so somebody will have to pay for the work time for fixing up 10.15. First payment for the current batch of bug fixes has to happen, so i can release those. Then i have tons of other work to do for a while to advance the real operating systems forward. I can only take so much exposure to macOS per year without losing it.

On Tue, Oct 29, 2019 at 4:50 AM Ian Max Andolina notifications@github.com wrote:

BTW, If I disable the Hi-DPI backing plane (OpenGL thinks it is 2048×1152), I can run GLView fullscreen at ~970fps, when I enable Hi-DPI backing plane (OpenGL thinks it is 4096×2304), then framerate drops to ~190fps on this Intel iGPU iMac.

http://realtech-vr.com/admin/glview

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNQAN2BGVCPFOQAOWTDQQ6XH7A5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPESMY#issuecomment-547244339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNTCICZRNVZBUZQTQ3LQQ6XH7ANCNFSM4I2JMOXA .

[scarfelab]

I won’t have time until early next week, but would be happy to do further tests then if it would be of any help.

P

On 30 Oct 2019, at 13:46, kleinerm notifications@github.com<mailto:notifications@github.com> wrote:

So i spent a few hours in the lab last night, among doing more useful things also testing the macMini 2012 with Intel HD 4000 IvyBridge gfx on Apples latest trainwreck. Graphics quality was fine, PTB's tests suggested timing was fine, but performance was slow. But the slowness doesn't seem to come from OpenGL, but from KbCheck taking massive amounts of time per invocation. If you remove KbCheck et al. from a test script, it runs fast again. Or RestrictKeysForKbCheck(KbName('q')); for example to only query one 'q' key. Seems not only their gfx/display department is filled with incompetents. Can you confirm this?

On Tue, Oct 29, 2019 at 9:07 PM Mario Kleiner mario.kleiner.de@gmail.com<mailto:mario.kleiner.de@gmail.com> wrote:

Your latest test results with the PTB kernel driver look perfect wrt. timing/timestamping, confirming the current bug fix works on 10.15 as well. That performance and sometimes image quality sucks on the latest trainwreck is an unrelated new OpenGL bug. That also happens on non-Retina displays, e.g., my good ol' VGA CRT connected via USB-C -> HDMI -> DVI -> VGA adapter. And also in windowed mode. But PTB's way of using the display is more advanced and demanding than some standard OpenGL benchmark. I also seem to remember that some PTB demos ran just fine sometimes.

Anyway, it doesn't matter. Tracking this down will likely take lots of extra time, with no guarantee of success, so somebody will have to pay for the work time for fixing up 10.15. First payment for the current batch of bug fixes has to happen, so i can release those. Then i have tons of other work to do for a while to advance the real operating systems forward. I can only take so much exposure to macOS per year without losing it.

On Tue, Oct 29, 2019 at 4:50 AM Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

BTW, If I disable the Hi-DPI backing plane (OpenGL thinks it is 2048×1152), I can run GLView fullscreen at ~970fps, when I enable Hi-DPI backing plane (OpenGL thinks it is 4096×2304), then framerate drops to ~190fps on this Intel iGPU iMac.

http://realtech-vr.com/admin/glview

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNQAN2BGVCPFOQAOWTDQQ6XH7A5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPESMY#issuecomment-547244339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNTCICZRNVZBUZQTQ3LQQ6XH7ANCNFSM4I2JMOXA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRLADCY2C46NEYA67NLQRGF2HA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECUHIQA#issuecomment-547910720, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRL3UPKRKY3NPONYNBTQRGF2HANCNFSM4I2JMOXA.

[iandol]

So i spent a few hours in the lab last night, among doing more useful things also testing the macMini 2012 with Intel HD 4000 IvyBridge gfx on Apples latest trainwreck. Graphics quality was fine, PTB's tests suggested timing was fine, but performance was slow. But the slowness doesn't seem to come from OpenGL, but from KbCheck taking massive amounts of time per invocation. If you remove KbCheck et al. from a test script, it runs fast again. Or RestrictKeysForKbCheck(KbName('q')); for example to only query one 'q' key. Seems not only their gfx/display department is filled with incompetents. Can you confirm this?

Hi Mario, I can test (as VBLSyncTest does use KbCheck) but the modified Screen has stopped working (it is the 31st here), and my iMac is Catalina so old Screen non-functional.

[kleinerm]

You don't need a functional Screen for that:

tic; for i=1:1000, KbCheck; end; toc

-> I get 102 msecs per KbCheck on a fast MBP 2017 with touchbar gimmick under 10.15.1. The new KbCheck can deal with the generally useless and annoying touchbar gimmick - and has to, because ESCape key is now part of the touchbar which is a separate "keyboard". I think query of the touchbar alone adds some 86 msecs.

I did some profiling on Catalina and this time the morons at Apple fucked up IOKit, because lack of talent and care seems to be not restricted to the graphics and display group. It's also great how Catalina now replicates the wildly popular endless number of "ask for permission" dialogs that made Microsoft Windows Vista such a beloved operating system. Except the consquences of clicking "Deny" here are more long lasting and annoying, can't wait for the first users writing bug reports.

On Thu, Oct 31, 2019 at 5:29 AM Ian Max Andolina notifications@github.com wrote:

So i spent a few hours in the lab last night, among doing more useful things also testing the macMini 2012 with Intel HD 4000 IvyBridge gfx on Apples latest trainwreck. Graphics quality was fine, PTB's tests suggested timing was fine, but performance was slow. But the slowness doesn't seem to come from OpenGL, but from KbCheck taking massive amounts of time per invocation. If you remove KbCheck et al. from a test script, it runs fast again. Or RestrictKeysForKbCheck(KbName('q')); for example to only query one 'q' key. Seems not only their gfx/display department is filled with incompetents. Can you confirm this?

Hi Mario, I can test (as VBLSyncTest does use KbCheck) but the modified Screen has stopped working (it is the 31st here), and my iMac is Catalina so old Screen non-functional.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNV7N3J2BCFHGXR7QDDQRJNLNA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWQ5LI#issuecomment-548212397, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNVP37CY6ZC5DGWEETTQRJNLNANCNFSM4I2JMOXA .

[scarfelab]

Hi Mario,

Results below.

A quick comment: Whilst I know you "worship at the church of Linux" (I think you described things similarly for Mac users), you verge on doing a disservice to PTB (and all the work you have put into it) by constantly berating people who dare to use anything but Linux.

Yes, Linux is better for high fidelity vision science, for all the reasons you state. But believe it or not, people use other operating systems! Especially for prototyping code.

By constantly denigrating anyone who uses anything but Linux (even if you do not know what they are using it for - e.g. prototyping versus actual experiments), you are pushing people away from using PTB.

So, whilst I can feel your frustration with the “train wreak” and the “iToy Company”; you have to realise that you are actively discouraging people from using PTB by doing this. Even though PTB is a fantastic system.

This is nothing I have not already said. But you need to realise that there are two things here:

(1) Pointing out glaring problems for doing vision science with certain operating systems, for specific tasks, which will be pretty much the same for any other systems e.g. PsychoPy.

(2) Denigrating anyone for daring to do vision science without using Linux.

Anyhow. Let me know how I can help with any further debugging of the “train wreak” “iToy” system.

Happy to help.

P

This is what I get with Matlab 2019a. The first evocation results in an error. The second runs. Results reported.

tic; for i=1:1000, KbCheck; end; toc PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least. Elapsed time is 0.088298 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.026540 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.022429 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.028894 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.026473 seconds.

Same pattern with 2019b

tic; for i=1:1000, KbCheck; end; toc PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least. Elapsed time is 0.073182 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.025135 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.021499 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.030307 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.029662 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.026336 seconds.

On 31 Oct 2019, at 18:34, kleinerm notifications@github.com<mailto:notifications@github.com> wrote:

You don't need a functional Screen for that:

tic; for i=1:1000, KbCheck; end; toc

-> I get 102 msecs per KbCheck on a fast MBP 2017 with touchbar gimmick under 10.15.1. The new KbCheck can deal with the generally useless and annoying touchbar gimmick - and has to, because ESCape key is now part of the touchbar which is a separate "keyboard". I think query of the touchbar alone adds some 86 msecs.

I did some profiling on Catalina and this time the morons at Apple fucked up IOKit, because lack of talent and care seems to be not restricted to the graphics and display group. It's also great how Catalina now replicates the wildly popular endless number of "ask for permission" dialogs that made Microsoft Windows Vista such a beloved operating system. Except the consquences of clicking "Deny" here are more long lasting and annoying, can't wait for the first users writing bug reports.

On Thu, Oct 31, 2019 at 5:29 AM Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

So i spent a few hours in the lab last night, among doing more useful things also testing the macMini 2012 with Intel HD 4000 IvyBridge gfx on Apples latest trainwreck. Graphics quality was fine, PTB's tests suggested timing was fine, but performance was slow. But the slowness doesn't seem to come from OpenGL, but from KbCheck taking massive amounts of time per invocation. If you remove KbCheck et al. from a test script, it runs fast again. Or RestrictKeysForKbCheck(KbName('q')); for example to only query one 'q' key. Seems not only their gfx/display department is filled with incompetents. Can you confirm this?

Hi Mario, I can test (as VBLSyncTest does use KbCheck) but the modified Screen has stopped working (it is the 31st here), and my iMac is Catalina so old Screen non-functional.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNV7N3J2BCFHGXR7QDDQRJNLNA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWQ5LI#issuecomment-548212397, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNVP37CY6ZC5DGWEETTQRJNLNANCNFSM4I2JMOXA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRJQM5BSF45B65UQ5MTQRMQKNA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECY2B5Y#issuecomment-548511991, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRNHQYIXBBMTNGTMVS3QRMQKNANCNFSM4I2JMOXA.

[iandol]

OK, from my iGPU iMac macOS 10.15.1 under MATLAB 2019b:

>> t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 128.53 ms per KbCheck.

I don't see any errors like Peter, but timing is terrible. So yes, that explains the timing issues I saw with VBLSyncTest. I'll test my Macbook Pro (no touchbar) when I get a chance...

[scarfelab]

Eek. Thats bad.

Forgot to say, I tested on a MacBook Pro with Touch Bar running 10.15.1

Don’t have any other Macs so would not be able to provide any additional datapoints.

On 1 Nov 2019, at 00:08, Ian Max Andolina notifications@github.com<mailto:notifications@github.com> wrote:

OK, from my iGPU iMac macOS 10.15.1 under MATLAB 2019b:

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 128.53 ms per KbCheck.

So yes, that explains the timing issues I saw with VBLSyncTest. I'll test my Macbook Pro (no touchbar) when I get a chance...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRJYCFTOXISF2O4LPV3QRNXQLA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZTWEY#issuecomment-548616979, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELPKRLDRORPAXEGMLHY2SDQRNXQLANCNFSM4I2JMOXA.

[kleinerm]

Peter i guess the reason you get much lower execution times is because it doesn't work? If you call KbStrokeWait and press a key afterwards it probably doesn't register. Iow. it can fail much faster than actually run successfully. That was the case on my fresh 10.15 installation before i went into system settings and jumped through all the hoops to enable low-level keyboard access and then restarted octave. After that it could register keypresses and all animations slowed down to a crawl.

On Fri, Nov 1, 2019 at 11:14 AM scarfelab notifications@github.com wrote:

Eek. Thats bad.

Forgot to say, I tested on a MacBook Pro with Touch Bar running 10.15.1

Don’t have any other Macs so would not be able to provide any additional datapoints.

On 1 Nov 2019, at 00:08, Ian Max Andolina <notifications@github.com mailto:notifications@github.com> wrote:

OK, from my iGPU iMac macOS 10.15.1 under MATLAB 2019b:

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 128.53 ms per KbCheck.

So yes, that explains the timing issues I saw with VBLSyncTest. I'll test my Macbook Pro (no touchbar) when I get a chance...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AELPKRJYCFTOXISF2O4LPV3QRNXQLA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZTWEY#issuecomment-548616979>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AELPKRLDRORPAXEGMLHY2SDQRNXQLANCNFSM4I2JMOXA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNVGRBOCUCZGQCBVNWTQRP6QBA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC2RABI#issuecomment-548737029, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNUISTCO434TGW2SCULQRP6QBANCNFSM4I2JMOXA .

[stglasauer]

Here’s my test with KBCheck:

MacBook Pro (15-inch, 2017), with touchbar

Matlab 2018b

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 11.21 ms per KbCheck.

Matlab 2019b Update1

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 0.03 ms per KbCheck.

BUT I got these messages first in Matlab 2019b: PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least.

Am 01.11.2019 um 01:08 schrieb Ian Max Andolina notifications@github.com:

OK, from my iGPU iMac macOS 10.15.1 under MATLAB 2019b:

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 128.53 ms per KbCheck. So yes, that explains the timing issues I saw with VBLSyncTest. I'll test my Macbook Pro (no touchbar) when I get a chance...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AM3YRWKQLXNTJ2A7HDB2S53QRNXQLA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZTWEY#issuecomment-548616979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM3YRWOAIG7NKGHA23XNHFLQRNXQLANCNFSM4I2JMOXA.

[kleinerm]

See above the reply to Peter's results. Thanks for testing, but i don't think i'll need more test results. I already roughly know where Apple screwed up this time. The more interesting question for me is, who will pay this time for the work to fix Apples latest screwup, if that is even possible? Because certainly not me anytime soon.

Of course if Peters assumption is correct that most Mac users do understand all the limitations of Apples fine products - and i doubt it - and mostly use them only for unimportant prototyping, then a super-slow KbCheck should not be an issue for anybody?

On Fri, Nov 1, 2019 at 3:06 PM stglasauer notifications@github.com wrote:

Here’s my test with KBCheck:

MacBook Pro (15-inch, 2017), with touchbar

Matlab 2018b

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 11.21 ms per KbCheck.

Matlab 2019b Update1

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 0.03 ms per KbCheck.

BUT I got these messages first in Matlab 2019b: PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least.

Am 01.11.2019 um 01:08 schrieb Ian Max Andolina < notifications@github.com>:

OK, from my iGPU iMac macOS 10.15.1 under MATLAB 2019b:

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 128.53 ms per KbCheck. So yes, that explains the timing issues I saw with VBLSyncTest. I'll test my Macbook Pro (no touchbar) when I get a chance...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AM3YRWKQLXNTJ2A7HDB2S53QRNXQLA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZTWEY#issuecomment-548616979>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AM3YRWOAIG7NKGHA23XNHFLQRNXQLANCNFSM4I2JMOXA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNTDXABODO4B7X5TGTDQRQZXFA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC3ANBI#issuecomment-548800133, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNW3CLN57ZKTPGMTCV3QRQZXFANCNFSM4I2JMOXA .

[iandol]

Mario, you don't owe anyone anything, we all owe you (even if not all of us can authorise contract work from grants easily)! I would prefer if PTB would work enough to be useable on my preferred working OS, but that is certainly not your cross to bear. Your unique expertise and ability lies in optimising low-level stuff, and you are obviously most productive in an open-source space for that. PTB on Linux is clearly the best platform that people should be collecting data on...

[scarfelab]

Hi Mario, Your assumption looks to have been correct. Below are the results from 2019a now

tic; for i=1:1000, KbCheck; end; toc Elapsed time is 15.171220 seconds.

"Of course if Peters assumption is correct that most Mac users do understand all the limitations of Apples fine products - and i doubt it - and mostly use them only for unimportant prototyping, then a super-slow KbCheck should not be an issue for anybody?"

-> This was not my assumption, or what I said.

P

[kleinerm]

Everybody try this PsychHID.mexmaci64 from my GitHub master:

https://github.com/kleinerm/Psychtoolbox-3/raw/master/Psychtoolbox/PsychBasic/PsychHID.mexmaci64

Another 1.25 weekend days ruined, another 1200 euros of billable work given away for free to support the machine sales and revenue of the richest and most incompetent/indifferent computer company on the planet. And i found new horrors on the side of Octave for macOS, rendering octave quite useless now. Usually, whatever hits octave on macOS will hit Matlab with a 12 months delay, because octave being freshly compiled individually for each macOS version by/from HomeBrew always uses the latest and therefore most broken Apple frameworks, whereas Matlab is built more conservatively to save maintenance costs at Mathworks, so it can coast a bit longer on the good times.

This one gets KbCheck down to ~ 3.3 msecs per invocation on a touchbar 2017 MBP, thanks to new optimization hacks piled on top of the other hacks that were used to work around other bugs introduced by Apple in 10.13 in 2017 and 2012 and in a few years between (because Apple thinks that careful work, backwards compatibility and quality testing is for losers). We now avoid lots of calls to the broken IOKit of 10.15, calls which may or may not be redundant or neccessary on typical keyboards, depending on what else the iToy company screwed up the last years.

If this works out ok, ok. Otherwise serious money would have to flow to do anything more on this. If one of you finds problems with the new PsychHID i'll simply revert this hack and be done with it.

On Mon, Nov 4, 2019 at 10:21 AM scarfelab notifications@github.com wrote:

Hi Mario, Your assumption looks to have been correct. Below are the results from 2019a now

tic; for i=1:1000, KbCheck; end; toc Elapsed time is 15.171220 seconds.

"Of course if Peters assumption is correct that most Mac users do understand all the limitations of Apples fine products - and i doubt it - and mostly use them only for unimportant prototyping, then a super-slow KbCheck should not be an issue for anybody?"

-> This was not my assumption, or what I said.

P

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNTVTIWPVZCROBB7I5TQR7STBA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC6T2DI#issuecomment-549272845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNSYAJFTQTLEQH4PBR3QR7STBANCNFSM4I2JMOXA .

[stglasauer]

MacBook Pro (15-inch, 2017), macOS 10.15.1 (19B88)

Matlab 2018b

tic; for i=1:1000, KbCheck; end; toc Elapsed time is 1.596323 seconds.

This is an improvement by a factor 10.

Matlab 2019b Update1

tic; for i=1:1000, KbCheck; end; toc PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least. Elapsed time is 0.158007 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.029616 seconds.

No change for Matlab 2019b, it was the same before with the previous PsychHID.mexmaci64

Am 04.11.2019 um 14:30 schrieb kleinerm notifications@github.com:

Everybody try this PsychHID.mexmaci64 from my GitHub master:

https://github.com/kleinerm/Psychtoolbox-3/raw/master/Psychtoolbox/PsychBasic/PsychHID.mexmaci64

Another 1.25 weekend days ruined, another 1200 euros of billable work given away for free to support the machine sales and revenue of the richest and most incompetent/indifferent computer company on the planet. And i found new horrors on the side of Octave for macOS, rendering octave quite useless now. Usually, whatever hits octave on macOS will hit Matlab with a 12 months delay, because octave being freshly compiled individually for each macOS version by/from HomeBrew always uses the latest and therefore most broken Apple frameworks, whereas Matlab is built more conservatively to save maintenance costs at Mathworks, so it can coast a bit longer on the good times.

This one gets KbCheck down to ~ 3.3 msecs per invocation on a touchbar 2017 MBP, thanks to new optimization hacks piled on top of the other hacks that were used to work around other bugs introduced by Apple in 10.13 in 2017 and 2012 and in a few years between (because Apple thinks that careful work, backwards compatibility and quality testing is for losers). We now avoid lots of calls to the broken IOKit of 10.15, calls which may or may not be redundant or neccessary on typical keyboards, depending on what else the iToy company screwed up the last years.

If this works out ok, ok. Otherwise serious money would have to flow to do anything more on this. If one of you finds problems with the new PsychHID i'll simply revert this hack and be done with it.

On Mon, Nov 4, 2019 at 10:21 AM scarfelab notifications@github.com wrote:

Hi Mario, Your assumption looks to have been correct. Below are the results from 2019a now

tic; for i=1:1000, KbCheck; end; toc Elapsed time is 15.171220 seconds.

"Of course if Peters assumption is correct that most Mac users do understand all the limitations of Apples fine products - and i doubt it - and mostly use them only for unimportant prototyping, then a super-slow KbCheck should not be an issue for anybody?"

-> This was not my assumption, or what I said.

P

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AAIXMNTVTIWPVZCROBB7I5TQR7STBA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC6T2DI#issuecomment-549272845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIXMNSYAJFTQTLEQH4PBR3QR7STBANCNFSM4I2JMOXA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AM3YRWM6GXHXK7IAAKIKL7LQSAPY3A5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC7HSDY#issuecomment-549353743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM3YRWIQVIJY3XQKRJSJEH3QSAPY3ANCNFSM4I2JMOXA.

[kleinerm]

On Mon, Nov 4, 2019 at 2:48 PM stglasauer notifications@github.com wrote:

MacBook Pro (15-inch, 2017), macOS 10.15.1 (19B88)

Matlab 2018b

tic; for i=1:1000, KbCheck; end; toc Elapsed time is 1.596323 seconds.

This is an improvement by a factor 10.

Yes, that's expected. The speedup will be much higher once the next PTB makes use of the touchbar toy to get a working ESCape key back. The interesting question is if all keys on the keyboard work properly, and on externally connected keyboards, keypads, mice etc.

Matlab 2019b Update1

tic; for i=1:1000, KbCheck; end; toc PsychHID-ERROR: Could not enumerate and attach to all HID devices (HIDBuildDeviceList(0,0) failed)! PsychHID-ERROR: One reason could be that some HID devices are already exclusively claimed by some 3rd party device drivers PsychHID-ERROR: or applications. I will now retry to only claim control of a hopefully safe subset of devices like standard PsychHID-ERROR: keyboards, mice, gamepads and supported USB-DAQ devices and other vendor defined devices and hope this goes better... PsychHID-INFO: That worked. A subset of regular mouse, keyboard etc. input devices and maybe some vendor defined devices will be available at least. Elapsed time is 0.158007 seconds. tic; for i=1:1000, KbCheck; end; toc Elapsed time is 0.029616 seconds.

No change for Matlab 2019b, it was the same before with the previous PsychHID.mexmaci64

That's because, just like Peter, you pressed the wrong button, when some security dialog popped up and asked you some incomprehensible question relating to what Matlab may or may not do, without giving any meaningful context to the question. Your KbCheck is fast because it doesn't actually check the keyboard/doesn't get keyboard responses anymore. It just silently fails on that machine + Matlab version now.

So for a sample size of n=4, so far 50% of all test subjects failed the new Catalina usability challenge imposed by those security prompts. Something Apple would have known if they had looked at the Microsoft Vista security usability disaster, but they are an output only company. Microsoft got tons of criticism and ridicule for that and undid it in Windows-7. I'm sure Apple will get praises by their most loyal customers instead, while all the software companies still writing apps for macOS will bear the burden of increased user support costs and disgruntled users. Of course if those companies products are expensive enough then users will pay the bill.

-mario

[iandol]

macOS 10.15.1 + MATLAB 2019b update1 (making sure MATLAB is added to Privacy > Input monitoring).

>> t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 3.83 ms per KbCheck.

Works, thank you Mario!!! My Linux lab machine takes 0.1ms of course, and no annoying security prompts ;-)

[scarfelab]

Sorry for the delay... Yes, this works. In 2019a Update 6.

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 2.48 ms per KbCheck.

Happy to help with any additional debugging.

[kleinerm]

thanks. The important test would be to test if all keys on the keyboard that are supposed to work actually work, e.g., via KbDemo. And if that holds on different machines and also with different externally connected keyboards, or mouse buttons and similar devices that KbCheck is supposed to support. Also especially on macOS 10.14/10.13 as Catalina doesn't matter much at this point. More important to not break existing setups than fixing an OS that should not be used in any production setting anyway, given that all Apple OS'es of version 10.x.y with y < 4 or 5 have been especially bug ridden in the last half decade, and Catalina seems to be especially bad if i trust all the newstickers. I usually wait until a .6 version before considering an upgrade, because then i know they won't care about it anymore, only provide critical security updates, and therefore probably not screw it up too badly any longer.

However, my only solution to fix any problems that could show up in such situations would be to revert the workaround, have the slow keyboard again on Catalina, and "moneys please", if somebody would want a better fix. In that sense, further testing showing new problems may only speed up the process of reverting the workaround, not fixing the new problems for free. For old OS'es like != 10.15 one could always disable the workaround, so only Catalina would be broken.

On Wed, Nov 6, 2019 at 6:23 PM scarfelab notifications@github.com wrote:

Sorry for the delay... Yes, this works. In 2019a Update 6.

t=tic; for i=1:1e3, KbCheck; end; tt=toc(t);fprintf('\nIt took: %3.2f ms per KbCheck.\n',(tt/1e3)*1e3);

It took: 2.48 ms per KbCheck.

Happy to help with any additional debugging.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kleinerm]

Seems the "corrupted visual stimuli" problems on AMD gpu's under macOS Catalina - a graphics/display driver bug in macOS - seem to be fixed with macOS 10.15.3? At least for my one and only Catalina + AMD test machine, the MBP 2017. Doing over 200 runs yielded zero failures, as opposed to the previous > 60% failure rate on 10.15.2 and earlier.

Can one of you with 10.15.3 and AMD graphics confirm that that specific problem is gone?

Otoh., now my machine under Catalina seems to have trouble with external displays connected via USB-C --> HDMI, either HDMI or DVI. Monitor gets detected, timing is good, but the monitor only shows a black screen, yay! VGA CRT still works. But this issue is not specific to PTB, known by Apple from apparently numerous bug reports, and unfixed since multiple releases. The internet is full of reports about this bug.

[iandol]

macOS 10.15.3 (19D76), AMD Radeon R9 M370X (2015 MBP) running a HDMI external 1920x180@60Hz, MATLAB 2019b update 3 and latest PTB + kernel driver — [Perceptual]VBLSyncTest looks good (though I get a few dropped frames, but currently I'm doing quite a lot of background stuff).

DriftDemo would only show a black screen with no errors (even when VBLSyncTest displayed stimuli fine). The difference is that DriftDemo and friends use Screen('OpenWindow'). If I rewrite DriftDemo to use PsychDefaultSetup(2); PsychImaging('OpenWindow', screenNumber, gray), then it works fine, and it seems that WhiteIndex/BlackIndex return 0/1 regardless of whether Screen is in 0-255 or 0-1 range (thus everything looking black). Not sure if this is a regression as I always use PsychImaging + floating point normally.

Running a complex set of multiple stimuli (that use PsychImaging) and everything looks fine. No visual noise or glitches.

And KbCheck() is still consistently ~2-3ms...

Thanks Mario!

[stglasauer]

macOS 10.15.3 (19D76), Radeon Pro 560 4 GB, MacBook Pro (15-inch, 2017), running on laptop screen, Matlab R2019b update 3 and latest PTB (revision 10423).

Did a couple of tests … and it looks great except for occasional hiccups

VBLSyncTest, first run, looks very good

INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline INFO: a total of 2 times out of a total of 605 flips during this session.

DriftDemo, first run, also very good

INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline INFO: a total of 4 times out of a total of 300 flips during this session.

KbDemo runs fine

DriftDemo also looks good!

Then I ran FontDemo, but this failed: ----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! -----

One or more internal checks (see Warnings above) indicate that synchronization of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.

A second run then seemed to work.

FlipTest, first run

Raising priority for test... Priority raised. Opening window and flipping frames. This should take about Inf seconds...

----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! -----

One or more internal checks (see Warnings above) indicate that synchronization of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.

FlipTest, second run

Raising priority for test... Priority raised. Opening window and flipping frames. This should take about Inf seconds... Priority restored. Test Results:. Median frame period: 0.016661 seconds Max frame period: 0.023356 seconds Min frame period: 0.010081 seconds Median frame frequency: 60.018905 seconds

If I run „clear all“ before calling any of the demos, then everything seems to work fine.

Hope that helps!

And many thanks, Mario!

Am 24.02.2020 um 08:19 schrieb Ian Max Andolina notifications@github.com:

macOS 10.15.3 (19D76), AMD Radeon R9 M370X (2015 MBP) running a HDMI external 1920x180@60Hz, MATLAB 2019b update 3 and latest PTB + kernel driver — [Perceptual]VBLSyncTest looks good (though I get a few dropped frames, but currently I'm doing quite a lot of background stuff).

DriftDemo would only show a black screen with no errors (even when VBLSyncTest displayed stimuli fine). The difference is that DriftDemo and friends use Screen('OpenWindow'). If I rewrite DriftDemo to use PsychDefaultSetup(2); PsychImaging('OpenWindow', screenNumber, gray), then it works fine, and it seems that WhiteIndex/BlackIndex return 0/1 regardless of whether Screen is in 0-255 or 0-1 range (thus everything looking black). Not sure if this is a regression as I always use PsychImaging + floating point normally.

Running a complex set of multiple stimuli (that use PsychImaging) and everything looks fine. No visual noise or glitches.

And KbCheck() is still consistently ~2-3ms...

Thanks Mario!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kleinerm/Psychtoolbox-3/issues/156?email_source=notifications&email_token=AM3YRWJDHD2NBGIJWSNJUFLRENYIRA5CNFSM4I2JMOXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMW2IHA#issuecomment-590193692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM3YRWM7JBLFEMOZKWNTAZTRENYIRANCNFSM4I2JMOXA.

[kleinerm]

Thanks

Sounds it is working also on other machines than mine, good.

@iandol No regression. It's just that PsychDefaultSetup(2) sets the default to expect 0-1 color range, and that doesn't get cleared until a "clear all". So the problem is mixing old-style demos with new ones. Ideally we'd rewrite all demos to use 0-1 range, but who has time for that?

@stglasauer Yep, occassional hickups are a constant thing on the trainwreck, but at least better than totally corruped stimuli.

Of course now we have a new problem, or at least i on the MBP 2017, but apparently many Apple customers which made the mistake of "upgrading" to Catalina. Apparently Apple installed a firmware "upgrade" with botched firmware as part of Catalina, which kills most external video outputs. After googling and resetting PRAM and SMC and doing rain-dances i got HDMI and VGA over USB-C back, instead of nothing at all. But DVI stays broken. Not only on Catalina, but also on Mojave and Ubuntu Linux -- because why only both macOS if they can do even more damage by botching the firmware and affecting all operating systems. This kills most of my testing equipment until the iIdiots fix their firmware, just in time for important Ubuntu 20.04-LTS testing.

I hate Apple.