Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]

Hi!

> >>>> Looks good... except one detail: you have "tpacpi::micmute" and
> >>>> "dell::micmute". I know it follows "tradition", but we are trying to
> >>>> fix that at the moment. Laptop micmute button is a laptop micmute
> >>>> button, and userspace should not need to know what prefix to use
> >>>> depending on vendor.
> >>>>
> >>>> I'd suggest using "sys::micmute".
> >>>
> >>> I can imagine that in future some devices like keyboards would have also
> >>> mute led. We already have keyboards with mute key, so it is something
> >>> not unrealistic. What should be name convention for these mute leds?
> >>>
> >>> Is not "sys::" prefix too generic?
> >>
> >> Good point.  I thought of "laptop::" but it's not always laptop.
> >> "builtin::"?  Doesn't sound great, either.
> >>
> >> 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 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.
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]