ACPI video.c brightness handler conflicts with toshiba_acpi

ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

I have now two different devices that refer to the same hardware:

lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
lrwxrwxrwx 1 root root 0 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/

Unfortunately, due to ACPI implementation the acpi_video0 one is much
inferior (as it provides only effectively two levels instead of 8);
and user level tools are apparently quite confused which one to select.

Is there any mechanism that would allow tochiba_acpi to claim brightness
for internal LCD screen that video would not attempt to grab it too?

Of course manually disabling brightness handling in video is always possible,
still is nice for this to be handled automatically.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Saturday 06 September 2008, Andrey Borzenkov wrote:
> I have now two different devices that refer to the same hardware:
> 
> lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
> lrwxrwxrwx 1 root root 0 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> 
> Unfortunately, due to ACPI implementation the acpi_video0 one is much
> inferior (as it provides only effectively two levels instead of 8);
> and user level tools are apparently quite confused which one to select.
> 
> Is there any mechanism that would allow tochiba_acpi to claim brightness
> for internal LCD screen that video would not attempt to grab it too?
> 
> Of course manually disabling brightness handling in video is always possible,

Actually it is not. brightness_switch_enabled only disables event handling;
it still resets actual brightness on loading and creates sysfs files to
confuse user space.

> still is nice for this to be handled automatically.
> 



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Thomas Renninger]

On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > I have now two different devices that refer to the same hardware:
> >
> > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> >
> > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > inferior (as it provides only effectively two levels instead of 8);
> > and user level tools are apparently quite confused which one to select.
> >
> > Is there any mechanism that would allow tochiba_acpi to claim brightness
> > for internal LCD screen that video would not attempt to grab it too?
> >
> > Of course manually disabling brightness handling in video is always
> > possible,
>
> Actually it is not. brightness_switch_enabled only disables event handling;
> it still resets actual brightness on loading and creates sysfs files to
> confuse user space.
>
> > still is nice for this to be handled automatically.
It is in latest ACPI test branch queued for 2.6.28.
The problem in bug:
http://bugzilla.kernel.org/show_bug.cgi?id=9614
is another. But the patchset pointed to in comment #43 should fix several, 
also your problem.

If not, please tell me and open a new bug.

Thanks,

       Thomas

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Zhang Rui]

On Sat, 2008-09-06 at 11:08 +0400, Andrey Borzenkov wrote:
> I have now two different devices that refer to the same hardware:
> 
> lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
> lrwxrwxrwx 1 root root 0 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> 
> Unfortunately, due to ACPI implementation the acpi_video0 one is much
> inferior (as it provides only effectively two levels instead of 8);
> and user level tools are apparently quite confused which one to select.
> 
> Is there any mechanism that would allow tochiba_acpi to claim brightness
> for internal LCD screen that video would not attempt to grab it too?
> 
Yes, the patches are in Andi's test tree currently.

please run
#git-clone
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6
acpi_test
#git-branch -r
#git-branch --track test origin/test
#git-checkout test

to get the source code if you want to give it a try. :)

thanks,
rui

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On Monday 08 September 2008, Thomas Renninger wrote:
> On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > I have now two different devices that refer to the same hardware:
> > >
> > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> > >
> > > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > > inferior (as it provides only effectively two levels instead of 8);
> > > and user level tools are apparently quite confused which one to select.
> > >
> > > Is there any mechanism that would allow tochiba_acpi to claim brightness
> > > for internal LCD screen that video would not attempt to grab it too?
> > >
> > > Of course manually disabling brightness handling in video is always
> > > possible,
> >
> > Actually it is not. brightness_switch_enabled only disables event handling;
> > it still resets actual brightness on loading and creates sysfs files to
> > confuse user space.
> >
> > > still is nice for this to be handled automatically.
> It is in latest ACPI test branch queued for 2.6.28.
> The problem in bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=9614
> is another. But the patchset pointed to in comment #43 should fix several, 
> also your problem.
> 
> If not, please tell me and open a new bug.
> 

It was exactly the right one. I'll get a look at adding proper detection
for Toshiba HCI systems. Thank you!

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Monday 08 September 2008, Thomas Renninger wrote:
> On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > I have now two different devices that refer to the same hardware:
> > >
> > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> > >
> > > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > > inferior (as it provides only effectively two levels instead of 8);
> > > and user level tools are apparently quite confused which one to select.
> > >
> > > Is there any mechanism that would allow tochiba_acpi to claim brightness
> > > for internal LCD screen that video would not attempt to grab it too?
> > >
> > > Of course manually disabling brightness handling in video is always
> > > possible,
> >
> > Actually it is not. brightness_switch_enabled only disables event handling;
> > it still resets actual brightness on loading and creates sysfs files to
> > confuse user space.
> >
> > > still is nice for this to be handled automatically.
> It is in latest ACPI test branch queued for 2.6.28.

