[PATCH] drm/sysfs: expose the "force" connector attribute

Daniel Vetter daniel at ffwll.ch
Mon May 19 10:30:10 PDT 2014


On Mon, May 19, 2014 at 6:22 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>
> On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter <daniel at ffwll.ch> 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 at intel.com> 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


More information about the dri-devel mailing list