2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Soeren Sonnenburg]

Dear all,

I am wondering whether the change from 

/sys/devices/platform/applesmc.768/leds/smc:kbd_backlight  (2.6.24) 
/sys/devices/platform/applesmc.768/leds/smc::kbd_backlight (2.6.25)

is intentional?

I recognized that it breaks current userspace applications changing the
keyboard background leds like pommed...

Soeren

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Soeren Sonnenburg]

On Wed, 2008-04-02 at 20:58 +0200, Soeren Sonnenburg wrote:
> Dear all,
> 
> I am wondering whether the change from 
> 
> /sys/devices/platform/applesmc.768/leds/smc:kbd_backlight  (2.6.24) 
> /sys/devices/platform/applesmc.768/leds/smc::kbd_backlight (2.6.25)
> 
> is intentional?
> 
> I recognized that it breaks current userspace applications changing the
> keyboard background leds like pommed...

OK it looks like commit 6c152beefbf90579d21afc4f7e075b1f801f9a75 from
Richard Purdie, 'leds: Standardise LED naming scheme' introduced this
change.

Why do we need '::' instead of a single ':' (that would not have broken
things)?

Also sometimes only a single ':' seperator is used like in
corgi:green:mail but e.g. not in clevo::mail ?!

Soeren

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Justin Mattock]

Hello; I noticed this as well, you loose the greatest feature; the
cool leds lights on the keyboard with the macbook pro,
A solution that worked for me was to compile pommed from the source
and edit kbd_backlight.h
regards;
               Justin P. Mattock

On Fri, Apr 4, 2008 at 6:54 AM, Soeren Sonnenburg <kernel@nn7.de> wrote:
> On Wed, 2008-04-02 at 20:58 +0200, Soeren Sonnenburg wrote:
>  > Dear all,
>  >
>  > I am wondering whether the change from
>  >
>  > /sys/devices/platform/applesmc.768/leds/smc:kbd_backlight  (2.6.24)
>  > /sys/devices/platform/applesmc.768/leds/smc::kbd_backlight (2.6.25)
>  >
>  > is intentional?
>  >
>  > I recognized that it breaks current userspace applications changing the
>  > keyboard background leds like pommed...
>
>  OK it looks like commit 6c152beefbf90579d21afc4f7e075b1f801f9a75 from
>  Richard Purdie, 'leds: Standardise LED naming scheme' introduced this
>  change.
>
>  Why do we need '::' instead of a single ':' (that would not have broken
>  things)?
>
>  Also sometimes only a single ':' seperator is used like in
>  corgi:green:mail but e.g. not in clevo::mail ?!
>
>  Soeren
>  --
>  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/
>



-- 
Justin P. Mattock

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Soeren Sonnenburg]

On Fri, 2008-04-04 at 15:12 +0000, Justin Mattock wrote:
> Hello; I noticed this as well, you loose the greatest feature; the
> cool leds lights on the keyboard with the macbook pro,
> A solution that worked for me was to compile pommed from the source
> and edit kbd_backlight.h
> regards;
>                Justin P. Mattock

Yeah, but it will not only affect pommed... and I don't see the
rationale of introducing :: to separate things... so I think we should
have another patch replacing the :: with ':' again to unbreak userspace
for 2.6.25.

Could someone more official please respond to this regression (CCing
Rafael to record it)

Soeren

> On Fri, Apr 4, 2008 at 6:54 AM, Soeren Sonnenburg <kernel@nn7.de> wrote:
> > On Wed, 2008-04-02 at 20:58 +0200, Soeren Sonnenburg wrote:
> >  > Dear all,
> >  >
> >  > I am wondering whether the change from
> >  >
> >  > /sys/devices/platform/applesmc.768/leds/smc:kbd_backlight  (2.6.24)
> >  > /sys/devices/platform/applesmc.768/leds/smc::kbd_backlight (2.6.25)
> >  >
> >  > is intentional?
> >  >
> >  > I recognized that it breaks current userspace applications changing the
> >  > keyboard background leds like pommed...
> >
> >  OK it looks like commit 6c152beefbf90579d21afc4f7e075b1f801f9a75 from
> >  Richard Purdie, 'leds: Standardise LED naming scheme' introduced this
> >  change.
> >
> >  Why do we need '::' instead of a single ':' (that would not have broken
> >  things)?
> >
> >  Also sometimes only a single ':' seperator is used like in
> >  corgi:green:mail but e.g. not in clevo::mail ?!
> >
> >  Soeren
> >  --
> >  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/
> >
> 
> 
> 

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Justin Mattock]

