SUMMARY When using drm.edid_firmware kernel parameter to override monitor EDID(s), DDC brightness setting stops working on monitor(s) whose EDID was overriden (but KEEPS working on other displays) and software / color management dimming is used instead (which of course looks horrible on LCD screens). This is a regression from 6.1 and is almost certainly linked to recent changes in brightness handling (e.g. per-monitor brightness setting and similar changes). STEPS TO REPRODUCE 1. Make sure no EDIDs are overriden (check that the kernel did not boot with drm.edid_firmware parameter) 2. Check that DDC-based brightness setting works correctly. 3. Reboot with e.g. "drm.edid_firmware=DP-1:FILENAME.edid.bin" parameter (in my case the EDID just adds some custom resolutions, everything else is identical to the original) OBSERVED RESULT On DP-1 display, software dimming is now used. Assuming there is another monitor connected to DP-2, DDC-based brightness setting still works on DP-2. If DP-2 EDID is also overriden, then it stops working on DP-2 as well. EXPECTED RESULT DDC-based brightness still works regardless of EDID overrides, as it used to in 6.1. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7 Qt Version: 6.8
Kernel: 6.11.6 GPU: AMD Radeon RX 6800 XT GPU driver: amdgpu
Could you confirm that `ddcutil detect` still shows the monitor, and it's just KDE's use of libddcutil that fails to handle it?
(In reply to Jakob Petsovits from comment #2) > Could you confirm that `ddcutil detect` still shows the monitor, and it's > just KDE's use of libddcutil that fails to handle it? I am facing same issue, It's being detected in ddcutil and also https://github.com/davidhi7/ddcci-plasmoid this applet works fine with dimming the hardware brightness ╰─❯ ddcutil detect Invalid display I2C bus: /dev/i2c-9 DRM connector: card0-eDP-1 EDID synopsis: Mfg id: SHP - Sharp Corporation Model: Product code: 5397 (0x1515) Serial number: Binary serial number: 0 (0x00000000) Manufacture year: 2021, Week: 13 This is a laptop display. Laptop displays do not support DDC/CI Display 1 I2C bus: /dev/i2c-12 DRM connector: card0-DP-3 EDID synopsis: Mfg id: ACR - Acer Technologies Model: EI322QUR Product code: 1839 (0x072f) Serial number: 3350021873V01 Binary serial number: 889201031 (0x35002187) Manufacture year: 2023, Week: 50 VCP version: 2.1
Also brightness changed using https://github.com/davidhi7/ddcci-plasmoid this applet is instant, while KDE built-in applet takes time to apply the changes, I dont know why, Is it possible to disable the kde applet totally, software/hardware option in applet to be not showned.
I can also confirm that ddcutil works fine. Both detect and setting brightness. Also happens on the recently released 6.2.3 Plasma version.
One more report affirming this regression, loss of external monitor brightness control, in Powerdevil from version 6.2.2-1 to 6.2.3-1 When using the system brightness hotkeys, only the internal laptop screen brightness is displayed and changed. I also do report the 2 second delay of brightness changes on the external monitor, but that is consistent with running the command ddcutil setvcp 10 100. I haven't tried any applets. I have downgraded just Powerdevil to 6.2.2-1 with all other packages at 6.2.3-1 and brightness controls returned to working. Hardware Laptop. Lenovo Thinkpad T490s with Intel 8365 / Coffee Lake north bridge / Whiskey Lake graphics / Canon Point south bridge / Alpine Ridge Thunderbolt External Monitor. Lenovo P24q-10 using HDMI Logitech LogiDock between laptop and monitor DDCUTIL detect Invalid display I2C bus: /dev/i2c-5 DRM connector: card1-eDP-1 EDID synopsis: Mfg id: LGD - UNK Model: Product code: 1580 (0x062c) Serial number: Binary serial number: 0 (0x00000000) Manufacture year: 2018, Week: 0 This is a laptop display. Laptop displays do not support DDC/CI Phantom display Associated non-phantom display: bus /dev/i2c-8 I2C bus: /dev/i2c-7 DRM connector: card1-DP-2 EDID synopsis: Mfg id: LEN - Lenovo Group Limited Model: P24q-10 Product code: 24997 (0x61a5) Serial number: Binary serial number: 16843009 (0x01010101) Manufacture year: 2019, Week: 35 DDC communication failed Use non-phantom device bus /dev/i2c-8 Display 1 I2C bus: /dev/i2c-8 DRM connector: card1-DP-4 EDID synopsis: Mfg id: LEN - Lenovo Group Limited Model: P24q-10 Product code: 24997 (0x61a5) Serial number: Binary serial number: 16843009 (0x01010101) Manufacture year: 2019, Week: 35 VCP version: 2.2
I did double-check, and cycled through prior versions of Powerdevil in my Arch pacman cache 6.1.5, 6.1.90, 6.2.0, 6.2.1 would only control the laptop screen brightness 6.2.2 is the only version that would control both laptop and HDMI screen brightness together
from journalctl --- Nov 16 14:51:24 jthink org_kde_powerdevil[5009]: (ddc_hotplug_change_handler) DRM connectors added: card1-DP-3 Nov 16 14:51:24 jthink org_kde_powerdevil[5009]: (ddc_hotplug_change_handler) card1-DP-3 Nov 16 14:51:26 jthink kwin_wayland[2705]: kwin_wayland_drm: failed to open drm device at "" Nov 16 14:51:26 jthink kwin_wayland[2705]: kwin_wayland_drm: failed to open drm device at "" Nov 16 14:51:26 jthink kwin_wayland[2705]: kwin_wayland_drm: failed to open drm device at "" Nov 16 14:51:29 jthink org_kde_powerdevil[5009]: stabilized_connector_names required 1 extra calls to get_sysfs_drm_connector_names() Nov 16 14:51:29 jthink org_kde_powerdevil[5009]: (ddc_hotplug_change_handler) DRM connectors added: card1-DP-5 Nov 16 14:51:29 jthink org_kde_powerdevil[5009]: (ddc_hotplug_change_handler) card1-DP-5 Nov 16 14:51:29 jthink org_kde_powerdevil[5009]: INTERNAL ERROR: Sys_Drm_Connector not found for connector card1-DP-5
ddcutil gives us the first 128 bytes of the EDID, and that's used to match it to the display - it seems that if you override the EDID, the kernel will also provide that overridden EDID to KWin, so the EDID no longer matches. > Display 1 > I2C bus: /dev/i2c-12 > DRM connector: card0-DP-3 If ddcutil can figure out the matching drm connector, perhaps there's some logic we can copy that doesn't depend on the EDID. As a completely different approach, why do you override the EDID? Ideally that shouldn't be necessary in the first place.
Some monitors just have completely broken EDIDs (edid-decode screams in horror, many errors, completely out of spec). Mine is a 170Hz monitor with a 170Hz timing entry, but max vertical range in the EDID is 165 Hz (and max pixel clock specified in the first block is also less than some timings require). Windows ignores that and 170Hz still works, but Linux doesn't and 170Hz timings are gone. Also, Gigabyte (my monitors manufacturer) had a broken firmware updater and now both my (identical) monitors have completely identical EDIDs - that is including serial number, week of manufacture etc. Those were different before the fw upgrade. EDID editing also allows for custom resolutions, refresh rates etc. Again, ddcutil works just fine (and so did Plasma 6.1).
I loaded KDE 6.2.4.1 last night, and my problem is gone. I can control the brightness of both my laptop and external HDMI screen.
(In reply to Jon List from comment #11) > I loaded KDE 6.2.4.1 last night, and my problem is gone. > > I can control the brightness of both my laptop and external HDMI screen. Your problem has nothing to do with this bug. You are not overriding your display's EDID. The actual reported problem (brightness controls not working on displays with overriden EDID) still persists on 6.2.4. Honestly if I had a way to revert to 6.1 "universal brightness" behavior, this bug wouldn't concern me. Would it be difficult to implement a choice between the 6.2 and 6.1 behavior? With setups like mine (just two identical monitors next to each other), I DON'T EVER want to control the brightness separately. I very much liked having a single brightness slider that controlled both (identical) monitors.
The yet unreleased ddcutil 2.2.0 will has this changelog entry: > Extensively reworked display change detection > - improved performance using UDEV > - use /sys to get EDID if possible > (...) If I understand Zamundaaa's comment correctly, and how things roughly work in ddcutil, then the next ddcutil update might be able to fix your issue. KWin would use the EDID from the kernel, that's what's provided by /sys files presumably, and if ddcutil also uses those then the two sides would match up again. As an Arch user, you have access to the AUR and could try the development version at https://aur.archlinux.org/packages/ddcutil-git - I just gave it a shot and it solved a few issues (different ones) for me as well. Please report back if this makes a difference for you.
Indeed this fixes the issue! I will keep using the git version of ddcutil until next stable is released. Thank you! P.S.: I will repeat myself: Is there even a chance (I realize this is a feature request) if implementing a setting to revert back to 6.1 behavior? I think that in some, even many display setups (typically dual/triple identical monitors next to each other) it simply makes no sense to set brightness individually and this new feature just adds hassle...
> As an Arch user, you have access to the AUR and could try the development > version at https://aur.archlinux.org/packages/ddcutil-git - I just gave it a > shot and it solved a few issues (different ones) for me as well. > > Please report back if this makes a difference for you. My external monitor connected via Thunderbolt <-> Dock <-> HDMI was working in terms of controlling both displays brightness but laptop wakeup often required reconnecting the Thunderbolt cable, or if not then there was a few too many rounds of crashes and resetting the connection before I had both displays working. ddcutil-git improved things here with the power cycling before successful connection Thanks everybody
(In reply to Jan Klos from comment #14) > P.S.: I will repeat myself: Is there even a chance (I realize this is a > feature request) if implementing a setting to revert back to 6.1 behavior? I > think that in some, even many display setups (typically dual/triple > identical monitors next to each other) it simply makes no sense to set > brightness individually and this new feature just adds hassle... We now have a feature request at Bug 496870. I agree that it would be good to allow setting the brightness with a slider that affects more than one display at a time, especially since not everyone is aware of applet icon scrolling (which does change brightness for all of them at the same time).