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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"