I have been working on the BBW, and am going to be moving over to a BBB. I am getting up to speed on HDMI (starting from scratch). I see that the EDID is read from the display device, letting me know about its capabilities.
I understand that per the spec, EDID info should be in readonly memory in the monitor and may be read even if the device is powered off. Also that some devices don’t play this way and report nothing unless they are actually powered on.
Is there a reliable, guaranteed way to see if a given device display is actually powered on?
Is there a preferred way to get display info from within a user application? I could run something like get-edid and parse-edid as a separate process and take the output from that, but that seems somewhat indirect. I could incorporate code from those programs into mine, but that seems redundant. I don’t suppose there is any kind of driver API I can access?
I understand that the LCD and HDMI use the same GPIO pins, and can’t be run simultaneously. Is it practical to say, boot using an LCD, check for the presence of an HDMI display, then switch to the HDMI output under user control? Ideally this would be done without rebooting the BBB and from within an application. If anyone has done this could you give me some pointers or identify likely pitfalls?
Also, the SRM says that the software to support CEC has not been implemented. Has anyone experimented with this, and how far have you gotten?
Resounding silence after a week - No Voice Of Experience out there?
It seemed obvious, like you mentioned... parse-edid... why reinvent the wheel?
That is what the EDID is for and that is what the HDMI specification is for. Unfortunately the displays out there decide what part to the specification they want to meet. And with all these zoom modes and display settings, you can’t really tell what the setup is on a particular screen. I suppose there is could be a way in the SW to fill in the blanks for your monitor and it is perfect all the time, but that would require a change to the DRM Linux driver.
Even being able to know if an HDMI device was connected and powered on would be very helpful. On one of the many posts here discussing HDMI it was mentioned that “per spec” you should be able to read the EDID even with the device powered off (but maybe they meant in standby?), but in practice it depended on the particular device.
Even being able to know if an HDMI device was connected and powered on would
be very helpful. On one of the many posts here discussing HDMI it was
mentioned that "per spec" you should be able to read the EDID even with the
device powered off (but maybe they meant in standby?),
Read Section 8.4.4 Enhanced DDC Sink... Just google 'HDMI Spec' as
i'm not sure if the spec is legally suppost to be posted.
but in practice it
depended on the particular device.
Well, yeah.. Are you looking for a database of all the devices that
work in that situation? (good luck on that..)
Yes, I was definitely getting the impression that without signing up for the $15K fee I could not view a legal copy of the spec. If I can find a monitor or two that work with the BBB and that have known behavior that’s plenty good enough. Section 8.5 Hot plug detect…"…does not indicate whether or not the sink is powered on…"
I would have thought that a way to query whether a device was powered, asleep, or awake, and a command to wake it up if asleep would be obvious and available, and perhaps they are to people who aren’t me.
Based on the very quick glance I have given it, it looks like CEC may be more intended for this (Section 14?), but even if that’s so it’s less supported on the BBB. At least I have a better idea where to look now. Thanks again.
Digging more into it.. "4.2.7 +5V Power Signal" looks like the hdmi
cable is suppost to power it enough to get the i2c eeprom data..
btw... All this talk.. Have you tried the "parse-edid" while connected
the bbb to a un-powered monitor?
I have not yet gotten parse-edid to work at all, and this is “preliminary research” - I don’t have a BBB on my desk yet, just a BBwhite. But yes, an ounce of experimentation can be worth a pound of theory and I’ll certainly see what results I get by testing.