javiertoti
commented
6 years ago Interesting topic for retrogamers, please help this man.
Closed mortaca closed 5 years ago
javiertoti
commented
6 years ago Interesting topic for retrogamers, please help this man.
marcushg85
commented
6 years ago I also think it is a really interesting function it should be available, thanks
xjauna
commented
6 years ago Interlaced mode is very interesting for retro devices.
pelwell
commented
6 years ago "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.
mortaca
commented
6 years ago 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:
hdmi_timings 512 1 25 46 17 480 1 1 3 23 0 0 0 60 1 9600000 1I 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.
6by9
commented
6 years ago 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. Whether there is the resource or motivation to experiment is a totally different question.
mortaca
commented
6 years ago 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.
6by9
commented
6 years ago 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?)
popcornmix
commented
6 years ago PIXELVALVE_VC bit 4 is called INT_MODE:
0 LCD / progressive mode
1 Interlaced modeBut 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.
6by9
commented
6 years ago 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 mode member of PIXELVALVE_PERIPH_SETUP_T.
DPI fixes it at PIXELVALVE_MODE_VIDEO, but the VEC middleware will set it to PIXELVALVE_MODE_VEC_PAL or PIXELVALVE_MODE_VEC_NTSC.
Whether that kicks the pixelvalve into producing the weird long and short sync pulses during the vsync to denote field order I don't know - I can't actually see any code that handles those values for the mode in the pixelvalve driver, so perhaps it is real magic!
mortaca
commented
6 years ago 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.
6by9
commented
6 years ago 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. I had been reading http://martin.hinner.info/vga/pal.html and others which give detail of the difference in sync pulses on the first couple of lines of each field to identify the fields. That may be possible as it remains as pure digital logic levels, but depends on how the hardware interfaces to the rest of the system.
mortaca
commented
6 years ago 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.
6by9
commented
6 years ago 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.
mortaca
commented
6 years ago 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.
6by9
commented
6 years ago 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? My analogue video knowledge is pretty rusty, and I don't have that much documentation on the DPI peripheral, so I can't say whether using XOR is valid or not. I was certainly surprised at your 3 states on the VGA lines and had wondered how you were combining them to feed the SCART. It had crossed my mind that simply wiring them together was going to be a tad iffy and may have given the waveform you were seeing.
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.
mortaca
commented
6 years ago 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.
Odd:
Even:
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.
6by9
commented
6 years ago 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. I can't quite tell if we can set them all up automatically as long as we know whether it is first or second field odd (PAL/NTSC). I'll try and make the full set configurable but optional on the dpi_timings line, and create a test firmware that you can try out.
mortaca
commented
6 years ago 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.
6by9
commented
6 years ago 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.
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. I'm trying to minimise it, but I don't have the hardware to test, and I'm not wanting to spend long at all on this. TBH If I haven't got a working image by the end of today then I'm shelving it - sorry, but time and resource are in short supply.
6by9
commented
6 years ago Please give the firmware image at https://drive.google.com/file/d/14X1eRLFsQQUy8t2wapjO2wbSR-hHclhi/view?usp=sharing a test.
It uses the dpi_timings line in config.txt (NOT hdmi_timings).
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:
< v_sync_even_pulse > < v_even_front_porch > < v_even_backporch > < v_even_active_lines > < second_field_offset >
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. < second_field_offset > is optional, and will be computed as half the overall line time if omitted.
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.
mortaca
commented
6 years ago 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.
dpi_timings=512 1 25 46 17 480 1 1 3 23 0 0 0 60 1 9600000 1 0
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:
even:
Then I tried following the instructions filling in the other fields of the timing but with the same result.
dpi_timings=512 1 25 46 17 480 1 1 3 23 0 0 0 60 1 9600000 1 1 3 1 23 240
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.
sigmaris
commented
6 years ago 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: https://github.com/sigmaris/linux/commit/2e8bec08123e4ffd02de2c8fdbe166128320c2b4
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.
mortaca
commented
6 years ago @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.
6by9
commented
6 years ago The J-PAC looks like it may be doing something involved with the sync signals. https://www.ultimarc.com/jpac.html:
Custom microcontroller only allows sync signals to be sent to the monitor if they are in the correct range that the monitor is designed for. Avoids driving the monitor with a too-high horizontal sync rate which can damage some arcade monitors. Sync circuitry also converts separate horizontal and vertical syncs into composite sync. Can handle both positive and negative vertical sync.
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.
6by9
commented
6 years ago 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. @sigmaris How have you setup the mode with KMS? If I can replicate that then I can derive the same settings from the firmware.
sigmaris
commented
6 years ago @6by9 Currently a custom kernel is needed; using the kernel, modules and DT overlays built from this branch "interlace-hack-vc4-dpidac" with CONFIG_DRM_RPI_DPIDAC enabled, and adding dtoverlay=vc4-kms-v3d and dtoverlay=vc4-vga666 to config.txt, and adding video=VGA-1:640x480i to cmdline.txt should be sufficient to get an interlaced signal output from a VGA666 adapter via DPI. That branch is a bit behind the current rpi-4.14.y kernel, but the 3 patches could be updated to the current kernel fairly easily if needed.
@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: https://github.com/anholt/linux/issues/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 video=VGA-1:640x480i on the kernel command line.
cedricp
commented
6 years ago Hi, I just want to thank you all guys ! I'm struggling for a long time now to connect my RPi3 to an old LCD from my car. I tested a custom VGA565 DPI (don't need deep color depth) but I only succeeded to display 320x240p. No way to get 480i signal. Finally, after reading this thread, I've got it working :+1: I used a HDMI to VGA converter, I mixed the HV sync signals with a custom XNOR gate to the green input line (this monitor is sync-on-green). I just had to configure the hdmi mode to 480i (mode 7, group 1) and voila :) Not sure the field ordering is right, but I can't see any problem on the screen.
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
commented
5 years ago Please close this issue if it has been resolved.
JamesH65
commented
5 years ago Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.
mortaca
commented
4 years ago Please close this issue if it has been resolved.
Why is solved? On the new VC6 driver or V3D the interlaced modes continue disabled on the DPI, please reopen again the issue.
milika
commented
3 years ago Please reactivate interlaced modes!!
6by9
commented
3 years ago 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. https://github.com/raspberrypi/linux/pull/4241 is fixing up the pixel valve configuration to support NTSC as previously it was only supporting the PAL/HDMI "odd field first" config.
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.
milika
commented
3 years ago 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.
4241 is fixing up the pixel valve configuration to support NTSC as previously it was only supporting the PAL/HDMI "odd field first" config.
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. Tool should be similar capabilities as your hdmi timings option? Thanks
6by9
commented
3 years ago 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. Tool should be similar capabilities as your hdmi timings option?
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 xrandr, assuming you're running X.
dtoverlay=vc4-kms-v3d and dtoverlay=vc4-kms-vga666.xrandr should list HDMI-1, HDMI-2, and VGA-1, with the default supported modes.xrandr --newmode as covered in the man pages, and https://askubuntu.com/questions/377937/how-do-i-set-a-custom-resolution as it's common to any Linux system running a DRM/KMS graphics stack. Whilst with hdmi_timings you set each value explicitly, DRM accumulates the values across each frame (see https://elixir.bootlin.com/linux/v5.10.46/source/include/drm/drm_modes.h#L203)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.
setiawanj
commented
3 years ago @6by9 Currently a custom kernel is needed; using the kernel, modules and DT overlays built from this branch "interlace-hack-vc4-dpidac" with
CONFIG_DRM_RPI_DPIDACenabled, and addingdtoverlay=vc4-kms-v3danddtoverlay=vc4-vga666to config.txt, and addingvideo=VGA-1:640x480ito cmdline.txt should be sufficient to get an interlaced signal output from a VGA666 adapter via DPI. That branch is a bit behind the current rpi-4.14.y kernel, but the 3 patches could be updated to the current kernel fairly easily if needed.
@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?
sigmaris
commented
3 years ago @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/
rtomasa
commented
2 years ago 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. #4241 is fixing up the pixel valve configuration to support NTSC as previously it was only supporting the PAL/HDMI "odd field first" config.
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.
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: https://github.com/raspberrypi/linux/commit/fe683ca72fbf0c258ef8976f20b3972e901fb1bd#diff-6c2809c90758efe822c708a4b8728e00