STICKY: Using a Gert VGA 666 adapter - [HOWTO]

[fridgemagnet]

Hi,

The latest Raspbian distro includes gstreamer support for the "kmssink" video sink which allows direct video rendering into a frame of a DRM device. This works really well on the Pi's HDMI output however I'd like to use it with this module (instead of HDMI, not in addition to). In order for the kmssink to work, it needs access to nodes in the /dev/dri folder, which only materialises when the "vc4-fkms-v3d.dtbo" overlay is loaded during boot. However if I try and enable this and the vga666.dtbo one as well, the Pi hangs during boot, there's a bit of initial disk activity but then everything stops.

Is it therefore possible to accomplish this and does anyone have any guidance on how to go about doing it?

Thanks,

Jon.

[Gert van Loo]

If this is a hardware-related problem, why does it happen only on Raspbian Buster and/or RPi 4, and not on Raspbian Stretch / RPi 3?

I don't know. Maybe they use a different drive strength for the GPIO or the Pi4 PCB has the tracks thinner and closer together. It can also be that there is more or different frequency noise on the supply. To trace things like this I would connect my spectrum analyzer to the signal and see if that show up anything different between the builds & PCB's.

[antiriad]

But could it be a Raspbian Buster (software) problem? the user in the previous page that recorded the video is using a Raspberry Pi 2. (I will test my RPi 4 + VGA666 + Raspbian Stretch ASAP...)

[6by9]

Hi,

The latest Raspbian distro includes gstreamer support for the "kmssink" video sink which allows direct video rendering into a frame of a DRM device. This works really well on the Pi's HDMI output however I'd like to use it with this module (instead of HDMI, not in addition to). In order for the kmssink to work, it needs access to nodes in the /dev/dri folder, which only materialises when the "vc4-fkms-v3d.dtbo" overlay is loaded during boot. However if I try and enable this and the vga666.dtbo one as well, the Pi hangs during boot, there's a bit of initial disk activity but then everything stops.

Is it therefore possible to accomplish this and does anyone have any guidance on how to go about doing it?

The VGA666 works fine on the Pi4 with vc4-fkms-v3d. You'll need the normal firmware setup for the VGA666 as described in the first post:

Code: Select all

enable_dpi_lcd=1
dpi_mode=XX
dpi_group=2

There have been a couple of small hiccups with overlays, so please ensure you have updated the kernel and bootloader.

[rememberizer]

Hi, first post here. I've been using the pi3 + lakka + VGA666 set to 240p 15khz on my arcade monitor for a while now. I replaced it with a pi4 and it works great as expected, but the image has a weird pixel wobble along the edges of sprites. It's like the pixels move back and forth between adjacent pixels, and it's more obvious in text against black backgrounds. This was definitely not present on the pi3. I'm using the same config.txt as I did on the pi3. I tested this on Raspbian and the issue was still there.

Has anyone come across this? Any ideas about how to fix it?

[antiriad]

Hello,
yes I have the same issue, please read my previous posts...

[rememberizer]

Hello,
yes I have the same issue, please read my previous posts...

Oh wow I didn't think to check the previous page. Sorry about that. are you also using the official power supply? I'll try to use a different one just to compare.

[antiriad]

are you also using the official power supply? I'll try to use a different one just to compare.

I'm using an unofficial power supply and I still have the issue on my Raspberry Pi 4.
Same SD card (Raspbian Buster) and VGA666 on Raspberry 3: no problem.

So I suppose it's a RPi4 issue but I don't know if it is somehow "fixable" by software (e.g. upgrading firmware or via config.txt options).
I really hope in some help by the forum...

[6by9]

are you also using the official power supply? I'll try to use a different one just to compare.

I'm using an unofficial power supply and I still have the issue on my Raspberry Pi 4.
Same SD card (Raspbian Buster) and VGA666 on Raspberry 3: no problem.

So I suppose it's a RPi4 issue but I don't know if it is somehow "fixable" by software (e.g. upgrading firmware or via config.txt options).
I really hope in some help by the forum...

Looking back over your posts I don't see full details of what you have added to config.txt. If you want anyone to try and help then that is the minimum required.
What is your dpi_timings line if you're trying to get mode 87 working?

[antiriad]

Looking back over your posts I don't see full details of what you have added to config.txt. If you want anyone to try and help then that is the minimum required.
What is your dpi_timings line if you're trying to get mode 87 working?

Hello and thank you for your support.
I am currently experiencing two different problems:

a) Video flickering with RPi 4 + VGA666. My config.txt (Raspbian Buster):

Code: Select all

dtparam=i2c_arm=off
dtparam=i2s=off
dtparam=spi=off
disable_overscan=1
scaling_kernel=8
dtoverlay=vc4-fkms-v3d
max_framebuffers=1
dtparam=audio=on
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=2

Using same SD card, same VGA666, same video cable and monitor on RPi 3 no problem at all (picture is perfectly stable).

b) Custom video modes not working on RPi4 + VGA666: I get no picture at all. My other config.txt (Raspbian Stretch Lite):

Code: Select all

device_tree=bcm2710-rpi-3-b.dtb
dtparam=i2c_arm=off
dtparam=i2s=off
dtparam=spi=off
dtparam=uart0=off
dtparam=uart1=off
dtoverlay=pi3-disable-bt-overlay
dtoverlay=pi3-enable-wifi
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 20 29 35 224 1 10 14 16 0 0 0 60 0 6400000 1
gpu_mem=128
scaling_kernel=8
sdtv_mode=16
dtparam=audio=on
boot_delay=1
force_turbo=1

Again, no problems on RPi3 with same SD card and hardware.

On my RPi4 I did a rpi-update three weeks ago.
Thank you

[rememberizer]

This is mine. Same problem on Lakka + arcade monitor, tested on Pi 3 and Pi 4, the problem is only present on pi 4.

Code: Select all

disable_overscan=1
dtparam=i2c_arm=off
dtparam=i2s=off
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=1920 1 152 247 280 240 1 3 7 12 0 0 0 60 0 40860000 1

[6by9]

I don't have any hardware at hand to test with, however having an odd number in any of the horizontal values will have issues. The pipeline on the pi4 runs at 2 pixels per clock, so inserting odd values would require switch output phase mid cycle. Most displays are tolerant of being out by one on these values.

In the cade of antiriad's line, switching to

Code: Select all

 hdmi_timings=320 1 20 30 34 224 1 10 14 16 0... 

will generally work.

Rememberizer's line is more awkward as there is only the one odd value. Tweaking that up or down by one will normally work, but will alter the frame rate by a very small fraction.

Note that dpi_timings should be used instead of hdmi_timings if that is what you are setting. Whilst there is a fallback to use hdmi_timings instead, it removes the ambiguity on the pi4 where both hdmi0 and dpi can be active simultaneously.

[antiriad]

Thank you very much!!! I'll check ASAP.

(But what about the flickering picture also using a standard resolution like in my "first" config.txt? Maybe we could fix it by firmware or config options?)

[6by9]

Thank you very much!!! I'll check ASAP.

(But what about the flickering picture also using a standard resolution like in my "first" config.txt? Maybe we could fix it by firmware or config options?)

I don't have any hardware at hand to test with

A quick check says
https://github.com/torvalds/linux/blob/ ... did.c#L229
So dmt mode 2 appears to have an odd value in the timings too. I thought we'd checked them all out and found only the 1366x768 modes that had issues, and those have a workaround implemented in the firmware. Finding a generic solution is non-trivial.

[rememberizer]

Rememberizer's line is more awkward as there is only the one odd value. Tweaking that up or down by one will normally work, but will alter the frame rate by a very small fraction.

Note that dpi_timings should be used instead of hdmi_timings if that is what you are setting. Whilst there is a fallback to use hdmi_timings instead, it removes the ambiguity on the pi4 where both hdmi0 and dpi can be active simultaneously.

