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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
