I followed that trail and I think the issue is in DDC.servicePort(from displayId: CGDirectDisplayID, detectUnitNumber: Bool) where there is a service matching logic that might not be able to distinguish between similarly named displays (since all the identifiers it uses are ones that might be exaclty similar for two different displays, including display serial number which is not really too unique for most display makers). It seems like the problem is in DDC.swift which is an external library used for Intel communication.
#BENQ BL3201PH CLICKING FLICKERY CODE#
I am sure this is not an issue that can't be fixed, I just don't have the hardware to debug this one so it doesn't make sense for me to try to figure out what is happening.Īnyway, to make some progress, I went through the relevant code quickly in MonitorControl and it does not seem to use the Display name for anything other than superficial purposes (showing stuff on the GUI) - from the earliest moment it uses the display ID provided by CoreGraphics DisplayID (which is an unique identifier, in case of Intel macs its a long number, for M1 macs its a short one) for identification so the two displays are not mixed up somehow. Yes, I know Lunar which is a great app who's developer became a buddy of sort of mine, but it uses a completely different code for DDC control both for Intel and M1.
( - is there a better way to raise awareness to an issue in the community?) I added a "Help wanted" tag to this thread. It would be great if somebody with an Intel setup and two displays would volunteer to understand what is happening exactly.
Unfortunatelly I don't know in depth how DDC.Swift works (I was working on the M1 control library) as I don't have an Intel machine (and two identical displays), so its a bit hard to debug this problem as of now. Reading the earlier remarks, this might be an Intel issue (as I see from the IDs, since such IDs are never given by the OS on M1) and might have something to do with DDC.Swift (which is an external library the app uses for Intel control). The fact that the two displays have the same name should not matter since the app works using IDs not names. Does that fix the - from the screenshot as far as I see the two displays have a separate DirectDisplay IDs so they should be controlled independently. You can make it stop doing this if you enable Advanced in General and then set the polling mode to 'None' - this still enables DDC writes so it should not impair usability. If this forces a reconfiguration (it should not), then my theory is that one of the displays might not like DDC reads and behaves badly because of this and disconnects/reconnects briefly which triggers a reconfiguration.
But MC should not do anything actively with the display except read its settings via DDC. So it might be that MC itself is forcing the reconfiguration. MC refreshes the display if it receives a call from the OS using CGDisplayRegisterReconfigurationCallback() - the fact that the app is continuously reconfiguring (if I understand correctly) would mean that the OS is constantly doing something with the display configuration (but not as frequently as 2 seconds because within a 2 second window the app is still waiting if there are further changes as macOS tends to send several callbacks during a single change).
0 kommentar(er)