Thank you for your help. I've tested with one up (248) and one down (246) and it doesn't seem like there was any change. I also found the following timing that I tried, all with even values and I still had the same issue.

Code: Select all

dpi_timings = 2048 1 180 202 300 240 1 3 5 14 0 0 0 60 0 42954545 1

[antiriad]

I don't have any hardware at hand to test with, however having an odd number in any of the horizontal values will have issues. The pipeline on the pi4 runs at 2 pixels per clock, so inserting odd values would require switch output phase mid cycle. Most displays are tolerant of being out by one on these values.

In the cade of antiriad's line, switching to

Code: Select all

 hdmi_timings=320 1 20 30 34 224 1 10 14 16 0... 

will generally work.
...
Note that dpi_timings should be used instead of hdmi_timings if that is what you are setting. Whilst there is a fallback to use hdmi_timings instead, it removes the ambiguity on the pi4 where both hdmi0 and dpi can be active simultaneously.

Hi,
I edited my config.txt for Raspbian Stretch Lite:

Code: Select all

dtparam=i2c_arm=off
dtparam=i2s=off
dtparam=spi=off
dtparam=uart0=off
dtparam=uart1=off
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
dpi_timings=320 1 20 30 34 224 1 10 14 16 0 0 0 60 0 6400000 1
gpu_mem=128
scaling_kernel=8
dtparam=audio=on

But I still get no picture at all (black screen) on my RPi4 + VGA666 + VGA > SCART cable + CRT TV.
No problems using a RPi3 with the same parts.

May it be a RPi4 firmware issue? Should I run rpi-update on my Rpi4 using a different SD card? It seems that custom video modes does not work on RPi4.
Thank you

[6by9]

Hi,
I edited my config.txt for Raspbian Stretch Lite:

Code: Select all

dtparam=i2c_arm=off
dtparam=i2s=off
dtparam=spi=off
dtparam=uart0=off
dtparam=uart1=off
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
dpi_timings=320 1 20 30 34 224 1 10 14 16 0 0 0 60 0 6400000 1
gpu_mem=128
scaling_kernel=8
dtparam=audio=on

But I still get no picture at all (black screen) on my RPi4 + VGA666 + VGA > SCART cable + CRT TV.
No problems using a RPi3 with the same parts.

May it be a RPi4 firmware issue? Should I run rpi-update on my Rpi4 using a different SD card? It seems that custom video modes does not work on RPi4.
Thank you

What firmware and kernel versions are you using? "uname -a" and "vcgencmd version". Not that this has changed that significantly recently.

I must be imaging that this 7" LCD panel with Adafruit Kippah is producing a perfect image with the configuration

Code: Select all

enable_dpi_lcd=1
dtoverlay=vga666
dpi_timings=800 0 40 48 88 480 0 13 3 32 0 0 0 60 0 32000000 6
dpi_mode=2
dpi_group=87
dpi_output_format=454661
gpio=0-21=a2,np

then.
SOME custom timings may have issues, but please don't make huge overreaching statements unless you really have proof to back them up.

Using your timings I get a display from my VGA monitor, although it complains that "Input not supported". The wrap point is in the wrong place, but I'm not going to fault the monitor in that case. So the Pi appears to be in the clear, although I can't validate the timings. I may go and grab my spare Kramer scaler at lunchtime and see whether that will sync down that low.
How is your VGA to SCART adapter producing the appropriate sync voltages from a VGA signal? VGA is TTL whilst SCART is 75ohm terminated 1V p-p (and I remembered it going negative).
The drive strength of the GPIOs may have changed slightly with the drop from 40nm to 28nm, but it is still compliant to the technical specs for the Pi. 75ohm termination of 3.3V will draw 44mA, so that exceeds the permitted load on a single GPIO.

A quick check says
https://github.com/torvalds/linux/blob/ ... did.c#L229
So dmt mode 2 appears to have an odd value in the timings too. I thought we'd checked them all out and found only the 1366x768 modes that had issues, and those have a workaround implemented in the firmware. Finding a generic solution is non-trivial.

