Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 10:04:14AM -0800, Kerry Shu wrote:
>
>> James Carlson wrote:
>>
>>> How exactly does the system know which module works on a given system?
>>>
>> If the corresponding ACPI method is found in _init of the vendor
>> specific module, then _init will return SUCCESS and we know the
>> module works.
>>
>
> That means the order in which the modules are tried is significant, no?
>
>
>>> Are these modules expected to test for platform compatibility by
>>> probing around in the module's _init(9E) function?
>>>
>> Yes. And per my understanding, the ACPI method string should be unique
>> per vendor.
>>
>
> Still, you're providing a very difficult to use interface for mapping
> these hotkeys: a kernel module interface.
>
I think there's some confusion.
There are three levels of mapping:
1) mapping some arbitrary ACPI event to a system event consumable by
userland
2) mapping the system event to an X11 key event
3) mapping the X11 key event to an action
The first of these is highly platform-specific, and is what is driven by
the kernel configuration. Its not entirely clear to me that a table
driven approach *could* be used in the general case -- how each BIOS
enables and delivers ACPI events might be highly vendor specifc. I
don't know that this *is* the case, merely postulate that it *might*
be. Even if a table driven approach *were* possible, changing the
configuration would probably require fairly detailed knowledge of the
platform's BIOS -- well beyond the scope of what one might expect users
to be able to configure.
The second is an artifact of the implementation, and no user should need
or want to change it. (Its a simple identity map.)
The third is user configurable today, and will remain so.
So, while I do wish that an easier user configuration were available for
these ACPI events (the first of those translations), or that the
industry had standardized a bit more here, the reality is that this
probably isn't practical, at least not at this point.
-- Garrett
> Nico
>
