Date: Thu, 13 Jul 2006 20:06:32 -0400 (EDT) From: john@utzweb.net To: freebsd-acpi@freebsd.org Cc: freebsd-mobile@freebsd.org Subject: Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops Message-ID: <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> In-Reply-To: <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> References: <20060711.104708.1159134898.imp@bsdimp.com> <200607111338.01412.mistry.7@osu.edu> <Pine.GSO.4.64.0607112352430.27869@sea.ntplx.net> <200607122136.54293.mistry.7@osu.edu> <Pine.GSO.4.64.0607130824240.6165@sea.ntplx.net> <44B6401F.8050507@centtech.com> <Pine.GSO.4.64.0607130848190.6165@sea.ntplx.net> <44B641F2.2020500@centtech.com> <Pine.GSO.4.64.0607130900460.6165@sea.ntplx.net> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34247.69.93.78.27.1152835592.squirrel>