linux-kernel - Re: [PATCH] input: extend EV

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]

Date:	Sun, 18 Feb 2007 11:12:41 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	Németh Márton <nm127@...email.hu>
Cc:	Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: extend EV_LED

On Sun, 2007-02-18 at 08:45 +0100, Németh Márton wrote:
> A blinking led is basically a PWM (Pulse Width Modulation)
> signal. A PWM signal has three different attribute. The
> first one is the amplitude, this attribute is already
> provided by the led subsystem as "brightness". There are two
> more attributes, which are the frequency [Hz] and the duty
> cycle [%], or the on-time [ms] and off-time [ms].
> 
> The frequency [Hz] and duty cycle [%] parameters has the
> problem, that if we are limited to integers, it is not
> possible to express slower blinks than 1Hz. We could also
> use [mHz] (milli-Hertz), but it is not very common unit.
> 
> The on-time [ms] and off-time [ms] seems to be easier to
> handle (and this is also easier to simulate from software if
> ever needed). An RO attribute could be introduced:
> 'pwm_available', which can contain parameter pairs separated
> by space, and the new parameter pair is in new line. An RW
> attribute 'pwm' could accept a parameter pair separated by
> space.

We already have a timer trigger which takes an on time and an off time
for the reason you mention above (floating point would get ugly).

The problem is mainly about finding ways to enable hardware acceleration
of the existing timer trigger (where possible) and maybe implementing a
simpler blink trigger which could be hardware accelerated when the full
blown timer trigger couldn't. 

Regards,

Richard

-
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/