It is still not in rc2; is it scheduled for 2.6.28 or delayed further?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Thomas Renninger]

On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> On Monday 08 September 2008, Thomas Renninger wrote:
> > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > I have now two different devices that refer to the same hardware:
> > > >
> > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > > > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> > > >
> > > > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > > > inferior (as it provides only effectively two levels instead of 8);
> > > > and user level tools are apparently quite confused which one to
> > > > select.
> > > >
> > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > brightness for internal LCD screen that video would not attempt to
> > > > grab it too?
> > > >
> > > > Of course manually disabling brightness handling in video is always
> > > > possible,
> > >
> > > Actually it is not. brightness_switch_enabled only disables event
> > > handling; it still resets actual brightness on loading and creates
> > > sysfs files to confuse user space.
> > >
> > > > still is nice for this to be handled automatically.
> >
> > It is in latest ACPI test branch queued for 2.6.28.
>
> It is still not in rc2; is it scheduled for 2.6.28 or delayed further?

Right, it's not there.
Len, what happened with the:
"Check for ACPI backlight support otherwise use vendor ACPIdrivers - version 4"
patches?

They are pretty essential for video.ko.
Otherwise graphics devices may get double poked (through vendor_acpi.ko drivers)
or may register for graphics cards which are not there.

    Thomas

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Rafael J. Wysocki]

On Tuesday, 28 of October 2008, Thomas Renninger wrote:
> On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> > On Monday 08 September 2008, Thomas Renninger wrote:
> > > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > > I have now two different devices that refer to the same hardware:
> > > > >
> > > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > > > > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> > > > >
> > > > > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > > > > inferior (as it provides only effectively two levels instead of 8);
> > > > > and user level tools are apparently quite confused which one to
> > > > > select.
> > > > >
> > > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > > brightness for internal LCD screen that video would not attempt to
> > > > > grab it too?
> > > > >
> > > > > Of course manually disabling brightness handling in video is always
> > > > > possible,
> > > >
> > > > Actually it is not. brightness_switch_enabled only disables event
> > > > handling; it still resets actual brightness on loading and creates
> > > > sysfs files to confuse user space.
> > > >
> > > > > still is nice for this to be handled automatically.
> > >
> > > It is in latest ACPI test branch queued for 2.6.28.
> >
> > It is still not in rc2; is it scheduled for 2.6.28 or delayed further?
> 
> Right, it's not there.
> Len, what happened with the:
> "Check for ACPI backlight support otherwise use vendor ACPIdrivers - version 4"
> patches?
> 
> They are pretty essential for video.ko.
> Otherwise graphics devices may get double poked (through vendor_acpi.ko drivers)
> or may register for graphics cards which are not there.

Do you have a pointer to those patches?

Thanks,
Rafael

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Tuesday 28 October 2008, Rafael J. Wysocki wrote:
> On Tuesday, 28 of October 2008, Thomas Renninger wrote:
> > On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> > > On Monday 08 September 2008, Thomas Renninger wrote:
> > > > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > > > I have now two different devices that refer to the same hardware:
> > > > > >
> > > > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root root 0
> > > > > > 2008-09-06 11:04 toshiba -> ../../devices/virtual/backlight/toshiba/
> > > > > >
> > > > > > Unfortunately, due to ACPI implementation the acpi_video0 one is much
> > > > > > inferior (as it provides only effectively two levels instead of 8);
> > > > > > and user level tools are apparently quite confused which one to
> > > > > > select.
> > > > > >
> > > > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > > > brightness for internal LCD screen that video would not attempt to
> > > > > > grab it too?
> > > > > >
> > > > > > Of course manually disabling brightness handling in video is always
> > > > > > possible,
> > > > >
> > > > > Actually it is not. brightness_switch_enabled only disables event
> > > > > handling; it still resets actual brightness on loading and creates
> > > > > sysfs files to confuse user space.
> > > > >
> > > > > > still is nice for this to be handled automatically.
> > > >
> > > > It is in latest ACPI test branch queued for 2.6.28.
> > >
> > > It is still not in rc2; is it scheduled for 2.6.28 or delayed further?
> > 
> > Right, it's not there.
> > Len, what happened with the:
> > "Check for ACPI backlight support otherwise use vendor ACPIdrivers - version 4"
> > patches?
> > 
> > They are pretty essential for video.ko.
> > Otherwise graphics devices may get double poked (through vendor_acpi.ko drivers)
> > or may register for graphics cards which are not there.
> 
> Do you have a pointer to those patches?
> 