That serves me right for reading the page on my phone where lines wrapped in awkward places. Mode 2 is fine - all the horizontal values are even.
640, 1, 32, 64, 96, 400, 0, 1, 3, 41, 0, 0, 0, 85,0, 31500000, 5

[6by9]

Grabbed my Kramer scaler/switcher (VP719XL should you care).
It syncs to your custom timings quite happily, although it identifies it as 720x235 @ 60Hz. Seeing as this is all analogue with no pixel clock it is impossible to determine the exact horizontal resolution.
There is a some bitcrawl creating a shimmering effect. Part of that may be due to the scaler inside the Kramer unit sampling the signal on the "wrong" transition as it thinks it is 720 pixels wide. As already noted, there is nothing really that can be done there. It may be exacerbated by having to use particular fractional divider values in the PLL creating the pixelclock. For your custom timings "vcgencmd measure_clock dpi" reports 6,380,859Hz, instead of your requested 6.4MHz. Core clock defaults to 500MHz on Pi4, so 500M/6.4M = 78.125.
You could try messing with the core clock frequency to try and reduce the fractional side, but the clock structure on the Pi4 is more complex than earlier revisions.

dpi_mode=2, dpi_group=2 is also quite happy, although again it reckons it is 720x400 @ 85Hz.

[rememberizer]

There is a some bitcrawl creating a shimmering effect.

As already noted, there is nothing really that can be done there.

Does this also apply to the custom timings I used?

[6by9]

There is a some bitcrawl creating a shimmering effect.

As already noted, there is nothing really that can be done there.

Does this also apply to the custom timings I used?

What, that there is bitcrawl? Yes, it exists on all low resolution timings I tested.
I suspect it exists on the higher resolutions too, but as it is a fraction of the pixel size, and the pixel size is smaller, it is less noticeable.

I hadn't tried your mode of

Code: Select all

hdmi_timings=1920 1 152 246 280 240 1 3 7 12 0 0 0 60 0 40860000 1

but have now. Is your display really 1920x240, or are you just trying to seriously stretch the pixels to try and fake a greater horizontal resolution?

The console is unreadable, but playing a video with omxplayer looks reasonable.
Edit: My scaler was causing most of the artifacts there in doing the upscale. The monitor will lock onto it (although it complains), and that is readable.

If you have 247 in for the sync timing then the left hand edge does ripple due to the extra pixel stuck in the pipe. Using 246 fixes that.

[antiriad]

Grabbed my Kramer scaler/switcher (VP719XL should you care).
...

I'm sorry, but I struggle to understand the outcome of the tests and, therefore, the answer in your post (not everyone on the forum is an engineer
).

In summary:
- is shimmering a problem due to RPi4 and cannot be solved in any way?
- why custom resolutions (which work well on RPi3) don't work on RPi4, using the same hardware (VGA666, cables, CRT TV)?

Thank you very much.

[6by9]

In summary:
- is shimmering a problem due to RPi4 and cannot be solved in any way?

I haven't compared to a Pi3.
Gert has already made comment that dotcrawl is inherent in having cross talk between highspeed GPIOs, and that is totally true.
As I've already commented, Pi4 is using a totally different clock structure. Having checked with a colleague, the pixel clock is being derived via a fractional divider from a 750MHz clock. That fractional divide will cause jitter on the sample clock. The 750MHz clock can not be changed as it also drives things like the ethernet clock.
In theory it would be possible to shift to using the divider off the core clock, and the core clock could be adjusted to make it an integer divider, but it is such a niche use case that it won't be high up the priority list to investigate. (Something very similar is done for the SDTV output for the same reasons, but that is one of the main features of the board, and is not on by default because it compromises performance).

- why custom resolutions (which work well on RPi3) don't work on RPi4, using the same hardware (VGA666, cables, CRT TV)?

