Closed braye closed 5 months ago
Hello, thanks for the report! I'll have a proper look tomorrow, but I want to quickly ask you if you have considered or even had experience using https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux, and if so what your feedback on that project is.
I haven't actually heard of that project until now! In a hilarious coincidence, I was just lamenting how easy it would be to fix this problem if the data was handled in the kernel and could be rewritten/cleaned up before reaching the application.
Hehe - if you have time, give it a try, I'm curious if that would solve all your problems. It sounds like a cool idea, although I'm asking this question everyone who reports an issue with DDC in wluma, and curiously nobody seems to be using it, for various reasons - but I still have very little data 😁
Well the ddcci
module seems to be inconsistent, but when it does create devices for both of the monitors, it does ostensibly work. No warnings in wluma
's output - will have to experiment with it more tomorrow.
I know you are still testing, so no rush at all, but please do let me know what you end up with.
And to answer your original question - you are totally right that it is the failing capabilities that prevents the monitor from being discovered. This happens because wluma
is checking the capabilities in order to see if this is a usable monitor. It's really more of an imposed requirement, not because wluma
actually needs any of the capabilities value. It was proven from a few other users that monitors that cannot report capabilities are most likely not usable at all, and in some cases even prevent people from using wluma
on docking stations. You can see this post for some additional details e.g. here https://github.com/maximbaz/wluma/issues/72#issuecomment-1537246622
If you would like to try anyway whether removing the capabilities validation would work for your setup, you can basically remove lines 70 and 78 here:
Sorry, I didn't get a chance to really test this until this evening. The code changes you proposed seems to work, though I did have to wrap the return value of that filter_map
in Some()
.
I changed the brightness and it's reflected in the logs:
[2024-03-19T02:53:20Z DEBUG wluma::brightness::ddcutil] Discovered displays: ["LG ULTRAGEAR 103NTPC9A464", "DELL U2415 CFV9N85Q0HWS"]
[2024-03-19T02:53:20Z DEBUG wluma::brightness::ddcutil] Using display 'DELL U2415 CFV9N85Q0HWS' for config 'DELL U2415 CFV9N85Q0HWS'
[2024-03-19T02:53:20Z DEBUG wluma::brightness::ddcutil] Discovered displays: ["LG ULTRAGEAR 103NTPC9A464", "DELL U2415 CFV9N85Q0HWS"]
[2024-03-19T02:53:20Z DEBUG wluma::brightness::ddcutil] Using display 'LG ULTRAGEAR 103NTPC9A464' for config 'LG ULTRAGEAR 103NTPC9A464'
[2024-03-19T02:53:20Z INFO wluma] Continue adjusting brightness and wluma will learn your preference over time.
[2024-03-19T02:53:26Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2024-03-19T02:53:26Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2024-03-19T02:53:27Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2024-03-19T02:53:28Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: invalid DDC/CI length
[2024-03-19T02:53:32Z DEBUG wluma::predictor::controller] [LG ULTRAGEAR 103NTPC9A464] Learning Entry { lux: "dark", luma: 0, brightness: 40 }
[2024-03-19T02:53:32Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2024-03-19T02:53:34Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
[2024-03-19T02:53:37Z DEBUG wluma::predictor::controller] [DELL U2415 CFV9N85Q0HWS] Learning Entry { lux: "dark", luma: 0, brightness: 50 }
[2024-03-19T02:53:40Z ERROR wluma::brightness::controller] Unable to get brightness value: DDC/CI error: Expected DDC/CI length bit
Along with all the (expected) errors from my monitors ;)
Re: the ddcci
kernel module - I did a bit of digging and it seems like it won't be upstreamed any time soon because of changes that are (supposedly) coming to sysfs :(
Okay, so it sounds like you'd rather use the ddcutil
from wluma than the ddcci
kernel module. Thanks also for confirming that removing capabilities check helps for your screens.
I'd propose to change that function as per following:
main
branch).That way we hopefully won't break anyone's setup (as I recall capabilities check primarily serves the purpose to filter out invalid screens when another valid one is also present), and at the same time make it work out of the box for your setup, without introducing any new per-monitor configs that you or anyone else would need to know about and configure.
What do you think? Would you like to send a PR? I don't have an external screen, so I would just trust your tests and green CI :grin:
I opened #102 with changes made based on your suggestions - let me know what you think!
Steps for reproducing the issue
Run wluma with an LG Ultragear 27GP83B and a Dell U2415.
What is the buggy behavior?
The LG monitor is not detected - the Dell shows up fine.
What is the expected behavior?
The monitor should be detected, and its brightness adjusted.
Logs
Version
4.3.0 - nixpkgs
Environment