On Wed, Mar 29, 2023 at 2:56 PM Shawn Lindberg <shawn.lindberg@xxxxxxxxx> wrote: > > On Tue, Mar 28, 2023 at 2:58 AM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > > > cec-ctl -d0 --tv --cec-version-1.4 > > > > That's wrong, the RPi is a Playback device, not a TV. So use --playback instead. > > > > You should also add this line to the config.txt: > > > > hdmi_ignore_cec=1 > > > > otherwise the RPi's firmware tries to process CEC messages as well. > > Oh, I thought that the TV/playback command was indicating what sort of > device the connected device is. This wasn't clear from the man page, > either. Thank you for that. I made the change to config.txt and > strangely when the RPi rebooted (I have it set to do this > automatically once a day) the projector automatically turned on. I > have never experienced this before. Further update on this. I continue to see the projector automatically power on every time the RPi does its daily reboot, so I think I may have to remove the hdmi_ignore_cec from the config.txt. Especially since I can't figure out how to reliably shut the projector back off again. > > > During this time, if I try to poll the projector, it will succeed. > > > However, if I monitor events, after a significant amount of time > > > (appears to be greater than 20 minutes, although this is difficult to > > > verify because of how long it takes) I go will eventually see the > > > following: > > > > > > Event: State Change: PA: 1.0.0.0, LA mask: 0x0000, Conn Info: yes > > > Timestamp: 30981.428s > > > > Now it appears to be able to read the EDID again and it has a valid > > physical address. > > > > > Transmitted by Specific to Specific (14 to 14): POLL > > > Tx, Not Acknowledged (4), Max Retries > > > Sequence: 21 Tx Timestamp: 30981.561s Tx, Not Acknowledged (4), Max Retries > > > > > > Event: State Change: PA: 1.0.0.0, LA mask: 0x4000, Conn Info: yes > > > Timestamp: 30981.561s > > > Transmitted by Specific to all (14 to 15): REPORT_PHYSICAL_ADDR (0x84): > > > phys-addr: 1.0.0.0 > > > prim-devtype: tv (0x00) > > > Sequence: 22 Tx Timestamp: 30981.696s > > > Transmitted by Specific to all (14 to 15): DEVICE_VENDOR_ID (0x87): > > > vendor-id: 3075 (0x00000c03) > > > Sequence: 23 Tx Timestamp: 30981.835s > > > Received from TV to Specific (0 to 14): FEATURE_ABORT (0x00): > > > abort-msg: 132 (0x84, REPORT_PHYSICAL_ADDR) > > > reason: invalid-op (0x03) > > > Sequence: 0 Rx Timestamp: 30981.949s > > > Received from TV to Specific (0 to 14): GIVE_OSD_NAME (0x46) > > > Sequence: 0 Rx Timestamp: 30982.026s > > > Transmitted by Specific to TV (14 to 0): SET_OSD_NAME (0x47): > > > name: TV > > > Sequence: 24 Tx Timestamp: 30982.137s > > > > > > After this point in time the standby command will succeed and the > > > projector will turn off. It's quite inconvenient to have to wait over > > > 20 minutes to turn the projector back off again. Any idea how I can > > > shorten this delay? > > > > There is something weird about your setup and EDID. I can't really tell > > what it is. > > After making the above changes and retesting, the behavior didn't > change. I still get the device not connected message and the invalid > physical address when I try to do standby. I should also note that one > way around this issue is to reboot the RPi. For some reason that seems > to get around the long delay in getting the physical address. > > I don't know what would be strange about my set up other than the > projector itself and a couple of lines I uncommented in the config.txt > to set the RPi to use HDMI even if the projector is not on at the time > of booting. Is there more information I can provide that would allow > us to figure out what's going on? If you are correct that for some > reason it is just not reading the EDID, is there a way to manually > provide that? I don't know much about it, but it's a static property > of the device (the projector in this case), right? Since I noticed that the physical address is populated properly when the RPi is booted while the projector is turned on, I did that and then tried using the get-edid utility to see if I could read the EDID block and save it to a file. Unfortunately, this didn't work, as the utility reports that there was no EDID available on any of the buses. So once again I am out of ideas.
