Hi! > > > >> A nice godfather is required here... > > > > > > > > Just use sys:: :-). > > > > > > > > laptop:: would work for me, too. (It is always laptop in the cases we > > > > are handling now, right?) > > > > > > > > When we get a keyboard with mute led, we'll have to decide if it > > > > should be input6::mute -- because it is on keyboard, or if it is > > > > sys::mute -- because the key is expected to mute whole system. > > > > > > drivers/input/input-leds.c seems to already support mute LED. > > > It will be exposed as inputN::mute. > > > > > > Documentation/leds/leds-class.txt defines LED naming pattern > > > to <devicename:color:function> and "sys" does not look as > > > something resembling device name. > > > > So what is your suggestion? > > I guess we should follow documentation. Or update documentation if it > does not make sense to follow it.
That's actually in progress. Let me and Jacek deal with it. We don't
need great "how to name a LED" discussion here (google: bike shed paiting).
> > I don't care much as long as it is same in tpacpi and dell
> > case. (Neither are device names, btw :-).
> >
> > Actually "::mute" would make sense, too.
>
> "::mute" is not a good idea due to name uniqueness.
>
> In case you would have two drivers which both provides "mute" led, then
> they need to have different name. Reason also why generic name "sys" is
> not a good idea.
> I think that driver name or subsystem name would be usable together with
> number.
>
> Userspace application would be probably interested to distinguish
> between "mute led which is part of laptop" and "mute led which is
> available on external USB keyboard".
>
> If external USB keyboard is identified as "input7" device, then
> "input7::mute" is a good name for mute key. But "sys::mute" does not say
> anything to which device or hardware it belongs nor does not solve
> problem that which device/driver/subsystem should have privilege to take
> this "sys" name.
Well, "sys" says this is system-wide mute LED. There are not expected
to be two of those, and there never will be, with the drivers
currently proposed.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
_______________________________________________ ibm-acpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
