Potentially bricked ASUS monitor with switching Input Source

[martin-scheele]

Hey, I've been messing around with ddcutil tonight trying to see what the valid input source values are for my monitor (ASUS PA248Q) for use with display-switch, and it seems that I tested the wrong value and the monitor is stuck power cycling.

It seemed that the input source values were non-standard, so I tried the standard ones and then some random values starting from 0 (I acknowledge this was a dumb idea, but a few of them worked). I don't have the terminal output from when I initially did this, but the value under question was 5 using ddcutil setvcp 60 5.

After that, the input overlay on the monitor popped up blank and the OSD became unavailable. I tried to connect again with ddcutil detect and the monitor was not found.

I factory reset the monitor (power cycling, holding menu button) and some diagnostic window popped up for a second and the monitor started power cycling (wake up -> boot logo -> empty input overlay -> black screen -> sleep), and ddcutil detect now sees the monitor but reports that I2C is unresponsive.

Here's the output from ddcutil detect:

ddcutil detect --verbose

Invalid display
   I2C bus:  /dev/i2c-2
      DRM_connector:                             card1-HDMI-A-2
      /sys/class/drm/card1-HDMI-A-2/dpms         On
      /sys/class/drm/card1-HDMI-A-2/enabled      enabled
      /sys/class/drm/card1-HDMI-A-2/status       connected
      /sys/class/drm/card1-HDMI-A-2/connector_id 136
      Driver:                                    i915
      I2C address 0x30 (EDID block#)  present:   false
      EDID exists:                               true
      I2C address 0x37 (DDC) responsive:         false
      Is LVDS or EDP display:                    false
      Is laptop display by EDID:                 false
      Is laptop display:                         false
      /sys/bus/i2c/devices/i2c-2/name            i915 gmbus dpc
      PCI device path:                           /sys/devices/pci0000:00/0000:00:02.0/i2c-2
   EDID synopsis:
      Mfg id:               ACI - Ancor Communications Inc
      Model:                PA248
      Product code:         9393  (0x24b1)
      Serial number:        E6LMQS008841
      Binary serial number: 16843009 (0x01010101)
      Manufacture year:     2014,  Week: 23
      EDID version:         1.3
      Extra descriptor:        
      Video input definition:    0x80 - Digital Input
      Supported features:
         DPMS standby
         DPMS suspend
         DPMS active-off
         Digital display type: RGB 4:4:4 + YCrCb 4:4:4
         Standard sRGB color space: False
      White x,y:        0.313, 0.329
      Red   x,y:        0.637, 0.331
      Green x,y:        0.304, 0.626
      Blue  x,y:        0.152, 0.071
      Extension blocks: 1
   EDID source: SYSFS
   EDID hex dump:
        +0          +4          +8          +c            0   4   8   c   
+0000   00 ff ff ff ff ff ff 00 04 69 b1 24 01 01 01 01   .........i.$....
+0010   17 18 01 03 80 37 23 78 ea 3d 15 a3 54 4d a0 27   .....7#x.=..TM.'
+0020   12 50 54 bf ef 00 71 4f 81 80 81 40 95 00 a9 40   .PT...qO...@...@
+0030   b3 00 d1 c0 01 01 28 3c 80 a0 70 b0 23 40 30 20   ......(<..p.#@0 
+0040   36 00 22 60 21 00 00 1a 00 00 00 fd 00 32 4c 1e   6."`!........2L.
+0050   53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 50   S...      .....P
+0060   41 32 34 38 0a 20 20 20 20 20 20 20 00 00 00 ff   A248.       ....
+0070   00 45 36 4c 4d 51 53 30 30 38 38 34 31 0a 01 2d   .E6LMQS008841..-
   This monitor does not support DDC/CI. (I2C slave address x37 is unresponsive.)
   If the monitor's on screen display has a DDC/CI setting, check it is enabled.
   Monitor Model Id:  ACI-PA248-9393
   Feature definition file ACI-PA248-9393.mccs not found.

Ultimately it's not a big deal if there's no solution to this. Let me know if there's any more info I can provide, and any help troubleshooting would be greatly appreciated.

[rockowitz]

Ouch! There have been a few reports of bricked Xaomi Mi monitors, but I don't recall one with a name brand like Asus and in a documented feature no less.

The one idea that comes o mind is changing the video input being used. Better yet, if you can, connect a video source to every monitor input at the same time. Other than that, and you've probably already done it, is Asus tech support. That the monitor goes haywire when setting a VCP feature documented in the Monitor Control Command Set is a bug.

A better way to determine the feature values used (which doesn't help you at this point) is to connect the computer to each input in turn and use getvcp to read the feature value.

Currently there's a warning about using setvcp when a Xaomi Mi monitor is detected. I'm considering strengthening this to ba block setvcp for any monitor known to be problematic, unless a new option, perhaps named ---allow-setvcp is specified. This could also apply to setting values in the manufacturer reserved range. But that would break a lot of existing scripts.

[martin-scheele]

Thanks for the reply - I've been in the process of getting in touch with ASUS support to see if they have anything to say (doubtful).

The monitor is pretty old and has VGA / DVI inputs (which I don't have), but connecting to either HDMI or DisplayPort doesn't work. I'll see if I can find something to actually connect to each input as a last attempt.

I think, just on the off chance that this could happen to someone else, it might be a good idea to have a disclaimer in the documentation that there is a possibility (albeit unlikely) that using setvcp could result in bug like this. I was lazy and just assumed that there wasn't a risk (and was too lazy to go get a DisplayPort cable + adapter) so I figured I'd try to find the feature values for the unknown inputs manually. Ultimately that's my fault, obviously, and I should have just exercised a bit more critical thinking and caution.

In any case, thanks for your time.

[rockowitz]

I agree that some sort of warning is in order. The question for me is how to do it in a way that's proportionate to the risk. Bricking a monitor is catastrophic, but exceedingly, exceedingly rare. And as I said, putting the warning in code would undoubtedly break many existing scripts.

You're putting too much blame on yourself. Setting the value of a VCP feature, or at least a documented feature, should not brick a monitor. That's a flat out bug in the monitor's DDC implementation.

You didn't mention it. so I'll ask if you tried getting and setting the value of feature xCA, which controls whether the OSD is enabled.

Probably worth trying to use the VGA and DisplayPort inputs. For our purposes DVI and HDMI are essentially the same - a dumb HDMI to DVI cable can be used to feed the DVI input.

Please submit the output of sudo ddcutil interrogate. Perhaps I'll see something.