[GH-ISSUE #1250] "Dead pixel(s)" at the left bottom of the external screen appears when app is running #721

Closed
opened 2026-05-05 06:35:06 -06:00 by gitea-mirror · 9 comments
Owner

Originally created by @einsteinhead on GitHub (Dec 11, 2022).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1250

Originally assigned to: @waydabber on GitHub.

Before opening the issue, have you...?

  • Searched for existing issues
  • Looked through the wiki
  • Updated MonitorControl to the latest version (if applicable)

Describe the bug

A super minor thing, but at first when I noticed it I thought it is hardware issue as it seemed as dead pixel(s) at the left bottom of the Apple Studio Display' corner. It seems it is actually the MonitorControl that puts some black pixel(s) at the corner of the external monitor when running.

Steps to reproduce

Visible at the left bottom corner of external monitor all the time while the app is running.

Expected behavior

No black or "dead-like" pixel(s) visible anywhere?

Anything else?

This is really a minor thing and doesn't bother me much, but could cause some confusion as it looks like as a monitor's hardware issue at first.

Environment Information (please complete the following information)

- macOS version: Ventura 13.1 (RC)
- Mac model: Macbook Pro (14-inch, 2021)
- MonitorControl version: 4.1.0 (7034)
- Monitor(s): Apple Studio Display
- Apple Silicon/M1 (yes or no): yes
Originally created by @einsteinhead on GitHub (Dec 11, 2022). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1250 Originally assigned to: @waydabber on GitHub. ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [X] Updated MonitorControl to the latest version (if applicable) ### Describe the bug A super minor thing, but at first when I noticed it I thought it is hardware issue as it seemed as dead pixel(s) at the left bottom of the Apple Studio Display' corner. It seems it is actually the MonitorControl that puts some black pixel(s) at the corner of the external monitor when running. ### Steps to reproduce Visible at the left bottom corner of external monitor all the time while the app is running. ### Expected behavior No black or "dead-like" pixel(s) visible anywhere? ### Anything else? This is really a minor thing and doesn't bother me much, but could cause some confusion as it looks like as a monitor's hardware issue at first. ### Environment Information (please complete the following information) ```markdown - macOS version: Ventura 13.1 (RC) - Mac model: Macbook Pro (14-inch, 2021) - MonitorControl version: 4.1.0 (7034) - Monitor(s): Apple Studio Display - Apple Silicon/M1 (yes or no): yes ```
gitea-mirror 2026-05-05 06:35:06 -06:00
  • closed this issue
  • added the
    bug
    done
    labels
Author
Owner

@waydabber commented on GitHub (Jan 11, 2023):

The app indeed puts a pixel on the screen to trigger screen update when the color table is changing for software dimming. This should not be black however as it's opacity is set to make it invisible. Are you maybe using some kind of color filter or accessibility setting that might make this pixel visible?

Can you post a picture of the problem? Thank you!

<!-- gh-comment-id:1379337699 --> @waydabber commented on GitHub (Jan 11, 2023): The app indeed puts a pixel on the screen to trigger screen update when the color table is changing for software dimming. This should not be black however as it's opacity is set to make it invisible. Are you maybe using some kind of color filter or accessibility setting that might make this pixel visible? Can you post a picture of the problem? Thank you!
Author
Owner

@einsteinhead commented on GitHub (Jan 11, 2023):

Seems like everything is just regular default settings for system (nothing really customised). Probably hard to see it in a picture, but it is just sitting here in the corner.

IMG_0394

<!-- gh-comment-id:1379408300 --> @einsteinhead commented on GitHub (Jan 11, 2023): Seems like everything is just regular default settings for system (nothing really customised). Probably hard to see it in a picture, but it is just sitting here in the corner. ![IMG_0394](https://user-images.githubusercontent.com/12696435/211904941-31607589-4f29-4f80-90fe-97f46a5637aa.jpg)
Author
Owner

@einsteinhead commented on GitHub (Jan 11, 2023):

This is from screenshot when zooming in:
Screenshot 2023-01-11 at 21 59 31

<!-- gh-comment-id:1379412310 --> @einsteinhead commented on GitHub (Jan 11, 2023): This is from screenshot when zooming in: <img width="1239" alt="Screenshot 2023-01-11 at 21 59 31" src="https://user-images.githubusercontent.com/12696435/211905714-6365737d-440a-4b09-89d8-798be887655a.png">
Author
Owner

@waydabber commented on GitHub (Jan 11, 2023):

Right. That should not be there. :)

<!-- gh-comment-id:1379476068 --> @waydabber commented on GitHub (Jan 11, 2023): Right. That should not be there. :)
Author
Owner

