mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 14:15:55 -06:00
[GH-ISSUE #364] Implementation MCCS via USB (EIZO) #287
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#287
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 @gustavneustadt on GitHub (Jan 5, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/364
I have a EV2785 and sadly MonitorControl doesnt work for me. I had contact with EIZO support and they confirmed to me that they do not build DDC/CI controllers in their monitors anymore. They seem to use their own proprietary windows software. (#351)
I found dccutil supports the MCCS protocol which is necessary (?) for monitors from Eizo. It communicates not via hdmi/dp but via usb with the monitors to control them. I didnt tried it, because I was not able to build it on my mac.
Would be nice to see a implementation of this.
@waydabber commented on GitHub (Aug 19, 2021):
You are right, this could be a useful feature. I'll try to add this in the future (but no promises).
"Alternatively, some monitors (e.g. Eizo ColorEdge, Apple Cinema) provide a USB interface to the VCP, as described in the USB Monitor Control Class Specification. ddcutil can communicate with these monitors over USB instead of I2C."
@waydabber commented on GitHub (Aug 19, 2021):
For future reference - ddcctl seems to use this to detect such displays:
39ce66b423/src/usb/usb_displays.c (L693-L743)Also, for Apple branded external displays standard DisplayService calls should work (this is now limited to the internal display only). The following could be used to detect such displays using a whitelist method and direct them to use DisplayService instead of DDC:
let ULTRAFINE_NAME = "LG UltraFine"
let THUNDERBOLT_NAME = "Thunderbolt"
let LED_CINEMA_NAME = "LED Cinema"
let CINEMA_NAME = "Cinema"
let CINEMA_HD_NAME = "Cinema HD"
let COLOR_LCD_NAME = "Color LCD"
let APPLE_DISPLAY_VENDOR_ID = 0x05AC
(credits for this goes to @alin23)
@gustavneustadt - a question: does the built in MacOS brightness slider control the Eizo display? Or even though it implements a similar protocol to Apple's Cinema display it is not being controlled by the OS? Thank you!
@alin23 commented on GitHub (Aug 19, 2021):
One can easily test if DisplayServices works for their monitor using the Lunar CLI.
DisplayServicesSetBrightnessandCoreDisplay_Display_SetUserBrightnessusing the following commands (run them one by one to see which one works)Set brightness
20for UUID37D8832A-2D66-02CA-B9F7-8F30A301B230usingDisplayServicesSet brightness to
20for UUID37D8832A-2D66-02CA-B9F7-8F30A301B230usingCoreDisplay@waydabber commented on GitHub (Aug 19, 2021):
Thanks @alin23 !
@gustavneustadt - please let us know if you have the results. Thank you!
@gustavneustadt commented on GitHub (Aug 21, 2021):
Thank you very much! I am currently on vacation but will try it for sure.
UPDATE:
@waydabber
Which one? Didnt find any software slider. If you mean the keyboard controls: No, this do not work.
@alin23
Sadly this does not work for me.
Since I am using a Hackintosh, the problem may come from faulty usb mapping or other hacky stuff – at the moment I have no other way to test this.
@deg0nz commented on GitHub (Aug 25, 2021):
Hi,
just a qick feedback:
I was able to test the Lunar stuff described by @alin23 with a MacBook and an Eizo EV2785 connected via USB-C. Lunar is NOT able to change the brightness of the display.
@waydabber commented on GitHub (Aug 25, 2021):
@gustavneustadt,
I meant the Dispaly Brightness slider in Big Sur's control center. But if the keyboards don't work, then probably EIZO displays are not regarded the same way as Apple displays even though they use a similar protocol.
@deg0nz,
thanks for the feedback.
We should probably divide this issue into two - supporting Apple displays is easy by using DisplayServices while supporting MCCS via USB is an entirely different thing to do.
@waydabber commented on GitHub (Aug 25, 2021):
Apple branded displays will be handled here:
https://github.com/MonitorControl/MonitorControl/issues/539
@deg0nz commented on GitHub (Aug 25, 2021):
One more update:
I digged into this a little bit, compiled
ddcutilin a Linux VM and tried if I could change/access my monitor's settings by redirecting the USB device of the monitor into the VM.Unfortunately, it didn't work.
I also stumbled across https://github.com/rockowitz/ddcutil/issues/68 and this part about the EV2785 in the docs at http://www.ddcutil.com/monitor_notes/ (Which is basically the same content as the issue):
So this means, unless someone is willing and able to reverse engineer this stuff for the EV2785, there is not much hope.
But different EIZO monitors seem to work (at least partially) according to the
ddcutildocs. For example the Coloredge CG19 seems to follow the MCCS specs (see link to monitor notes above).@waydabber commented on GitHub (Sep 3, 2021):
For those with Apple displays, there is a link to a test build with proper support in this issue: https://github.com/MonitorControl/MonitorControl/issues/539
Unfortunately this will not work for EIZO displays.
@waydabber commented on GitHub (Oct 16, 2021):
I am afraid MCCS over USB probably won't happen unless somebody who actually has an EIZO display that supports this protocol and has the ability to port the relevant codes from this over to Swift/macOS does the job.
(Of course if somebody is willing to donate a display like this to the cause then the core dev team can work on it as well but even then it's gonna be a lot of work so I don't really see this as a feasible alternative).
I'll convert this issue into a discussion since it makes no sense to have this sit here forever while letting the stalebot eat the issue does not seem to be the proper way to handle this either.