On Mon, May 19, 2014 at 6:22 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > > On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote: >>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood <thomas.wood@xxxxxxxxx> wrote: >>> > It was intended as a debug/testing feature to allow tests in >>> > intel-gpu-tools to enable or disable connectors: >>> > >>> > http://lists.freedesktop.org/archives/intel-gfx/2014-May/045556.html >>> > >>> > >>> > I'll update the commit message for the next version of the patch. >>> >>> Thanks! But please make it a debugfs feature, if possible. We >>> shouldn't expose interfaces in sysfs that aren't part of the core API. >>> Note that this might require you to encode the connector-name in the >>> debugfs-attribute-name. >> >> Imo having the read and write side in completely different parts doesn't >> make a lot of sense. Hence I think doing this in sysfs is ok. Also users >> might want to frob this for testing, and usually debugfs is a bit further >> away on most systems. > > So the read-side is not debug-only? That wasn't clear to me. In that > case, I'm fine with keeping it in sysfs, although I'm not entirely > sure why anyone is interested in "force" information. Oh, I've mixed this up with the corresponding patch to overwrite the edid, which we want to keep exposing through sysfs ofc. I guess debugfs for this is indeed fine then since it's completely new. Might be a bit of fun for lifetimes (especially with dp mst), but meh on that one - we can't make this worse really. So I agree that debugfs makes more sense. For the filename bikeshed a simpley "connector_<name>_force seems good enough. Or maybe a connector-<name> subdir if we want to dwell in overkill. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
