From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 14 00:06:28 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 761B316A4DA; Fri, 14 Jul 2006 00:06:28 +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 EF64143D45; Fri, 14 Jul 2006 00:06:27 +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 C784DF1464; Thu, 13 Jul 2006 20:06:32 -0400 (EDT) Received: from 69.93.78.27 (proxying for 216.254.62.194) (SquirrelMail authenticated user john-utzweb-net); by utzweb.net with HTTP; Thu, 13 Jul 2006 20:06:32 -0400 (EDT) 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> <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> Date: Thu, 13 Jul 2006 20:06:32 -0400 (EDT) From: john@utzweb.net To: freebsd-acpi@freebsd.org 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-mobile@freebsd.org Subject: 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 00:06:28 -0000 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" > >