Bug 1944 - ACPI Extensions for Display Adapters
ACPI Extensions for Display Adapters
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Video
i386 Linux
: P2 normal
Assigned To: Luming Yu
:
: 1878 1943 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-23 14:30 UTC by Len Brown
Modified: 2004-11-15 20:11 UTC (History)
12 users (show)

See Also:
Kernel Version: 2.6.0-test10
Tree: Mainline
Regression: ---


Attachments
First try to implement an ACPI Extensions for Display Adapters. (7.34 KB, patch)
2004-02-12 12:09 UTC, Bruno Ducrot
Details | Diff
A README for the previous patch. (6.41 KB, text/plain)
2004-02-12 12:11 UTC, Bruno Ducrot
Details
First try to implement an ACPI Extensions for Display Adapters (38.74 KB, patch)
2004-02-12 12:13 UTC, Bruno Ducrot
Details | Diff
Mail with problem description & further info (27.83 KB, text/plain)
2004-02-12 14:24 UTC, Georg Greve
Details
dsdt binary for Toshiba Libretto L5 (17.36 KB, application/octet-stream)
2004-02-12 18:55 UTC, John Belmonte
Details
The acpidmp output of a Fujitsu Lifebook p2110 (48.94 KB, text/plain)
2004-07-26 18:35 UTC, Wayne Wylupski
Details
video extension patch against Bruno Ducrot's (30.00 KB, patch)
2004-09-07 02:08 UTC, Luming Yu
Details | Diff
updated version (53.74 KB, patch)
2004-10-08 23:39 UTC, Luming Yu
Details | Diff

Description Len Brown 2004-01-23 14:30:59 UTC
Systems containing a built-in display adapter are requred to implement the ACPI Extensions for 
Display Adapters. -- ACPI Spec 2.0c appendix B. 
 
These extensions involved brightness control, device switching, and power state support. 
 
Currently, some of these features are implemented in the asus_extras and toshiba_extras 
drivers.  A generic drivers/acpi/video.c driver should be created to support these features on all 
vendors platforms.  When it is available, that functionality should be removed from the asus and 
toshiba specific drivers.
Comment 1 Len Brown 2004-01-23 14:31:40 UTC
*** Bug 1943 has been marked as a duplicate of this bug. ***
Comment 2 Karol Kozimor 2004-01-23 15:38:52 UTC
Yes, it certainly does, I remember even suggesting such an abstraction a long
time ago, when I bumped upon this part of the spec, but then decided to do the
display output switching in a way that looked cleaner.

What strikes me as the possible problem is that we can't really rely on the
specification: my machine only has _DOS (partially implemented), _DOD (looks
sane) and per-output-device _ADR, _DCS, _DGS and _DSS (which also seem sane).
The fact is that due to the reasons stated above, I didn't even take care to
test those methods.

Another thing is to parse the DSDT in order to find the proper device -- there
doesn't seem to be any specific _HID value we could bind a driver to that would
be associated with the display adapter.

Then, finally, I've had enough problems with the ASUS-specific SDSP method which
is supposed to switch display output, but for obscure reasons works only on some
hardware. Thus, I'm not really very optimistic.

However, such an abstraction would certainly be good to have -- asus_acpi would
require a bit of cleanups and a global structure for the necessary functions to
be exported -- that's not a problem. The idea is, should this video.c be an
ACPI-specific thing, or perhaps a more general kernel/power/ bit that other
drivers (notably console / fb or X) could use?
Comment 3 Bruno Ducrot 2004-02-12 12:09:19 UTC
Created attachment 2097 [details]
First try to implement an ACPI Extensions for Display Adapters.
Comment 4 Bruno Ducrot 2004-02-12 12:11:04 UTC
Created attachment 2098 [details]
A README for the previous patch.
Comment 5 Bruno Ducrot 2004-02-12 12:13:48 UTC
Created attachment 2099 [details]
First try to implement an ACPI Extensions for Display Adapters

First try to implement an ACPI Extensions for Display Adapters

Resend, apparently bz2 files are not correct ?
Comment 6 Georg Greve 2004-02-12 14:24:55 UTC
Created attachment 2100 [details]
Mail with problem description & further info

Tried it with Kernel 2.6.2 on ASUS M2N -- no success yet.
Comment 7 John Belmonte 2004-02-12 17:40:59 UTC
My testing results (Toshiba Libretto L5):

    * EDID works, but I noticed that it will return null if I plug in my
external monitor after booting-- no hotplug support

    * LCD/brightness returns "levels:  80 10 10 30 50 80 100".  (My LCD has 8
brightness levels.)  This is why I never pursued the use of generic ACPI
brightness info for acpi_toshiba. 

    * video out control does not work for either LCD or CRT.  For example, "echo
0x80000000 > /proc/acpi/video/VGA/LCD/state" does nothing.
Comment 8 Bruno Ducrot 2004-02-12 17:55:29 UTC
Hi John, can you send me the dsdt for the libretto?
I'm a bit curious to see the methods for the lcd, especially lcd levels.
Comment 9 John Belmonte 2004-02-12 18:55:02 UTC
Created attachment 2102 [details]
dsdt binary for Toshiba Libretto L5
Comment 10 Bruno Ducrot 2004-02-12 19:40:35 UTC
Thank, John.  Well, that's interresting so far.
I think at least the ref. implementation is OK, it's just that I don't understand
why there are those funny number returned by _BCL.
Comment 11 John Belmonte 2004-02-12 20:07:52 UTC
> I think at least the ref. implementation is OK, it's just that I don't
> understand why there are those funny number returned by _BCL.

My wild guess would be that someone decided to improvise and give _BCL some new
meaning:

  80 - use this for a/c
  10 - use this for battery
  10 30 50 80 100 - available levels

However, like I said, my screen actually has 8 levels.

In any case, I just can't take this spec seriously since it doesn't define a way
to read the level back.
Comment 12 Len Brown 2004-05-26 10:55:05 UTC
                    Method (_BCL, 0, NotSerialized) 
                    { 
                        Name (BUFF, Package (0x07) 
                        { 
                            0x50,	/* 80% */ 
                            0x0A,	/* 10% */ 
                            0x0A,	/* 10% */ 
                            0x1E,	/* 30% */ 
                            0x32,	/* 50% */ 
                            0x50,	/* 80% */ 
                            0x64	/* 100% */ 
                        }) 
                        Return (BUFF) 
                    } 
 
These percentages look consistent with the _BCL defintion in the spec. 
1st is the AC power number, 
2nd is the battery poweor number, 
the others are to be cycled through in response to hot-key. 
 
Comment 13 Wayne Wylupski 2004-07-26 18:35:22 UTC
Created attachment 3432 [details]
The acpidmp output of a Fujitsu Lifebook p2110

My BIOS quasi-supports the video features (expand, S10, switch video adapter)
-- I can tell by echo 0x00000011 to > /proc/acpi/debug_level and watching what
happens when I hit the function key.  I know the FUJ02B1 _HID exists for
handling some functions, such as video brightness, volume, mute and
enable/disable mouse.  I'd like to see the video functions supported, please.
Comment 14 Len Brown 2004-07-26 23:36:07 UTC
Re: Fujitsu Lifebook DSDT 
 
Looks like GPE 3 handles 3 types of events: 
 
