On Fri, 2009-03-06 at 09:56 +0000, Matthew Garrett wrote: > > Have you looked at whether or not this method functions on more than the > > one laptop? Toshiba are notoriously good at getting their own interfaces > > wrong from one laptop to another. > It's present on every Toshiba DSDT I have that has a VALD/VALZ method. Nod, I shall have to have a check through the ones here if I can. > > In addition, the fn+whatever keymaps are often different between > > laptops, especially for things like the WWW or MAIL buttons. > > Presumably if the hotkeys fail to activate then the normal > > /proc/acpi/toshiba/keys thing will continue? > Yes, it'll be as functional as it was previously. They can be remapped > on machines that have a different keymap. Since I don't understand the input layer well enough yet, can you confirm if it is possible to add new mappings in without changing the source? I.E. if laptop <foo> has another hotkey not yet considered, is it just an FDI for hal, or is it a source change in the kernel? > > How will it interact with software stacks like HAL when the lock button > > is pressed? > I don't really understand the question? It was more: will events come out of both the notify method *and* the /proc/acpi/toshiba/keys stuff, or will they only come out of the notify method if it can be enabled? (I'm just trying to establish that things polling /proc/acpi/toshiba/keys won't end up causing duplicated events). Assuming I'm just being over-paranoid or not understanding the minutae, then I give this a +1 because the behaviour is certainly desirable since it'll allow the tosh laptops to not wake up regularly to check for hotkeys. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