Hello; there must be some kind of reason for the change from ":" to
"::" smc::kbd_backlight, maybee something with the kernel spitting
out:

[  464.524630] applesmc: wait status failed: 5 != 4
[  464.727477] applesmc: wait status failed: c != 8
[  606.219666] applesmc: wait status failed: 5 != 4
[  606.421338] applesmc: wait status failed: c != 8
[  656.152925] applesmc: wait status failed: 5 != 4
[  656.358032] applesmc: wait status failed: c != 8
[  743.488092] applesmc: wait status failed: 5 != 4
[  743.687861] applesmc: wait status failed: c != 8
[ 1559.745211] applesmc: wait status failed: 5 != 4
[ 1559.946876] applesmc: wait status failed: c != 8
[ 1617.527543] applesmc: wait status failed: 5 != 4
[ 1617.733097] applesmc: wait status failed: c != 8
[ 1855.794475] applesmc: wait status failed: 5 != 4
[ 1855.997410] applesmc: wait status failed: c != 8
[ 2062.038870] applesmc: wait status failed: 5 != 4
[ 2062.240451] applesmc: wait status failed: c != 8
[ 2145.673882] applesmc: wait status failed: 5 != 4
[ 2145.874891] applesmc: wait status failed: c != 8
[ 2226.070113] applesmc: wait status failed: 5 != 4
[ 2226.275480] applesmc: wait status failed: c != 8
[ 2233.295702] applesmc: wait status failed: 5 != 4
[ 2233.501599] applesmc: wait status failed: c != 8
[ 2490.349096] applesmc: wait status failed: 5 != 4
[ 2490.554648] applesmc: wait status failed: c != 8
[ 2526.524932] applesmc: wait status failed: 5 != 4
[ 2526.727963] applesmc: wait status failed: c != 8
[ 2994.653714] applesmc: wait status failed: 5 != 4
[ 2994.856479] applesmc: wait status failed: c != 8
[ 3556.760811] applesmc: wait status failed: 5 != 4
[ 3556.960414] applesmc: wait status failed: c != 8
[ 4104.040447] applesmc: wait status failed: 5 != 4
[ 4104.241539] applesmc: wait status failed: c != 8
[ 4183.083313] applesmc: wait status failed: 5 != 4
[ 4183.283102] applesmc: wait status failed: c != 8
[ 4405.815336] applesmc: wait status failed: 5 != 4
[ 4406.013374] applesmc: wait status failed: c != 8
[ 4828.790663] applesmc: wait status failed: 5 != 4
[ 4828.990296] applesmc: wait status failed: c != 8
[ 5001.422026] applesmc: wait status failed: 5 != 4
[ 5001.624074] applesmc: wait status failed: c != 8
[ 5054.881643] applesmc: wait status failed: 5 != 4
[ 5055.085512] applesmc: wait status failed: c != 8
[ 5091.950244] applesmc: wait status failed: 5 != 4
[ 5092.153377] applesmc: wait status failed: c != 8
[ 5142.416144] applesmc: wait status failed: 5 != 4
[ 5142.619838] applesmc: wait status failed: c != 8
[ 5201.180057] applesmc: wait status failed: 5 != 4
[ 5201.378893] applesmc: wait status failed: c != 8
[ 6071.409386] applesmc: wait status failed: 5 != 4
[ 6071.611533] applesmc: wait status failed: c != 8
[ 6563.512077] applesmc: wait status failed: 5 != 4
[ 6563.711152] applesmc: wait status failed: c != 8
[ 6775.019376] applesmc: wait status failed: 5 != 4
[ 6775.218753] applesmc: wait status failed: c != 8
[ 7028.430958] applesmc: wait status failed: 5 != 4
[ 7028.631925] applesmc: wait status failed: c != 8
[ 7069.534835] applesmc: wait status failed: 5 != 4
[ 7069.734629] applesmc: wait status failed: c != 8
[ 7222.764415] applesmc: wait status failed: 5 != 4
[ 7222.964181] applesmc: wait status failed: c != 8
[ 7229.991367] applesmc: wait status failed: 5 != 4
[ 7230.194062] applesmc: wait status failed: c != 8
[ 7250.619742] applesmc: wait status failed: 5 != 5
[ 7250.819656] applesmc: wait status failed: c != 8
[ 7890.440161] applesmc: wait status failed: 5 != 4
[ 7890.641210] applesmc: wait status failed: c != 8
[ 8048.801254] applesmc: wait status failed: 5 != 4
[ 8049.001035] applesmc: wait status failed: c != 8
[ 8170.854568] applesmc: wait status failed: 5 != 4
[ 8171.059915] applesmc: wait status failed: c != 8
[ 8747.146058] applesmc: wait status failed: 5 != 4
[ 8747.345261] applesmc: wait status failed: c != 8
[ 9034.362620] applesmc: wait status failed: 5 != 4
[ 9034.568220] applesmc: wait status failed: c != 8