@waydabber commented on GitHub (Jan 11, 2023):

All right, I was able to reproduce the issue with MonitorControl. This did not work like this in the past, so it's strange, maybe it's a Ventura related issue? BetterDisplay does not seem to have this even though it uses a similar technique for colortable dimming (but the code is a new implementation so probably it just skipped the pitfall that manifests itself with MC).

<!-- gh-comment-id:1379481168 --> @waydabber commented on GitHub (Jan 11, 2023): All right, I was able to reproduce the issue with MonitorControl. This did not work like this in the past, so it's strange, maybe it's a Ventura related issue? BetterDisplay does not seem to have this even though it uses a similar technique for colortable dimming (but the code is a new implementation so probably it just skipped the pitfall that manifests itself with MC).
Author
Owner

@waydabber commented on GitHub (Jan 18, 2023):

Alpha is not set properly on the screen-refresh enforcement pixel for color table control. Similar issue as this: https://github.com/waydabber/BetterDisplay/issues/1365 (as @janisgodins pointed out).

<!-- gh-comment-id:1387384901 --> @waydabber commented on GitHub (Jan 18, 2023): Alpha is not set properly on the screen-refresh enforcement pixel for color table control. Similar issue as this: https://github.com/waydabber/BetterDisplay/issues/1365 (as @janisgodins pointed out).
Author
Owner

@Ender-Wang commented on GitHub (Dec 15, 2023):

I also run into this problem today, I am migrating from my old m1 mac to the m3 max, I did not see it on my M1, so I started finding solutions what caused it.. Killing processes in the activity monitor and found out it's Moniter Control. I use Bartender and DockMate, those have screen recording access. Not sure what caused that to appear on my M3 mac, since I restored it from a time machine backup.

<!-- gh-comment-id:1858035173 --> @Ender-Wang commented on GitHub (Dec 15, 2023): I also run into this problem today, I am migrating from my old m1 mac to the m3 max, I did not see it on my M1, so I started finding solutions what caused it.. Killing processes in the activity monitor and found out it's Moniter Control. I use Bartender and DockMate, those have screen recording access. Not sure what caused that to appear on my M3 mac, since I restored it from a time machine backup.
Author
Owner

@shreyanshk commented on GitHub (May 25, 2024):

Confirming that it is also reproducible on my end too with MacOS 14.5 (23F79) on an M3 Pro MBP. This machine was setup from fresh and no backups were restored.

<!-- gh-comment-id:2130978962 --> @shreyanshk commented on GitHub (May 25, 2024): Confirming that it is also reproducible on my end too with MacOS 14.5 (23F79) on an M3 Pro MBP. This machine was setup from fresh and no backups were restored.
Author
Owner

@waydabber commented on GitHub (Oct 3, 2024):

Just checked, this is indeed an issue. It's the color table activity enforcer pixel created by the app. It should be invisible, will fix it in the next release.

<!-- gh-comment-id:2391479415 --> @waydabber commented on GitHub (Oct 3, 2024): Just checked, this is indeed an issue. It's the color table activity enforcer pixel created by the app. It should be invisible, will fix it in the next release.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/MonitorControl#721
No description provided.