So far I am running with these commits from git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:

commit f43d728731c691772ddc29e50d25c68a859935b5
Author: Thomas Renninger <trenn@suse.de>
Date:   Fri Aug 1 17:37:55 2008 +0200

    Check for ACPI backlight support otherwise use vendor ACPI drivers


commit ad9ed8385ed6ec5be8da7094db911c824258ceec
Author: Thomas Renninger <trenn@suse.de>
Date:   Fri Aug 1 17:37:54 2008 +0200

    ACPI: video: Ignore devices that aren't present in hardware

I have been waiting for in-tree inclusion to submit patches for
toshiba_acpi against stable base.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Thomas Renninger]

On Tuesday 28 October 2008 04:15:19 pm Rafael J. Wysocki wrote:
> On Tuesday, 28 of October 2008, Thomas Renninger wrote:
> > On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> > > On Monday 08 September 2008, Thomas Renninger wrote:
> > > > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > > > I have now two different devices that refer to the same hardware:
> > > > > >
> > > > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root
> > > > > > root 0 2008-09-06 11:04 toshiba ->
> > > > > > ../../devices/virtual/backlight/toshiba/
> > > > > >
> > > > > > Unfortunately, due to ACPI implementation the acpi_video0 one is
> > > > > > much inferior (as it provides only effectively two levels instead
> > > > > > of 8); and user level tools are apparently quite confused which
> > > > > > one to select.
> > > > > >
> > > > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > > > brightness for internal LCD screen that video would not attempt
> > > > > > to grab it too?
> > > > > >
> > > > > > Of course manually disabling brightness handling in video is
> > > > > > always possible,
> > > > >
> > > > > Actually it is not. brightness_switch_enabled only disables event
> > > > > handling; it still resets actual brightness on loading and creates
> > > > > sysfs files to confuse user space.
> > > > >
> > > > > > still is nice for this to be handled automatically.
> > > >
> > > > It is in latest ACPI test branch queued for 2.6.28.
> > >
> > > It is still not in rc2; is it scheduled for 2.6.28 or delayed further?
> >
> > Right, it's not there.
> > Len, what happened with the:
> > "Check for ACPI backlight support otherwise use vendor ACPIdrivers -
> > version 4" patches?
> >
> > They are pretty essential for video.ko.
> > Otherwise graphics devices may get double poked (through vendor_acpi.ko
> > drivers) or may register for graphics cards which are not there.
>
> Do you have a pointer to those patches?

I remember they were in Andi's ACPI test branch already.
Andi/Len do you have an idea what happened to them?

   Thomas

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Thomas Renninger]

On Tuesday 28 October 2008 17:22:12 Andrey Borzenkov wrote:
> On Tuesday 28 October 2008, Rafael J. Wysocki wrote:
> > On Tuesday, 28 of October 2008, Thomas Renninger wrote:
> > > On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> > > > On Monday 08 September 2008, Thomas Renninger wrote:
> > > > > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > > > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > > > > I have now two different devices that refer to the same
> > > > > > > hardware:
> > > > > > >
> > > > > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root
> > > > > > > root 0 2008-09-06 11:04 toshiba ->
> > > > > > > ../../devices/virtual/backlight/toshiba/
> > > > > > >
> > > > > > > Unfortunately, due to ACPI implementation the acpi_video0 one
> > > > > > > is much inferior (as it provides only effectively two levels
> > > > > > > instead of 8); and user level tools are apparently quite
> > > > > > > confused which one to select.
> > > > > > >
> > > > > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > > > > brightness for internal LCD screen that video would not attempt
> > > > > > > to grab it too?
> > > > > > >
> > > > > > > Of course manually disabling brightness handling in video is
> > > > > > > always possible,
> > > > > >
> > > > > > Actually it is not. brightness_switch_enabled only disables event
> > > > > > handling; it still resets actual brightness on loading and
> > > > > > creates sysfs files to confuse user space.
> > > > > >
> > > > > > > still is nice for this to be handled automatically.
> > > > >
> > > > > It is in latest ACPI test branch queued for 2.6.28.
> > > >
> > > > It is still not in rc2; is it scheduled for 2.6.28 or delayed
> > > > further?
> > >
> > > Right, it's not there.
> > > Len, what happened with the:
> > > "Check for ACPI backlight support otherwise use vendor ACPIdrivers -
> > > version 4" patches?
> > >
> > > They are pretty essential for video.ko.
> > > Otherwise graphics devices may get double poked (through vendor_acpi.ko
> > > drivers) or may register for graphics cards which are not there.
> >
> > Do you have a pointer to those patches?
>
> So far I am running with these commits from
> git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:
This tree does not exist anymore...

