On Tue, Feb 15, 2022 at 3:46 PM Doug Anderson dianders@chromium.org wrote:
On Tue, Feb 15, 2022 at 2:52 PM Brian Norris briannorris@chromium.org wrote:
It still makes me wonder what the point of the /dev/drm_dp_aux<N> interface is though, because it seems like you're pretty much destined to not have reliable operation through that means.
I can't say I have tons of history for those files. I seem to recall maybe someone using them to have userspace tweak the embedded backlight on some external DP connected panels? I think we also might use it in Chrome OS to update the firmware of panels (dunno if internal or external) in some cases too? I suspect that it works OK for certain situations but it's really not going to work in all cases...
Yes, I believe I'm only submitting patches like this because fwupd apparently likes to indiscriminately whack at dpaux devices: https://github.com/fwupd/fwupd/tree/main/plugins/synaptics-mst#kernel-dp-aux...
That seems like a bad idea.
(We've already disabled that plugin on these systems, but it seems wise not to leave the stumbling block here for the next time.)
I suppose this just further proves the point that this is really not a great interface to rely on. It's fine for debugging during hardware bringup and I guess in limited situations it might be OK, but it's really not something we want userspace tweaking with anyway, right? In general I expect it's up to the kernel to be controlling peripherals on the DP AUX bus. The kernel should have a backlight driver and should do the AUX transfers needed. Having userspace in there mucking with things is just a bad idea. I mean, userspace also doesn't know when a panel has been power cycled and potentially lost any changes that they might have written, right?
I sorta suspect that most of the uses of these files are there because there wasn't a kernel driver and someone thought that doing it in userspace was the way to go?
*shrug* beats me.
Brian