Date: Thu, 13 Jul 2006 07:52:02 -0500 From: Eric Anderson <anderson@centtech.com> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-mobile@freebsd.org Subject: Re: Dell laptops Message-ID: <44B641F2.2020500@centtech.com> In-Reply-To: <Pine.GSO.4.64.0607130848190.6165@sea.ntplx.net> References: <20060711.104708.1159134898.imp@bsdimp.com> <200607111338.01412.mistry.7@osu.edu> <Pine.GSO.4.64.0607112352430.27869@sea.ntplx.net> <200607122136.54293.mistry.7@osu.edu> <Pine.GSO.4.64.0607130824240.6165@sea.ntplx.net> <44B6401F.8050507@centtech.com> <Pine.GSO.4.64.0607130848190.6165@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/13/06 07:50, Daniel Eischen wrote: > On Thu, 13 Jul 2006, Eric Anderson wrote: > >> On 07/13/06 07:29, Daniel Eischen wrote: >>> On Wed, 12 Jul 2006, Anish Mistry wrote: >>> >>>> On Tuesday 11 July 2006 23:54, Daniel Eischen wrote: >>>>> On Tue, 11 Jul 2006, Anish Mistry wrote: >>>>>> On Tuesday 11 July 2006 13:10, Daniel Eischen wrote: >>>>>>> Also, the Fn (the blue key) can't be used to suspend, control >>>>>>> volume, switch CRT/LCD, etc, and most importantly enable the >>>>>>> radio on the wireless card (Fn + F2). Even if the wpi driver >>>>>>> works, it's worthless if I can't enable the radio. >>>>>> >>>>>> It might simply need an acpi function keys driver for your >>>>>> system. Would you post an "acpidump -dt" from your system? >>>>> >>>>> Here it is: >>>>> >>>>> http://people.freebsd.org/~deischen/e1405.acpi.dump >>>>> >>>>> I don't know how to decipher it nor what to do with it. >>>> >>>> There doesn't seem to be a function key device. This probably means >>>> that pressing the keys just generate keyboard scan codes. >>>> >>>> Does acpi_video work for you? It looks like it should work. >>> >>> No, not really. Also, closing the lid will cause a suspend, >>> but after that it won't ever wakeup no matter what keys I >>> hit. >>> >>> # kldload /boot/kernel/acpi_video.ko >>> found TV(200), detectable by BIOS, head #0 >>> found CRT monitor(100), detectable by BIOS, head #0 >>> found unknown output(400), detectable by BIOS, head #0 >>> found unknown output(300), detectable by BIOS, head #0 >>> acpi_video1: <ACPI video extension> on vgapci1 >>> evaluation of \\_SB_.PCI0.VID2._DOD makes no sense >>> >>> $ sysctl -a | grep acpi >> >> [..snip..] >>> hw.acpi.video.tv0.active: 0 >>> hw.acpi.video.crt0.active: 0 >>> hw.acpi.video.out0.active: 0 >>> hw.acpi.video.out1.active: 0 >> [..snip..] >> >> >> 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. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B641F2.2020500>