daitj
commented
8 months ago Are you daisy chaining the monitors?
Could you try this PR #108 and see if this fixes your issue?
Closed blanknam3d closed 2 months ago
daitj
commented
8 months ago Are you daisy chaining the monitors?
Could you try this PR #108 and see if this fixes your issue?
blanknam3d
commented
7 months ago Are you daisy chaining the monitors?
These monitors aren't daisy chained, let alone capable of being daisy chained. But some are run through DisplayPort adapters - though I don't think that's related to this issue, as they're manually controllable with ddcutil in the terminal without issue
Could you try this PR and see if this fixes your issue?
I tried using the extension.js from that PR, it seems to just throw up an error that completely prevents the extension from loading instead:
SyntaxError: import declarations may only appear at top level of a module @ resource:///org/gnome/shell/ui/main.js:3:0
Either that's broken, or I misunderstood what it meant to try that PR.
daitj
commented
7 months ago I am sorry yeah that PR was done before GNOME 45, you need to cherry pick the changes done in that commit and edit the extensions.js you have manually.
I have asked the original author if they can make the PR one more time, lets see.
ailin-nemui
commented
7 months ago I made a new extension based on this approach which I originally PRed in #108 , if you want you can give it a try: https://extensions.gnome.org/extension/6325/
daitj
commented
7 months ago @blanknam3d Could you report it back here if @ailin-nemui's extension works for you.
blanknam3d
commented
7 months ago Just gave it a shot - It seems to consistently pick up more displays, whereas previously it sometimes picked up 2 or even 3 on a good day, but still has the same issue of not detecting all 4.
ailin-nemui
commented
7 months ago that's annoying! what version of ddcutil are you using / can you try v2 if you aren't already on it? to me it sounds like even ddcutil detect already suffering from i2c congestion on your system
if you repeatedly spam ddcutil detect in the terminal, does it ever detect all monitors as valid?
blanknam3d
commented
7 months ago what version of ddcutil are you using / can you try v2 if you aren't already on it?
I'm using 2.0.0.
to me it sounds like even ddcutil detect already suffering from i2c congestion on your system
It may possibly be - my system also has various i2c devices for RGB lighting in it & they're controlled by OpenRGB, though closing OpenRGB doesn't appear to make any difference. For some reference:
/sys/bus/i2c/devices/i2c-0/name: AMDGPU SMU 0
/sys/bus/i2c/devices/i2c-1/name: AMDGPU SMU 1
/sys/bus/i2c/devices/i2c-2/name: AMDGPU DM i2c hw bus 0
/sys/bus/i2c/devices/i2c-3/name: AMDGPU DM i2c hw bus 1
/sys/bus/i2c/devices/i2c-4/name: AMDGPU DM i2c hw bus 2
/sys/bus/i2c/devices/i2c-5/name: AMDGPU DM i2c hw bus 3
/sys/bus/i2c/devices/i2c-6/name: AMDGPU DM aux hw bus 0
/sys/bus/i2c/devices/i2c-7/name: AMDGPU DM aux hw bus 1
/sys/bus/i2c/devices/i2c-8/name: AMDGPU DM aux hw bus 2
/sys/bus/i2c/devices/i2c-9/name: SMBus PIIX4 adapter port 0 at 0b00
/sys/bus/i2c/devices/i2c-10/name: SMBus PIIX4 adapter port 2 at 0b00
/sys/bus/i2c/devices/i2c-11/name: SMBus PIIX4 adapter port 1 at 0b20if you repeatedly spam ddcutil detect in the terminal, does it ever detect all monitors as valid?
It detects all actual monitor devices on the GPU as valid - i2c-2 to i2c-5 are my actual monitors, i2c-0 and i2c-1 are "AMDGPU SMU 0" & "AMDGPU SMU 1" respectively.
The invalid displays it keeps detecting are on the "AMDGPU DM aux hw" buses - although I've never tried testing it, I have a feeling the invalid displays it is detecting on those buses may just be the RGB accent light on the GPU... Though I also somewhat doubt that, as prior to upgrading to Fedora 39 & for even sometime afterward, the extension worked without any issues and ddcutil didn't detect any invalid devices whatsoever.
Info about the GPU itself, in case that might help with this issue:
Primary video controller at PCI address 0000:0b:00.0 (boot_vga flag is set)
Device class: x030000 VGA compatible controller
Vendor: x1002 Advanced Micro Devices, Inc. [AMD/ATI]
Device: x73df Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
Subvendor/Subdevice: 1043/05d7 ASUSTeK Computer Inc.
Driver name: amdgpu
Driver version: Unable to determine
I2C device: i2c-3 name: AMDGPU DM i2c hw bus 1
I2C device: i2c-1 name: AMDGPU SMU 1
I2C device: i2c-4 name: AMDGPU DM i2c hw bus 2
I2C device: i2c-2 name: AMDGPU DM i2c hw bus 0
I2C device: i2c-0 name: AMDGPU SMU 0
I2C device: i2c-5 name: AMDGPU DM i2c hw bus 3I have a debug version of my extension, which will print additional logs to journalctl, maybe you can give it a try:
monitor-brightness-volume@ailin.nemui.debug.zip
unpack it inside the ~/.local/share/gnome-shell/extensions/monitor-brightness-volume@ailin.nemui folder
then restart and try to change the brightness, and see if there is any clue of an error in the logs.
also you may want to try pasting the following command into a terminal, and see if you can reproduce the failure (because this is essentially what the extension should be doing when you try to adjust the brightness):
for bus in 2 3 4 5 ; do ddcutil setvcp --bus $bus --noverify 10 33 ; done33 = brightness value
does it also fail to change the brightness? do you get any error messages?
daitj
commented
7 months ago You might want to try this instead, so that all the calls are done in parallel
for bus in 2 3 4 5 ; do ddcutil setvcp --bus $bus --noverify 10 33 & done
blanknam3d
commented
7 months ago Tried both commands - both work as expected, they adjust brightness of all four displays.
@ailin-nemui I tried that debug version of your extension... it seems it just entirely misses the first display bus somehow?
Jan 18 11:58:05 powertower gnome-shell[9743]: ### monitor-brightness-volume@ailin.nemui ### Searching for DDC/I2C monitors
Jan 18 11:58:05 powertower gnome-shell[9743]: ### monitor-brightness-volume@ailin.nemui ### detected monitor buses: 3,4,5
Jan 18 11:58:09 powertower gnome-shell[9743]: ### monitor-brightness-volume@ailin.nemui ### total detected monitor buses: 3,4,5It can control the brightness of the latter 3 displays it sees, but the first & primary display, it doesn't pick that up let alone control the brightness of it.
ailin-nemui
commented
7 months ago why thanks for reporting back, that's a bit curious! could you try updating ddcutil to 2.1.0 see if that makes a difference? and also provide the output of ddcutil detect --terse on your system
and try this special build I made: monitor-brightness-volume@ailin.nemui.debug2.zip
blanknam3d
commented
7 months ago could you try updating ddcutil to 2.1.0 see if that makes a difference?
Seems that was released exactly yesterday - usually Fedora's maintainers are relatively quick on updates, if Fedora hasn't shipped ddcutil 2.1.0 within a week or so, I'll get to installing it manually so I can report back on this with the main + debug builds of the extension... if it's even necessary to, as it turns out:
and try this special build I made: monitor-brightness-volume@ailin.nemui.debug2.zip
That build seems to work on all 4 monitors consistently, even with ddcutil 2.0.0. Whatever you've done in this build appears to be the solution to the problem!
Jan 18 13:35:28 powertower gnome-shell[22489]: ### monitor-brightness-volume@ailin.nemui ### Searching for DDC/I2C monitors
Jan 18 13:35:29 powertower gnome-shell[22489]: ### monitor-brightness-volume@ailin.nemui ### detected monitor buses: 2,3,4,5
Jan 18 13:35:33 powertower gnome-shell[22489]: ### monitor-brightness-volume@ailin.nemui ### total detected monitor buses: 2,3,4,5@blanknam3d
did you actually tried to disable "Display state check" from this extension's settings, it might help you with detecting the all the displays. @ailin-nemui's extension doesn't use display state check i.e. D6
Also for debugging what happens when you do this?
for bus in 2 3 4 5 ; do ddcutil getvcp --bus $bus --noverify D6 & donedid you actually tried to disable "Display state check" from this extension's settings, it might help you with detecting the all the displays.
Doesn't change anything. Still misses the displays.
Also for debugging what happens when you do this? (command)
When I run that command exactly as-is, it seems to get hung up on one of the displays, or sometimes even think there aren't displays on the buses that were previously established as having displays. But if I run for bus in 2 3 4 5 ; do ddcutil getvcp --bus $bus D6 ; done instead, choosing to not do the calls in parallel, it doesn't get hung up on anything or report any issues.
It sometimes also returns this when I do those calls in parallel enough times:
busno=2. Monitor apparently returns -EIO for unsupported features. This cannot be relied on. (sometimes also returns this for bus 4)
daitj
commented
7 months ago It could be related to this rockowitz/ddcutil#358
Anyway in your case ddcutil cannot seem to work in parallel. Your hardware, drivers and linux kernel version can effect that, you can see lots of issues like this in ddcutil's upstream repo.
I suppose for this extension it would be better to have a settings to switch ddcutil calls from parallel to one-by-one.
Matt-1-2-3
commented
7 months ago Im having a similar issue with 2 displays one being my LG C3 OLED tv but KDE Wayland
:ddcutil detect
Invalid display
I2C bus: /dev/i2c-5
DRM connector: card1-HDMI-A-1
EDID synopsis:
Mfg id: GSM - Goldstar Company Ltd (LG)
Model: LG TV SSCR2
Product code: 33229 (0x81cd)
Serial number:
Binary serial number: 16843009 (0x01010101)
Manufacture year: 2023, Week: 1
DDC communication failed. (getvcp of feature x10 returned Error_Info[EIO in ddc_write_read_with_retry, causes: EIO])
Display 1 I2C bus: /dev/i2c-6 DRM connector: card1-DP-1 EDID synopsis: Mfg id: NEC - NEC Corporation Model: EA243WM Product code: 26725 (0x6865) Serial number: 32117493NA Binary serial number: 0 (0x00000000) Manufacture year: 2013, Week: 6 VCP version: 2.0
daitj
commented
4 months ago @Matt-1-2-3 I think you should report this to upstream ddcutil repo instead. But from top of my head I think most TV do not support DDC/CI communication for ddcutil to work.
daitj
commented
2 months ago There are lots of issues with ddcutil and display hubs, DP daisy chaining and also with NVIDIA driver,
For example in my system, I have NVIDIA 2080Ti with 535 driver, USB-C to DP Alt Mode connected to Dell monitor and then using MST connected to Acer monter via DP.
ddcutil doesn't detect bus 4 (Dell) and 5 (Acer) as a proper display and only shows bus 6 (Dell again),
but I am able to control brightness of Acer and Dell using --bus 4 and --bus 5
So I made a cache file ~/.cache/ddcutil_detect as a workaround.
Display 1
I2C bus: /dev/i2c-4
Monitor: DEL:Dell:5331PR3
Display 2
I2C bus: /dev/i2c-5
Monitor: ACR:Acer:CNT318Y1RB
I will close this for now.
Describe the bug
The extension seems to be mistaking actually-working displays as being noncommunicable, due to ddcutil reporting invalid displays on later buses with similar info.
To Reproduce
Delete cache file if it exists and try again
Cache file doesn't exist.
Journal logs
Screenshots
Desktop (please complete the following information):
Additional context
When I run
ddcutil setvcp 10 +90 --bus 2(or bus 3, bus 4, etc... for all valid displays) I can set brightness just fine. Same if I usegetvcpto retrieve the current brightness value of displays on buses 2/3/4/5. There's absolutely no problem communicating with the displays themselves, just that ddcutil reports additional invalid displays & that seems to be confusing the extension.My GPU is a Radeon RX 6700 XT, and I am using Wayland. I previously had this issue with an RTX 2070 installed in the same system while on Xorg, however I had solved the issue myself on Xorg & Wayland with the RTX 2070 installed. I do not have the RTX 2070 anymore, so I cannot test with that GPU.
(edit - fixed formatting error)