mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 14:15:55 -06:00
[GH-ISSUE #277] Not working with LG 38WN95-C #216
Labels
No labels
Status: Abandoned
arm64
beta
beta
bug
done
duplicate
enhancement
feedback needed from reporter
in progress
invalid
investigating
known Issue
monitor Issue
pull-request
translation
unable to reproduce
unreleased
x86
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/MonitorControl#216
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SlawaGurevich on GitHub (Aug 14, 2020).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/277
Checklist
Issue Description
So the tool is not working with the new LG 38WN95-C. I can control neither the brightness nor the volume. (See screenshots bellow.) I also tried with the ddcctl tool, screenshot attached as well. Not sure about the "Failed to poll the display". Couldn't find much on Google about this error.
Expected behavior
Well, the tool should work with this monitor. I checked, whether it supports control over DDC, and according to the manufacturer, it does.
Screenshots


Environment Information (please complete the following information):
@JoniVR commented on GitHub (Aug 14, 2020):
I have the new LG 38GN950 myself now (which is very close to your model) and it works perfectly for me.
I'm using thunderbolt (actually displayport through an eGPU, but it works directly too). My first suggestion would be trying a different cable/connection anyways (I know this is probably not what you want to hear but it has the highest succes rate).
Polling is not the same as sending a command. Polling is trying to read values, in some cases, reading will fail but sending commands will work, so definitely try sending a command too. Check out the wiki for more information on this.
@SlawaGurevich commented on GitHub (Sep 27, 2020):
Hi @JoniVR ,
thanks for the reply. I finally got around to testing this.
So I got another Thunderbolt 3 cable, the only one I had lying around actually, the one from my MacBook to connect it to power. However, the monitor didn't turn on at all, so I assume this cable won't work. I'll try getting another TB3 cable, although I'd rather not buy another one just to find out it wasn't a problem with the cable.
As for sending commands, I tried out some from the help menu, but the display didn't respond:
It is still listed as unknown, even in 2.1.0. Shouldn't it at least be recognized by the app for it to be usable? With the Vendor and Hardware ID being public and all...
@wojciechczyz commented on GitHub (Oct 23, 2020):
Mac book power cable is not thunderbolt, it does not has thunder logos on it either.
@GM-Alex commented on GitHub (Jan 13, 2021):
@JoniVR I have also a LG 38GN950 and a LG 34UC98-W. Since I start using the LG 38GN950 and replaced a LG 24EB23 with the LG 38GN950 Monitor Control freezes and my macbook gets super slow. The mouse has micro freezes if it's moving and Monitor Control doesn't react until I kill it. I'm using a Caldigit TS3 Dock, the LG 34UC98-W is connected via Display Port and the LG 38GN950 via a Thunderbolt to HDMI cable. Is there any debug information I can you provide to fix this issue?
Edit: The problem is reproducible if I unplug the dock and replug it. The activity monitor shows that Monitor Control doesn't react, some times Monitor Control start working again after some seconds some time it will not.
@waydabber commented on GitHub (Aug 21, 2021):
@SlawaGurevich - since ddcctl can't control the display as well (MC uses DDC.swift but it seems neither software is working), probably there is not much we can do on MonitorControl's end with this as this is a hardware issue. :( Sorry about that.
@GM-Alex - please try the new 3.0.0 version as this has a slightly different logic to detect displays and handle configuration changes and please report back if this solves the issue or not. Thank you!
@waydabber commented on GitHub (Aug 25, 2021):
I'll close this issue for now but please feel free to comment if there is anything we can do. If the issue persists, we can reopen this issue! Thank you!