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

john at utzweb.net john at utzweb.net
Fri Jul 14 00:06:28 UTC 2006


Self Reply, i am moving this over to freebsd-acpi with this additional set
of facts....

> 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!

further facts,does this VID entry look reasonable?


            Device (VID)
            {
                Name (_ADR, 0x00020000)
                Method (_DOS, 1, NotSerialized)
                {
                    Store (Arg0, MIS4)
                    SMI (0x9E, MIS4)
                }

                Method (_DOD, 0, NotSerialized)
                {
                    Return (Package (0x02)
                    {
                        0x00010100,
                        0x00010400
                    })
                }

                Device (CRT)
                {
                    Method (_ADR, 0, NotSerialized)
                    {
                        Return (0x0100)
                    }

                    Method (_DCS, 0, NotSerialized)
                    {
                        Store (SMI (0x8E, 0x01), Local0)
                        Return (Local0)
                    }

                    Method (_DGS, 0, NotSerialized)
                    {
                        Store (SMI (0x99, 0x01), Local0)
                        Return (Local0)
                    }

                    Method (_DSS, 1, NotSerialized)
                    {
                        DSS (0x01, Arg0)
                    }
                }

                Device (LCD)
                {
                    Method (_ADR, 0, NotSerialized)
                    {
                        Return (0x0400)
                    }

                    Method (_DCS, 0, NotSerialized)
                    {
                        Store (SMI (0x8E, 0x02), Local0)
                        Return (Local0)
                    }

                    Method (_DGS, 0, NotSerialized)
                    {
                        Store (SMI (0x99, 0x02), Local0)
                        Return (Local0)
                    }

                    Method (_DSS, 1, NotSerialized)
                    {
                        DSS (0x02, Arg0)
                    }
                }
            }

what is also worthy of note is this empty VID2 entry:


          Device (VID2)
            {
                Name (_ADR, 0x00020001)
                Method (_DOS, 1, NotSerialized)
                {
                }

                Method (_DOD, 0, NotSerialized)
                {
                    Return (Package (0x00) {})
                }
            }

evidently, our ACPI code believes this to be bogus (correctly, i think),
because the dmesg shows a complaint:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> mem
0xe0000000-0xe7ffffff,0xf4f80000-0xf4ffffff irq 11 at device 2.0 on pci0
agp0: <Intel 82830M (830M GMCH) SVGA controller> on vgapci0
agp0: detected 892k stolen memory
agp0: aperture size is 128M
acpi_video0: <ACPI video extension> on vgapci0
drm0: <Intel i830M GMCH> on vgapci0
info: [drm] AGP at 0xe0000000 128MB
info: [drm] Initialized i915 1.4.0 20060119
vgapci1: <VGA-compatible display> mem
0xd8000000-0xdfffffff,0xf4f00000-0xf4f7ffff at device 2.1 on pci0
acpi_video1: <ACPI video extension> on vgapci1

evaluation of \\_SB_.PCI0.VID2._DOD makes no sense   <--- WARNING HERE


drm1: <Intel i830M GMCH> on vgapci1
info: [drm] AGP at 0xe0000000 128MB
info: [drm] Initialized i915 1.4.0 20060119


does this jog anybody's cranium? what does the VID stuff look like on
laptops where the video portion of sus/res actually works?

> tnx!
>
> johnu
>
> _______________________________________________
> freebsd-mobile at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe at freebsd.org"
>
>




More information about the freebsd-mobile mailing list