Andrey, do you still have a local copy?
Could you use git format-patch and repost the whole series
(should be about 11 patches) to Len and CC me.
It would be some work for me to recollect everything.

I hope Len is reading that soon and can give a comment why this was
in Andi's, but did not get into his ACPI git tree...

This should directly go into ACPI test branch again.
It would be great if it could still get cherry-picked into .28.

Thanks,

     Thomas

Norbert: I just saw your brightness complains about your Sony on the acpi 
list. You should start testing with the patchset we are talking about here.
video.ko is rather broken without them.

     Thomas

> commit f43d728731c691772ddc29e50d25c68a859935b5
> Author: Thomas Renninger <trenn@suse.de>
> Date:   Fri Aug 1 17:37:55 2008 +0200
>
>     Check for ACPI backlight support otherwise use vendor ACPI drivers
>
>
> commit ad9ed8385ed6ec5be8da7094db911c824258ceec
> Author: Thomas Renninger <trenn@suse.de>
> Date:   Fri Aug 1 17:37:54 2008 +0200
>
>     ACPI: video: Ignore devices that aren't present in hardware
>
> I have been waiting for in-tree inclusion to submit patches for
> toshiba_acpi against stable base.

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 4804 bytes --]

On Wednesday 29 October 2008, Thomas Renninger wrote:
> On Tuesday 28 October 2008 17:22:12 Andrey Borzenkov wrote:
> > On Tuesday 28 October 2008, Rafael J. Wysocki wrote:
> > > On Tuesday, 28 of October 2008, Thomas Renninger wrote:
> > > > On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
> > > > > On Monday 08 September 2008, Thomas Renninger wrote:
> > > > > > On Saturday 06 September 2008 09:19:59 am Andrey Borzenkov wrote:
> > > > > > > On Saturday 06 September 2008, Andrey Borzenkov wrote:
> > > > > > > > I have now two different devices that refer to the same
> > > > > > > > hardware:
> > > > > > > >
> > > > > > > > lrwxrwxrwx 1 root root 0 2008-09-06 11:04 acpi_video0 ->
> > > > > > > > ../../devices/virtual/backlight/acpi_video0/ lrwxrwxrwx 1 root
> > > > > > > > root 0 2008-09-06 11:04 toshiba ->
> > > > > > > > ../../devices/virtual/backlight/toshiba/
> > > > > > > >
> > > > > > > > Unfortunately, due to ACPI implementation the acpi_video0 one
> > > > > > > > is much inferior (as it provides only effectively two levels
> > > > > > > > instead of 8); and user level tools are apparently quite
> > > > > > > > confused which one to select.
> > > > > > > >
> > > > > > > > Is there any mechanism that would allow tochiba_acpi to claim
> > > > > > > > brightness for internal LCD screen that video would not attempt
> > > > > > > > to grab it too?
> > > > > > > >
> > > > > > > > Of course manually disabling brightness handling in video is
> > > > > > > > always possible,
> > > > > > >
> > > > > > > Actually it is not. brightness_switch_enabled only disables event
> > > > > > > handling; it still resets actual brightness on loading and
> > > > > > > creates sysfs files to confuse user space.
> > > > > > >
> > > > > > > > still is nice for this to be handled automatically.
> > > > > >
> > > > > > It is in latest ACPI test branch queued for 2.6.28.
> > > > >
> > > > > It is still not in rc2; is it scheduled for 2.6.28 or delayed
> > > > > further?
> > > >
> > > > Right, it's not there.
> > > > Len, what happened with the:
> > > > "Check for ACPI backlight support otherwise use vendor ACPIdrivers -
> > > > version 4" patches?
> > > >
> > > > They are pretty essential for video.ko.
> > > > Otherwise graphics devices may get double poked (through vendor_acpi.ko
> > > > drivers) or may register for graphics cards which are not there.
> > >
> > > Do you have a pointer to those patches?
> >
> > So far I am running with these commits from
> > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:
> This tree does not exist anymore...
> 
> Andrey, do you still have a local copy?
> Could you use git format-patch and repost the whole series
> (should be about 11 patches) to Len and CC me.

