Re: [PATCH] input: extend EV_LED

On Thu, 2007-02-15 at 23:47 +0100, Németh Márton wrote:
Pavel Machek <pavel@xxxxxx> wrote:
I do not know the LED subsystem in detail, but I do not
know any possibility to access the i8042 from different
subsystem than the input subsystem.

What do you think and recommend?

I think you need to use leds framework for what you are
trying to do.

I'm actually not sure if led framework can do that. It was
designed for leds on gpios, and handles blinking itself.

The led framework is generic. If you can write a function to turn it
on/off you can drive it with the LED framework.

But he could export two leds :-).

what do you mean about two leds? The first one would be
off/0.5Hz and the other off/1Hz?

I read in linux/Documentation/led-class.txt the following:

| Some leds can be programmed to flash in hardware. As this
isn't a generic
| LED device property, this should be exported as a device
specific sysfs
| attribute rather than part of the class if this
functionality is required.

Does it mean that neither the input subsystem nor the led
subsystem is designed for hardware acelerated blinking leds?
Is there any usual way what attribute a hw accelerated
blinking LED_MAIL should export?

This has been discussed in several places several times. The problem
with hardware accelerated flashing is that you're are often limited to
certain constraints (this case being no exception) and indicating what
these are to userspace in a generic fashion is difficult.

One way I've come up with is adds capability to the class to have LED
specific triggers and you can then expose these hardware capabilities as
an extra trigger specific to the LED.

Another proposal more specific to this use case was to have some
information behind the scenes which the software timer based trigger
could use to turn on the "hardware acceleration" if present and capable
of the requested mode. This might just need a function pointer in the
core so could be quite neat.

Nether patch exists yet.

Cheers,

Richard


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

Relevant Pages

  • Re: PATCH : LEDs - possibly the most pointless kernel subsystemever
    ... Why would output devices be ... > Perhaps because the input subsystem could/should be renamed to event ... LEDs provided by other subsystems to the generic interface, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [PATCH] fujtisu application panel driver
    ... The original driver used ioctl's and a separate ... LEDs shoud use the generic led subsystem instead of input layer. ... input subsystem, and no application support for mail led through LED ... No, this drivers mapping table is from bits to key codes, not scan codes to keycodes. ...
    (Linux-Kernel)
  • Re: [PATCH] input: extend EV_LED
    ... But he could export two leds :-). ... | LED device property, this should be exported as a device ... Does it mean that neither the input subsystem nor the led ... subsystem is designed for hardware acelerated blinking leds? ...
    (Linux-Kernel)
  • Re: [PATCH] input: extend EV_LED
    ... designed for leds on gpios, ... Does it mean that neither the input subsystem nor the led ... subsystem is designed for hardware acelerated blinking leds? ... could use to turn on the "hardware acceleration" if present and capable ...
    (Linux-Kernel)
  • Re: PATCH : LEDs - possibly the most pointless kernel subsystemever
    ... >> Better question is why it is not integrated with input subsystem ... (similar to kbd leds). ... Why would output devices be ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)