3 ms·
Yeah, this is almost certainly the same bug. Some more info here [1] [2] [3]. In my case, using the second direct HDMI cable like you did was a non-starter beca
by ohazi 6y ago
Yeah, this is almost certainly the same bug. Some more info here [1] [2] [3]. In my case, using the second direct HDMI cable like you did was a non-starter because my Thinkpad only supports 4k at 30 Hz via the built-in HDMI port (!), vs. 4k at 60 Hz if you use the Thunderbolt port or a dock / adapter connected to that port. 30 Hz gave me eye strain after less than 5 minutes.
[1] https://gitlab.freedesktop.org/drm/intel/-/issues/37 https://gitlab.freedesktop.org/drm/intel/-/issues/37
[2] https://github.com/rockowitz/ddcutil/issues/11 https://github.com/rockowitz/ddcutil/issues/11
[3] https://github.com/rockowitz/ddcutil/issues/146 https://github.com/rockowitz/ddcutil/issues/146
- mixmastamyk 6y agoYes, I participated in that ddcutil issue. You might try anyway. Believe I use the thunderbolt connection for my monitor, the second direct hdmi connection is used only for sending ddc commands. In other words, both inputs seem to be listened to with my Dell monitor.
- ohazi 6y agoThat is one chonky serial cable... :-P Your monitor must listen to DDC commands from inactive inputs. I think mine doesn't, because this whole problem came about when I realized that my desktop could ask the monitor to switch to the other input, but couldn't ask it to switch back. Apparently a lot of computer monitors only listen to DDC commands coming from the selected input, while TVs almost always listen to them from all inputs, because they often need to do things like "switch to Roku input when the Roku asks, even if some other set-top box is driving the display." If my monitor could do this, I could just run the input switching script entirely on my desktop (based on whether the keyboard has just appeared or just disappeared), and I wouldn't have to send DDC commands via the dock at all.