Update online docs for 3.0.22.1 release.

Author: kleinerm

docs/AdditiveBlendingForLinearSuperpositionTutorial.md

@@ -43,19 +43,24 @@ references and details.
 'Native10Bit' - Enables the native 10 bpc framebuffer support on all supported  
 [GPUs](GPUs). All gpus from AMD since ~2006, Intel since around ~2010 and [NVidia](NVidia) since  
 around ~2008 support this on Linux. This also works similar modern with [NVidia](NVidia)  
-Quadro and AMD Fire professional gpu's ounder MS-Windows.  
+Quadro and AMD Fire professional gpu's under MS-Windows. Also works on  
+Apple Silicon Macs.  
 
 'Native11Bit' - Enables the native ~11 bpc framebuffer support on some ATI  
 Radeon X1xxx / [HDxxx](HDxxx) GPU's with DCE-8 to DCE-12 display engine when used under  
 Linux. These GPU's do support ~11 bits per color channel when this special mode  
 is used (11 bits red, 11 bits green, 10 bits blue).  
 
 'Native16Bit' - Enables the native up to 16 bpc framebuffer support on AMD  
-GPU's when used under Linux with Vulkan display backend. While this activates  
-a 16 bpc framebuffer, the precision of the video output signal depends on the  
-specific gpu, connection and display. As of 2023, the "Sea Islands" AMD gpu  
-family and later can output at most 12 bpc precision to suitable displays over  
-HDMI or [DisplayPort](DisplayPort).  
+GPU's when used under Linux with Vulkan display backend. While this  
+activates a 16 bpc framebuffer, the precision of the video output signal  
+depends on the specific gpu, connection and display. As of 2023, the "Sea  
+Islands" AMD gpu family and later can output at most 12 bpc precision to  
+suitable displays over HDMI or [DisplayPort](DisplayPort). This works for gpu's up to  
+and including the Vega gpu family. However, as of May 2025 it is unclear  
+though if this support still works on current generation AMD "Navi" gpu  
+family "RDNA" gpu's, or if some bugs in AMD's current Vulkan driver  
+releases prevent this, and if that problem can be worked around.  
 
 'Native16BitFloat' - Enable native 16 bit floating point (~11 bit linear)  
 framebuffer support on suitable operating systems and graphics cards.  

docs/BitsPlusCSFDemo.md

@@ -3,9 +3,6 @@
 
 [BitsPlusCSFDemo](BitsPlusCSFDemo)([screenid=max] [, gamma = 2.2][, method=0][, charttype=0])  
 
-This demo utilizes the Psychtoolbox imaging pipeline. Therefore it won't  
-work on gfx-hardware older than ATI Radeon X1000 or [NVidia](NVidia) Geforce 6000.  
-  
 Demonstrates advantage of the 14 bpc Mono++ display mode, and similar high  
 bit depths display modes over the standard 8 bpc display mode of standard  
 graphics hardware. The demo displays either the Campbell-Robson CSF chart  
@@ -18,8 +15,8 @@ modes:
 A 'method' of 0 outputs to a regular 8 bit framebuffer. This is the  
 default, if no method argument is provided.  
 
-A 'method' of 1 tries to utilize the native 10 bpc framebuffers of recent  
-AMD/[NVidia](NVidia) hardware.  
+A 'method' of 1 tries to utilize the native 10 bpc framebuffers of modern  
+hardware.  
 
 A 'method' of 2 uses a method known as "[PseudoGray](PseudoGray)" or "Bitstealing" for  
 output.  
@@ -31,11 +28,11 @@ attenuator device.
 
 In 'method' == 5, the M16 display mode of the [VPixx](VPixx) - [DataPixx](DataPixx) box is used.  
 
-A 'method' of 6 tries to utilize the native ~11 bpc framebuffers of recent  
-AMD hardware.  
+A 'method' of 6 tries to utilize the native ~11 bpc framebuffers of  
+modern AMD hardware with DCE display engines on Linux.  
 
-A 'method' of 7 tries to utilize the native up to 16 bpc framebuffers of recent  
-AMD hardware.  
+A 'method' of 7 tries to utilize the native up to 16 bpc framebuffers of  
+modern AMD hardware.  
 
 A 'method' of 8 tries to utilize the native 16 bpc float framebuffers of recent  
 hardware.  

docs/GStreamer.md

@@ -81,11 +81,11 @@ file:
 <http://gstreamer.freedesktop.org/download/\>  
 
 The following [[GStreamer](GStreamer)][(GStreamer)]((GStreamer)) runtime packages have been lightly tested for compatibility  
-with Psychtoolbox 3.0.22.0, as of May 2025:  
+with Psychtoolbox 3.0.22.1, as of July 2025:  
 
