Broadcomm closed sourced the chip that the rpi runs on. This is basically the problem. You need to submit a bug report to the official forum/github and pray for them to fix the issue. OK I know you might be running linux but that linux requires kernel level precompiled binary blobs to get the various parts of the SoC blobs to do proprietary things. "The Community" pretends it is open source but as soon as you start trying to use it for anything that's not an officially supported distro you will run into the NDA and pay multi-million surety to have the privilege of requesting access to documents that they won't give you because you're not willing to agree to purchasing a million units to demonstrate your loyalty. So basically you have closed source example projects for the rpi to choose from and no support for the burnt in bugs that those examples did not address.

Nicest thing to use these days for io is ICE40(project icestorm) + rpipicow or esp32 as an spi-wifi bridge only.

In reply to Bill Paul.

I think "force hotplug" means the opposite of what it sounds like.

In reply to jwz.

That's an excellent question. You're right, a lot of the time these things are headless so why would it fark up only for you?

But also, even if that "force hotplug" property were renamed, why wouldn't it be on by default? I would think hotplugging would be the rule and hardwiring would be the exception.

In reply to Bill Paul.

I did not go down the path of "disable HDMI entirely" to see what that would do (even though my guess was "nothing good") because I do occasionally need to plug in a monitor for debugging.

I never found a working solution to tell it to just pretend HDMI is always there, so I plugged in an EDID ghost, a "solution" I had previously rejected even before the spate of know-nothing post-before-reading crowd suggested that nine times. I hate that solution and I hate them. But I'm so sick of dealing with this that I just cargo-culted it, which I guess makes me no better than those other idiots. Hooray.

The thing I hate most about this is that those idiots will see that and say to themselves, "See? My suggestion was Right and Correct." No. Fuck you. Fuck off. Fuck all the way off and keep fucking off then fuck off some more.

There were a few other suggestions that came in after I had already given up, that I did not try, such as: "Oh, maybe 'hdmi_force_hotplug' has been renamed to 'vc4.force_hotplug' and you're supposed to have known that by reading the driver source or something because we're sure as fuck not going to document it anywhere or note the change".

But here is another thing that I don't understand:

• One presumes that other people use the GPIO pins on Raspberry Pi 4Bs.
• One presumes that a common use case is that the device does not have a monitor plugged in.
• How the fuck can I be the first person to experience this weird-assed bug?

I'm late to this party, and I can't give an exact solution to this because as usual I'm way over here and don't have the same hardware I can monkey with. But here are a few things I know:

- SoCs never have enough pins for all the I/O blocks in the chip, so pins are multiplexed
- The board designer must Choose Wisely (tm) when selecting what I/O blocks to enable based on their needs
- The SoC has register blocks for selecting pin functions, as well as enabling power and clocks to the various I/O blocks
- Some pinmux and power/clocking decisions are made at boot time (the serial console UART may need to always be on, for example)
- Other pinmux/power/clocking decisions may be made on the fly as devices are enabled *and* devices on which they depend are also enabled
- For high speed I/O devices, there are often external transceiver chips. This is common for USB, PCI, ethernet and likely HDMI/DisplayPort/whatever graphics interfaces too (I am not a graphics expert.)
- High-speed I/O devices also need to have I/O signal pins
- The external transceiver chips need to be managed somehow and often the management mechanism is via I2C (I2C is just the transport, different devices have their own vendor/device specific command protocols to do things)
- I2C also needs pins

What might be happening is that when the HDMI interface is enabled, it also needs an I2C controller to manage the external transceiver (not to mention I/O pins for the graphics data, possibly SerDes lanes), and when that I2C is turned on the pinmux controller is being twiddled to enable I2C function for some of the pins, and this is somehow causing the pin function of the GPIO pins to be affected.

Then once the monitor is detected the pin/power/clocking settings stabilize.

If you don't give a damn about HDMI for this device, it occurs to me you might be able to edit the device tree to chop off that branch of the tree. For Arm-based systems, Linux relies on the device tree to know what hardware is present, and that includes telling it about the HDMI controller. If you delete the HDMI controller node from the device tree (along with any children it has) it will never try to bind any driver to it.

Device tree files can be a pain in the ass to grok though, they are like the Windows Registry of the Linux world. If you only have the compiled device tree blob (DTB) you can decompile it with the device tree compiler tool (dtc) and while some informative context may be lost, it may still be possible to identify the graphics controller block and chop it out, then compile it back to a DTB again.

In reply to Phil Armstrong.

Literally the opposite of the goal. Read the other replies before commenting.

In reply to jwz.

If convincing the pi that it doesn’t have any hdmi sockets is the goal then

dtoverlay=vc4-kms-v3d-pi4,nohdmi

is what you want according to https://github.com/raspberrypi/linux/blob/e5c6e2c80b6fc1ff9cbb010f5d0cff97dcb9a023/arch/arm/boot/dts/overlays/README#L4405

Convincing it to pretend that a monitor is plugged in requires providing an edid file to substitute for the data a real monitor would provide IIRC, but I’ve never tried to do that.

In reply to jwz.

As far as I can tell, doing root cause analysis is out of fashion these days. I guess it’s too slow and has too much detail. Heuristiken über Alles.

As always, the real madness isn't in the question, it's in the replies.