Do you have at least subjects for the patches? I have only
been using the quoted below, so I am not sure which other to pick.
Here is what git log --author=Renninger gives me:

Thu Aug 28 17:26:10 2008 +0200 ACPI video: Debug interface used for error message cleanup
Fri Aug 1 17:37:55 2008 +0200 Check for ACPI backlight support otherwise use vendor ACPI drivers
Fri Aug 1 17:37:54 2008 +0200 ACPI: video: Ignore devices that aren't present in hardware
Mon Jul 23 14:44:41 2007 +0200 ACPI: autoload modules - Create __mod_acpi_device_table symbol for all ACPI drivers
Mon Jun 26 23:58:43 2006 -0400 ACPI: Enable ACPI error messages w/o CONFIG_ACPI_DEBUG
Tue Nov 8 05:27:00 2005 -0500 [ACPI] Fix Null pointer deref in video/lcd/brightness

If you have open git repository, I could probably just push my
linux-acpi branch to you?

> It would be some work for me to recollect everything.
> 
> I hope Len is reading that soon and can give a comment why this was
> in Andi's, but did not get into his ACPI git tree...
> 
> This should directly go into ACPI test branch again.
> It would be great if it could still get cherry-picked into .28.
> 
> Thanks,
> 
>      Thomas
> 
> Norbert: I just saw your brightness complains about your Sony on the acpi 
> list. You should start testing with the patchset we are talking about here.
> video.ko is rather broken without them.
> 
>      Thomas
> 
> > commit f43d728731c691772ddc29e50d25c68a859935b5
> > Author: Thomas Renninger <trenn@suse.de>
> > Date:   Fri Aug 1 17:37:55 2008 +0200
> >
> >     Check for ACPI backlight support otherwise use vendor ACPI drivers
> >
> >
> > commit ad9ed8385ed6ec5be8da7094db911c824258ceec
> > Author: Thomas Renninger <trenn@suse.de>
> > Date:   Fri Aug 1 17:37:54 2008 +0200
> >
> >     ACPI: video: Ignore devices that aren't present in hardware
> >
> > I have been waiting for in-tree inclusion to submit patches for
> > toshiba_acpi against stable base.
> 
> 
> 



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Andi Kleen]

On Wed, Oct 29, 2008 at 04:54:54PM +0100, Thomas Renninger wrote:
> > So far I am running with these commits from
> > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:
> This tree does not exist anymore...

It is now linux-acpi-summer2008-2.6
I renamed to avoid confusion with Len's tree.
But Len should have taken all the patches in there.

-Andi

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Thomas Renninger]

On Wednesday 29 October 2008 06:13:46 pm Andi Kleen wrote:
> On Wed, Oct 29, 2008 at 04:54:54PM +0100, Thomas Renninger wrote:
> > > So far I am running with these commits from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:
> >
> > This tree does not exist anymore...
>
> It is now linux-acpi-summer2008-2.6
> I renamed to avoid confusion with Len's tree.
> But Len should have taken all the patches in there.

Hmm, looks like he did not.
Thanks for the pointer to the old tree, that made things easy.
I am going to post them to Len privately for inclusion into his test branch 
for now, there should be no need to post them on several lists a fifth 
time...
Let's see whether they still pop up in his next pull request for .28, 
hopefully they do...

Thanks,

      Thomas

Re: ACPI video.c brightness handler conflicts with toshiba_acpi

[Len Brown]

> > Do you have a pointer to those patches?
> > 
> 
> So far I am running with these commits from git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6:
> 
> commit f43d728731c691772ddc29e50d25c68a859935b5
> Author: Thomas Renninger <trenn@suse.de>
> Date:   Fri Aug 1 17:37:55 2008 +0200
> 
>     Check for ACPI backlight support otherwise use vendor ACPI drivers
> 
> 
> commit ad9ed8385ed6ec5be8da7094db911c824258ceec
> Author: Thomas Renninger <trenn@suse.de>
> Date:   Fri Aug 1 17:37:54 2008 +0200
> 
>     ACPI: video: Ignore devices that aren't present in hardware
> 
> I have been waiting for in-tree inclusion to submit patches for
> toshiba_acpi against stable base.

Ah, the commit id's above solved the mystery.
It looks like andi checked these patches directly into his
"test" branch rather than a topic branch.  eg. they were
sitting on top of the old pcc_acpi driver etc.

So I lost them when I deleted the old test branch
in order to merge the updated topic branches
into a new test branch.

-Len