I'm tired of seeing this, how to get rid of this regression if you
want to call this that.?
regards;
               Justin P. Mattock

On Sat, Apr 5, 2008 at 5:32 AM, Soeren Sonnenburg <kernel@nn7.de> wrote:
> On Fri, 2008-04-04 at 15:12 +0000, Justin Mattock wrote:
>  > Hello; I noticed this as well, you loose the greatest feature; the
>  > cool leds lights on the keyboard with the macbook pro,
>  > A solution that worked for me was to compile pommed from the source
>  > and edit kbd_backlight.h
>  > regards;
>  >                Justin P. Mattock
>
>  Yeah, but it will not only affect pommed... and I don't see the
>  rationale of introducing :: to separate things... so I think we should
>  have another patch replacing the :: with ':' again to unbreak userspace
>  for 2.6.25.
>
>  Could someone more official please respond to this regression (CCing
>  Rafael to record it)
>
>  Soeren
>
>  > On Fri, Apr 4, 2008 at 6:54 AM, Soeren Sonnenburg <kernel@nn7.de> wrote:
>  > > On Wed, 2008-04-02 at 20:58 +0200, Soeren Sonnenburg wrote:
>  > >  > Dear all,
>  > >  >
>  > >  > I am wondering whether the change from
>  > >  >
>  > >  > /sys/devices/platform/applesmc.768/leds/smc:kbd_backlight  (2.6.24)
>  > >  > /sys/devices/platform/applesmc.768/leds/smc::kbd_backlight (2.6.25)
>  > >  >
>  > >  > is intentional?
>  > >  >
>  > >  > I recognized that it breaks current userspace applications changing the
>  > >  > keyboard background leds like pommed...
>  > >
>  > >  OK it looks like commit 6c152beefbf90579d21afc4f7e075b1f801f9a75 from
>  > >  Richard Purdie, 'leds: Standardise LED naming scheme' introduced this
>  > >  change.
>  > >
>  > >  Why do we need '::' instead of a single ':' (that would not have broken
>  > >  things)?
>  > >
>  > >  Also sometimes only a single ':' seperator is used like in
>  > >  corgi:green:mail but e.g. not in clevo::mail ?!
>  > >
>  > >  Soeren
>  > >  --
>  > >  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/
>  > >
>  >
>  >
>  >
>



-- 
Justin P. Mattock

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Soeren Sonnenburg]

On Sat, 2008-04-05 at 06:44 +0000, Justin Mattock wrote:
> Hello; there must be some kind of reason for the change from ":" to
> "::" smc::kbd_backlight, maybee something with the kernel spitting
> out:
> 
> [  464.524630] applesmc: wait status failed: 5 != 4
[...]

> I'm tired of seeing this, how to get rid of this regression if you
> want to call this that.?
> regards;

The '::' is only a cosmetic thing and won't give you these messages.
Anyway I am getting them too (but very very rarely) - but it is a
completely different issue.

Soeren

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Richard Purdie]

