Many things here:
First, try PsychLinuxConfiguration + logout + login again, launching octave from a terminal window (without sudo). The script will ask for your admin password at appropriate times, calling sudo as needed. Usually you don’t want to run octave or matlab with sudo, as it potentially screws up file ownerships, e.g., if it stores its own config files (e.g., the Octave/Matlab command history or settinga) with ownership “root” then, instead of your user name. Or what also might have happened is that because octave was launched sudo the PsychLinuxConfiguration script might have misidentified your user account as ‘root’ and created permissions for realtime priority and for membership in the “psychtoolbox” Unix user group for the ‘root’ user instead of your own user account name. If you type id in a terminal and don’t get “psychtoolbox” listed as one of the groups you are a member of, then that might be because of that.
→ The general PTB design is to make it not necessary to run matlab or octave with sudo if all the configuration steps completed successfully.
I also think the booting in BIOS mode wasn’t necessarily a problem: The one thing that prevents low-level access by default is EFI secure boot, but if your machine booted with BIOS CSM, iow. no EFI, then there also wasn’t any EFI secure boot enabled. Anyhow, doesn’t hurt to use modern EFI boot now. Also, PTB never made it to the point where it could fail due to EFI secure boot or such, according to the output.
The reason it doesn’t recognize your NVidia as low-level controllable is a peculiar one - I think we haven’t had this one yet: According to the following output …
" PTB-DEBUG: Checking PCI device [ASPEED Technology, Inc. ASPEED Graphics Family] with class x00030000"
…, there is a 2nd display controller in your machine, a very primitive and basic ASPEED chip, which is usually only found in server machines for remote maintenance or for a maintenance technician to connect a very simple display monitor in a server room. My suspicion is that that chip is not disabled on your machine and gets marked by the BIOS or EFI firmware as “VGA boot gpu” - the one used during machine powerup and initial boot for display. This throws off PTB’s gpu detection logic, as if no gpu is explicitely selected (via the PsychTweak('UseGPUIndex', gpuindex); command in a multi-gpu machine), PTB will choose the VGA boot gpu as the proper one.
You could either execute PsychTweak(‘UseGPUIndex’, 0); first, to force use of the NVidia. This might fix the beamposition timestamping. Or if you don’t have any need for that primitive ASPEED display chip, there’s probably somewhere a EFI firmware setting to disable it completely, so it will disappear from the system.
I assume your OLED monitor, and previously that LCD display, is connected to the NVidia, not to some other output connector on your machine - which would be that primitive ASPEED chip?
What’s the output of xrandr --listproviders and the content of the ~/.local/share/xorg/Xorg.0.log` ? If the X-Server would also decide to choose the ASPEED as the primary gpu, that could cause quite lots of performance problems.
Btw. for stereo shutter goggles you almost certainly do not want to use G-Sync or have it enabled → It should be off. That would likely screw up the stereo shutter timing for good, as such goggles need a very predictable and fixed frame duration and frame cycle, so they can sync up the phase of their own switching cycle to the switching cycle of the display.
Btw. one thought wrt. the stereo goggles breaking down on OLED: I haven’t looked at how your specific model of stereo goggles works, and there are different working principles for such stereo shutters, but one non-computer related problem could be if your goggles depend on the presence of a polarizing light filter on the display monitor? A LCD display by design/by the way a LCD works, necessarily emits polarized light, but an OLED monitor doesn’t do that. So if the goggles somehow would depend on the photons from the monitor being polarized, they would possibly fail to do their shuttering job when pointed towards an OLED monitor?
Also: we have FrameSequentialStereoTest as a test and demo on how to deal with different frame-sequential stereo setups and their quirks.
Makes also sense to post PTB output when you use frame-sequential stereo mode 1, to make sure you are in fact using the right mode of operation.
I may state the obvious here, but it does need setup in a custom xorg.conf setting afaiu, cfe. Option "Stereo" "integer" section in:
https://download.nvidia.com/XFree86/Linux-x86_64/525.116.03/README/xconfigoptions.html
I think mode Option "Stereo" "3" is what you’d want.
-mario
[60 minutes of out 30 minutes of paid-for support used → License used up.]
Some manufacturers (LG) putting their own polarisers on their gaming monitor OLEDs causing further problems with shutter glasses. I wanted to get timing issue sorted, so I’d know that any remaining issues were hardware problems!