Replies: 2 comments 9 replies
|
I am using it with original BMW Navigation unit with ibus script running in the background. System powers on with ibus activity and powers off when there is no incoming message anymore. I use HDMI for video and audio output. How did you manage to run LIVI without X? |
|
Wayland using cage. |
|
Here you can find my completed prototype before going for a professional PCB. Totally fulfills oem input and more. It has also smart video input detection so it can detect overlay signals from OEM system and display on top of PI video output. RPI PI pico was very useful because of its speed, 5V tolerance, and great PIO hardware. I am using HDMI for audio output. For me it took almost a year to start to until this level while I had almost 0 information about 240p video standarts. Anybody who has similar hardware I would suggest focusing on hacking Jungle chip for video input and controlling. I-BUS Equipped cars list:
|
Hi Lasse, I moved my setup to boxes, next week I am planning to set them up again next week. Before I tried to patch vc4_hdmi for pixel doubling but It was not successfull. I realized that there can be another approach to pixel doubling, if the resolution provides the aspect ratio in vc4_hdmi horizontal axis can be scaled down. This enables monitor visible on other devices. Also during runtime it is possible to add double_clk via drm atomic commit.
In my experience it is more likely not an adapter problem, pi cannot go under 9-10mhz pixel clock, so horizontal scanning frequency is no problem. All adapters I tried worked if pixel clock is good. VGA to HDMI adapters are just dump DACs in my opinion. For csync generation I am using pi pico PIO, if you need an mcu to do some housekeeping too it worths(for example hdmi ddc). |
|
They are not just dumb DACs, that may actually be part of the problem. Sure, you can simply increase the horizontal resolution to ramp up the pixel clock, but then you either have to use asymmetrical scaling (good luck with Wayland), or you need to get that information into the AVI InfoFrame, which is what the HDMI-to-RGB converter reads. The generation of that InfoFrame happens deep in the kernel, so there is no simple userspace way to control it. You don’t need a Pico for CSYNC. It’s as simple as combining HSync and VSync with two resistors. At least on the display controllers I tested, this worked fine, and the signal level was also well above the TTL high-level requirement. On a custom PCB, you’d probably use something like a 74HCT86 for the sake of peace of mind. |
it’s problem only in cheap vga adapters, bay another adapter, change factory EDID and try all RPi with kms-vc4 with bookworm works well low resolution and interlaced mode |
|
HDMI's specified pixel rate for a single link starts at 25 MHz. Formats below that, like 480i at a native 13.5 MHz, are only carried in spec via pixel repetition (doubling), which brings the link rate back up to ~27 MHz. The real problem isn't the pixel clock but the regime it lives in: a ~15.7 kHz horizontal frequency that most cheap adapters are never validated for. Their PLLs are typically designed only for 720p/1080p timings, so they may fail to lock onto the ~15 kHz range, which is why some adapters don't work with 480i even when HDMI certified. Go genuinely low (non doubled timings) and you're below the HDMI minimum entirely, where behaviour is fully adapter dependent. There's a second constraint on the Pi itself. Below a certain threshold the pixel clock comes from an integer division of the oscillator, so only discrete frequencies work. On older Pis (Pi 1 to 3) the oscillator is 19.2 MHz, so only values like 9.6, 6.4 or 4.8 MHz are valid, and this is exactly why simple doubling doesn't get you into spec there: the doubled target still has to land on one of those fixed steps. On the Pi 4 the oscillator is 54 MHz, and in practice anything below ~9 MHz (54 / 6) stops working. It isn't limited to powers of two, any integer divisor works, but the fractional divider isn't used down there, so you can't set an arbitrary frequency. The Pi 5 uses a new HDMI controller on the mainline KMS/DRM stack, so the old firmware side clocking no longer applies the same way. I haven't verified its low frequency behaviour on hardware. That's why I force every timing above 25 MHz, using pixel doubling for 480i and quadrupling for lower resolutions. It may not be necessary on every adapter, but it keeps the link in spec and rules out the pixel clock as a failure mode, especially on the Pi 4 and lower. |
|
You're right about the adapters not being checked for strange non-standard modes, but I'll note something. I have not studied the algorithms of operation in depth, but now that RPi2/3/zero 2 W, that RPi4/5 work fine at low frequencies on OS bookworm and newer. Older OS cannot work without manipulation and manual configurations in config.txt but the new OS reads the non standards EDID from the eeprom without problems, and it works if the vga adapter supports (physicals) this frequency. and this change happened with the release of RPi5, and I believe all versions of the boards received this change, but I cannot confirm) |
Uh oh!
There was an error while loading. Please reload this page.
Just wondering what everyone is running LIVI on?
I'm using a Dell Latitude 7200 2in1 (12" tablet) mounted to my dash with a custom mount that I made utilizing the magnetic keyboard attachment.
I'm running a Debian 13 minimal install, using a custom embedded setup that boots straight into LIVI using cage. No Desktop environment at all. Quick booting setup. I made s script to create this setup here. Only use it if you want your tablet to do NOTHING but LIVI... My setup has no audio, as I use the car's Bluetooth and "Disable Audio" in LIVI.
(I used to use a full fedora GNOME desktop, but this is better)
All reactions