mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 14:15:55 -06:00
[GH-ISSUE #478] Intel DDC command unreliability on versions > v2.1.0 #380
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#380
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 @kevinjohncutler on GitHub (Jul 26, 2021).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/478
Originally assigned to: @JoniVR, @waydabber on GitHub.
Checklist
Describe the bug
Function row brightness and volume keys (apple magic keyboard) no longer work for me. They work up to version 2.1.0, but not in 2.2.0 or the 3.0.0 beta. I'm using LG 5K2K displays. This bug is present when one or both monitors are connected.
To Reproduce
Launch MonitorControl 2.2.0 and use function row keys to adjust display brightness or volume.
Expected behavior
Brightness keys should adjust brightness, volume keys should adjust volume.
Additional context
The menu bar sliders do work to adjust brightness and volume. Also, the Hide OSD option works for volume now on my displays (yay!) when using the function keys, but of course the keys do not adjust volume (just as the brightness keys do not adjust brightness). The volume OSD is not hidden when using the menu bar sliders, but the brightness OSD is.
Behavior is not affected by the Hide OSD toggle, but it may be affected by the Polling Mode. It is hard to tell, but cycling the brightness up and down with the function keys will produce sporadic increases or decreases in brightness (depending on which key is being pressed), generally at the extremes of the brightness scale.
Environment Information (please complete the following information):
@LCLx commented on GitHub (Jul 27, 2021):
Same here. Menu bar sliders do work but shortcuts do not.
Environment Information (please complete the following information):
@moonagic commented on GitHub (Jul 27, 2021):
Same here. Menu bar sliders do work but shortcuts do not.
Environment Information (please complete the following information):
@gilesbutler commented on GitHub (Jul 27, 2021):
Same here.
Environment Information (please complete the following information):
macOS version: 11.5
Mac model: MacBook Pro (15-inch, late 2017)
MonitorControl version: 2.2.0
Monitor(s): LG 32UD99-W
Apple Silicon/M1 (yes or no): no
@jmtakahashi commented on GitHub (Jul 27, 2021):
Same here.
Environment Information (please complete the following information):
macOS version: 11.5
Mac model: MacBook Pro (13-inch, early 2015)
MonitorControl version: 2.2.0
Monitor(s): LG 34WL85C-B
Apple Silicon/M1 (yes or no): no
@JoniVR commented on GitHub (Jul 27, 2021):
I can confirm this happens for me as well on the release build (2.2.0), strangely enough, when I build it with Xcode it works perfectly.. will investigate..
edit: only happens when building in release mode, works fine in debug mode.. fun fun fun
@Scope666 commented on GitHub (Jul 27, 2021):
Same here, reverting back to 2.1 fixes the issue.
@jmtakahashi commented on GitHub (Jul 27, 2021):
Can we revert using Homebrew?
On Tue, Jul 27, 2021 at 7:18 AM Scope666 @.***> wrote:
--
Jason Takahashi
@.***
+1 (808) 349-5848
@Sayvai commented on GitHub (Jul 27, 2021):
Same issue applies on my LG UltraWide 34UC99-W monitor.
Brightness function keys no longer work on the above connected extended monitor. But when i revert installed version back to
2.1.0, the brightness keys work again.macOS version:
Big Sur 11.4Mac model:
MacBook Air 2020MonitorControl version:
2.2.0Monitor(s):
LG UltraWide 34UC99-WApple Silicon/M1 (yes or no):
no@JoniVR commented on GitHub (Jul 27, 2021):
I'm guessing this is probably still related to #238, which had the same issue.. Seemed fixed to me but apparently only in debug mode, which suggests a timing issue perhaps?
Also, as someone else pointed out in that thread, spamming the command a few times makes it work (hence why it works with the sliders), but it doesn't seem like a very elegant solution to me.
@StanleyCruvinel commented on GitHub (Jul 27, 2021):
Same here. Menu bar sliders do work but shortcuts do not and neither hide OSD .
Environment Information (please complete the following information):
macOS version:
11.5.1Mac model:
MacBook ProMonitorControl version:
2.2.0Monitor(s):
LG 32UL750Apple Silicon/M1 (yes or no):
no@Horsey- commented on GitHub (Jul 28, 2021):
I'm also having the same issues as above:
reverted to 2.1.0 and it works just fine for me
thank you for this project!
@BenjaminX commented on GitHub (Jul 28, 2021):
@flayks commented on GitHub (Jul 28, 2021):
Same issue here since 2.2.0. Not working either with 3.0.0b2
Reverted to 2.1.0 in the meantime
macOS version: 11.4
Mac model: MacBook Pro (15-inch, 2018)
MonitorControl version: 2.2.0/3.0.0b2
Monitor(s): Dell U3219Q Display
Apple Silicon/M1 (yes or no): no
@thiagocorreiap commented on GitHub (Jul 28, 2021):
Same here. Menu bar sliders do work but shortcuts do not.
Environment Information (please complete the following information):
macOS version: 11.4
Mac model: MacBook Pro (13-inch, 2020, Two Thunderbolt 3 ports)
MonitorControl version: 2.2.0
Monitor(s): ASUS PB278
Apple Silicon/M1 (yes or no): no
@StanleyCruvinel commented on GitHub (Jul 28, 2021):
When press simultaneos volume keys Up and Down or Down and Mute, the OSD shows up and change the volume !
@jason-wihardja commented on GitHub (Jul 29, 2021):
@jmtakahashi you can. Just download the earlier cask definition into your local computer and you can install it like
brew reinstall --cask ./monitorcontrol.rb. I just did the same@jmtakahashi commented on GitHub (Jul 29, 2021):
@jason-wihardja Thanks for the reply. Do I download the through brew? I've never rolled back using Brew. Can you instruct me on how to get the 2.1.0 cask definition? Thank you.
@jason-wihardja commented on GitHub (Jul 29, 2021):
There are 2 ways you could do that. The first one would be to visit the Github repo at https://github.com/Homebrew/homebrew-cask/, search for the right commit, then download the raw file into your computer. The second way would be to go through the local repo in your machine, work out the last working commit, then extract the file out.
I'll explain the latter, since it's how I usually do it.
cdinto the folder of your local repo. I assume that you're using the default setting, so that would be/usr/local/Homebrew/Library/Taps/homebrew/homebrew-caskrbfile that you're interested in, in this caseCasks/monitorcontrol.rb$ git log -5 -- Casks/monitorcontrol.rb5f6f955d40a9b012f279da8349d1618c90ee7d0b$ git show 5f6f955d40a9b012f279da8349d1618c90ee7d0b:Casks/monitorcontrol.rb > ~/Desktop/monitorcontrol.rb$ brew reinstall --cask ~/Desktop/monitorcontrol.rbThat's it. You should be back with version 2.1.0 after completing all the steps.
@jmtakahashi commented on GitHub (Jul 29, 2021):
@jason-wihardja thank you for the detailed step-by-step! Much appreciated!!!!!!
Will upgrading and updating Brew overwrite this?
@jason-wihardja commented on GitHub (Jul 29, 2021):
I don't know about your usual workflow, but I don't usually upgrade all my formulas at once. So whenever I update, I will look at the output of the update command then specifically choose which formula I would upgrade. This way I can avoid upgrading monitorcontrol until a fix is available
@jmtakahashi commented on GitHub (Jul 29, 2021):
@jason-wihardja I usually automate my update, but will need to switch to manual until this bug is resolved.
After reverting back to 2.1.0, I realized that the "Hide OSD" function works with the Brightness Control (the monitorOSD doesn't not show, only the Mac native OSD), but the Volume Control flickers the monitor OSD when changing volume levels on my mac, both with the function buttons or the Menu Bar slider.
Is this happening on your computer as well?
@jason-wihardja commented on GitHub (Jul 29, 2021):
Yes, unfortunately we can't really pin a cask like a normal formula. So you can't lock the version
Nope. It works ok just like before. Have you tried replugging the monitor? Mine is a Dell U3818DW. No issues so far.
@jmtakahashi commented on GitHub (Jul 29, 2021):
I just restarted my computer, and also unplugged my monitor. I'm on an LG 34WL85C-B. Same glitching of the monitor's OSD is happening when I change my volume.
I found a recently opened bug issue, but the title is misleading. #462
Interestingly, I also noticed that my System Preferences -> Display "resets" to "Scaled" even after I had set it to "Default for Display".
@arpitest commented on GitHub (Jul 30, 2021):
same. menu works, multimedia keys dont (OSD looks ok, but volume does not change)
U32R59x displayport monitor, RX580, Big Sur intel 11.5.1 (hackintosh)
reverting to 2.1 solves the problem.
@JoniVR commented on GitHub (Jul 30, 2021):
I appreciate everyone willing to help here, but I think we’ve established that it’s not working properly. Just repeating the same thing everyone else is saying doesn’t help much.
Shortcuts don’t work and menu works (because it basically spams the command multiple times).
No need to post your info or say that it doesn’t work anymore, if you have specific info on the problem that hasn’t been mentioned yet, temporary workarounds or other technical details you’re obviously still welcome to post them.
From what I can tell from my quick debug session a few days ago, it only happens when you build in release mode, to reproduce it you can simply change the scheme to release mode in Xcode.
@JoniVR commented on GitHub (Aug 3, 2021):
Hi all, please try v3.0.0 beta 3, it should work on Intel now and function keys should work. You might still notice a bit of choppiness/delay, I'll try to fix it properly before we do a final 3.0.0 release. 🙂
@Sayvai commented on GitHub (Aug 3, 2021):
Thanks Joni.
v3.00 beta 3works on my Intel chip Big Sur OS, restoring the brightness function keys functionality on both monitors.Like you've mentioned, the brightness function keys are choppy / laggy in response to changes (even skips some brightness levels / changes), which i understand is a work in progress, but at least the brightness menu slider adjustments / change responses appears to be smooth.
Great recovery in the meantime, and thank you 👍
@wondergit113 commented on GitHub (Aug 3, 2021):
Can confirm 3.00 beta 3 works much better but still has the experience as described above. Will continue to test future changes.
Nice new icon, btw!
@stiligFox commented on GitHub (Aug 4, 2021):
Can confirm that with 3.0.0 Beta 4 on Intel, the choppiness is there, and one or two of my three displays will skip brightness levels when changing using the shortcut keys, but overall is working in the right direction! It also works fine when changing the values from the menubar. Thanks so much for all the work you're putting into it!
@Phunky commented on GitHub (Aug 5, 2021):
Tested Beta 4 on my 16" Macbook Pro and shortcut keys respond across both monitors but neither change volume or brightness and the same when using the range sliders in the menubar app.
@JoniVR commented on GitHub (Aug 7, 2021):
Minor update, I've delete v2.2.0 to prevent more people from installing it by accident and running into issues, I'm not sure if this helps people who install through brew though, but feel free to let me know.
@Moulick commented on GitHub (Aug 8, 2021):
@bevanjkay has reverted the version in brew to 2.1.0. As the manual hacks for brew to rollback to 2.1.0 no longer necessary https://github.com/Homebrew/homebrew-cask/pull/109566
Thanks @bevanjkay
cc: @jason-wihardja @jmtakahashi
@JoniVR commented on GitHub (Aug 11, 2021):
Just a minor update (and for the sake of keeping track of the issue):
I think I found out what's causing the issue. The DDC.swift send function makes use of a semaphore to lock the Framebuffer DispatchQueue instantiation (mutex style), and I think this is causing it. If you call DDC.sem.wait() twice at the start of the function, the issues on release are gone. I think it was probably caused by some compiler optimisation changes in Swift 5.2 (they did some under the hood tweaks), which caused it to lock or become unreliable.
This is obviously not a proper solution as it still introduces some lagging, so I'm planning on looking into it a but further whenever I get some more time. But at least now we know where the bug is and we can properly fix it.
@JoniVR commented on GitHub (Aug 21, 2021):
Hi all, please try v3.0.0 RC1 and let me know your experiences, the issue isn't resolved properly yet but the workaround should be less choppy in this release.
@Sayvai commented on GitHub (Aug 21, 2021):
Wow, thanks @JoniVR .
What i can say with version
3.0.0 RC1, is that it is much better than with the prior beta versions, with the response to the brightness function keys much more smoother, to the point where it is really hard to tell whether any choppiness is noticeable, reacting pretty much the same as in the previous stable version2.1.0, which i had just reverted back to temporarily to compare brightness adjustment responses.I know a proper reliable resolution is still in the works (🤞 ), but this at least feels normal to me now. Great job, and thanks! 👍
macOS version:
Big Sur 11.5.2Mac model:
MacBook Air 2020MonitorControl version:
3.0.0 RC1Monitor(s):
LG UltraWide 34UC99-WApple Silicon/M1 (yes or no):
no@waydabber commented on GitHub (Sep 5, 2021):
I fixed this issue in the
feat/betabranch. It should be fully compatible with master as well. It would be great if somebody with a real Intel mac could test it (since I have only M1 macs I installed a Hackintosh on my PC to debug this one on Intel :)).@wondergit113 commented on GitHub (Sep 5, 2021):
RC1 and RC2 fixed this for me on Intel Mac running macOS 11.5.2
@waydabber commented on GitHub (Sep 5, 2021):
Hi @jamesg311 - yes, but it was just a temporary fix, we had to disable Swift code optimization for it to work properly.
--
Most notably the read part should be tested since on my Hackintosh it did not work properly (but did not work with the latest RC as well which was a baseline so its probably a Hackintosh problem).