Open pixel clock request

[LewisGamer]

Is there any way of having an open pixel clock setting without restrictions when setting frequencies via mode lines.

There is an active project using the Gert666 display driver via GPIO to recreate native arcade resolutions at 15khz, but the current firmware does not allow for exact frequencies. If there a way to make the raspberry Pi more flexible on this?

[steinerlein]

I'm also very interested in this being solved. I need a pixelclock of 15.36 Mhz. Is there some workaround for now?

[JamesH65]

Been having a look at this issue. Just been trying various pixel clocks with a 720x480p HDMI setup. I can reduce the clock to 5.750MHz without any problems (using an HDMI analyser to check the output clock, and also vcgencmd measure_clock pixel which matches). So its appears that you can produce lower pixel clock values for HDMI. So what exactly is the issue people are seeing? Is it only on DPI displays? Is it still there, as there may have been firmware changes that have affected this.

[sigmaris]

@JamesH65 It does seem to still be an issue on DPI specifically, with the latest firmware.

pi@netbootpi:~ $ vcgencmd version
Jan 22 2019 16:50:58
Copyright (c) 2012 Broadcom
version 7bfabcecab2918f85a2a217b389e256eac696962 (clean) (release) (start)

I booted this Pi with these config.txt parameters:

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 #240p with 6.4MHz pixelclock

to enable output to a TV with SCART, via the VGA666 and then this UMSA adapter to convert the VGA signal into SCART. The Linux console is visible on the TV in 320x240 resolution.

Note that the pixel clock is 6.4MHz, an integer divisor of 19.2MHz.

When I switch to a similar 224p mode with a 6.7MHz pixel clock (taken from here), no signal is displayed on the TV:

pi@netbootpi:~ $ vcgencmd hdmi_timings 320 1 16 31 59 224 1 12 3 23 0 0 0 60 0 6700000 1
hdmi_timings=320 1 16 31 59 224 1 12 3 23 0 0 0 60 0 6700000 1
pi@netbootpi:~ $ # at this point the display goes blank and TV shows "No Signal" message
pi@netbootpi:~ $ for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do echo -e "$src:\t$(vcgencmd measure_clock $src)" ; done
arm:    frequency(45)=600062000
core:   frequency(1)=250000000
h264:   frequency(28)=250000000
isp:    frequency(42)=250000000
v3d:    frequency(43)=250000000
uart:   frequency(22)=48000000
pwm:    frequency(25)=0
emmc:   frequency(47)=200000000
pixel:  frequency(29)=154000000
vec:    frequency(10)=0
hdmi:   frequency(9)=163683000
dpi:    frequency(4)=0
pi@netbootpi:~ $ fbset -depth 16
pi@netbootpi:~ $ fbset -depth 32
pi@netbootpi:~ $ # fbset is a hack to get Linux to restore the console, however even afterwards, nothing is displayed on TV

Then I switched back to the original mode with 6.4MHz pixel clock:

pi@netbootpi:~ $ vcgencmd hdmi_timings 320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1
pi@netbootpi:~ $ for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do echo -e "$src:\t$(vcgencmd measure_clock $src)" ; done
arm:    frequency(45)=600000000
core:   frequency(1)=250000000
h264:   frequency(28)=250000000
isp:    frequency(42)=250000000
v3d:    frequency(43)=250000000
uart:   frequency(22)=48000000
pwm:    frequency(25)=0
emmc:   frequency(47)=200000000
pixel:  frequency(29)=154000000
vec:    frequency(10)=0
hdmi:   frequency(9)=163683000
dpi:    frequency(4)=0
pi@netbootpi:~ $ fbset -depth 16
pi@netbootpi:~ $ fbset -depth 32
pi@netbootpi:~ $ # now, after the fbset, the Linux console is showing on the TV, as before.

The same blank screen / "No Signal" message on the TV is encountered when booting with the 6.7MHz mode, hdmi_timings=320 1 16 31 59 224 1 12 3 23 0 0 0 60 0 6700000 1, in config.txt.

I would also note that the limitation, that only integer divisors of 19.2MHz pixel clock work for low resolution DPI modes, is not present in the open source KMS display driver. It can set and display low resolution modes with various pixel clocks. Interlaced modes also work with a kernel patch, see https://github.com/raspberrypi/linux/issues/2668#issuecomment-424048611 for details of this.

Another bit of info that might be of interest: I have noticed that using modes with integer divisors of 19.2MHz pixel clock produce a better picture with the open source KMS display driver. Other pixel clocks below 19.2MHz tend to result in some pixel wavering / jittering on the screen, as if pixels are jittering left and right by 0.5px. Modes with pixel clocks of 6.4 and 9.6MHz are stable in comparison.

