Closed
Conversation
These are for the LexActivator SDK and runtimes.
To make troubleshooting easier for user.
… Windows. Tested against Octave 7.3 64-Bit Intel on Windows-10 and Windows-11.
Used for license checking and management for prebuilt mex files which are included in the Psychtoolbox distribution and require paid software licensing on target platforms like Octave and Matlab on macOS and Windows. Uses Cryptlex as license management provider, and their LexActivator SDK and client libraries. See: https://cryptlex.com This code is implemented and currently used on behalf of Psychtoolbox commercial host company, the Medical Innovations Incubator GmbH, in Tübingen, Germany. Website: https://psychtoolbox.net Any questions wrt. the software licensing should be directed to them under the following current address, as of November 2024: Medical Innovations Incubator GmbH Eisenbahnstr. 63 72070 Tübingen Germany Commercial register: HRB 751684 Register court: Local court Stuttgart, Germany Contact E-Mail address for inquiries: info@mi-incubator.com Signed-off-by: Mario Kleiner <kleiner@mi-incubator.com>
Add path to PsychPlugins subfolder for 64-Bit Intel or ARM plugin dll's, depending on processor build architecture. This is future prep for a Windows-on-ARM variant, although no immediate plans exist for such a variant.
Make sure mex files that aren't license managed and don't use PTB core infrastructure still build in the future. Currently these are moglcore, moalcore, pnet and SRAnipalMex. Suppress some pointless compiler warnings under Octave's POSIX like MinGW build system on Windows, for moglcore and PsychOculusVRCore1.
Caused by using a POSIX/Unix MinGW build system for Octave on Windows, where EWOULDBLOCK is a defined - but pointless for our purpose here - error code, so redefining it to something meaningful without first undefining it caused a compiler warning.
…ure drivers. AMDVLK v-2024.Q4.2 will have a suitable bug fix, so the workaround ain't needed anymore on Navi+ / RDNA gpu's supported by that driver. The fix is untested and not testable by myself as I don't have a RDNA+ gpu, but I performed a full code review and conclude that the bug should be fixed by that fix, which now implements dynamic allocation of suitable data structures, so no hard mode count limit anymore and future proof. Bug report: GPUOpen-Drivers/xgl#179 Bugfix merged 5.11.2024: GPUOpen-Drivers/xgl#180
Also add unrelated PsychColorCorrection to contents.m file for PsychGLImageProcessing.
Define preliminary target folder for mex files built for/on 64-Bit ARM. Not neccessary the final word on this, but will do for current experiments. Enable basic building on Fedora Linux and spins/remixes for 64-Bit cpu architectures. Build WaitSecs to identify as a Wayland mex file when building on a Wayland system. This mostly for the benefit of LM stats collection about Linux WSI type.
The target folder for these files may not be the last word, but it will do for now, ie. current experimentation.
Wayland lacks all required standardized protocol and functionality to establish identity pixel passthrough, e.g., no gamma table control or dithering control for regular non-privileged applications. For now, simply turn this into a no-op, and user has to configure identity pixel passthrough manually via a Wayland compositor specific means, if such a thing exists.
…hw cursors. Some 64-Bit ARM platforms display engines or drivers do not support hardware cursors, so displaying a mouse cursor will enforce fallback cursor rendering that may impair visual timing significantly, which is not what we want in these test scripts. As a workaround, HideCursor() the cursor on 64-Bit ARM for that reason. When we are at it, convert PerceptualVBLSyncTestFlipInfo.m from DOS CR+LF to Unix LF line endings to make things less disgusting.
…d sample rate. Some recent sound chips don't like our hard-coded 44100 Hz, so leave it to the audio system to choose what it can handle. Doesn't matter if sound sounds weird during this test, as it only fills the purpose of creating some processing load in the audio system, not to please the ears of the listener.
…switcher trouble.
PsychVideoSwitcher('SwitchMode') is unreliable when used under Wayland
on some 64-Bit ARM gpu's. Skip it when running timing tests that utilize
the Videoswitcher on such hardware + software setups.
…scaling. These are hacks, and only half of them work halfways, but better than nothing, and if only to document what doesn't work well so far, so we don't repeat past mistakes again out of forgetfulness... Especially the hack in PsychWindowGlueWayland.c was totally useless, and is therefore coded to be a no-op due to bscale = 1; as other bscale values do more harm than good. The hack in PsychScreenGlueWayland.c is implemented in the wrong place, but shows some promise, just needs a more careful implementation for future production use.
Wrong include path for libfreenect headers, dead and unused since many years, but not a problem on Debian/Ubuntu for some reason. A very real problem on some other distros though.
Suppress some pointless compiler warnings for moglcore, moalcore on recent gcc compiler versions. Make PsychOpenXRCore and PsychCV build conditional on availability of OpenXR SDK and Apriltags library. Only avoid PsychOpenXRCore build on 32-Bit ARM, but allow on 64-Bit ARM. Allow PsychCV build on ARM systems if Apriltags library is available on those systems.
Name is libptbdrawtext_ftgl_arm64.so.1
Same ones we get on Octave, lets declutter our lifes.
Use of multiple onscreen windows could cause the wrong OpenGL context of the wrong onscreen window to be in use during operation. Fix this.
… bug. Same for TextToStuffColorMismatchTest.m. Same bug as worked around in some other demos and tests in the past. See commit f601cf0 When we are at it, refine DrawManuallyAntiAliasedTextDemo.m a bit for Windows and macOS text font file definition deficiencies, to avoid some cutoff parts of text glyphs.
…MDVLK. No feedback from my tester yet, and I can't wait any longer with the release, so mention that 16 bpc Navi+ support via current AMDVLK is unclear, as well as the effectiveness of my workarounds in a hacked up AMDVLK 2023.Q3.3 driver. See: https://psychtoolbox.discourse.group/t/failed-to-choose-the-12-bit-precision-window-on-amd-graphics-card/5699
PTB beta update 3.0.22.0 "Oh wie schoen ist Panama!" [This Psychtoolbox release was sponsored by Mathworks under the year 2024/2025 contract for significant enhancements, sponsoring the OpenXR hand tracking support as major new feature.](https://www.mathworks.com/solutions/neuroscience.html) ### Compatibility changes wrt. Psychtoolbox 3.0.21.0: - This release no longer supports the Ubuntu 20.04-LTS "Focal Fossa" family of Linux operating system distributions, and siblings like Debian GNU/Linux 11 "Bullseye". In fact, it requires Ubuntu 22.04.5-LTS "Jammy Jellyfish" with all updates installed, or Debian GNU/Linux 12 "Bookworm" and equivalent distributions, ie. Linux distributions where all software components are at least as modern and recent as those in Ubuntu 22.04.5-LTS. Psychtoolbox Mex files will no longer work on older distributions, or if some would appear to work, they might show various subtle and not so subtle malfunctions - iow. they woud be unfit for research grade data collection. - Psychtoolbox for Matlab on Linux now also requires a paid software subscription license, while the Octave variant for Linux remains free of cost to use. ### Highlights: - New fast, mostly seamless fixed refresh rate switching on Linux with AMD graphics. - Hand tracking performance optimizations. ### All: - Software subscription licenses can now also be activated during setup with user email+password of the account of the license manager self service portal. Psychtoolbox will fetch the correponding license key automatically. - License management now contains functionality needed for implementation of campus licenses, unattended auto setup of licenses, and educational licenses. - Performance optimizations for the articulated hand and finger tracking for OpenXR, which was introduced in Psychtoolbox 3.0.20.4. Now operates 20-30 times faster, doing its job in less than 0.5 msecs on average hardware. - PR655parsespdstr(): Fix to handle zero values in measurements correctly. Contributed by Danny Garside @da5nsy thanks! - Various other smaller refinements, bug fixes and documentation updates. ### Linux: - Psychtoolbox was built and tested against Matlab R2024b and Octave 6.4 under Ubuntu 22.04.5-LTS. Now only works on Ubuntu 22.04-LTS and later. - Added workarounds for bugs in AMD's Vulkan driver AMDVLK that have been introduced due to mistakes by AMD's developers since version v-2023.Q2.2 and later, starting in May 2023. These bugs prevent 16 bpc ultra-high precision framebuffers to be reported as supported in both SDR and HDR mode of operation, with some driver versions even 10 bpc support is lacking in SDR Standard Dynamic Range mode! The bug prevents all AMD RDNA 3+ graphics cards with Navi 30 or later gpu family from using these 16 bpc framebuffers, and thereby from achieving up to 12 bpc effective output precision. Our new workaround tricks the faulty drivers into supporting these modes anyway and thereby restores the 10 bpc modes in SDR/HDR and tries to restore 16 bpc modes for up to 12 bpc effective output color precision in SDR and HDR again. While this has been confirmed to work on gpu's of the AMD Vega gpu family and earier models, the situation on AMD Navi / RDNA gpu's ist still unclear at time of this release. There might be additional bugs in the AMDVLK drivers still preventing this. Unfortunately the tester for this feature on AMD RDNA gpu's has not reported back in reasonable time and we have to release now, with this question still to be answered. - Support for rapid, seamless video refresh rate switching on modern FreeSync capable AMD graphics cards, when used with a Variable Refresh Rate capable display device, connected via DisplayPort, e.g. suitable FreeSync, GSync and "Vesa DisplayPort Adaptive Sync" capable monitors. This can be triggered for a whole X-Screen with one or multiple active outputs via the command ``Screen('Framerate', screenId, 2, reqHz);`` or on a individual per-output basis via ``Screen('ConfigureDisplay', 'FineGrainedSwitchRefreshRate', screenId, outputId, reqHz);`` This allows to request an instant switch of the displays to a new video refresh rate `reqHz` within the variable refresh rate range supported by the display monitor, e.g., to run dynamic animations or movie playback at a specific exact rate, and switch that rate on a trial-by-trial basis if needed, with switching times in the range of only one to a few video refresh cycle duration. All AMD graphics cards since the Sea Island gpu family from around the year 2014 should be supported. The new test and demo `VRRFixedRateSwitchingTest.m` demonstrates and tests this. - Fix touchscreen enumeration for touchscreens operated by the "Intel Precision Touch and Stylus Daemon" iptsd version 3 and later. `GetTouchDeviceIndices()` now filters out the wrong touchscreen device and enumerates the correct devices. ### Windows: - Psychtoolbox was built and tested against Matlab R2024b and Octave 7.3. ### macOS: - Psychtoolbox was built and tested against native Matlab R2024b and against native Octave 9.4 from HomeBrew, on macOS 13.7.5 Ventura for Intel Macs, and on macOS 14.5 Sonoma for Apple Silicon Macs. - Add a Datapixx mex file for Matlab on Apple Silicon Macs, based on VPixx latest release. This is supposed, but not tested by us, to make basic support for VPixx devices work on macOS for Apple Silicon. Note that the Datapixx mex file for Octave is not ready and most likely broken on Apple Silicon, as of now. Enjoy!
Resync with public 3.0.22.0 release "Oh wie schoen ist Panama!"
Added new function. Also modified LMSTOMacBoyn so that it can return luminance as well as MB ls chromaticity if called with a new optional flag. This would have been a better initial design, but I left the default behavior unchanged so as not to break code that calls it without the new flag. Tested a reasonable amount but will be working more on this for use in the project and will tweak further next little while as needed.
…e Java path on Matlab R2025a and later. Matlab R2025a and later ditched the Java based GUI in favor of a completely new GUI and graphics backend, based apparently on JavaScript + Chromium embedded "web browser" framework + WebGL rendering. This makes our GetCharJava implementation completely non-functional, with no known way to salvage it. As of now, I wouldn't know how to do an alternative implementation hooking into the new JavaScript GUI, but first investigation suggests it is likely impossible. Therefore we now fall back to our KeyboardQueue based GetChar et al. implementation, just as on Octave, on MS-Windows, and for matlab -nodesktop mode. New limitations caused by this: 1. Same keyboard queue related restrictions as on MS-Windows, ie. no concurrent use of KbQueues for the default keyboard and GetChar/CharAvail/FlushEvents/ListenChar on macOS and Linux. 2. Less reliable handling of composed characters, or no such handling at all. Less extra information as aux info, only timestamp, no other modifier keys state reporting etc. 3. Suppression of typed characters spilling into the Matlab command window does no longer work in GUI mode on Matlab R2025a and later. Such is life... -> So far successfully tested on R2025a under macOS 15.5 for Apple Silicon, and on Octave, both GUI and non-GUI. Other platforms are supposed to behave the same under R2025a. -> Behaviour on older pre-R2025a releases is supposed to stay the same as before this commit.
…t for R2025a+. Not that it matters, as that serial() path is never used, and serial() itself is to be removed soon from Matlab.
… and its non-Java GUI. Dead code removal, and a comment that the Java swing cleanup is no longer done or needed on R2025a+.
psychusejava('desktop') no longer reports true on R2025a and later, so use usejava('desktop') which works as
before, ie. reports true in Matlab GUI mode, even though R2025a+ no longer uses Java for the GUI, but likely
JavaScript.
Also slightly optimize the Octave case, when we are here.
…25a+ on macOS Apple Silicon. Apparently macOS ASE bugs from R2024b and earlier have been fixed in the new non-Java GUI.
…vies. Should help issues like described in: https://psychtoolbox.discourse.group/t/invalid-movie-handle-provided-error-message/5719
No need for JOGL Java OpenGL related workarounds anymore for R2025a+, now that WebGL is used. Still needs broken Vulkan loader workaround.
…htnessMode'). This did not ever work on any macOS version since its introduction around macOS 10.12 up to and including macOS 15, neither on IntelMacs nor on Apple Silicon Macs. Kill this useless code.
…reDisplay', 'Brightness'). This doesn't work at all on Apple Silicon machines. On IntelMacs it still works for internal displays, but it relies on long deprecated CGDisplayIOServicePort(), and it doesn't keep the Brightness slider in the display settings UI in sync with settings, so it is inferior to the method using SPI's, which is used by default. Let's remove it and RIP.
…ightness'). This one uses the SPI's DisplayServicesSetBrightness() and DisplayServicesGetBrightness() if available. These work on Apple Silicon Macs, as opposed to the old method, which only worked on Intel Macs. The IntelMac method still exists as fallback.
…hCocoaSetUserFocusWindow(). This allows debug output to display when executing GetHostingWindowPID().
Matlab R2025a with its new JavaScript based GUI splits off all the Matlab GUI handling into a separate Matlab GUI process, whereas Psychtoolbox and all its Windows and all other Matlab user scripts etc. run in a separate process. In the past, up to R2024b with its Java based GUI, the GUI and Psychtoolbox were running inside the same Unix process as different threads. This has consequences for at least use on macOS for Intel Macs (see followup commits for a slight twist on this for Apple Silicon Macs under macOS): Whenever an opaque, unoccluded, topmost, decorationless fullscreen onscreen window is opened via the regular path, ie. the standard way most PTB windows are used, that video output display is captured, an optimized low level video mode is selected, and CGL is used for rendering and display. Both, display capture and using CGL, combined or each in isolation, will cause the Unix process running Psychtoolbox to become the active foreground application, take keyboard input focus from whatever process had it before, and receive + dispatch keyboard events to its own NSWindows for processing. On old Matlab up to R2024b and also all current versions of Octave, as the PTB process is identical to the Matlab / Octave GUI process, this means the keyboard input focus stays with the Matlab / Ocave GUI process, as the old and new keyboard input process is the same process. Events get properly dispatched to and handled by the NSWindow GUI windows of Matlab / Octave. On new Matlab R2025a+, the Matlab PTB process takes keyboard input focus from the separate Matlab GUI process and its NSWindow Matlab GUI windows, and gives it to its own NSWindow windows. The same is true when running either Matlab or Octave in command line mode from the Terminal window, where Matlab/Octave PTB process steals keyboard input focus from the Terminal window GUI process. Problem is: Only for transparent onscreen windows and windowed onscreen windows does PTB and its PTB process actually have its own NSWindow's to receive keyboard focus and dispatch and swallow/discard key events. In fullscreen mode under CGL, there aren't any PTB NSWindows - and thereby there aren't *any* NSWindows in the PTB process to dispatch keyboard input to! Net result is the NSApplication instance of the PTB process doesn't know what to do with keyboard input and its default action is to discard it and make a beep noise via system sounds. Iow. Each keypress while CGL is active will make an annoying beep when Matlab/Octave are run from a terminal, or with the new Matlab R2025a+ GUI. I have tried numerous ways to prevent switching of keyboard input focus / even dispatch from the R2025a+ GUI process (or Terminal GUI process) to PTB's process, which all failed. Also, all attempts to divert / give back keyboard focus to the GUI process of Matlab R2025a+ or Terminal via various Appkit methods, immediately after CGL or display capture takes over, failed: Although the methods report "success", this is apparently a no-op "success" / silent failure, as the methods execution is blocked by macOS. Long story short: As of now, we can't prevent this beeping from happening on R2025a+ or Octave/Matlab command line Terminal use, at least on IntelMacs. The best we can do is return foreground activation status and keyboard input focus to the separate Terminal GUI process or separate Matlab R2025a+ GUI process *after* the PTB fullscreen onscreen windows are closed and the corresponding displays released, to spare the need for the user to manually restore input focus to the Terminal or Matlab window. For this, this commit implements a more robust method than the old one, to hand over focus: 1. At Screen() startup, the currently active foreground app process with keyboard focus is determined and its process pid stored - assuming this is the proper Terminal GUI or Octave GUI or Matlab GUI process. 2. At each display release during onscreen window close, a method is invoked on the process with that stored pid, to transfer foreground activation and keyboard input focus back. This process typically happens with a delay of 1-2 seconds. So far this was successfully tested on macOS 13.7 on an Intel Mac with Octave 9.4, Matlab R2024b and the new Matlab R2025a in both command-line "-nodesktop" terminal mode, launched/running from Terminal.app, and in GUI mode with Octave's QT GUI, R2024b's Java GUI and R2025a's JavaScript GUI, for windowed windows and transparent windows - where no such keyboard problems exist, and most important for fullscreen CGL windows. Seems to work well enough. Unfortunately this leaves the annoying beep problem unaddressed, with no viable solution yet after 20+ hours of investigation and experimentation. We do have an ok solution though for Apple Silicon Macs, which will follow in a separate followup commit, so this will mostly affect IntelMacs running R2025a+. As R2025b will be the last Matlab version for macOS on IntelMacs, this means that effectively only R2025a and R2025b on Intel Macs will be affected. Mathworks roadmap says that R2026a and later will not work on IntelMacs anymore. Best solution for users would be to simply stick to R2024b or earlier on Intel Macs.
… better. The situation (see previous commit) is that the Matlab or Octave process which hosts Psychtoolbox gets foreground activation status and its NSWindow GUI windows - if any - get keyboard input focus, but there aren't any GUI windows in that process in the case of Matlab 2025a+, so no GUI window -> no window with keyboard focus -> keypress goes unhandled -> annoying beep. Lets give the PTB hosting process a special PTB NSWindow that can receive keyboard focus and keyboard input, whenever this is needed due to use of a CGL fullscreen window. Whenever a CGL window is opened the first time, create a PTB "ghost window", with a titlebar and a text input widget as content view, but hidden behind the onscreen stimulus window. This window - eligible for key input - gets assigned keyboard input focus by macOS and receives the keystrokes. It doesn't do anything with them at all, but macOS is happy about the "processed" keystrokes and the annoying beeps stop. This right now is needed for CGL fullscreen stimulus windows - your typical use case - on macOS for IntelMacs, and works. It is not needed for other NSWindows, e.g., windowed windows, tranparent windows, or Vulkan windows, so it doesn't get applied there. Tested on Intel Mac with octave CLI and GUI, Matlab R2024b CLI and GUI, and Matlab R2025a CLI and GUI, fullscreen, transparent, and windowed. Seems to work well enough. As a bonus this also fixes the Octave/Matlab running in CLI (-nodesktop) mode from a terminal window, where the triggering dual-process situation always existed. Current open question: Does the ghost window become mispositioned on a multi-display setup? I can only test single display atm. And the general slight dirtyness of the approach: Attaching an NSApplication / NSApp delegate class to the NSApp object of the PTB hosting process, overriding the NSResponder:noResponderFor: method with a no-op implementation of our own would solve the problem a bit more elegant, without need for the ghost window, but need for new Obj-C / Cocoa complexity. Not sure if that is worth the extra work and potential future Obj-C complications. For now this will do...
…licon Macs. Apple Silicon Macs use the Vulkan display backend for fullscreen windows under macOS, instead of CGL on Intel Macs, therefore a different approach is needed to avoid the beep on keypress. As Vulkan already uses a fullscreen Cocoa NSWindow, and we omit CGL, we now also omit CGDisplayCapture, the other trigger for keyboard focus stealing, as it seems to be not needed for Vulkan display. This leaves the keyboard focus at all times with the original process, Octave GUI, Matlab GUI or the Terminal.app, and the problem does not happen. Tested on Apple Silicon macOS with octave GUI/no-GUI and Matlab R2025a GUI/no-GUI. This should do it for avoiding annoying beeps on keypress on macOS with CLI mode octave/Matlab and with Matlab R2025a+ for the time being. Fingers crossed!
-> macOS Sequoia 15.5 build system. XCode 16.4. -> Octave 9.4 and Matlab R2025a. -> "Annoying beep on keypress" fixes for Matlab R2025a+
-> macOS Ventura 13.7.5 build system. XCode 14.3. -> Octave 9.4 and Matlab R2025a. -> "Annoying beep on keypress" fixes for Matlab R2025a+
Old download was removed, so adapt link from 1.22.5 -> 1.22.12.
…ol v1.
If a Wayland server supports the commit timing protocol version 1, then
bind and enable it, and use it for implementation of precisely timed
stimulus onset timing, ie. implement PsychOSScheduleFlipWindowBuffers()
for Wayland on top of it.
The protocol allows to request surface presentation at a specific target
time, following our Screen('Flip', window, tWhen); semantic for 'tWhen'.
The new code translates 'tWhen' into corresponding Wayland target time
in the compositors presentation clock domain and then tags the surface
commit with that target time constraint, using the new extension.
When we are at it, make a small optimization to our pixelformat setup:
For opaque fullscreen windows, request an alpha bit depth of zero, ie.
no alpha channel, as it would not be used anyway. This allows Mesa in
10 bpc deep color mode to request RGB10 surfaces instead of RGB10A2
surfaces, ie. RGB10 with 2 bit X-Ignore padding. This in turn allows
some Wayland compositors to use direct scanout / direct pageflips
as a performance optimization and skip compositing of opaque fullscreen
windows. Testing on Apple Silicon shows this to work with KDE/KWin 6.4.
Strangely it does not work with GNOME/Mutter 48, although it should.
KWin can do direct scanout for both RGBA8 8 bpc and RGB10 10 bpc
framebuffers of ours - it adapts display engine format to our source
wayland buffers format, whereas Mutter can't - it always runs 10 bpc
on my test machine, but also can't direct scanout that.
Some other small optimization included.
As of July 2025, the only Wayland compositor implementing support
for wp_commit_timing v1 is Mutter v48 and thereby GNOME 48. Testing
GNOME 48 on an Apple Silicon Mac with Asahi Linux showed that the
protocol works in principle, ie. Psychtoolbox and the compositor
properly speak with each other wrt. desired presentation time. The
reliability is disappointing though: Only flips at next frame work
reliably - the one case one doesn't need such a protocol. Flips two
frames ahead are rather unreliable and often miss the target onset
time by a video refresh cycle. Flips of >= 3 refresh cycles into
the future *always* miss by at least one refresh cycle, even on a
60 Hz display! Our own standard "WaitSecs" fallback implementation
provides much more reliable timing! Very disappointing!
It remains to be seen if this Mutter issue only happens on display
systems without VBLANK interrupts and vblank counters / timestamping,
as on Apple Silicon's DCP display engine, or if the same problem
happens on standard gpu's with proper vblank support, e.g., on
Intel or AMD or NVidia (nouveau powered) gpu's.
So for now, the verdict is "unusable on at least one tested system
configuration". Stay tuned...
GStreamer 1.26 and later on MS-Windows now install into the C:\Program Files\gstreamer\... subfolder, instead of the old path C:\gstreamer\... This means that if the GStreamer install path environment variable is not set for some reason, and the probe sequence for typical locations would be used, it woul not find a GStreamer 1.26 or later installation. Extend the fallback probe sequence to first probe the new default install locations in C:\Program Files\gstreamer\ for drives C, D, E, F, G, before trying the old locations for older GStreamer versions. This should fix startup failure with GStreamer 1.26+ if the env variable GSTREAMER_1_0_ROOT_MSVC_X86_64 is not defined. The ordering of first probing the new locations, then the old ones, also makes sure that a stale directory left over from old GStreamer installations in the old location will not throw the process off.
R2025a and later do not use a Java GUI anymore, so no need for us to be on the Java classpath anymore. Skip static classpath setup during call from PsychtoolboxPostInstallRoutine(). Dynamic setup is already skipped by its call chain.
Psychtoolbox 3.0.22.1 update "Little Miss Sunshine!". [This Psychtoolbox release was partially sponsored by Mathworks under the year 2024/2025 contract for improving compatibility with Matlab R2025a.](https://www.mathworks.com/solutions/neuroscience.html) ### Compatibility changes wrt. Psychtoolbox 3.0.22.0: - Establish basic compatibility with Matlab version R2025a and later. - Make use with GStreamer 1.26 on MS-Windows more robust. ### Highlights: - Compatibility fixes for Matlab R2025a with its new JavaScript based GUI and WebGL based graphics and plotting system, and the split process design between compute and GUI. Substantial work was needed to repair ListenChar, CharAvail, GetChar and FlushEvents, and to avoid annoying beep tones on key presses under macOS + R2025a. GetChar should work mostly as in the past, although limitations persist in some areas, some possibly hard or impossible to fix. A part of this compatibility work was sponsored by Mathworks. - Brightness control of at least internal displays now also works on Apple Silicon Macs. ### All: - ``GetChar()/CharAvail()/ListenChar()/FlushEvents()``: Do no longer use the Java path on Matlab R2025a and later. Matlab R2025a and later ditched the Java based GUI in favor of a completely new GUI and graphics backend, based apparently on JavaScript + the Chromium embedded "web browser" framework + WebGL rendering. It also split off all GUI and plotting code into a separate Matlab application process from the main process that executes the Matlab interpreter with all user script code and all of Psychtoolbox, completely isolating these two processes from each other, with only a restricted and proprietary communication link between them (most likely based on local IP loopback connections). This makes our GetCharJava implementation completely non-functional, with no known way to salvage it. As of now, I wouldn't know how to do an alternative implementation hooking into the new JavaScript GUI, but first investigation suggests it is likely impossible, at least without significant help from Mathworks - they'd need to implement special purpose functionality for us. Therefore we now fall back to our KeyboardQueue based GetChar et al. implementation, just as on Octave, on MS-Windows, and for Matlab in "matlab -nodesktop" mode. New limitations caused by this: 1. The same keyboard queue related restrictions as on MS-Windows, ie. no concurrent use of KbQueues for the default keyboard and GetChar/CharAvail/FlushEvents/ListenChar on macOS and Linux. 2. Less reliable handling of composed characters, or no such handling at all. Less extra information as aux info, only timestamp, no other modifier keys state reporting etc. 3. Suppression of typed characters spilling into the Matlab command window does no longer work in GUI mode on Matlab R2025a and later. Such is life... - IsGUI(): Fix for Matlab R2025a and its non-Java GUI. - No longer add the Psychtoolbox/PsychJava/ folder to Matlab's Java class path on Matlab R2025a and later, as we can no longer use Java for our purposes, so no point in adding our Java class to the Matlab path. - PlayMoviesWithoutGapDemo1.m: Refine for more robustness with short movies. This should help issues like described in: https://psychtoolbox.discourse.group/t/invalid-movie-handle-provided-error-message/5719 - Add ``MacBoynToLMS()`` to invert ``LMSToMacBoyn()``. Contributed by David Brainard. - Various other smaller refinements, bug fixes and documentation updates. ### Linux: - Psychtoolbox was built and tested against Matlab R2025a and Octave 6.4 under Ubuntu 22.04.5-LTS. Now only works on Ubuntu 22.04-LTS and later. - PsychLinuxConfiguration(): Adapt for Matlab R2025a and later. No need for JOGL "Java OpenGL" related workarounds anymore for R2025a+, now that WebGL is used. Matlab still needs the "broken override Vulkan loader" workaround though. ### Windows: - Psychtoolbox was built against Matlab R2024b and tested against Matlab R2025a. - help GStreamer: Update link to MS-Windows MSVC GStreamer 1.22. The old download was removed, so adapt link from 1.22.5 to 1.22.12 as closest to the last tested version. - Add robustness of GStreamer setup if GStreamer version 1.26 or later is used. GStreamer 1.26 changed the default installation location on MS-Windows. Normally the proper location of GStreamer runtimes is communicated to Psychtoolbox via an environment variable. If this isn't the case in some cases then a probe sequence for common default installation locations was used. The probe sequence is now updated to search and hopefully find GStreamer 1.26+ at its default install locations, avoiding startup failure. ### macOS: - Psychtoolbox was built and tested against native Matlab R2025a and against native Octave 9.4 from HomeBrew, on macOS 13.7.5 Ventura for Intel Macs, and on macOS 15.5 Sequoia for Apple Silicon Macs. - Fix keyboard input focus restoration after closing opaque fullscreen onscreen windows on Intel Macs. Substantial work was needed to achieve this with the new Matlab R2025a dual-process design (Psychtoolbox process separate from Matlab GUI process). - Fix a new bug, where in fullscreen window mode on R2025a, every keypress causes an annoying beep tone from macOS. This is also due to the new split dual-process design, but workarounds have been implemented to hopefully fix it. - Screen: Implement new method for ``Screen('ConfigureDisplay', 'Brightness')`` which also works on (at least) the internal displays of Apple Silicon Macs. Also removed support for 'AutoBrightnessMode' which did not ever work with any macOS release, so give up on it. - TwoStateQuery(): Cleanup, and reenable good questdlg() for Matlab R2025a+ on macOS for Apple Silicon Macs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.