Davidoccam: methinks Andreas speaks much sense, as does Hardware_man ( or CAN-DO man as I call him)!
in the background Gordon (Raspberry Pi - Director of Engineering) wants to help but it is mightily complex.
The red-herring of HDMI and HDCP is raised. Nobody wants it anyway as it is a poisoned chalice.
The other poisoned chalice of USB also raised its ugly head,
Hardware_man: I want to use the Pi board to run a high profile H.264 encoder to get data rates down to the write speed of the SD card for a high end DVR implementation.
I am a hardware engineer. I already expected to have to do an "adapter" board. The Sony outputs HD digital on 4 7 bit LVDS channels. I noticed the camera connector only brings two I think LVDS data inputs and an LVDS clock input out. And I expect impossible to tack solder wires onto the Broadcom chip as the BGA pins are probably buried deep under the chip.
So I would do an adapter board to convert the Sony LVDS to parallel and then convert again to two LVDS channels and a clock LVDS channel to drive the camera connector.
But I would need to know stuff like data format, MSB first or LSB first, number of bits for LVDS channel, clock speed etc.
But I don’t know much about writing drivers. I guess this would be a “generic” driver as it would be for a camera that is already “tuned”
Now, If I used the analog high definition component video from the Sony and put a 3 channel video A/D converter on my adaptor board, this would then become a much more “universal” design as any high definition “tuned” camera that had analog component video out could just “plug and play” without regard to exact data formats of the camera’s digital output.
If I agree to give this adapter board schematic to the foundation, then would the foundation argee to writing the universal driver?
He offers to make a board that will look EXACTLY like the chosen camera ( which has no HDMI and no 'main issue is HDMI in that it needs all sorts of nasty DRM' and has nothing to do with HDMI or HDCP- red herring).
Dear Pi Foundation,
I’ll go back to my earlier proposal, except with a CSI-2 output.
I design the circuit and lay out a PCB to take analog component video in and output CSI-2. I will “sweeten” the deal: I will give the Foundation both the schematic and Gerber files. I’ll even throw in the BOM. The Foundation is free to do what ever they want with this, keep it proprietary, manufacture it, and / or post it all.
In exchange, the foundation will provide the firmware and / or software to take this “through” to the H.264 encoder and the software to use this as a DVR recording to the SD card. Again, the Foundation may keep this proprietary or include it in your normal firmware distribution.
What do you think?
Davidoccam: I think you speak much sense, and I think Andreas agrees with me, He has a good suggestion which I will try to paraphrase..
If Hardware_man created a FPGA or a hardware board that emulated exactly the important necessary and sufficient parts of the EXISTING PROPOSED CAMERA, then NO DRIVER MODIFICATIONS AT ALL would be required. A path into the GPU would exactly follow the existing paths. Expensive Driver man who is so busy (and Broadcom ), would have to do nothing.
I think Hardware_man could be told enough about the now redundant camera control niceties that his FPGA would give all the right answers to the driver that EXISTING PROPOSED CAMERA would give.
Thus a path exists. Politics is the art of the possible.
If I were at sea in a naval analogy , in a fierce battle in a fierce gale and this HAD to be done. I would want Hardware_man and Andreas on the ship with me repairing the camera system.
Gordon meanwhile, back in the Admiralty, issues the order to signal the requisite interface details to the ship immediately and forgets about possible interns and huge bills and complex politico-legal barnacles on the ship of progress.
The Camera is jury-rigged and the now all-seeing ship fights it's way home.
Crowds line the docks in Portsmouth cheering. yay!
DavidOccam Portsmouth UK.