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?

[LewisGamer]

We want to achieve low resolutions such as 320x240 with a horizontal frequency of around 15.6kHz and vertical refresh rate of 60Hz.

We want to be able to maintain those values with differing resolutions by specifying a custom pixel frequency which may reside outside of the 4.8, 6.4 or 9.6 range.

[popcornmix]

Can you give an example of the settings you are trying that don't work?

[LewisGamer]

We can get close, but not close enough. This plays havoc with sychronsing the audio and video chips. If the horizontal frequency is out by a fraction, then it can lead to problems.
For example.

384 x 256 @ 55.017605 Hz Is the resolution and frequency for R-type. We can get close to this using the constraints of the locked Pi modeline. But achieving a match is not possible at the moment.

[LewisGamer]

99% perfect.pixel clock = 8.120000 384 408 448 520 256 261 264 284
Pixel clock = 8.120000 which the Pi cannot produce.

[popcornmix]

Can you explain exactly how you are configuring this?
Are you using hdmi_timings from config.txt?
Are you using the hdmi_timings vcgencmd?
Something else?

Post complete config.txt settings (or whatever you are using to do this).

[LewisGamer]

The Pi can currently do
4.8, 6.4, or 9.6
With no leniency

[LewisGamer]

vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9600000 1

[LewisGamer]

Sorry, that results in a resolution of 506 x 264 at 55hz nowhere near to the native resolution, but a close frequency. So the game runs at close to the correct speed, but more time is being spent drawing lines that are not needed affecting the emulation.

[popcornmix]

So are you saying
vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9600000 1
works correctly, but trying to get a 8.12MHz clock fails?
What the vcgencmd command you are using that fails?
How does it fail? No picture, or actual frequency is measured to be different?

[LewisGamer]

No picture. The clock has to match 4.8, 6.4, or 9.6 exactly to display an image. If it does not match you get no picture.

[LewisGamer]

The perfect scenario would be to be able to produce any clock frequency between 4.8 and 9.6 and still get an image

[LewisGamer]

Arcade manufacturers used to tweak the pixel clocks to get odd resolutions out of the limited hardware of the time. As the pi only has 3 clock modes we can't run the games on arcade 15khz monitors as they should be.

Is at all possible to unlock the pixel clock and allow us to create 'exotic' mode lines? We would be able to accurately reproduce native arcade resolutions.

a program called SOFT15KHZ is used for certain graphics cards, that can produce these signals, but the clock must be able to accept values other than the 3 currently available on the pi. Is there at all a way to change this via a firmware update, or is it a hardware constraint?

Perhaps a future model would be able to resolve this, if not a firmware change.

[popcornmix]

The PLL supports abitrrary frequencies from 600MHz to 2.4GHz and the pixel clock is generated from this with an integer divisor.
The maximum divisor is limited, so when a frequency is too low to be generated we switch to using the OSC (19.2MHz) as the source with an integer divisor.
That probably explains the limited low frequencies available.

I'll try to have a closer look at the exact limits with clock divisors.
What you want may not be possible from the hardware.
Maybe the PLL can be persuaded to run below 600MHz (out of spec) but I'm not sure.

[LewisGamer]

Thank you for looking into this, looking forward to your response.

[LewisGamer]

Any joy with this @popcornmix :)

[Sir-Ironic]

Hi.

I use this timings with GPIO2SCART on my rpi2.
hdmi_timings 1920 1 48 192 240 248 1 3 10 6 0 0 0 60 0 38400000 1
With 1920 honrizontal pixels, never mind honrizontal games resolutions.
It works nice on my CRT.

So 38.4Mhz pixel clock can be use.

Usable Pixel clock are :
4800000 - 6400000 - 9600000 - 19200000 - 38400000 - 76800000 (not tested)
Why 67800000 or 384000000(384Mhz) show me a picture ?

I would like to know (as mamy people) if fixed pixel clock is a limit or not.

[Chips-fr]

As popcornmix said there is two source clock that could be used, hence a selection is made at some step and if only divisor is possible then frequency above 19,2 MHz could only be generated with the PLL which looks more versatile anyway on higher frequency.
We will see what can be done, but it could be good to know complete hardware limitations (divisor size, PLL step etc...) and current algorithm because there could be some interesting combination that couldn't be achieve with current algorithm and even some pixel clock that haven't been found with current algorithm...

[LewisGamer]

@Sir-Ironic so, you are attempting to get the same results as us. 15hz signals via the GPIO. Does the horizontal resolution not matter when producing the mode line? What rules do you follow for producing accurate vertical refresh rates, and how close can you get?

