Gert van Loo wrote:
There is no need for specific driver support. As all the pins are driven by hardware the signals ARE already present.
They just don't come out until you set the GPIO pins to DPI mode.

Now if you read the manual very carefully you should be able to find out how to get these signals out.
Hint: look at the installation section and at all the files present on github.

jdb wrote:As a manual workaround, use a GPIO-poking interface (wiringpi or similar) to directly set GPIO0 and GPIO1 to ALT2 to gain access to PCLK and DE.

Thank you!
The next thing is finding out how to set this up as early as possible in the boot process.
This is a very exciting way to get the older people (like me) to start reading and actually learning something!

jojopi wrote:… only available on the camera connector, and on Rev2 GPIO21 (red7) is. So even 8 colour mode is difficult to wire.

I had not read the documentation. Using dpi_output_format=6, red7 can be moved to GPIO25, and then 8 colour mode presents no wiring difficulty on a Model A/B Rev2.

Better still, with board modification to free GPIO16 and GPIO6 (which can be remapped in the device tree), the four most significant bits are available for all three guns. So 4096 colours would appear to be possible without having to write non-standard data in the framebuffer.

Does hvs_set_dither work on the DPI peripheral? Would it be technically possible to extend it to support dithering to 4:4:4 bits?

Would it be possible to convert this adapter to generate a composite video signal at 1vpp with a 50Hz retrace signal??

I am aware of the colour limitation but I would like to explore the possibility of drawing pixels in the VBI region and if genlock was possible mix / overlay this with the composite video port.
Basically I want to simulate the teletext service on my Pi and maybe add subtitles to video clips so they be recorded to S-VHS tape rather than putting the text over the frames.

If I order:
20 boards, I'll have to charge $5-$6 USD + s/h per bare board not to lose money
50 boards, I'll have to charge $4-$5USD + s/h per bare board not to lose money
100 boards, I'll have to charge $2-$3 USD + s/h per bare board not to lose money

I'll take the risk for carrying some stock - say 50 boards - but I'd really like to know that I won't be stuck with 89 boards, so if you want some, please speak up!

Note: at above prices I am not charging my time for filling orders etc

it will use the custom hdmi timings for DPI.
You may need a datasheet for the display to determine the timings required, although starting with the CVT settings may get you an image is the display is happy with that.

Yet Broadcom seem to think "DPI" means "display pixel interface", and that matches with MIPI DPI. Whatever it's called there doesn't seem to be a lot of detail in the public domain on the SoC hardware.

hippy wrote:Yet Broadcom seem to think "DPI" means "display pixel interface", and that matches with MIPI DPI. Whatever it's called there doesn't seem to be a lot of detail in the public domain on the SoC hardware.

I think this is right. I've checked the peripheral spec and it just refers to "DPI" - no mention of "display parallel" or "display pixel".
The internet has very few references to either. I believe we are compatible with MIPI DPI, and they do call it "display pixel interface".

I think I'll just stick to calling it DPI and DSI, with the former needing lots of pins due to its parallel nature, and the latter using fewer pins due to its serial nature...

I did not document the DPI or the SMI as a the time they could not be used due to a severe lack of available pins.
There was never any 'secrecy' about these interfaces.
It was more 'what can I do in the limited time allocated: the important interfaces first'.

We now have a lot more pins on the B+ and there are now people working full-time on the PI
so I assume the details will appear in due time.

DPI is already giving me a lot of ideas, and I am sure SMI will as well.

Gert van Loo wrote:I did not document the DPI or the SMI as a the time they could not be used due to a severe lack of available pins.
There was never any 'secrecy' about these interfaces.
It was more 'what can I do in the limited time allocated: the important interfaces first'.

We now have a lot more pins on the B+ and there are now people working full-time on the PI
so I assume the details will appear in due time.

Gert van Loo wrote:I did not document the DPI or the SMI as a the time they could not be used due to a severe lack of available pins.
There was never any 'secrecy' about these interfaces.
It was more 'what can I do in the limited time allocated: the important interfaces first'.

We now have a lot more pins on the B+ and there are now people working full-time on the PI
so I assume the details will appear in due time.

I'm very curious as to what the secondary memory interface is good for. I noticed it has a wide data bus, but only a few address lines, so it it for some kind of paged block mode flash device, like a K9K2G16Q0M, or for some kind of FIFO RAM?
Or something else altogether.
Is it possible to add a fast swap mechanism (virtual memory) using it?
Or, I'm speculating even more, for a SATA interface....