John Plocher wrote:
> [jumping in late after reading the thread...]
>
>
>> Since there is no generic ACPI specification for other hotkeys, most
>> vendors just define their own specific ACPI based hotkey method. This
>> case will also add Toshiba specific ACPI hotkey method support for:
>> 1. Fn + ESC: audio mute On/Off
>> 2. Fn + F1: screen lock
>> 3. Fn + F3: suspend to RAM(on S3 capable platform)
>> 4. Fn + F8: wireless LAN On/Off
>> 5. Fn + F9: touchPad On/Off
>>
>
> So, to use a real world example to flesh out the details: I don't
> have a toshiba; instead I've got an apple mac laptop. It uses
>
> F1 lower screen backlite
> F2 brighten screen backlite
> F3 mute
> F4 lower volume
> F5 raise volume
> F6 NUM LOCK
> F7 cycle between internal and external screen mirroring -vs-
> independent displays
> F8 kbd backlite off
> F9 lower kbd backlite
> F10 brighten kbd backlite
> F11 Move windows off screen to show desktop & icons on it
> "Eject" eject's cd/dvd
> Lid close Suspend to RAM
>
> With this proposal, can this platform be detected and these keys be
> set up and used automatically? If not, what needs to be done to make
> it work (and who whould have to do the work - you, someone in the OS
> developer community, the end user, ???)
>
Depends entirely on the implementation. I've seen no fewer than three
different approaches vendors use, and the details differ for each (I
don't know what Apple uses):
1. keys send PS/2 or USB key events. This requires no work other than
the user establishing the handling using the gnome applications.
2. keys are handled using microcontroller firmware internally. This
requires no work on anyone's part. They just work.
3. keys are handled using ACPI or similar BIOS, and require OS support.
In the current proposal, adding support for a laptop that does this
requires code modifications in ON. The proposal could probably be
refined so that unbundled versions could be developed, but ultimately
someone would still need to develop code no matter what.
The complete anarchy here (some might call it "freedom for vendor
innovation") is not helpful. It would be nice if there were standards
for this stuff. IMO, most of the vendors aren't overly inclined to
care much though, since they all deliver their own Windows platform
drivers already, and usually they don't care that much about making
things easy for other operating systems. Even the vendors that
cooperate and provide information (Toshiba) might not want to develop
common standards, since their openness (or rather the closedness of
their competitors) might actually be a competitive edge for them in
certain markets. (And developing common standards is *expensive*
usually, since committees and politics then get involved.)
-- Garrett
> -John
>
