rockowitz
Potentially bricked ASUS monitor with switching Input Source
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.
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.
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.
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.