On Tue, Feb 15, 2022 at 3:46 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > On Tue, Feb 15, 2022 at 2:52 PM Brian Norris <briannorris@xxxxxxxxxxxx> 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-interface 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