Custom resolutions do work, with the minor quirk over odd values in the timings.

The Pi DPI interface is not specified to drive your particular cabling arrangements, or indeed any. It is up to the designer of that hardware to ensure it is within tolerances.

I'm suspecting that the Pi4 has changed the electrical output characteristics on the GPIO lines, and is now not driving the sync line on your display strongly enough. This is why I have queried how your VGA to SCART lead is combining the H & V sync signals to generate the composite sync signal required on SCART.
The VGA666 docs already acknowledge that the sync lines are out of spec on the GPIOS:

The design violates the GPIO specification. You should not draw more than 16mA from a pin. Thus
the minimum resistor is 3.3/0.016 = 206 Ohms. But you will notice that the HSYNC and VSYNC
resistor are less. I tried 200 Ohm but found that it does not work on some monitors. On the prototype I
used 100 Ohm resistors, you might even have to go down to 80 ohms

So if your conversion to composite sync takes the GPIO drive further out of spec then you really are on your own.

Please investigate your hardware before making further complaints.
At the present time I have satisfied for myself that custom timings to the DPI interface are working as they should.
I will look at fixing up the odd horizontal timings values automatically, but that's more of a cleanup than anything else.

[fridgemagnet]

Hi,

The latest Raspbian distro includes gstreamer support for the "kmssink" video sink which allows direct video rendering into a frame of a DRM device. This works really well on the Pi's HDMI output however I'd like to use it with this module (instead of HDMI, not in addition to). In order for the kmssink to work, it needs access to nodes in the /dev/dri folder, which only materialises when the "vc4-fkms-v3d.dtbo" overlay is loaded during boot. However if I try and enable this and the vga666.dtbo one as well, the Pi hangs during boot, there's a bit of initial disk activity but then everything stops.

Is it therefore possible to accomplish this and does anyone have any guidance on how to go about doing it?

The VGA666 works fine on the Pi4 with vc4-fkms-v3d. You'll need the normal firmware setup for the VGA666 as described in the first post:

Code: Select all

enable_dpi_lcd=1
dpi_mode=XX
dpi_group=2

There have been a couple of small hiccups with overlays, so please ensure you have updated the kernel and bootloader.

Thanks for the pointer, having done just that it all sprang into life. Cheers.

[rememberizer]

Does this also apply to the custom timings I used?

What, that there is bitcrawl? Yes, it exists on all low resolution timings I tested.
I suspect it exists on the higher resolutions too, but as it is a fraction of the pixel size, and the pixel size is smaller, it is less noticeable.

I hadn't tried your mode of

Code: Select all

hdmi_timings=1920 1 152 246 280 240 1 3 7 12 0 0 0 60 0 40860000 1

but have now. Is your display really 1920x240, or are you just trying to seriously stretch the pixels to try and fake a greater horizontal resolution?

The console is unreadable, but playing a video with omxplayer looks reasonable.
Edit: My scaler was causing most of the artifacts there in doing the upscale. The monitor will lock onto it (although it complains), and that is readable.

If you have 247 in for the sync timing then the left hand edge does ripple due to the extra pixel stuck in the pipe. Using 246 fixes that.

This is a "super resolution" that's set up so that I can integer scale most emulated systems easily on a CRT.

There was still bitcrawl when I set 246 on my CRT. You mean you didn't see any when you used 246? Edit: oh, I get it now, only the left edge was fixed. so bitcrawl on CRT is not fixable on low res Pi4. Thanks for all your help, at least I won't go crazy trying to fix this anymore and I'll just keep using my pi 3!

[antiriad]

at least I won't go crazy trying to fix this anymore and I'll just keep using my pi 3!

I have come to the same conclusion.

But let me say, at least, that it's really sad that analogue output is no longer "supported" properly, this was the feature that personally made the RPi "special" compared to other single board computers.

I hope at least that in the future will be possible to "avoid" the bitcrawl on VGA666 even disabling some other functionalities (like one of the dual 4K monitor).