On Sun, 18 Feb 2007, Richard Purdie wrote:
> I just said that finding a way to do it generically is difficult, not
> that we shouldn't do it.
Very well, let's do it, then.
> Even if half your functionality is exposed through the class, that half
> that is standardised rather than adhoc. Having
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
>
On Fri, 2007-02-16 at 01:12 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Feb 2007, Richard Purdie wrote:
> > 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
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote:
>
> On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote:
> > On Thu, 15 Feb 2007, Richard Purdie wrote:
> > > This has been discussed in several places several times.
> The problem
> > > with hardware accelerated flashing is that
On Sun, Feb 18, 2007 at 08:45:00AM +0100, Németh Márton wrote:
On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote:
On Thu, 15 Feb 2007, Richard Purdie wrote:
This has been discussed in several places several times.
The problem
with hardware accelerated flashing is that you're are
On Fri, 2007-02-16 at 01:12 -0200, Henrique de Moraes Holschuh wrote:
On Thu, 15 Feb 2007, Richard Purdie wrote:
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
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
On Sun, 18 Feb 2007, Richard Purdie wrote:
I just said that finding a way to do it generically is difficult, not
that we shouldn't do it.
Very well, let's do it, then.
Even if half your functionality is exposed through the class, that half
that is standardised rather than adhoc. Having said
On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Feb 2007, Richard Purdie wrote:
> > 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
On Fri, 16 Feb 2007, Henrique de Moraes Holschuh wrote:
On Thu, 15 Feb 2007, Richard Purdie wrote:
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)
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
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
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.
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
On Thu, 15 Feb 2007, Richard Purdie wrote:
> 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
On Fri, 2007-02-16 at 00:24 +0100, Pavel Machek wrote:
> > 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?
The LED class itself can call in interrupt context so you'd have to
Pavel Machek <[EMAIL PROTECTED]> wrote:
> 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
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
On Thu, 2007-02-15 at 23:47 +0100, Németh Márton wrote:
> Pavel Machek <[EMAIL PROTECTED]> 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
On Thu, 15 Feb 2007, Richard Purdie wrote:
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
On Thu, 2007-02-15 at 23:47 +0100, Németh Márton wrote:
Pavel Machek [EMAIL PROTECTED] 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?
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.
Pavel Machek [EMAIL PROTECTED] wrote:
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
On Fri, 2007-02-16 at 00:24 +0100, Pavel Machek wrote:
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?
The LED class itself can call in interrupt context so you'd have to
schedule
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On 2/14/07, Németh Márton <[EMAIL PROTECTED]> wrote:
> >
> >
> > Dmitry Torokhov <[EMAIL PROTECTED]> írta:
> >
> > > On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Extend EV_LED handling code so that it can handle not
> > > >
On 2/14/07, Németh Márton <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov <[EMAIL PROTECTED]> írta:
> On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote:
> >
> > Extend EV_LED handling code so that it can handle not
> > only two states (on/off) but also others. For example
> > a LED can blink
Dmitry Torokhov <[EMAIL PROTECTED]> írta:
> On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote:
> >
> > Extend EV_LED handling code so that it can handle not
> > only two states (on/off) but also others. For example
> > a LED can blink using hardware acceleration. The code
> > changed so that
Dmitry Torokhov [EMAIL PROTECTED] írta:
On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote:
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware acceleration. The code
changed so that it is similar
On 2/14/07, Németh Márton [EMAIL PROTECTED] wrote:
Dmitry Torokhov [EMAIL PROTECTED] írta:
On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote:
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware
Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 2/14/07, Németh Márton [EMAIL PROTECTED] wrote:
Dmitry Torokhov [EMAIL PROTECTED] írta:
On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote:
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also
On 2/11/07, Németh Márton <[EMAIL PROTECTED]> wrote:
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware acceleration. The code
changed so that it is similar to the code at EV_SND.
Hi,
I am not sure we
On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote:
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware acceleration. The code
changed so that it is similar to the code at EV_SND.
Hi,
I am not sure we
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware acceleration. The code
changed so that it is similar to the code at EV_SND.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff -uprN
Extend EV_LED handling code so that it can handle not
only two states (on/off) but also others. For example
a LED can blink using hardware acceleration. The code
changed so that it is similar to the code at EV_SND.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
diff -uprN
34 matches
Mail list logo
