ACPI video.c brightness handler conflicts with toshiba_acpi
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.
Quoted 5 lines · Andrey Borzenkov
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/
Quoted 8 lines
Unfortunately, due to ACPI implementation the
acpi_video0one 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_acpito 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.
Quoted 2 lines
still is nice for this to be handled automatically.
Quoted 14 lines · Andrey Borzenkov
Quoted 13 lines · Andrey Borzenkov
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_video0one 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_acpito claim brightness for internal LCD screen that video would not attempt to grab it too?
Quoted 8 lines
Quoted 2 lines
Of course manually disabling brightness handling in video is always possible,
Actually it is not.
brightness_switch_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 1 line
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
Quoted 22 lines · Thomas Renninger
Quoted 21 lines · Andrey Borzenkov
Quoted 10 lines · Andrey Borzenkov
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_video0one 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.Quoted 5 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.
Quoted 9 lines
Quoted 1 line
Quoted 1 line
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!
Quoted 18 lines · Thomas Renninger
Quoted 17 lines · Andrey Borzenkov
Quoted 15 lines · Andrey Borzenkov
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_video0one 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_acpito 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,
Quoted 6 lines
Quoted 5 lines
Actually it is not.
brightness_switch_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 1 line
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?
Quoted 25 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 24 lines · Thomas Renninger
Quoted 23 lines · Andrey Borzenkov
Quoted 11 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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
Quoted 32 lines · Thomas Renninger
Quoted 25 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 24 lines · Thomas Renninger
Quoted 23 lines · Andrey Borzenkov
Quoted 11 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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?
Quoted 8 lines
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
Quoted 38 lines · Rafael J. Wysocki
Quoted 37 lines · Thomas Renninger
Quoted 25 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 24 lines · Thomas Renninger
Quoted 23 lines · Andrey Borzenkov
Quoted 11 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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?
Quoted 6 lines
Quoted 3 lines
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 <[email protected]> Date: Fri Aug 1 17:37:55 2008 +0200
Check for ACPI backlight support otherwise use vendor ACPI drivers
commit ad9ed8385ed6ec5be8da7094db911c824258ceec
Author: Thomas Renninger <[email protected]> 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.
Quoted 42 lines · On Tuesday 28 October 2008 17:22:12 Andrey Borzenkov wrote:
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Thomas Renninger
Quoted 27 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 26 lines · Thomas Renninger
Quoted 25 lines · Andrey Borzenkov
Quoted 13 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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?
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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
Quoted 15 lines
commit
f43d728731c691772ddc29e50d25c68a859935b5Author: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:55 2008 +0200Check for ACPI backlight support otherwise use vendor ACPI drivers
commit
ad9ed8385ed6ec5be8da7094db911c824258ceecAuthor: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:54 2008 +0200ACPI: video: Ignore devices that aren't present in hardware
I have been waiting for in-tree inclusion to submit patches for
toshiba_acpiagainst stable base.
Quoted 49 lines · Thomas Renninger
Quoted 48 lines · On Tuesday 28 October 2008 17:22:12 Andrey Borzenkov wrote:
Quoted 46 lines · Rafael J. Wysocki
Quoted 35 lines · Thomas Renninger
Quoted 27 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 26 lines · Thomas Renninger
Quoted 25 lines · Andrey Borzenkov
Quoted 13 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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?
Quoted 8 lines
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?
Quoted 7 lines
Quoted 2 lines
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?
Quoted 36 lines
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
Quoted 15 lines
commit
f43d728731c691772ddc29e50d25c68a859935b5Author: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:55 2008 +0200Check for ACPI backlight support otherwise use vendor ACPI drivers
commit
ad9ed8385ed6ec5be8da7094db911c824258ceecAuthor: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:54 2008 +0200ACPI: video: Ignore devices that aren't present in hardware
I have been waiting for in-tree inclusion to submit patches for
toshiba_acpiagainst stable base.
Quoted 3 lines · Thomas Renninger
Quoted 2 lines
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
Quoted 9 lines · Andi Kleen
Quoted 4 lines · Thomas Renninger
Quoted 2 lines
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
Len Brown
reviewerQuoted 14 lines
Quoted 4 lines
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
f43d728731c691772ddc29e50d25c68a859935b5Author: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:55 2008 +0200Check for ACPI backlight support otherwise use vendor ACPI drivers
Quoted 8 lines
commit
ad9ed8385ed6ec5be8da7094db911c824258ceecAuthor: Thomas Renninger <[email protected]> Date: Fri Aug 1 17:37:54 2008 +0200ACPI: video: Ignore devices that aren't present in hardware
I have been waiting for in-tree inclusion to submit patches for
toshiba_acpiagainst 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
Quoted 39 lines · Rafael J. Wysocki
Quoted 38 lines · Thomas Renninger
Quoted 26 lines · On Monday 27 October 2008 17:52:55 Andrey Borzenkov wrote:
Quoted 25 lines · Thomas Renninger
Quoted 24 lines · Andrey Borzenkov
Quoted 12 lines · Andrey Borzenkov
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_video0one 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.Quoted 6 lines
Is there any mechanism that would allow
tochiba_acpito 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_enabledonly disables event handling; it still resets actual brightness on loading and creates sysfs files to confuse user space.Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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?
Quoted 5 lines
Quoted 3 lines
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
Quoted 5 lines · Andrey Borzenkov
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/
Quoted 7 lines
Unfortunately, due to ACPI implementation the
acpi_video0one 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_acpito 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-clonegit://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6acpi_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