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
>
> _______________________________________________
> [email protected] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "[email protected]"
>
>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.