Why is the interlaced mode disabled in the DPI? #2668
Comments
|
Interesting topic for retrogamers, please help this man. |
|
I also think it is a really interesting function it should be available, thanks |
|
Interlaced mode is very interesting for retro devices. |
|
"Me too"/upvote posts like this don't help - they just generate email spam for the devs. The thumbs-up feature is better because it generates less clutter and no notifications, but we still get to see the interest. The commit you reference is in the open source ARM-based "vc4" V3D driver. Is this what you are using (you don't say)? If so, the correct place to report this question/issue is in the author's repo. If not, this commit is a red herring. |
|
I'm not really using the vc4 driver but the post is in general to deal with the theme of the mode interlaced by the GPIO, when launching an interlaced hdmi_timing like this: I find this image, in the picture it is not appreciated but two displaced images instead of superimposed and by HDMI converter these timings are functional. If the use of a modified driver like vc4 or another can be the solution I would greatly appreciate a recommendation of where to continue investigating. |
|
AFAIK The DPI peripheral doesn't have the capabilities to produce an interlaced frame, unlike the VEC (composite video) and HDMI. It would need to output the relevant set of long and short sync periods to identify the fields, and I can find no reference to that in the documentation. It's just possible that some of the pixel valve setup intended for the VEC may have a useful effect on the DPI interface too, because AIUI you effectively are wanting PAL or NTSC interlacing on DPI. |
|
The resources or motivation can be obtained in different ways, there is no problem in making a contribution for the hours of research employed. The best thing would be to achieve this through software but I can experiment with the use of dedicated hardware for this purpose if necessary, the next steps I can follow are to analyze with oscilloscope the synchronism signal emitted by a hdmi to vga converter and compare it with the same hdmi_timing through the DPI, so we can know exactly what we need. Any idea is very grateful. |
|
Well we have no interlaced hardware to connect to the DPI interface, nor video analyser (AFAIK). We may even struggle to find a display with a composite or SCART input! There is one obvious setup parameter that may tickle things into life but which is fixed for DPI displays. It wouldn't be difficult to stuff that into a config.txt entry, or extend the new dpi_timings parameter, to allow it to be set to NTSC or PAL instead. Whether it will do anything useful I have no idea. (For others at Pi Towers, PIXELVALVE_MODE_xxx. I can't find pixelvalve docs, but does it seem sane to try switching from VIDEO to VEC_NTSC/VEC_PAL?) |
|
PIXELVALVE_VC bit 4 is called INT_MODE: But I don't believe anyone has ever tried to drive a DPI display in interlaced mode so the chances of this magically doing something useful are low. |
|
INT_MODE is already controllable by the interlaced flag in hdmi_timings/dpi_timings (the 15th field of the 17 by the looks of it). It appears that @mortaca has already set that in his test hdmi_timings. I was more curious over the |
|
First of all, thank you very much for the interest shown in this topic, it is really something that many users will thank. I have done some tests waiting for an HDMI to VGA adapter to compare, I have looked at the CSYNC synchronous signal in my circuit which is nothing more than the mix of HSYNC and VSYNC and I have compared between a progressive hdmi_timing with the interlaced option disabled and the aforementioned timing with the option activated and interlaced resolution values and they are exactly the same signal. 240p timing by DPI: 480i timing by DPI: EDITED: Ok I have done new tests, I have obtained a hdmi to vga converter and I have made a vga to scart cable mixing the H and V sync, for the configuration of the Pi I used the hdmi_mode=1 and hdmi_group=8 to start with a 240p mode , it has worked and this is the synchronization signal, exactly the same as for the DPI port. Then I changed to hdmi_mode=6 which is 480i and the change in the image is significant, it has also worked well and the synchronization signal are this.
I tried using the hdmi_timings but these do not work with the hdmi_group=2 hdmi_mode=87 Conclusion, Here we can see the two heights in the synchronism signal that define when it is an even or odd field in the signal that does not exist through the DPI port. |
And they can't exist directly from the DPI interface as it is pure binary digital logic and can't create that the third voltage level. That was the reason I had already said I didn't believe that the DPI interface was capable of doing it. |
|
True but the DPI port has two pins that can be used for this purpose, the 0(PCLK) u and the 1(DE)
Then it would be necessary to add this new level to the sync signal through a little electronic but nothing problematic. |
|
This is all cast in hardware, so no real options to add new magical features without respinning the silicon (not going to happen and not backwards compatible). PCK and DE have dedicated functions for driving LCD panels so I very much doubt they have any other modes of operation within the DPI peripheral. |
|
Ok, it would be necessary to use a compute module to have an extra pin to do this but I think that all this is not necessary, reviewing the documentation that you have previously contributed, the sync signal that looks a bit different from what I could check with the oscilloscope. The first difference is that they speak of sync+luma, in addition to the sync it carries the brightness signal, but we in the Pi have the pure H and V sync so the waves that appear in the document we do not have them. The second most important difference is that the differentiation of even and odd fields I do not see that it is done with a third logical level, it is all in only two high and low levels with the vertical signal acting in XOR mode, I am currently simply mixing the two signals with two resistors in paralallel so this would be equivalent to a logical OR gate, maybe here is the solution! This would be the signal generated by my circuit currently VS the signal resulting from using a logical XOR gate: With this we could obtain that inversion in the signal that we see in the documentation that contributed :D If you see it right I start to create the circuit to check it. |
|
The sync pin for RGBS mode on a SCART plug is also the composite video pin in normal mode. Whether the source puts out the full composite signal or only the syncs is up to the individual implementation. Are the traces you've shown actual captures from the DPI HS and VS lines, or something else? Using a Compute Module is not going to help - all of this is backed into the silicon as dedicated peripherals. If the signal isn't generated by the peripheral then it is not possible in software to magically expose it. |
|
The combined sync signal that shows in the last tests is made from H and V sync of the VGA output of the HDMI to VGA converter, to combine them you have to use two resistors in parallel in this way so that the outputs do not short-circuit, It is the simplest way to mix the signal.
It is not the most perfect way to do it since the sync pulses that should be towards the positive part when the horizontal pulse is down are inverted, that's why more logical levels appear, but it seems that the TV has no problem in understanding the signal of this way because the image is seen correct, however it is not the orthodox way of doing it. I have done more checks and I think that what happens and it seems much simpler than we thought, in the signal through the DPI port the pulses of the even fields do not appear when the signal must be interlaced. This capture is of the vertical signal isolated by selecting in the oscilloscope to see the odd fields by the hdmi to vga converter: When we select the even fields, this other pulse appears displaced from the previous one: As a result of mixing with the horizontal signal we obtain these two captures for even and odd fields, we do not look at the levels because the TV accepts it this way and the image is seen correctly. When we do the same check through the DPI port we observe that there are odd fields in the VSync: And in the Csync everything is correct for progressive: But when I select the even fields in the oscilloscope, nothing appears, the signal loses synchronism and is not able to find them unlike the signal coming from the hdmi. I think this is the problem, the hdmi_timings are not able to generate the even fields when the box to activate the interlaced mode is 1 in its corresponding field. |
|
Random RGBHV to RGBS circuit found on the internet - http://www.epanorama.net/circuits/vga2rgbs.html Simple mixing of H & V syncs will cause all sorts of confusion - sorry, but I'm going to ignore all results that you post using simple mixing. Post the individual H & V traces and you potentially have something that is useful. Looking in more detail at the structures being passed around, there are a bundle more settings for the pixel valve that are only used interlaced modes for the VEC to set up the even field sync parameters. |
|
The first two captures of the previous post are of the Vsync without mixing, anyway most cables and adapters use this way of mixing the signal, you can see below one of the hundreds of schemes to make a cable vga to scart with this method: http://www.geocities.ws/podernixie/htpc/cables-en.html I myself have distributed many circuits with this system and it has been tested on many TVs without problem, there are integrated that also do this function more accurately but this is not the subject of the main message. About creating a special field in the hdmi_timings is it really necessary? the "interlaced" field is not valid? you just have to make it functional, right now it does not do anything. Thank you very much again for the time provided. |
Setting "interlaced" does do something, but it doesn't tell the system:
One that still isn't clear is exactly whether I need field or frame height in parameter 6. So, yes, there is a bundle of extra config required. |
|
Please give the firmware image at https://drive.google.com/file/d/14X1eRLFsQQUy8t2wapjO2wbSR-hHclhi/view?usp=sharing a test. It uses the In theory, given one extra parameter (to make 18) of the field order, the remaining fields should be set appropriately. 0 = even field first, same as PAL, 1 = odd field first, same as NTSC. If not, then you can also add on the: One quirk - v_even_active_lines will be half v_active_lines, as one is for the frame and one is for the field. v_active_lines is divided by 2 for the odd field active_line count when interlaced. Having said I have no test kit, I suspect that our oscilloscopes can be convinced to decode video and lock on to individual lines, and I have a VGA666 which would act as a suitable interface. If the firmware doesn't work for you I will see what that produces. |
|
Ok the results are promising, I think something happens with the firmware that is not entirely compatible with the version of the operating system that I am using because it starts very very slow but I obtained this image by applying this timing that previously resulted in two separate fields.
I've looked at the signal, I know you do not like to see it that way but the odd and even fields now do exist. odd: Then I tried following the instructions filling in the other fields of the timing but with the same result. I do not understand very well what happens but it seems a very important improvement, these are captures of the previous operation, with a constant vertical sweep with the same timing and previous firmware. I think now it's just a matter of adjusting the timings, but I think it's working !!!!!!! Again many thanks for the work and effort invested, I will continue testing, of course you can use a vga666 if you have it and if your LCD TV has scart input (it is not necessary to be CRT) you can make a cable vga to scart following the scheme that I have previously sent. |
|
For what it's worth, the vc4 KMS driver can output an interlaced signal on DPI if you apply a hack to remove the code that disallows interlaced modes, like this: sigmaris@2e8bec0 Connected via a VGA666, and an Ultimarc J-PAC adapter, to an arcade cabinet, it can display a 480-line interlaced picture: This is displaying a 240x320 vertical game on a horizontal-oriented CRT monitor; to give enough space to fit the 320 vertical pixels, a 480-line mode is needed. The photo was taken before I adjusted the aspect ratio, so the game screen is much wider than it should be. The 480 line mode is also useful for displaying the Linux console in the highest possible resolution. The only caveat is that perceptually on the screen, there seems to be more line flicker than there ought to be, which makes me wonder if the odd and even lines are being drawn physically on top of each other by the CRT instead of interlaced between each other. I wonder if this is related to the half-line offset on the even field being absent in the signal? I don't have an oscilloscope so can't inspect the sync signals. |
|
@sigmaris Awesome, can you share the driver already compiled? I'm looking at ../kernel/drivers/gpu/vc4/drm/ but I only find one file already compiled vc4.ko With this I am going to add new functions to the RGB-Pi software. |
|
The J-PAC looks like it may be doing something involved with the sync signals.
I will have a look at the setup that the vc4 driver is pushing into the pixelvalve, but I don't think I see it setting the values that I believe are required for genuine interlaced support. |
|
Take it back, the vc4 driver does have some setup for interlaced at https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/gpu/drm/vc4/vc4_crtc.c#L414, but ONLY for PAL/HDMI, not NTSC field ordering. You have access to all those register values via the config.txt line, therefore it should be possible to achieve the same setup. |
|
@6by9 Currently a custom kernel is needed; using the kernel, modules and DT overlays built from this branch "interlace-hack-vc4-dpidac" with @mortaca Sorry, it's not just a single driver, and I don't think a binary kernel module I compiled would work with other kernels. You can try compiling the patched kernel from the above branch, though. For background info - Because DPI has so far only been used to drive fixed-resolution LCD panels with the open-source driver, there isn't an easy way to use it with a range of displays supporting several different video modes, like would be connected via VGA666, Pi2SCART, etc adapters. There was some discussion of this here: anholt#36 and I tried a few different approaches. Eventually, I added a DRM bridge driver based on dumb-vga-dac.c, which is needed to set the bus format and video modes on the VGA connector, and a devicetree overlay to activate the driver. Amongst other things the DT overlay contains display timings which are loaded by the driver to define video modes; the example modes there are a 640x480 progressive VGA mode for VGA-capable displays, and a 320x240 progressive mode and 640x480 interlaced mode for 15kHz displays. These can and should be changed (e.g. by an additional DT overlay) to the appropriate modes for the connected display - modes can't be autodetected due to the lack of DDC / EDID data. The mode used at boot can be force selected by an argument like |
|
Hi, The XNOR gate is built with 4 NAND and a transistor to invert an input (I did it with salvaged components).
The XNOR gate is made like this : I used a 74LS00 (4 NAND gates) to do a XOR operation and I invert an input to finally build a XNOR. |
pelwell
added
the
Close within 30 days
|
Please close this issue if it has been resolved. |
|
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant. |
Why is solved? On the new VC6 driver or V3D the interlaced modes continue disabled on the DPI, please reopen again the issue. |
|
Please reactivate interlaced modes!! |
Do you have hardware that shows that it works? There's no point in enabling something that is broken. The kernel driver will take the lead here. If someone can provide a configuration that shows it working, then I may be persuaded to look at the firmware again. Interlacing has too many parameters to make it trivial to enable. Is it odd or even field first? What field delay is in use? How do the porch timings differ between fields? These vary between PAL and NTSC. HDMI follows PAL, but there's no guarantee which way something connected via DPI would go. The simplest option to test is probably a VGA666 feeding an interlaced video mode to a VGA monitor. 1024x768i @ 43Hz is a DMT standard mode so has a chance to be supported by the monitor. CEA modes are unlikely to be. It'll largely be down to your specific sink device. |
What would be the tool i can use on rpi 3b/4 with my vga666? I have a bunch of crts, from 30khz pc monitors to 15khz tvs. |
You'll need to build a custom kernel first to allow selection of interlaced modes. Just removing the conditional at https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_dpi.c#L209 and rebuilding the kernel (see https://www.raspberrypi.org/documentation/linux/kernel/building.md). Whether there are other restrictions I don't know. In theory
If you boot only to a console then it's harder. I'll talk with those involved as to whether it is sensible to extend the kernel command line parsing to allow a complete mode to be defined. Currently it's only possible to select modes computed via the CVT timing formula, or which are found via the EDID or some other definition for the connector. |
@sigmaris I've given this a try on my Pi 4B, on top of the latest kernel, but it doesn't seem to work. No VGA connector appears. Do you know if this should work on Pi 4? |
I don't have a Pi 4 to try it myself, but in principle the approach should work on a Pi 4 using "full" KMS. There's a blog post by someone who's updated the code for the DRM bridge driver to recent kernels and made it into an out-of-tree module, and mentions using it with the Pi 4: http://mydedibox.fr/rpi4-custom-modes-on-a-crt-tv-the-holy-grail/ |
Here the proof that interlaced works perfectly fine via DPI in KMS mode in Rasberry Pi 4 when removing the 2 lines that prevents interlaced from vc4_dpi.c: https://twitter.com/rtomasal/status/1461303096144011265?s=20 |
Hello, I am the main developer of the RGB-Pi project to connect the Raspberry with CRT TVs through the DPI port, users would love to be able to use interlaced modes but I see that in the firmware this mode is disabled, why? How could I enable it again please? Thank in advance.
I found this on the firmware: fe683ca#diff-6c2809c90758efe822c708a4b8728e00
The text was updated successfully, but these errors were encountered: