Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops

[john at utzweb.net]

Hijacking this a bit, but it's very relevant IMHO

> On Thu, 13 Jul 2006, Eric Anderson wrote:
>
>> On 07/13/06 07:50, Daniel Eischen wrote:
>>> On Thu, 13 Jul 2006, Eric Anderson wrote:
>>>
>>>> And then if you do:
>>>>
>>>> sysctl hw.acpi.video.out0.active=1
>>>> and then
>>>> sysctl hw.acpi.video.out0.active=0
>>>>
>>>> Does your screen do something?
>>>
>>> Yes, hw.acpi.video.out0.active=1 seems to switch to the CRT,
>>> but once there, setting it back to 0 does not bring it back.
>>> Fn + CRT/LCD also has no effect.  The only way to get it back
>>> is to reboot.
>>>
>>
>> Did you try to do this too:
>>
>> sysctl hw.acpi.video.out1.active=1
>>
>> Or some other combinations?
>>
>> Sounds like it works ok, you just need to figure out which outputs map
>> to
>> your LCD/CRT/etc.

So, if you look at:

 /usr/src/sys/dev/acpicaacpi_video.c::acpi_video_vo_init()

you will notice that 'out' is what you get when you fall out of the switch:

       switch (adr & DOD_DEVID_MASK) {
        case DOD_DEVID_MONITOR:
                desc = "CRT monitor";
                type = "crt";
                voqh = &crt_units;
                break;
        case DOD_DEVID_PANEL:
                desc = "LCD panel";
                type = "lcd";
                voqh = &lcd_units;
                break;
        case DOD_DEVID_TV:
                desc = "TV";
                type = "tv";
                voqh = &tv_units;
                break;
        default:
                desc = "unknown output";
                type = "out";
                voqh = &other_units;
        }


my Latitude C400 (i830M) also shows up with out0 and i am highly confident
that what *should* be happening is that it should be *winning* at lcd.

when i was running 6.1-RELEASE i tried h3xoring the switch to have the lcd
be the default case but that didnt seem to help anything and i have not
tried the selfsame hack since switching over to CURRENT ( for the first
time since i started using FreeBSD back in 10/93!).

the switch is quite simple, so it really looks like there are only two
things that could be wrong:

1. either the addr passed as the inparm (UNIT32 adr) is wrong

2. the bit's at the address are screwed up so that the dont make the mask.


my devguy gut votes for 2, but i have yet to debug...urmm printf this
thing again.

so who the hell is acpi_video asking?

anybody know? i am resisting an impolite cross-post to freebsd-acpi based
on the assumption that anybody who knows anything over there is probably
on this list too.

i suspect that untwisting this will probably break the logjam on several
dell acpi annoyances.

X obviously get's it right, where is the fork in the road between X and ACPI?

i *will* figure this out, but if anybody has any thoughts they wanted to
chime in with, i would love to read them!

tnx!

johnu