Scope (_GPE) { Method (_L03 ... 
... Notify (\_SB.PWRB, 0x02) 
... Notify (\_SB.PCI0.EIO.FJEX, 0x80) 
... Notify (\_SB.PCI0.EIO.CMBT, 0x81) 
 
Device (PWRB) {Name (_HID, EisaId ("PNP0C0C")) 
Device (FJEX) {Name (_HID, "FUJ02B1") 
Device (CMBT) { Name (_HID, "FUJ02E1") 
 
The 1st is the standard CM power button -- which 
we handle in button.c.  But the 2nd and 3rd are 
directed to Fujitsu-specific devices we don't have 
drivers for. 
 
Ideally, Fujitsu would provide these hot-key drivers, 
or at least provide specs so somebody in the 
community can write them.  You could load such 
a driver on demand the same way that button.c 
is loaded for PNP0C0C, except the fujitsu.c 
driver would look for "FUJ02B1" or "FUJ02E1". 
 
These devices have a bunch of vendor-specifc 
methods -- just _STA and _INI are standard. 
It may be possible to glean what vendor specific 
methods should be called on what events by reading 
the AML. 
 
The drivers would presumably also call into generic 
ACPI/video code (subject of this bug report) to effect 
the actual video switching.  While video switching 
appears to be supported via standard methods, it 
doesn't appear that this DSDT supports brightness 
control via ACPI. 
 
If an effort is undertaken to engineer a Fujitsu-specific 
driver, it should be the subject of a new bug report; since 
this one is intended to focus on the generic support 
that it would depend on. 
Comment 15 Len Brown 2004-07-26 23:52:00 UTC
Re comment #11 
John, ACPI 3.0 documents _BQC -- Brightness Query Current (level) 
to return a value in the _BCL list.  I don't know if this is a new 
feature in 3.0, or if it was erroneously missing from the 2.0c. 
 
Comment 16 Luming Yu 2004-09-07 02:08:10 UTC
Created attachment 3641 [details]
video extension patch against  Bruno Ducrot's

The patch includes some fixes, enhancement against the first video extension
patch from Bruno Ducrot.
Comment 17 Luming Yu 2004-10-08 23:39:14 UTC
Created attachment 3787 [details]
updated version

updated last one, && merged Bruno Ducrot's patch.
Comment 18 Jost Diederichs 2004-10-14 07:54:20 UTC
I wanted to test the acpi-video driver on my Toshiba Satellite Pro 4300.
The latest patch applied cleanly but I am having some compile trouble (am I miss
ing a header file?)

The following is the output of make for kernel 2.6.9-rc4:

  CC      drivers/acpi/scan.o
drivers/acpi/scan.c: In function `acpi_match_ids':
drivers/acpi/scan.c:172: error: `driver' undeclared (first use in this function)
drivers/acpi/scan.c:172: error: (Each undeclared identifier is reported only onc
e
drivers/acpi/scan.c:172: error: for each function it appears in.)
make[2]: *** [drivers/acpi/scan.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
Comment 19 Luming Yu 2004-10-14 08:09:02 UTC
the video extension patch will not change anything in function acpi_match_ids. 
Because in kernel 2.6.8.1, there don't have such function. Would you please 
verify it with 2.6.8.1 kernel?
Comment 20 Jost Diederichs 2004-10-15 08:54:33 UTC
You are right, thank you.
With kernel 2.6.8.1 tha patch compiles and the video extension works (partially).
Summary: I can change the brightness but (I assume) I can't switch off the
backlight.
Here are some results (Toshiba Satellite Pro 4300):

tree of /proc/acpi/video:
`-- VGA
    |-- CRT
    |   |-- EDID
    |   |-- brightness
    |   |-- info
    |   `-- state
    |-- DOS
    |-- LCD
    |   |-- EDID
    |   |-- brightness
    |   |-- info
    |   `-- state
    |-- POST
    |-- POST_info
    |-- ROM
    |-- TV
    |   |-- EDID
    |   |-- brightness
    |   |-- info
    |   `-- state
    `-- info

some dmesg output:
ACPI: Video Device [VGA] (multi-head: yes  rom: yes  post: no)
ACPI: Please implement acpi_video_bus_ROM_seq_show

contents of VGA/info:
Switching heads:              yes
Video ROM:                    yes
Device to be POSTed on boot:  no

contents od VGA/LCD/info:
device_id:    0x0110
type:         UNKNOWN
known by bios: no

contents of VGA/LCD/brightness:
levels:  80 10 10 30 50 80 100
current: 80


Am I correct that, in order to turn off the backlight, the POST method should work?
Comment 21 Daniel Esser 2004-10-20 07:45:56 UTC
A generic video acpi driver would be fine. I have an Toshiba Satellite Pro M30
and device switching does not work with toshiba_acpi. Somebody needs the DSDT?
In the last days a spend some time to modify toshiba_acpi to get support for
device switching. I can activate crt but the display does not really switch.
Comment 22 Len Brown 2004-10-22 21:03:19 UTC
applied patch in comment #17 
Comment 23 Len Brown 2004-11-15 19:40:37 UTC
shipped in Linux 2.6.10-rc2 - closed. 
Comment 24 Len Brown 2004-11-15 20:11:51 UTC
*** Bug 1878 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.