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.

[popcornmix]

Can you test this firmware: https://drive.google.com/uc?id=0B-6zmEDJwxZEN1hLOTVWSjRMVEk&export=download

It avoids using the OSC for lower frequencies and always uses the PLL. It avoids my problem:

pi@domnfs:~ $ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9610000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9610000 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)=9610000
pi@domnfs:~ $ vcgencmd hdmi_timings 506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9600000 1
hdmi_timings=506 1 8 44 52 264 1 6 10 6 0 0 0 60 0 9600000 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)=9600000

I suspect it will either fix things for you, or make all low frequencies not work. Either way it would be useful information.`

[LewisGamer]

Tried the mode lines above, and got back frequency (29) is 0 on both working and non working

[LewisGamer]

Will give this firmware a try ASAP

Cheers again for the efforts! :)

[LewisGamer]

Sadly no image from the test firmware. none of the current mode lines we have worked. do we need to follow new rules to get frequencies working via the Ger666 GPIO driver?

[popcornmix]

Can you read the pixel frequency when using the new firmware? Does it look correct?

[Chips-fr]

I think you guys aren't aligned in the way you enable hdmi timings to be taken in account, hence your discrepancy on measure_clock pixel frequency result.

Personnaly, i was just using vcgencmd to send hdmi timings (which result in no more display), then CTRL+ALT+F1 to go in console, then CTRL+ALT+F7 to go back in xwindows then display was there. Another way is to boot with hdmi timings in the /boot/config. But in thoses way of working i always get 0 as measure_clock pixel (as LewisGamer). If i used the popcornmix way of doing (dynamically switching with temporary switching to CEA4), frequency is sometimes working even on original firmware for hdmi timings which never worked (due to not accepted pixel clock):

With original firmware, first try a non accepted pixel clock resulting in black screen:

pi@raspberrypi:~ $ vcgencmd hdmi_timings 256 1 18 25 42 224 1 12 3 23 0 0 0 60 0 5369318 1
hdmi_timings=256 1 18 25 42 224 1 12 3 23 0 0 0 60 0 5369318 1
pi@raspberrypi:~ $ vcgencmd measure_clock pixel ; tvservice -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
frequency(29)=0
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=5370000

frequency is OK. But whatever i do screen stay black :(

But just after this if i put timings which are normally accepted, then at the end i got 0 despite this timings should be working well... moreover the screen is black.

pi@raspberrypi:~ $ vcgencmd hdmi_timings 320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
hdmi_timings=320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
pi@raspberrypi:~ $ vcgencmd measure_clock pixel ; tvservice -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
frequency(29)=5369000
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=0

but going back and forth from console to xwindows give me back the display :) Then now frequency is always stuck on 0 (until reboot):

pi@raspberrypi:~ $ vcgencmd hdmi_timings 320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
hdmi_timings=320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
pi@raspberrypi:~ $ vcgencmd measure_clock pixel ; tvservice"CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice"DMT 87"; sleep 1; vcgencmd measure_clock pixel
frequency(29)=0
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=0
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=0

Now with the test firmware which always display black screen whatever i do ( traces taken with VNC :) ):

pi@raspberrypi:~ $ vcgencmd hdmi_timings 256 1 18 25 42 224 1 12 3 23 0 0 0 60 0 5369318 1
hdmi_timings=256 1 18 25 42 224 1 12 3 23 0 0 0 60 0 5369318 1
pi@raspberrypi:~ $ vcgencmd measure_clock pixel ; tvservice -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
frequency(29)=0
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=5370000

pi@raspberrypi:~ $ vcgencmd hdmi_timings 320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
hdmi_timings=320 1 16 8 72 240 1 8 5 9 0 0 0 60 0 6400000 1
pi@raspberrypi:~ $ vcgencmd measure_clock pixel ; tvservice -e "CEA 4" ; sleep 1; vcgencmd measure_clock pixel ; tvservice -e "DMT 87"; sleep 1; vcgencmd measure_clock pixel
frequency(29)=5369000
Powering on HDMI with explicit settings (CEA mode 4)
frequency(29)=74250000
Powering on HDMI with explicit settings (DMT mode 87)
frequency(29)=6400000

My conclusion:

• On original firmware, frequency pixel was somewhat working giving right value even for "non supported" pixel clock but it "randomly" stuck to 0 from times to times and can give temporary 0 depending in the way you set timings.
• The test firmware, despite always giving black screen, tends to always have valid frequency pixel returned value (except perhaps the "cold value" as original firmware anyway). I did stress it more and it is always return good value.

[LewisGamer]

So, would you say the hardware is capable of producing more pixel clock frequencies, but the driver and/or firmware would have to be updated to get them outputting via GPIO?

[LewisGamer]

Any progress on this @Popcornmix ? :)

[Sir-Ironic]

Currently, because of the limitation of the pixel clock, I use a high vertical resolution. This allows me to display many resolution and refresh rate in full screen and without overscan.

I use big front porch, back porch and sync but it works very well. A friend told me that it was not working on his CRT monitor.

Here are the resolutions I use for consoles and arcade games.

EMULATIONSTATION hdmi_timings 450 1 50 30 85 288 1 10 1 25 0 0 0 60 0 9600000 1

NEOGEO hdmi_timings 1920 1 152 247 280 224 1 13 8 19 0 0 0 59.186 0 40610000 1

PCENGINE hdmi_timings 1920 1 158 250 286 232 1 4 3 23 0 0 0 59.94 0 41060000 1

PLAYSTATION hdmi_timings 1920 1 152 247 280 240 1 1 7 14 0 0 0 60 0 40860000 1 hdmi_timings 1920 1 132 247 280 288 1 3 3 18 0 0 0 50 0 40240000 1

MEGADRIVE/GENESIS/MASTER SYSTEM hdmi_timings 1920 1 48 192 240 240 1 3 3 16 0 0 0 59.92 0 37680000 1 hdmi_timings 1920 1 48 192 240 288 1 6 3 16 0 0 0 49.70 0 37340000 1

NES hdmi_timings 1920 1 158 200 286 240 1 1 8 13 0 0 0 60.10 0 40380000 1 hdmi_timings 1920 1 158 200 314 240 1 23 6 43 0 0 0 50.01 0 40450000 1

SNES hdmi_timings 1920 1 160 200 286 224 1 9 8 21 0 0 0 60.10 0 40410000 1 hdmi_timings 1920 1 158 200 314 239 1 25 6 42 0 0 0 50.01 0 40450000 1

AMIGA hdmi_timings 1920 1 180 192 334 262 1 14 15 22 0 0 0 50 0 41200000 1

224p x 60Hz hdmi_timings 1920 1 152 247 280 224 1 8 7 23 0 0 0 60 0 40860000 1

240p x 60Hz hdmi_timings 1920 1 152 247 280 240 1 3 7 12 0 0 0 60 0 40860000 1

216 x 60Hz hdmi_timings 1920 1 152 247 280 224 1 8 7 23 0 0 0 60 0 40860000 1

192 x 60Hz hdmi_timings 1920 1 152 247 280 224 1 8 7 23 0 0 0 60 0 40860000 1

256p x 55Hz hdmi_timings 1920 1 100 320 260 288 1 1 3 1 0 0 0 55 0 41900000 1

254p53.20Hz hdmi_timings 1920 1 100 320 260 254 1 1 3 36 0 0 0 53.20 0 40670000 1

224p58.97Hz hdmi_timings 1920 1 50 250 250 250 1 8 10 8 0 0 0 58.97 0 38750000 1

240p55.72Hz hdmi_timings 1920 1 50 250 250 260 1 4 5 8 0 0 0 55.72 0 38130000 1

[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 ?