From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 14 06:05:58 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9BAD16A4DD; Fri, 14 Jul 2006 06:05:58 +0000 (UTC) (envelope-from john@utzweb.net) Received: from marley.grokthis.net (marley.grokthis.net [69.93.78.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 663E943D53; Fri, 14 Jul 2006 06:05:40 +0000 (GMT) (envelope-from john@utzweb.net) Received: from utzweb.net (marley.grokthis.net [127.0.0.1]) by marley.grokthis.net (Postfix) with ESMTP id 7AAD1F1467; Fri, 14 Jul 2006 02:05:40 -0400 (EDT) Received: from 69.93.78.27 (proxying for 24.22.134.170) (SquirrelMail authenticated user john-utzweb-net); by utzweb.net with HTTP; Fri, 14 Jul 2006 02:05:40 -0400 (EDT) Message-ID: <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> In-Reply-To: <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> References: <20060711.104708.1159134898.imp@bsdimp.com> <200607111338.01412.mistry.7@osu.edu> <200607122136.54293.mistry.7@osu.edu> <44B6401F.8050507@centtech.com> <44B641F2.2020500@centtech.com> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> Date: Fri, 14 Jul 2006 02:05:40 -0400 (EDT) From: john@utzweb.net To: john@utzweb.net User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Patch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 06:05:59 -0000 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: port 0xcf8-0xcff on acpi0 > pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid > pci0: on pcib0 > vgapci0: mem > 0xe0000000-0xe7ffffff,0xf4f80000-0xf4ffffff irq 11 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 892k stolen memory > agp0: aperture size is 128M > acpi_video0: on vgapci0 > drm0: on vgapci0 > info: [drm] AGP at 0xe0000000 128MB > info: [drm] Initialized i915 1.4.0 20060119 > vgapci1: mem > 0xd8000000-0xdfffffff,0xf4f00000-0xf4f7ffff at device 2.1 on pci0 > acpi_video1: on vgapci1 > > evaluation of \\_SB_.PCI0.VID2._DOD makes no sense <--- WARNING HERE > > > drm1: 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" >> >> > > > _______________________________________________ > 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" > >