I've been looking over the wistron_btns driver (again), and am rather puzzled by some of the latest additions to it.
In particular, laptops such as the 3020 and 5020 series (both identical, bar different AMD processors) are being polled to map their extra keys - however, both these laptops (and, AFAIK, most modern Acer laptops since at least 2005) do _not_ require this - all the extra keys are already emitting scancodes. >From what I can see, it would be surely better to drop the BIOS probing and polling on the newer laptops, and then either: A) Use the setkeycode ioctl for these particular laptops Pro: For users with x86-64 Acer laptops that produce scancodes, wistron_btns could be made to work, since the BIOS probing and polling code is now unnecessary. Con: Should setkeycode really be used in a kernel driver? (I don't know what the official policy is here) B) Let userspace map the scancodes to keycodes (such as HAL 0.5.10 and above is doing at the moment) (i.e. cut back wistron_btns to _just_ the older models that really do need polling to generate keycodes). Pro: Don't have to update the kernel for every single new Acer model and keyboard layout found (in the case of HAL, it would just be the hal-info package, which contains all this kind of information). Con: Not everyone may be using HAL - potential for inconsistency in keyboard mappings. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D
