Date: Fri, 14 Jul 2006 01:06:27 -0600 From: Colin Faber <cfaber@ruckusmail.com> To: john@utzweb.net Cc: freebsd-acpi@freebsd.org, Carl Gustavsson <carl.gustavsson@telia.com>, mobile@freebsd.org Subject: Re: Dell laptops Message-ID: <44B74273.6060802@ruckusmail.com> In-Reply-To: <33711.69.93.78.27.1152834137.squirrel@69.93.78.27> References: <20060711.104708.1159134898.imp@bsdimp.com> <20060711114633.G67466@orthanc.ca> <44B54E3A.9040102@ruckusmail.com> <44B554AA.20009@telia.com> <33711.69.93.78.27.1152834137.squirrel@69.93.78.27>
next in thread | previous in thread | raw e-mail | index | archive | help
john@utzweb.net wrote: >> Colin Faber wrote: >> >>> I'm running -CURRENT on a D610 with working crt/lcd Fn switch, bge, >>> wireless (via ndis), sound, video (including DRM/DRI), est (via >>> powerd), and Lid switch control. >>> >>> The only problems I've noticed so far is that when running est with >>> powerd in adaptive mode, it seems to adjust the cpu timing many times >>> a second, which has lead to some applications being unstable and or >>> performing horribly (the most notable would be audio applications, >>> each time the cpu timing is switch you hear a pause). >>> > > aha! now i get it, the same thing happens with powerd, i notice the > hiccups when i am listening to something. > > perhaps there is an unutilized hardware callback somewhere that can inform > powerd/est that the audio device is in use and that it shouldnt toggle the > cpu..... > Possibly. Digging into this a little bit deeper I've also noticed that mplayer will pause when I close the lid. All this does is result in a devd callback to a script called Lid in /etc/rc.d that I wrote. This in turn issues a simple sysctl hw.acpi.video.lcd0.active=0 when closed and =1 when open. Maybe the ACPI system it self is resulting in the hiccups.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B74273.6060802>