if i were doing this at my desk and faced with this, and when you say "all gpio pins" I guess you mean all the gpio pins on the raspberry pi, i'd honestly start poking at the linux pinctrl driver and add some printk's to whatever reset / clock reconfig stuff it has.

i'm assuming at this point it's booted linux, and all gpio pins are being yanked down/up?

because that behaviour really sounds like someone added a "oh if I can't see this, maybe something is busted, just keep yanking on this chain periodically until things work" workaround.

if you'd like some help i could go see if i have a matching pi in my collection and whack debian on it and see if i can reproduce it and then work backwards to which bit of software is being dumb.

someone smarter and better paid than me suggests comparing the output of `pinctrl` in state [2] against the output in state [3] (once stable)

mhoye uses this post as an example of how the stackoverflow crowd was primed for LLM brainrot:

All the suggestions are things you can try that make the problem go away. There's no "this is the issue, here is why it occurs and what you can do about it."

There's no comprehension.

Someone who doesn't read is no better off than somebody who can't. So how is a person who doesn't want to understand a problem before making suggestions any more useful than a machine that can't understand anything before making suggestions?

I wonder if it’s a weird memory allocation thing. The video memory and the normal ram are shared. I wonder if the GPIO and Video have some overlapping memory tables. When you connect the monitor it’s all properly allocated, then when you unplug it takes a while for some bit of data to overwrite that memory space. I’m not technical enough or smart enough to test or debug this but it came to mind as I was reading about miners using dummy hdmi to trick anti hash cards.

In reply to Aedius Filmania ⚙️🎮🖊️.

Do not explain Mastodon to me. *plonk*

In reply to jwz.

I see only one reply 🤷🏻

This is how mastodon works.

In reply to jwz.

Maybe reading via Mastodon, where some replies are not fetched automatically? But yes, once clicking through...

UPDATE: I have now been informed NINE TIMES that HDID dongles exist by people who don't read the replies before commenting with the first thing that popped into their head, don't have an answer to my actual question, but think they know how to Google.

I am blocking every single one of you.

Don't be that guy.

In reply to thielges.

Overlay supposedly helps with that, but perhaps not 100%.

In reply to jwz.

HDMI dummy plugs would be my solution. uHDMI to HDMI dongle for $5, and an HDMI dummy for another $5.

https://www.amazon.com/UGREEN-Adapter-Compatible-Raspberry-ZenBook/dp/B00B2HORKE

https://www.amazon.com/Woieyeks-Virtual-Emulator-Headless-Supports/dp/B0CKKLTWMN

In reply to Jonathan Dowland.

That bit about the GPIO pins makes "console=ttyS0" sound like a really bad idea.

In reply to Gerard Thornley.

SD corruption after a power cut is my main RPI nemesis.   I’ve tried everything including turning off most logging and directing the rest to a ram disk.  It is powered by a UPS too but that only has enough juice for 30 minutes.  Those measures do help to reduce corruption , but it still happens, just not as frequent.

One think that a little low power computer ideal for headless applications would tolerate abrupt power loss better.  Consumer products that brick when you unplug them are near worthless.   Auto SD corruption would be nice.  

You can always try the brute-force-and-ignorance option and just plug a dummy HDMI connector that terminates all the signals and has an EDID chip that tells tall tales to the video output hardware in the Pi.

This link is something I dug up from a search engine just now. I skimmed it and it seems to be okay but apologies for risking inflicting AI slop on you.
https://techdim.com/hdmi-dummy-plug-what-is-it-and-how-do-you-use-it/

I tried a variant of this with Windows 10. I wanted to VNC into it when there was no screen attached. But it wouldn't let me. So I dug up a broken HDMI-to-VGA converter I had, plugged that in and suddenly Windows would let me connect. Yay!

slim chance this might be related, I encountered this some years ago, a only-when-headless, non-booting Linux (Ubuntu 20), due to kernel config: https://rightsock.blogspot.com/2020/05/intel-compute-stick-wont-boot-without.html?m=1

It seems to me that the obvious solution is to just attach a small HDMI monitor, like this 2.7" one, and display some manner of scarlet letter to let everyone know what a bad computer it is. With AI becoming a thing, for some reason, we need to start shaming devices more.

In reply to akiran_n.

wow, what is this witchcraft.

In reply to jwz.

You should still try it to see if it stops the GPIO flapping at least.  If it does then you can look for convenient ways to enable/disable HDMI at runtime by loading/unloading or binding/unbinding kernel module(s) via SSH or some other means.  You might also want to test if the GPIO flapping sets in again after unplugging the monitor and unloading the respective kernel module(s).  I suspect that the module internally keeps state of where it has seen activity already to stop its polling loop.

In reply to James Young.

The GPIO inputs are just switches, but there is also an SPI display involved. Start here https://www.dnalounge.com/backstage/src/phonebooth/phonebooth.pl and here https://www.dnalounge.com/backstage/src/phonebooth/gpio_poll.c but if you're serious about this I'll send you a tar file. I do not recommend it.

two questions:
1. How complicated is the GPIO input? If I wanted to retrace your steps, what would I need?
2. Which kernel version?

In reply to Scott M.

"nohdmi" sounds a lot like "no HDMI" which is the opposite of what I want.

In reply to Scott M.

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L5821

Suggests a nohdmi flag to the driver:

dtoverlay=vc4-kms-v3d,nohdmi