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.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?
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:fridgemagnet wrote: ↑Mon Oct 07, 2019 6:38 pmHi,
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?
Code: Select all
enable_dpi_lcd=1
dpi_mode=XX
dpi_group=2
I'm using an unofficial power supply and I still have the issue on my Raspberry Pi 4.rememberizer wrote: ↑Fri Oct 18, 2019 6:22 amare you also using the official power supply? I'll try to use a different one just to compare.
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.antiriad wrote: ↑Fri Oct 18, 2019 3:00 pmI'm using an unofficial power supply and I still have the issue on my Raspberry Pi 4.rememberizer wrote: ↑Fri Oct 18, 2019 6:22 amare you also using the official power supply? I'll try to use a different one just to compare.
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...
Hello and thank you for your support.
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
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
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
Code: Select all
hdmi_timings=320 1 20 30 34 224 1 10 14 16 0...
A quick check saysI don't have any hardware at hand to test with
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.6by9 wrote: ↑Sun Oct 20, 2019 8:47 am
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.
Code: Select all
dpi_timings = 2048 1 180 202 300 240 1 3 5 14 0 0 0 60 0 42954545 1
Hi,6by9 wrote: ↑Sun Oct 20, 2019 8:47 amI 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 towill generally work.Code: Select all
hdmi_timings=320 1 20 30 34 224 1 10 14 16 0...
...
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.
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
What firmware and kernel versions are you using? "uname -a" and "vcgencmd version". Not that this has changed that significantly recently.antiriad wrote: ↑Sun Oct 20, 2019 9:46 pmHi,
I edited my config.txt for Raspbian Stretch Lite:
But I still get no picture at all (black screen) on my RPi4 + VGA666 + VGA > SCART cable + CRT TV.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
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
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
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.6by9 wrote: ↑Sun Oct 20, 2019 11:16 amA 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.
What, that there is bitcrawl? Yes, it exists on all low resolution timings I tested.
Code: Select all
hdmi_timings=1920 1 152 246 280 240 1 3 7 12 0 0 0 60 0 40860000 1
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
I haven't compared to a Pi3.
Custom resolutions do work, with the minor quirk over odd values in the timings.antiriad wrote:- why custom resolutions (which work well on RPi3) don't work on RPi4, using the same hardware (VGA666, cables, CRT TV)?
So if your conversion to composite sync takes the GPIO drive further out of spec then you really are on your own.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
Thanks for the pointer, having done just that it all sprang into life. Cheers.6by9 wrote: ↑Mon Oct 14, 2019 10:17 amThe 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:fridgemagnet wrote: ↑Mon Oct 07, 2019 6:38 pmHi,
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?There have been a couple of small hiccups with overlays, so please ensure you have updated the kernel and bootloader.Code: Select all
enable_dpi_lcd=1 dpi_mode=XX dpi_group=2
This is a "super resolution" that's set up so that I can integer scale most emulated systems easily on a CRT.6by9 wrote: ↑Wed Oct 23, 2019 3:14 pmWhat, 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 ofbut 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?Code: Select all
hdmi_timings=1920 1 152 246 280 240 1 3 7 12 0 0 0 60 0 40860000 1
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.
I have come to the same conclusion.rememberizer wrote: ↑Wed Oct 23, 2019 11:09 pmat least I won't go crazy trying to fix this anymore and I'll just keep using my pi 3!