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@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@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
>>
>> _______________________________________________
>> [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.