On Sat, 2008-04-05 at 07:32 +0200, Soeren Sonnenburg wrote:
> On Fri, 2008-04-04 at 15:12 +0000, Justin Mattock wrote:
> > Hello; I noticed this as well, you loose the greatest feature; the
> > cool leds lights on the keyboard with the macbook pro,
> > A solution that worked for me was to compile pommed from the source
> > and edit kbd_backlight.h
> > regards;
> >                Justin P. Mattock
> 
> Yeah, but it will not only affect pommed... and I don't see the
> rationale of introducing :: to separate things... so I think we should
> have another patch replacing the :: with ':' again to unbreak userspace
> for 2.6.25.
> 
> Could someone more official please respond to this regression (CCing
> Rafael to record it)

Basically the LED names were a mess, there is a documented standard
which has been there since the beginning (Documentation/leds-class.txt)
and a number of drivers didn't follow that. That standardisation commit
was an attempt to deal with this problem once and for all and in that
sense its a bugfix, not a regression. The fact function wasn't part of
the original naming scheme was a mistake (see previous discussions on
LKML) which we're trying to address without breaking the documented
standard. The side effect is that some existing drivers need to be
updated to match the documentation (and should never have been merged in
the first place because of that) :(.

Regards,

Richard

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Soeren Sonnenburg]

On Sat, 2008-04-05 at 11:42 +0100, Richard Purdie wrote:
> On Sat, 2008-04-05 at 07:32 +0200, Soeren Sonnenburg wrote:
> > On Fri, 2008-04-04 at 15:12 +0000, Justin Mattock wrote:
> > > Hello; I noticed this as well, you loose the greatest feature; the
> > > cool leds lights on the keyboard with the macbook pro,
> > > A solution that worked for me was to compile pommed from the source
> > > and edit kbd_backlight.h
> > > regards;
> > >                Justin P. Mattock
> > 
> > Yeah, but it will not only affect pommed... and I don't see the
> > rationale of introducing :: to separate things... so I think we should
> > have another patch replacing the :: with ':' again to unbreak userspace
> > for 2.6.25.
> > 
> > Could someone more official please respond to this regression (CCing
> > Rafael to record it)
> 
> Basically the LED names were a mess, there is a documented standard
> which has been there since the beginning (Documentation/leds-class.txt)
> and a number of drivers didn't follow that. That standardisation commit
> was an attempt to deal with this problem once and for all and in that
> sense its a bugfix, not a regression. The fact function wasn't part of
> the original naming scheme was a mistake (see previous discussions on
> LKML) which we're trying to address without breaking the documented
> standard. The side effect is that some existing drivers need to be
> updated to match the documentation (and should never have been merged in
> the first place because of that) :(.

So to make it clear "devicename:colour:function" means in the case of
applesmc smc::kbd_backlight because there is no colour defined. One
could have used "devicename:function:colour" without breaking things -
no ?

So it seems we will have to file bug reports to the led dealing
userspace programs ...

Soeren

Re: 2.6.25 intended change: smc:kbd_backlight vs. smc::kbd_backlight ?

[Richard Purdie]

On Sat, 2008-04-05 at 17:33 +0200, Soeren Sonnenburg wrote:
> On Sat, 2008-04-05 at 11:42 +0100, Richard Purdie wrote:
> > Basically the LED names were a mess, there is a documented standard
> > which has been there since the beginning (Documentation/leds-class.txt)
> > and a number of drivers didn't follow that. That standardisation commit
> > was an attempt to deal with this problem once and for all and in that
> > sense its a bugfix, not a regression. The fact function wasn't part of
> > the original naming scheme was a mistake (see previous discussions on
> > LKML) which we're trying to address without breaking the documented
> > standard. The side effect is that some existing drivers need to be
> > updated to match the documentation (and should never have been merged in
> > the first place because of that) :(.
> 
> So to make it clear "devicename:colour:function" means in the case of
> applesmc smc::kbd_backlight because there is no colour defined. One
> could have used "devicename:function:colour" without breaking things -
> no ?

No, since devicename:colour was there from the start and the
documentation said we could append to it.

> So it seems we will have to file bug reports to the led dealing
> userspace programs ...

I'm afraid so, not ideal but we need to get this sorted out properly
once and for all.

Regards,

Richard