Rpi4b | bcm2711 | What is page flipping?

[mariokleiner]

Btw. wrt. DPI display not working under kms, I wonder if your DPI panel needs a suitable device tree overlay loaded in /boot/config.txt and that is missing.

Cfe. drm/kms: DPI signals disabled when dpms sleeps display. · Issue #5152 · raspberrypi/linux · GitHub

-mario

[dinisov]

@mariokleiner

vsync would work, so lack of tearing is expected, but the timing mechanisms for stimulus onset scheduling and timestamping are not implemented in fkms. Slight update: Looking at recent driver source code, they made some improvements to fkms in the last 3 years, so some rudimentary/basic support may be there, at least for some display setups, but not the high-precision/robustness support.

Funny your response went into my spam filter and then I had to go through the pain of realising that while the fkms driver lacks tearing, several other things do not work. After a painful tour de force to understand things a neuroscientist should not have to go into, I finally taught myself enough about kernels and device trees and overlays to get my DPI projector (DLPDLCR230NPEVM Evaluation board | TI.com) to work with the kms driver.

Basically if you switch to kms it ignores hdmi_timings/dpi_timings for whatever reason, and you have to pass the settings as parameters to an overlay called vc4-kms-dpi-generic designed specifically for this purpose. In my case, to use the above projector with 1920x1080 @58 Hz the lines in config.txt were:

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-generic,hactive=1920,hfp=20,hsync=10,hbp=10
dtparam=vactive=1080,vfp=10,vsync=10,vbp=10
dtparam=clock-frequency=125000000,rgb666

@mariokleiner

If you want to join the so far depressingly tiny group of non-free riders

I’m currently a postdoc with no funding of my own, you have my word that as soon as I get some funding I will contribute.

[mariokleiner]

@dinisov

@mariokleiner

vsync would work, so lack of tearing is expected, but the timing mechanisms for stimulus onset scheduling and timestamping are not implemented in fkms. Slight update: Looking at recent driver source code, they made some improvements to fkms in the last 3 years, so some rudimentary/basic support may be there, at least for some display setups, but not the high-precision/robustness support.

Funny your response went into my spam filter and then I had to go through the pain of realising that while the fkms driver lacks tearing, several other things do not work. After a painful tour de force to understand things a neuroscientist should not have to go into, I

Well, much modern neuroscience research does need neuroscientists to understand quite a bit about how modern computer hardware works (or doesn’t), if they don’t want to screw up their data collection. Some of it can be offloaded on people like myself, writing high quality software and providing some knowledge on demand, but that requires actually funding people like myself by contributing financially to the software. The widespread lack of understanding of the complexities involved in modern computer hardware, operating systems etc. probably also contributes to the lack of actual support for projects like Psychtoolbox, following the false logic of “I don’t know anything about this, but how hard could it really be?”. Or people without deep knowledge write their own software, hence so many toolkits with shiny websites, trendy programming languages, maybe even the occasional nice GUI (because all these are relatively easy, or easier to learn to do), but shockingly bad implementations in the lower-level parts that actually matter for reliable and precise data collection and which require deep understanding of the hardware and the internals of modern operating systems.

finally taught myself enough about kernels and device trees and overlays to get my DPI projector (DLPDLCR230NPEVM Evaluation board | TI.com) to work with the kms driver.

Basically if you switch to kms it ignores hdmi_timings/dpi_timings for whatever reason,

Mostly because much of that hdmi_timings stuff in the RPi’s config.txt file is legacy Broadcom firmware proprietary stuff, only workable with their proprietary and limited fkms interface, whereas Device Tree Overlays are the standard way of doing things for the ARM world for fixed/semi-fixed hardware, or quite often in general on SoC’s, so that’s what standard Linux device drivers like the kms video driver use.

and you have to pass the settings as parameters to an overlay called vc4-kms-dpi-generic designed specifically for this purpose. In my case, to use the above projector with 1920x1080 @58 Hz the lines in config.txt were:

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-generic,hactive=1920,hfp=20,hsync=10,hbp=10
dtparam=vactive=1080,vfp=10,vsync=10,vbp=10
dtparam=clock-frequency=125000000,rgb666

Yes, that’s what i’ve hinted at / would have helped stepping you through for paid support.

@mariokleiner

If you want to join the so far depressingly tiny group of non-free riders

I’m currently a postdoc with no funding of my own, you have my word that as soon as I get some funding I will contribute.

My opinion is that this should be paid for by your lab / PI / out of overhead grant money for your project, or similar, not out of your own pocket, given that 150 Euros / year are nothing for most funded labs in industrialized countries.

Anyway, glad you could solve it and learned something useful for the future about the RPi in the process.
-mario