Calling all hotkey expertise...

[Colin Ian King]

Thanks Herton,

On Thu, 2011-02-10 at 19:58 -0200, Herton Ronaldo Krzesinski wrote:
> Em Qui, 2011-02-10 às 21:00 +0000, Colin Ian King escreveu:
> > Hi there,
> > 
> > I'm pulling together a document with Tony Espy on a BIOS recommendations
> > guide. I'm really interested in any documents, links, and helpful info
> > on how hotkeys work.  It is a non-trivial issue and there are many
> > different ways it is implemented.  
> 
> From what I remember and from experience (correct me if I say something
> wrong), vendors usually implement hotkeys:
> - using a WMI interface, where a driver needs to be written. The driver
> receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
> the response/data so if the event is a hotkey it gets a code and
> translates it to input layer. It's a lot easier if the vendor gives
> information on its WMI implementation, as by nature of ACPI-WMI every
> vendor can choose what parameters/format to accept on WMI methods etc.

Yep, good one and becoming more frequent. As documented here:
https://wiki.ubuntu.com/Kernel/Reference/WMI

Personally, I'd like to write a MOF disassembler to extract a high level
view of the WMI configuration from the WQxx objects rather than by
poking around and figuring out how these work by trial-and-error...
when I have time.. :-)

> - using a vendor specific device HID. The vendor implements its own acpi
> device in DSDT, with a HID name it choses. A specific platform driver
> needs to be written too. Methods and way to work with this device are
> totally defined by the vendor. One example is topstar_laptop in the
> kernel. Also it's easier if vendor gives info/spec on every aspect of
> what it implemented in BIOS/dsdt, otherwise we have to discover by
> reading DSDT and do experiments (trial and error).

Thanks for the pointer to this user example.

> - sending codes directly via the keyboard controller (so implemented
> directly in embedded controller, also some people call it as keyboard
> bios, but anyway I think should be on ec firmware). So kernel directly
> receive keyboard codes on keyboard input device, no need to extra
> driver, but many times the codes have to be remaped on user space to the
> real key code meaning/value (udev keymaps)

I wonder if there are any standard configurations we can recommend for
this
method of hotkeys?  Any ideas anyone?


> 
> It seems we already have some documentation on this:
> https://wiki.edubuntu.org/Hotkeys/Architecture
> 
> Also there are cases of some hotkeys where the Vendor implements it on
> BIOS or let the OS control it:
> - Brightness keys
> some vendors put brightness handling on bios, but if the system reports
> as being Windows Vista or newer via acpi_os (which Linux does), it
> disables its brightness handling and let OS do it, so sometimes you have
> to pass acpi_osi="!Windows 2006" on kernel command line to brightness
> keys to work.
> - Video output switch
> only on newer bioses, and same as brightness keys, but bios disables its
> handling only if system is Windows 7 or newer, so you have to pass
> acpi_osi="!Windows 2009" on kernel command line.
> This is because recommendation Microsoft does to the vendors. I don't
> fully understand it, but the acpi_osi parameters make the bios take
> control again and are workarounds.
> 
> > 
> > If you have *any* useful info, please can you forward it to me.  I may
> > even get around to compiling it all into a Wiki page.
> > 
> > Thanks!
> > 
> > Colin
> > -- 
> > Colin King 
> > Hardware Enablement Team - Kernel Team - Platform Team - Canonical
> > Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
> > 
> > 
>