[LewisGamer]

@Sir-Ironic so, you are attempting to get the same results as us. 15hz signals via the GPIO. Dear es the horizontal resolution not matter when producing the mode line? What rules do you follow for producing accurate vertical refresh rates, and how close can you get?

[Sir-Ironic]

I use Custom Resolution Utility (CRU) to produce HDMI Timings. The Detailed Resolution fonction (Edit).
http://img11.hostingpics.net/pics/201729CRU.png
And a lot of try ... a lot.
[Front Porch + Sync = Back Porch]

Honrizontal resolution is high (1920 with a viewport of 1848), we can't see difference bitween this resolution and native resolution.

For Vertical resolution. Actually i can produce 224p (visible area) at 60Hz. I know, a lot of arcade games use differents refresh rate.

With another Timings in 240p, i can only see 230 lignes, there's 10 lines overscaned.
For a game like R-type, 384x256x55Hz, we can see all 256 lines (and 2 black lines up and down) a 55Hz.

I know, i must find all Timings for all resolutions but it's a hard work with pixel clock limit.

** 60Hz Timings **
hdmi_timings 960 1 24 96 120 248 1 3 10 6 0 0 0 60 0 19200000 1
hdmi_timings 1920 1 48 192 240 248 1 3 10 6 0 0 0 60 0 38400000 1

** 50Hz Timings ** Up to 256p
hdmi_timings 1920 1 48 192 240 302 1 3 10 6 0 0 0 50 0 38400000 1
hdmi_timings 960 1 24 96 120 302 1 3 10 6 0 0 0 50 0 19200000 1

** 55Hz Timings ** Up to 256p
hdmi_timings 1888 1 48 184 232 278 1 3 10 6 0 0 0 55 0 38400000 1
hdmi_timings 944 1 24 88 112 280 1 3 10 6 0 0 0 55 0 19200000 1

** Amiga **
hdmi_timings 968 1 24 96 120 288 1 10 10 10 0 0 0 50 0 19200000 1
hdmi_timings 1920 1 140 200 260 256 1 18 10 29 0 0 0 50 0 39400000 1
...

[Sir-Ironic]

Tell me if i'm wrong.

I use this Timings on my CRT for Bad Dudes vs Dragonninja (256x240x57.41Hz) :
hdmi_timings 1920 1 41 202 243 260 1 4 5 9 0 0 0 57.41 0 38400000 1

I get this :
http://img11.hostingpics.net/pics/890810capture.png
(I resized the picture - RASPI2PNG)

And on the TV :
http://img11.hostingpics.net/pics/716054IMAG0118.png
(There's an overscan of 12 lines).

I carefully look at scrolling, it is perfect. no tear/lag, pause every 1 second.

The game is synchro to 57.41Hz so the screen too?
The scrolling is really perfect, I will try another game whose scrolling is not perfect at 60Hz, Ghost'n Goblins...

[LewisGamer]

@Sir-Ironic There is a bit of an effort to get lots of arcade resolution mode lines for various emulators on the Pi. Feel free to share your findings, and I'm sure we can help each other out.

Jump on the Pi2Jamma group on facebook :)

[popcornmix]

According to spec PLLH must be between 600MHz and 2400MHz (but we support up to 3000MHz when overclocking)
There is a fixed divide by 10 from the PLL, plus an 8-bit divisor.
So we should be able to divide PLL by between 10 and 2550.
So highest pixel clock is 240MHz (300MHz with overclock)
And lowest pixel clock is 0.235MHz
So low frequencies look to be possible from the PLL.

But I think there is something intermittent going wrong.
I don't have a display to test with, but I am using this scheme:

$ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 4000000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 4000000 1
$ tvservice  -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice  -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=4000000

