mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 14:15:55 -06:00
[GH-ISSUE #296] Acer XB280HK works with ddctl but not with MonitorControl #234
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#234
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 @jonashaag on GitHub (Sep 29, 2020).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/296
Checklist
Describe the issue
MonitorControl does not allow for changing brightness, but
ddctldoes.Expected behavior
Brightness control should be available (disabled/greyed out).
Additional context
ddctlchanges the brightness correctly, but reports errors.Possible values seem to be in [0, 100].
Environment Information (please complete the following information):
@JoniVR commented on GitHub (Sep 30, 2020):
So if I understand correctly, ddcctl reports the sending of the command failed but it works anyways? I could perhaps try to provide a build where the check for ddc is disabled for you to test (or you could test it yourself if you know how).
Do keep in mind that we're not using ddcctl under the hood anymore but perhaps if we disable the ddc check it might work. If that's the case we could provide it as an "advanced prefs" setting.
@jonashaag commented on GitHub (Sep 30, 2020):
I guess that would work!
@jonashaag commented on GitHub (Sep 30, 2020):
And yes, the command seems to be executed correctly, even though an error is reported.
@waydabber commented on GitHub (Aug 21, 2021):
Hi, you might want to try the new version 3.0.0 to confirm that the issue is still present (or not). If it does not work please provide a screenshot of the Displays tab so we might see how MonitorControl recognizes the display (controllable or not). Thank you!
@jonashaag commented on GitHub (Aug 21, 2021):
Unfortunately I don’t have that particular display anymore so won’t be able to test :(
@waydabber commented on GitHub (Aug 21, 2021):
Ok, no problem. Thanks for the reply! Hope the new display works properly with MonitorControl. :)
I'll close this issue then.