> I would like to wait for documentation and not to invent/mess something > again and more. I get your point, but even getting our hands on the docs would most likely do nothing for the fact that hotkey behavior differs between models. > Creating big list with DMI names and associate hooks for > them based on "our" observation is good way to hell! Obviously it's not an elegant solution. Obviously using WMI for something as simple as handling a keypress is insane. Yet, this is the way vendors (at least some of them) chose. I guess the decision to be made is whether to try to support it anyway or accept the fact that arbitrary hardware will not be fully functional, even though we know exactly why. Of course that's not my call to make and I respect your decision. Just putting my two cents in as I despise the idea of letting the vendor decide which features of the hardware I bought from them I can use and which ones I can't. > We even do not know: > > 1) how to activate code for receiving events Oh, but we do! At least for some models ;) We just don't know _why_ it should be done the way it is done. It sure would be nice to know that, but should it stop us from implementing a working solution? > 2) what is format of which event Well, dell-wmi.ko seems to be decoding the events pretty well. And again, the format differs between models (and is probably subject to change in yet to be released hardware) and we can't really do a thing about it. We can either support it or not. > 3) which keypress should be reported by i8042 bus and which via ACPI/WMI That depends on the model ;) -- Best regards, Michał Kępień -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