-For MS-Windows: 64-Bit Intel MSVC runtime v1.22.5 for use with 64-Bit Matlab/Octave.  
+For MS-Windows: 64-Bit Intel MSVC runtime v1.22.12 for use with 64-Bit Matlab/Octave.  
 
-<https://gstreamer.freedesktop.org/data/pkg/windows/1.22.5/msvc/gstreamer-1.0-msvc-x86\_64-1.22.5.msi\>  
+<https://gstreamer.freedesktop.org/data/pkg/windows/1.22.12/msvc/gstreamer-1.0-msvc-x86\_64-1.22.12.msi\>  
 
 You \*must\* install the MSVC variants of [[GStreamer](GStreamer)][(GStreamer)]((GStreamer)), not the [MinGW64](MinGW64) variants!  
 

docs/GetChar.md

@@ -39,13 +39,14 @@ OS type and version, the type of desktop GUI in use, or if you use Matlab
 or Octave, and if you use Matlab with or without Java based GUI active.  
 For portability it is therefore best to ignore all info returned beyond  
 the character code. Composed characters, e.g., putting accents on top of  
-letters, do not always work on all setups. In general, only Matlab with  
-Java based desktop GUI enabled on Linux and macOS will get optimal  
-international keyboard and composed character handling, at reduced timing  
-precision, whereas anything on MS-Windows, and on Linux with KDE desktop,  
-and on Octave, and Matlab in -nodesktop mode, will use an implementation  
-based on [KbQueues](KbQueues), which has better timing and flexibility, but worse  
-handling of international keyboards and composed characters at the moment.  
+letters, do not always work on all setups. In general, only Matlab  
+versions older than R2025a, which have a Java based desktop GUI, on Linux  
+and macOS, will get optimal international keyboard and composed character  
+handling, at reduced timing precision, whereas anything on MS-Windows,  
+and on Linux with KDE desktop, and on Octave, and Matlab in -nodesktop  
+mode, and Matlab R2025a or later, will use an implementation based on  
+[KbQueues](KbQueues), which has better timing and flexibility, but worse handling of  
+international keyboards and composed characters at the moment.  
 
 "when" is a struct. It (used to) return the time of the keypress, the "adb"  
 address of the input device, and the state of all the modifier keys  
@@ -99,7 +100,8 @@ are not.
 ---\> If precise timing of the keypress is important, use [KbCheck](KbCheck) or  
 [KbWait](KbWait) or [KbQueueXXX](KbQueueXXX) functions or [KbEventGet](KbEventGet) for consistent results!  
 
-### macOS or Linux (with other than KDE desktop GUI), with Matlab and Java enabled:  
+macOS or Linux (with other than KDE desktop GUI), with Matlab older than  
+R2025a, and Java GUI enabled:  
 
 JAVA PATH: The [GetChar](GetChar) implementation for Matlab on these systems is  
 based on Java. Therefore, the Psychtoolbox subfolder [PsychJava](PsychJava) must be  
@@ -124,7 +126,9 @@ your script. If Matlab returns to its command prompt without reenabling
 keyboard input via [ListenChar](ListenChar)(0) or [ListenChar](ListenChar)(1), Matlab will be left  
 with a dead keyboard until you press the CTRL+C key combo. This silencing  
 of clutter does currently not work in matlab -nojvm mode, or if you use  
-GNU/Octave instead of Matlab.  
+GNU/Octave instead of Matlab. It also does not work on Matlab R2025a in  
+GUI mode anymore, as Mathworks switched to a [JavaScript](JavaScript) based GUI, with  
+no known good and reliable way of suppressing keystrokes on that GUI.  
 
 OTHER "when" RETURN ARGUMENT FIELDS: Owing to differences in what  
 accessory information the underlying operating systems provides about  

docs/ListenChar.md

@@ -32,9 +32,9 @@ suppression of keyboard input to Matlab and unsuppressed mode.
 
 Please note that the commands [ListenChar](ListenChar), [CharAvail](CharAvail) and [GetChar](GetChar) are  
 subject to various constraints and limitations, depending on the  
-operating system you use, if you use Matlab in Java or -nojvm mode, if  
-you use Octave, if you have [Screen](Screen)() onscreen windows open or not, or if  
-you use [KbQueueXXX](KbQueueXXX) functions in parallel or not. Therefore use of these  
+operating system you use, if you use a Matlab with/without Java based GUI,  
+or if you use Octave, if you have [Screen](Screen)() onscreen windows open or not, or  
+if you use [KbQueueXXX](KbQueueXXX) functions in parallel or not. Therefore use of these  
 functions can be troublesome for any but the most simple usages. Use of  
 [KbCheck](KbCheck), [KbWait](KbWait), [KbStroke](KbStroke)/Press/[ReleaseWait](ReleaseWait) is often simpler if you are  
 just after keyboard input. Use of [KbQueue](KbQueue) functions, e.g., [KbQueueCheck](KbQueueCheck),  
