Date: Thu, 26 Feb 2015 10:35:57 -0500 From: Anthony Jenkins <Anthony.B.Jenkins@att.net> To: John Baldwin <jhb@freebsd.org>, freebsd-acpi@freebsd.org Subject: Re: No acpi_dell(4) Message-ID: <54EF3D5D.4010106@att.net> In-Reply-To: <2401337.2oUs7iAbtB@ralph.baldwin.cx> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/25/2015 02:53 PM, John Baldwin wrote: > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: >> On 02/22/2015 01:08 PM, hiren panchasara wrote: >>> I've just got a lightweight dell e7240 which is pretty nice with very >>> good batterylife. >>> >>> Only trouble is none of the buttons work. >>> >>> Is there any hackery people do to make them work? Time permitting, I'd >>> like to see if we can get something together which looks like acpi_ibm. >> Some machines throw acpi_wmi(4) events when those special buttons are >> pushed. Load acpi_wmi(4) driver and cat /proc/wmistat0. The WMI >> objects with hex numbers in the EVENT column *might* be for your keys. >> My HP Envy Sleekbook uses WMI for the radios key, but I haven't figured >> out how to get events for the LCD brightness control keys (although my >> brightness controls *do* work). I used a Linux driver as a reference tho... >> >> I'd like to make the acpi_wmi(4) interface easier to use, but my backlog >> of contributions I'm sitting on is only growing. > I've been waiting to see if you were going to post an update to rev 3 of your > CMOS patch after Ian's last round of feedback FWIW. Much of his feedback > seemed relevant (and I know you've already accepted some other rounds of > feedback on that patch before then, hence 'v3') > I am... I've just been stalling, mostly because it "works for me" and I didn't understand some of the critiques, particularly the "pessimization" one (over my head I think). I'll toss what I have out there for further review; I'll shoot for today or tomorrow. One of the things I felt I had to do in the CMOS handler was allow ACPI to perform multibyte accesses to the CMOS region, but the existing CMOS read/write functions were only byte accessors, and each byte access was locked. A multibyte access would lock, read/write a byte, unlock, lock, read/write a byte, unlock.... So I wrote multibyte accessors (which had some issues I think I corrected) and had the original RTC CMOS accessor functions call the multibyte ones. The multibyte accessors performed the locking, so a multibyte access would lock, read/write a byte, read/write a byte..., unlock. I believe one of the recommendations was to "put it back the way it was", which I did, along with failing any attempt by ACPIBIOS to access multiple bytes. I think the reason behind having an ACPI CMOS handler is to give the OS a say when ACPIBIOS wants to access CMOS, to prevent it from stepping on the toes of an RTC CMOS driver who's also twiddling CMOS registers and (presumably) knows the state of the device. Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54EF3D5D.4010106>