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.
*** Bug 1943 has been marked as a duplicate of this bug. ***
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?
Created attachment 2097 [details] First try to implement an ACPI Extensions for Display Adapters.
Created attachment 2098 [details] A README for the previous patch.
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 ?
Created attachment 2100 [details] Mail with problem description & further info Tried it with Kernel 2.6.2 on ASUS M2N -- no success yet.
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.
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.
Created attachment 2102 [details] dsdt binary for Toshiba Libretto L5
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.
> 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.
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.
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.
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.
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.
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.
Created attachment 3787 [details] updated version updated last one, && merged Bruno Ducrot's patch.
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
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?
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?
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.
applied patch in comment #17
shipped in Linux 2.6.10-rc2 - closed.
*** Bug 1878 has been marked as a duplicate of this bug. ***