@@ -45,13 +45,13 @@ more flexible and subject to less restrictions and gotchas than use of
 
 ### Some of the restrictions and caveats:  
 
-1. Works very well with Matlab and its Java based GUI enabled on Linux (on  
-desktop GUI's other than KDE) and macOS, as well as on [WindowsXP](WindowsXP) and earlier  
-versions of Windows.  
+1. Works very well with Matlab releases older than R2025a and their Java  
+based [GUIs](GUIs) enabled on Linux (but only on desktop GUI's other than KDE),  
+and on macOS.  
 
-2. When used on Windows Vista or later (Vista, Windows-7, ..., Windows-10)  
-with Matlab's Java GUI, you cannot use any [KbQueue](KbQueue) functions at the same  
-time, ie., [KbQueueCreate](KbQueueCreate)/Start/Stop/Check/Wait as well as [KbWaitTrigger](KbWaitTrigger),  
+2. When used on Microsoft Windows with old Matlab versions with Java GUI,  
+you cannot use any [KbQueue](KbQueue) functions at the same time, ie.,  
+[KbQueueCreate](KbQueueCreate)/Start/Stop/Check/Wait as well as [KbWaitTrigger](KbWaitTrigger),  
 [KbEventFlush](KbEventFlush), [KbEventAvail](KbEventAvail), and [KbEventGet](KbEventGet) are off limits after any call  
 to [ListenChar](ListenChar), [ListenChar](ListenChar)(1), [ListenChar](ListenChar)(2), [FlushEvents](FlushEvents), [CharAvail](CharAvail) or  
 [GetChar](GetChar). You would need to call [ListenChar](ListenChar)(0) before you could call  
@@ -61,21 +61,22 @@ to [ListenChar](ListenChar), [ListenChar](ListenChar)(1), [ListenChar](ListenCha
 use them again. Use of other devices, e.g., mouse or joystick, is not  
 prohibited during use of [GetChar](GetChar) et al.  
 
-3. If you use Matlab in "matlab -nojvm" mode without its GUI, or if you  
-use GNU/Octave instead of Matlab, the same restrictions as in 2. apply -  
+3. If you use Matlab in "matlab -nojvm" or "matlab -nodesktop" mode without  
+its GUI, or if you use a Matlab of version R2025a or later, or you use  
+GNU/Octave instead of Matlab, the same restrictions as in 2. apply -  
 no parallel use of the default keyboards [KbQueue](KbQueue). [KbQueues](KbQueues) can be used  
-for other input devices and on Linux and OSX for keyboards other than the  
+for other input devices and on Linux and macOS for keyboards other than the  
 default keyboard.  
 
 The only feature that works in parallel with [KbQueues](KbQueues) on the default keyboard  
 is the suppression of spilling of keystroke characters into the Matlab or  
-Octave window during [ListenChar](ListenChar)(2) - at least on Linux and OSX. On  
-Windows this can't be prevented at all in "matlab -nojvm" mode. However,  
-if you switch to [ListenChar](ListenChar)(2) mode, you cannot break out of it by  
-pressing CTRL+C on Linux if the keyboard queue that is in parallel use  
-didn't get [KbQueueStart](KbQueueStart) called, ie. if it is stopped. On OSX with a  
-stopped Keyboard queue, neither CTRL+C nor stopping a runaway script  
-works.  
+Octave window during [ListenChar](ListenChar)(2) - at least on Linux and macOS with old  
+Matlab versions before R2025a and their Java based [GUIs](GUIs). On Windows this  
+can't be prevented at all in "matlab -nojvm" mode. However, if you switch  
+to [ListenChar](ListenChar)(2) mode, you cannot break out of it by pressing CTRL+C on  
+Linux if the keyboard queue that is in parallel use didn't get  
+[KbQueueStart](KbQueueStart) called, ie. if it is stopped. On macOS with a stopped  
+Keyboard queue, neither CTRL+C nor stopping a runaway script works.  
 
 4. On Linux, as a exception, some [GetChar](GetChar), [CharAvail](CharAvail) functionality may  
 still work in case 3. under certain conditions, e.g., if you don't use  
@@ -95,7 +96,7 @@ Basically: Mixing [GetChar](GetChar) et al. and modern [KbQueue](KbQueue) functi
 not advisable, or if needed, great care must be taken to sidestep all the  
 mentioned limitations. Also the [KbQueue](KbQueue) functions usually have better  
 timing precision and allow to flexibly address multiple keyboards  
-separately at least on Linux and OSX.  
+separately at least on Linux and macOS.  
 
 
 For further explanation see help for "[GetChar](GetChar)".