0

getting EDID in Brightscript



Hello, is it possible to get the EDID information of a connected monitor in BrightScript? Background: One type of monitors we use will sometimes show a picture on startup, sometimes not - the monitor shows in that case an error message. Rebooting the HD410 helps, after a reset everything works fine. The videomode is set to 1024x768x75p (fixed), this happens both on Software 3.2.67 and 3.2.78beta. When I go to the shell an type Roku>edid hdmi I get the EDID-Data (when the monitor is showing the picture) or the message that there are no data found (when the monitor is not working). My Idea is now to write in a start script some lines like that: if EDID = "invalid" then RebootSystem() end if Is there a way to do that?

6 comments

  • 0
    Avatar
    RokuLyndon


    Hi.

    You cannot access edid info via script currently.
  • 0
    Avatar
    laborratte


    Hi Lyndon,
    thanks for response but bad to hear  <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( -->

    meanwhile I did some additional tests and put a I2C Sniffer on the DDC-Line to monitor the communication between HD and our monitors.

    The HD starts the communication with a call to address 0x30 (which is IMHO not VESA conform), after that it calls address 0x50 to receive the EDID. A normal monitor ignores a call to 0x30 and delivers the EDID on 0x50.
    Unfortunately our monitor response to 0x30 - only once and only after a power up (which is not VESA conform either). This response seems to make the HD angry so it stops investigating the DDC line immeditaly. In consequence, ther are no EDID and the HDMI port is not working properly.

    So the picture is as follow: Powering up both Monitor and HD gives us no picture, resetting the HD with continues power on the monitor gives us a picture.

    We need a solution on that because it is a bigger intallation with over 30 monitors and HD110/HD410.

    TIA
    Joergen
  • 0
    Avatar
    RokuLyndon


    Can you not include a script or playlist on the flash card that explicitly sets the output resolution, then no edid query is required. The edid is only used if no videomode is set and the unit has to query the display tofind out what it supports.
  • 0
    Avatar
    laborratte


    We explicit set the videomode always in every script, but the unit does not reboot if the resolution is the same as last time.

    The edid is only used if no videomode is set and the unit has to query the display tofind out what it supports.


    This might be true for VGA (not tested yet), but the HDMI port is not setup properly when no EDID is found.
  • 0
    Avatar
    RokuLyndon


    I'm still not clear on what's happening. What exactly is going wrong?
  • 0
    Avatar
    laborratte


    Sorry when it does not get clear, but english is not my native language...

    We have a monitor (12" XGA, industrial type), attached to the HDMI port of a HD410 (or HD110 - both in actual and beta firmware).
    The HD410 is set to video mode 1024x768x75p in autorun script.

    When both units (monitor and HD110) are powered up at the same time we have no picture, the monitors shows an error.
    When the monitor stays powered and the HD410 is rebooted (by interrupting power or with reboot command by shell or script) we get a picture.

    Analyzing the behavior pointed to a broken communication on the DDC line which we monitored with an I2C measurement equipment. We found that the HD410 started the DDC communication with a non VESA conform request and it seems to expect no response. But the monitor responses to that message, only if this message is the first after power up. This response stops the HD410 from requesting the EDID and finishing the setup of the HDMI port.

    A possible work around would be to reboot the HD410 until the unit has a valid EDID for the HDMI port. Thats why I asked for the EDID via script.

    Another solution would be to avoid the non VESA conform request on address 0x30 from the HD410. But I don't know if this is something you have access to within your firmware or if this is a fixed behavior of the hardware you use at the HDMI port.

    Meanwhile we had an answer from the monitor manufacturer that he uses the DDC line for programming purposes (using non VESA conform messages after power up) and that it is not possible to change the behavior.

    Hope that things are more clear now.
Please sign in to leave a comment.