So, here you can see we set the pixel clock to 74.25MHz for 720p and then set the pixel clock to 4MHz successfully. The 4MHz will be using the PLL (as it's not an integer divisor of 19.2MHz osc).
The result of measure_clock is reliable (it actually connects the clock to a test counter and lets it run for a short period) so you can believe what it reports.

But during my testing I sometimes get in a state where measure_clock returns 0, and I suspect this ties up with your blank screen issues. Can you check what vcgencmd measure_clock pixel reports both when display is working and when it is not working to confirm if I am seeing the same issue?

[OliverHoermann]

1up for your information!

[popcornmix]

I'm not sure if I'm seeing the same issue as you but there seems to be a bug when choosing a frequency that is an integer divisor of the oscillator.

pi@domnfs:~ $ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19210000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19210000 1
pi@domnfs:~ $ tvservice  -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice  -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=19210000
pi@domnfs:~ $ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19200000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19200000 1
pi@domnfs:~ $ tvservice  -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice  -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=0
pi@domnfs:~ $ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19210000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 19210000 1
pi@domnfs:~ $ tvservice  -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice  -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=0
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=0

i.e. 19.21MHz initially worked
Then 19.2MHz failed
Now 192.21MHz (and any other frequency) also fails. I think it is not switching back to PLL correctly.

But so far if I don't use a frequency that is an integer divisor of the oscillator it seems to behave correctly. But that doesn't seem to match the bug reported.

[LewisGamer]

Not getting an image when I tried the mode lines above.

[LewisGamer]

So, you are saying that it should be able to use these frequencies, but the bug is preventing it from switching?

[popcornmix]

I don't know. Please report output of

vcgencmd measure_clock pixel

After a working and non-working change of pixel clock frequency.

[erixswanson]

I'm trying to get a 25Mhz pclk using the DPI to push an old mono gas plasma at 640x400. I've got a logic analyzer that I've been switching between the original equipment's output and the pi's output. Here's what I've got for hdmi_timings-

#### 640x480@65 (output works)
hdmi_timings=640 1 56 56 80 480 0 1 3 25 0 0 0 65 0 36000000 1
#### 640x400@70 (no output)
# hdmi_timings=640 1 49 95 15 400 0 31 2 16 0 0 0 70 0 25000000 1

With either the stock firmware or the testing firmware listed earlier in this thread, the first hdmi_timings
works as expected but the second has no outputs on pclk, de, hsync, vsync, or any of the data lines.

Shouldn't I be watching the 'vcgencmd measure_clock dpi' instead of pixel? Pixel is showing 0 even though pclk is ticking right along with the first hdmi_timings line.

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)=1200126000
core: frequency(1)=400000000
h264: frequency(28)=300000000
isp: frequency(42)=300000000
v3d: frequency(43)=299999000
uart: frequency(22)=47999000
pwm: frequency(25)=0
emmc: frequency(47)=249959000
pixel: frequency(29)=0
vec: frequency(10)=108000000
hdmi: frequency(9)=163683000
dpi: frequency(4)=35996000

[starquake]

@erixswanson Do you have a link to pictures of that gas plasma? Would love to see that!

[erixswanson]

It's a Toshiba T5200. '92ish 386 clamshell luggable. Figured it could do with an upgrade :) Absolutely no specs/datasheet/anything on the display. Capable of 640x480, but boots into text mode of 640x400. Drove me nuts trying to figure out why vsync was coming 80 lines early.

[dcervi]

@popcornmix Can we expect any improvement soon regarding this old constraint? I've been searching and found references from years ago like this one: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=112735

[LewisGamer]

@popcornmix same here. Can we find out if it is at all possible to alter the firmware to allow more flexible timing. I hear someone may have produced a custom firmware that is capable of this, but they are not for letting the cat out of the bag.

[substring]

@popcornmix this issue is the keystone to reaching the _ almost perfect_ arcade/console emulation on CRT as we would match original hardware timings very closely, even surpassing what PCs can do. Can we expect some good news ?

[LewisGamer]

@popcornmix any news on this yet?

[ghost]

Does the firmware provided by @popcornmix needs further testing, or can we assume that more tweaks are needed before doing so ?
The tests results @Chips-fr provided are looking pretty thorough, is there anything more that can be done to make the magic happen ?

[LewisGamer]

I do think more can be done. I don't have the ability to test, as I cannot remote in to my Pi. Looking into this with Broadcom the chip is capable of having an open clock. We just need someone who can alter the firmware and test as they make changes. I'm hoping the Pi4 will opt for an open pixel clock. Who do we push to see if this can be done with the next hardware, if not with this hardware?

[ghost]

Well, there's already millions of existing units wich are presumably able to handle a wide range of pixel clock, i think pushing the research a little further would not be a waste of time. With all respect due : would a bounty on BountySource help ?

[LewisGamer]

Go for it! I would spread the work as much as possible. And put in!

[JamesH65]

@popcornmix Any further thoughts on this? (Note to other posters, popcornmix v. busy at the moment, so holding breath not recommended!)

[LewisGamer]

Any movement on this? Do we know if it is a hardware issue. It looks like we came very close to getting it to work. @popcornmix ?

[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 raspberrypi/linux#2668 (comment) 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: sigmaris/linux@072a0e5 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.