From owner-freebsd-mobile@FreeBSD.ORG Thu Jul 13 23:01:34 2006 Return-Path: X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652F516A501; Thu, 13 Jul 2006 23:01:34 +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 233EA43D5D; Thu, 13 Jul 2006 23:01:30 +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 420C9F1442; Thu, 13 Jul 2006 19:01:31 -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 19:01:35 -0400 (EDT) Message-ID: <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> In-Reply-To: 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> Date: Thu, 13 Jul 2006 19:01:35 -0400 (EDT) From: john@utzweb.net To: "Daniel Eischen" 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: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 23:01:34 -0000 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! tnx! johnu