[dwhinham]

@sigmaris

I'm using a 320x240 DPI screen connected to a Compute Module 3 (via a Circuit Sword PCB) and I'm struggling to get it to give me a 60Hz or 50Hz output for smooth emulator VSync.

Using this line in the config.txt:

dpi_timings=320 1 20 30 38 240 1 4 3 15 0 0 0 60 0 9600000 1

I get a display that's about 90Hz according to FPS counters in VSync'd applications. Using the formula for the pixel clock (320 240 60 = 4608000) I get no display. Is that part of what this issue ticket is about?

I had a brief look into using the KMS driver which sounds promising from your comments, but can't find out any info on how I might use it to drive my DPI display, or whether it's even possible - would I have to write a custom device tree overlay for my LCD? Any brief hints on how I might get started with this?

Thanks!

[sigmaris]

@dwhinham The KMS driver would definitely need some kind of custom DT overlay to describe the DPI to panel hardware connection, and the type of panel. If you're using a DPI panel with a single fixed mode / fixed timings, you could check in https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/panel/panel-simple.c to see if your model of DPI panel is already supported and has display mode timings in there. If it is, all you need is the custom overlay mentioned below.

If the panel isn't already supported, you can add a static drm_display_mode and panel_desc into panel-simple.c, then add an entry in platform_of_match[] in the same file with your custom panel_desc and "compatible" string. This commit is an example: https://github.com/sigmaris/linux/commit/072a0e54598e852e3d41dc6efe1ba78b2e3e0f7f though it does that 3 times for different modes - you'd only need one.

Then add a DT overlay like this one: https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/vc4-kms-kippah-7inch-overlay.dts but with your specific "compatible" string in place of ontat,yx700wv03. You might also need to change the reference to dpi_18bit_gpio0 depending on the DPI->Panel bus width - is it 24 bits, 18 bits, etc. Then recompile the kernel and devicetree files, enable the vc4-kms-v3d overlay and your own DT overlay for the panel, and hopefully it should work. You could even submit the patch to panel-simple.c upstream.

[dwhinham]

@sigmaris That's extremely helpful, thankyou for the quick response - I'll give it a shot!

Presumably I would remove all the hdmi/dpi parameters from config.txt - would I also remove the dpi18 overlay that I'm currently using?

Thanks again!

[sigmaris]

Presumably I would remove all the hdmi/dpi parameters from config.txt

Yes, actually AFAIK those parameters like hdmi_timings, etc, have no effect when using the vc4-kms-v3d overlay because they're for the closed-source firmware, and when the vc4-kms-v3d overlay is active the firmware doesn't control the display. But it's probably best to comment them out to avoid confusion.

would I also remove the dpi18 overlay that I'm currently using?

I think so - this part I am less sure about, but the function of dpi18-overlay.dts seems to be to switch GPIOs 0-21 into ALT2 mode to use them for DPI, and with the vc4-kms-kippah-7inch-overlay.dts overlay that's instead accomplished by the pinctrl-0 line referencing dpi_18bit_gpio0 (which is in bcm270x.dtsi )

[LewisGamer]

BIG BIG NEWS!!! Thank you! out prayers have been answered! Looks like we can now create 1:1 video signals!

https://www.youtube.com/watch?v=lC-UQK5bQ4w&feature=youtu.be&fbclid=IwAR144kezW47DH_FC5RWqLWDh-tn9Bp9F2b9nYP_dNnq3xjjiz2eMkAkoB4A

Amazing news for the arcade and console preservation community!

[kamicane]

BIG BIG NEWS!!! Thank you! out prayers have been answered! Looks like we can now create 1:1 video signals!

https://www.youtube.com/watch?v=lC-UQK5bQ4w&feature=youtu.be&fbclid=IwAR144kezW47DH_FC5RWqLWDh-tn9Bp9F2b9nYP_dNnq3xjjiz2eMkAkoB4A

Amazing news for the arcade and console preservation community!

My tests indicate that this is not solved. I have a script in place that translates linux modelines (that I generate with switchres) to hdmi_timings, and, as before, unless I artificially bump up the horizontal resolution, the monitor loses sync.

This is after I did rpi-update.

[frezeen]

in the youtube link he speak about a raspberry pi4.. @kamicane do u test it on pi4?

[LewisGamer]

Sorry, yes. This has been fixed on the Pi4 the clock limitations have been confirmed to be at a hardware level. With the implementation of the new Broadcom chip that supports 4K they have made the pixel clock more flexible. The only option is to upgrade sadly.

[kamicane]

Ah, sorry, didn't notice that small detail. My testing were on the pi3.