Patch to fix this Re: 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 06:05:59 UTC 2006


acpi_video.c expects the lcd to be identified as 0x0110, but my Dell
Latitude C400 (and probably others) id's the lcd at 0x0400:

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


so, acpi_video needs to account for this.


got this sorted, and now the display turns back on, here's the patch, i
already send-pr'd it


spaz at minime /usr/home/spaz]$ diff -u acpi_videoorig.c acpi_video.c
--- acpi_videoorig.c    Thu Jul 13 22:44:40 2006
+++ acpi_video.c        Thu Jul 13 22:44:28 2006
@@ -113,6 +113,7 @@
 #define DOD_DEVID_MONITOR      0x0100
 #define DOD_DEVID_PANEL                0x0110
 #define DOD_DEVID_TV           0x0200
+#define DOD_DEVID_LCD           0x0400
 #define DOD_BIOS               (1 << 16)
 #define DOD_NONVGA             (1 << 17)
 #define DOD_HEAD_ID_SHIFT      18
@@ -416,6 +417,7 @@
                voqh = &crt_units;
                break;
        case DOD_DEVID_PANEL:
+       case DOD_DEVID_LCD:
                desc = "LCD panel";
                type = "lcd";
                voqh = &lcd_units;
@@ -558,6 +560,7 @@
                voqh = &crt_units;
                break;
        case DOD_DEVID_PANEL:
+       case DOD_DEVID_LCD:
                voqh = &lcd_units;
                break;
        case DOD_DEVID_TV:
[spaz at minime /usr/home/spaz]$

> 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"
>>
>>
>
>
> _______________________________________________
> 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