Re: [PATCH] input: extend EV_LED

Hi!

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.

Even if that function is slow and sleeps?

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.

I do not think we want to permit this led to run in "not accelerated"
mode. I believe i8042 accesses are pretty expensive.

Nether patch exists yet.

Yep, interested party should create one of them :-). (And I'd prefer
the first one, due to i8042 slowness).

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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] input: extend EV_LED
    ... hardware can do, especially when that means bothering the EC with a slow ... (e.g. it is all a ThinkPad and most WiFi/network card leds need). ... the LED so what we need is an LED blink trigger. ... could use to turn on the "hardware acceleration" if present and capable ...
    (Linux-Kernel)
  • Re: [PATCH] input: extend EV_LED
    ... provide custom attributes on top of the led class, ... hardware can do, especially when that means bothering the EC with a slow ... (e.g. it is all a ThinkPad and most WiFi/network card leds need). ... could use to turn on the "hardware acceleration" if present and capable ...
    (Linux-Kernel)
  • 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
    ... I'm actually not sure if led framework can do that. ... designed for leds on gpios, ... Does it mean that neither the input subsystem nor the led ... subsystem is designed for hardware acelerated blinking leds? ...
    (Linux-Kernel)