Messages in this thread | | | Date | Fri, 16 Feb 2007 00:24:38 +0100 | From | Pavel Machek <> | Subject | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |