linux-kernel - Re: [PATCH 2/2] input: Add LED support to Synaptics device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hbpddz58s.wl%tiwai@suse.de>
Date:	Wed, 21 Apr 2010 08:31:15 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Pavel Machek <pavel@....cz>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] input: Add LED support to Synaptics device

At Tue, 20 Apr 2010 22:43:03 -0700,
Dmitry Torokhov wrote:
> 
> On Mon, Apr 19, 2010 at 12:44:08PM +0200, Takashi Iwai wrote:
> > At Fri, 16 Apr 2010 10:00:20 +0200,
> > I wrote:
> > > 
> > > At Thu, 15 Apr 2010 21:12:18 +0200,
> > > Pavel Machek wrote:
> > > > 
> > > > Hi!
> > > > 
> > > > > The new Synaptics devices have an LED on the top-left corner.
> > > > > This is controlled via the command 0x0a with parameters 0x88 or 0x10.
> > > > > 
> > > > > The detection of the LED isn't clear yet.  It should have been the new
> > > > > capability bits that indicate the presence, but on real machines, it
> > > > > doesn't fit.  So, for the time being, the driver checks the product id
> > > > > in the ext capability bits and assumes that LED exists on the known
> > > > > devices.
> > > > > 
> > > > > The support of LED is controlled via a normal input event with EV_LED
> > > > > bit mask.  It supports LED_MUTE bit.  X driver can detect the LED
> > > > > support by checking these bits.
> > > > 
> > > > Could we use generic LED API for this?
> > > 
> > > Yeah, actually I started implementing with LED ADI at first.
> > > 
> > > But, then it turned out to be that it's much easier to use the
> > > existing LED input bits since this LED is really tightly coupled with
> > > the synaptics input device.  An individual LED device makes hard to
> > > find out the corresponding input device.
> > > 
> > > If we assume there is only one synaptics and only one synaptics-LED
> > > device, then yes, the situation can be a bit easier, though.
> > > 
> > > > It is not really 'mute' led after all...
> > > 
> > > If the problem is the misuse of LED_MUTE bit, how about adding a new
> > > LED bit, e.g. LED_TOUCHPAD?
> > 
> > The revised patch with an addition of LED_TOUCHPAD is below.
> > 
> 
> Sorry Takashi, but I will not add any new LED types to input. Even
> current input LEDs are going to be accessible thought standard LED
> framework (even though I have not apploed Samuel's patch yet I do think
> it would move kernel in the right direction).

Hrm, OK, we can live in other way, too.  For touchpad, it wouldn't be
a big problem because it's likely a single device.

But, how can we link a led class device and another device, in
general?

Also, another remaining question is the lifetime of led device.
The mouse device tends to be re-assigned often, e.g. at each time you
suspend/hibernate.  Should led device also be removed and revived at
each time, or should we keep it and just ignore event?  If we remove
it, how can we avoid race?


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/