Ended up being an EDID issue. With the updated labwc/raindrop the headset quit working with the desktop environment. Showed connected, showed it knew its valid modes from the edid. But didn't configure the encoders/planes/fb/crtc with it. I later found that by using the kms/drm ioctls I could setup the display chain and it still worked fine. Then I discovered if I used a "video=" with a "D" in the cmdline.txt it would force it on and start off with the planes/fb/crtc configured. Then the desktop would use it and it showed up again in raindrop like before with randr. But only if it wasn't plugged in on boot up. This only worked if you forced it on with it unplugged and plugged it in after booting to gui. Finally after experimenting with forcing the edid via "drm.edid_firmware=", I seen that using the edid.bin from the headset caused the same issues even with booting and it unplugged.
Knowing the parsing of the edid was causing the connector to be disabled, I found that in the logs via "dmesg | grep -i drm":
[ 2.417490] vc4-drm axi:gpu: [drm] User-defined mode not supported: "1440x2560": 60 252760 1440 1488 1520 1600 2560 2563 2573 2633 0x68 0x9
So I went to work to fix the edid data. The log message stated it was a mode problem and listed the timings. I assumed that was what I needed to fix. Found a really nice EDID editor/creator. Tried many iterations of modifying the original edid and making new ones from scratch. None would pass without generating an error on boot. When the display would work forcing the connector on and letting it generate the timings with the "video=" and "M" option, I duplicated the hdmi timings I knew it was happy with and still failed. As a last ditch effort I ripped the edid from my main display that it had no problem with and used it. It had edid data that wasn't even close for the vr headset, but when using "M" it ignores the edid data anyway. Sure enough it parsed it clean with no errors in the log and the headset worked even with being plugged in on boot.
So then I went through the edid transferring data from the oem headset into it section by section until it failed again and I knew what caused it. Much to my dismay it wasn't anything to do with the resolutions or timings. It was the header where the vendor and product info lives. There are two fields, one for product id and the other for serial number. Not that I could find info that backs this up online, but apparently one is a checksum or something akin to the other, and only certain combinations are valid. That or there is some bug in the linux kernels parsing of it. The vr headset had a product id:0003 and serial number:00000000, that would not fly. My Asus monitor had 32A3 and 0004FAC1 and works. After experimenting, both containing all 0's is also valid and what I ended up putting in my edid to resolve the issue.
So I learned edid data can be picky. A field that doesn't have squat to do with the operation of the device can keep it from working. If the current build of the rpi 64bit os doesn't like the edid, that connector is disabled. Even if using the "M" option that ignores edid and picks it own timings for the selected resolution. If a "bad" edid is read from the device on boot or forced software wise after, same result. Which was hard to track down, because even after it didn't like the header of the edid, it continued to read it and fill out all the modes data to the kms/drm. Info that worked, it just refused to use it.
I've lurked this forum for over 10 years. Always found what I needed without posting, never even created an account until this. Was kind of disheartened my thread didn't even get a reply. You always hope someone like 6x9 will sweep in and give you 30 seconds of their time and save you 30 days. Either way I hate finding threads where someone asks the question you need an answer to, and there wasn't any reply's or solutions found. I hope this benifits someone out there.
Knowing the parsing of the edid was causing the connector to be disabled, I found that in the logs via "dmesg | grep -i drm":
[ 2.417490] vc4-drm axi:gpu: [drm] User-defined mode not supported: "1440x2560": 60 252760 1440 1488 1520 1600 2560 2563 2573 2633 0x68 0x9
So I went to work to fix the edid data. The log message stated it was a mode problem and listed the timings. I assumed that was what I needed to fix. Found a really nice EDID editor/creator. Tried many iterations of modifying the original edid and making new ones from scratch. None would pass without generating an error on boot. When the display would work forcing the connector on and letting it generate the timings with the "video=" and "M" option, I duplicated the hdmi timings I knew it was happy with and still failed. As a last ditch effort I ripped the edid from my main display that it had no problem with and used it. It had edid data that wasn't even close for the vr headset, but when using "M" it ignores the edid data anyway. Sure enough it parsed it clean with no errors in the log and the headset worked even with being plugged in on boot.
So then I went through the edid transferring data from the oem headset into it section by section until it failed again and I knew what caused it. Much to my dismay it wasn't anything to do with the resolutions or timings. It was the header where the vendor and product info lives. There are two fields, one for product id and the other for serial number. Not that I could find info that backs this up online, but apparently one is a checksum or something akin to the other, and only certain combinations are valid. That or there is some bug in the linux kernels parsing of it. The vr headset had a product id:0003 and serial number:00000000, that would not fly. My Asus monitor had 32A3 and 0004FAC1 and works. After experimenting, both containing all 0's is also valid and what I ended up putting in my edid to resolve the issue.
So I learned edid data can be picky. A field that doesn't have squat to do with the operation of the device can keep it from working. If the current build of the rpi 64bit os doesn't like the edid, that connector is disabled. Even if using the "M" option that ignores edid and picks it own timings for the selected resolution. If a "bad" edid is read from the device on boot or forced software wise after, same result. Which was hard to track down, because even after it didn't like the header of the edid, it continued to read it and fill out all the modes data to the kms/drm. Info that worked, it just refused to use it.
I've lurked this forum for over 10 years. Always found what I needed without posting, never even created an account until this. Was kind of disheartened my thread didn't even get a reply. You always hope someone like 6x9 will sweep in and give you 30 seconds of their time and save you 30 days. Either way I hate finding threads where someone asks the question you need an answer to, and there wasn't any reply's or solutions found. I hope this benifits someone out there.
Statistics: Posted by BluecatKY — Thu Feb 20, 2025 12:59 am