FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 02-10-2011, 08:58 PM
Herton Ronaldo Krzesinski
 
Default Calling all hotkey expertise...

Em Qui, 2011-02-10 ąs 21:00 +0000, Colin Ian King escreveu:
> Hi there,
>
> I'm pulling together a document with Tony Espy on a BIOS recommendations
> guide. I'm really interested in any documents, links, and helpful info
> on how hotkeys work. It is a non-trivial issue and there are many
> different ways it is implemented.

From what I remember and from experience (correct me if I say something
wrong), vendors usually implement hotkeys:
- using a WMI interface, where a driver needs to be written. The driver
receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
the response/data so if the event is a hotkey it gets a code and
translates it to input layer. It's a lot easier if the vendor gives
information on its WMI implementation, as by nature of ACPI-WMI every
vendor can choose what parameters/format to accept on WMI methods etc.
- using a vendor specific device HID. The vendor implements its own acpi
device in DSDT, with a HID name it choses. A specific platform driver
needs to be written too. Methods and way to work with this device are
totally defined by the vendor. One example is topstar_laptop in the
kernel. Also it's easier if vendor gives info/spec on every aspect of
what it implemented in BIOS/dsdt, otherwise we have to discover by
reading DSDT and do experiments (trial and error).
- sending codes directly via the keyboard controller (so implemented
directly in embedded controller, also some people call it as keyboard
bios, but anyway I think should be on ec firmware). So kernel directly
receive keyboard codes on keyboard input device, no need to extra
driver, but many times the codes have to be remaped on user space to the
real key code meaning/value (udev keymaps)

It seems we already have some documentation on this:
https://wiki.edubuntu.org/Hotkeys/Architecture

Also there are cases of some hotkeys where the Vendor implements it on
BIOS or let the OS control it:
- Brightness keys
some vendors put brightness handling on bios, but if the system reports
as being Windows Vista or newer via acpi_os (which Linux does), it
disables its brightness handling and let OS do it, so sometimes you have
to pass acpi_osi="!Windows 2006" on kernel command line to brightness
keys to work.
- Video output switch
only on newer bioses, and same as brightness keys, but bios disables its
handling only if system is Windows 7 or newer, so you have to pass
acpi_osi="!Windows 2009" on kernel command line.
This is because recommendation Microsoft does to the vendors. I don't
fully understand it, but the acpi_osi parameters make the bios take
control again and are workarounds.

>
> If you have *any* useful info, please can you forward it to me. I may
> even get around to compiling it all into a Wiki page.
>
> Thanks!
>
> Colin
> --
> Colin King
> Hardware Enablement Team - Kernel Team - Platform Team - Canonical
> Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
>
>

--
[]'s
Herton


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-11-2011, 01:07 AM
Ike Panhc
 
Default Calling all hotkey expertise...

On 02/11/2011 05:00 AM, Colin Ian King wrote:
> Hi there,
>
> I'm pulling together a document with Tony Espy on a BIOS recommendations
> guide. I'm really interested in any documents, links, and helpful info
> on how hotkeys work. It is a non-trivial issue and there are many
> different ways it is implemented.
>
> If you have *any* useful info, please can you forward it to me. I may
> even get around to compiling it all into a Wiki page.
>
> Thanks!
>
> Colin

This is what I write long time ago...

https://wiki.ubuntu.com/KernelTeam/HardwareEnableWithDSDT

and this is a useful article for wmi based hotkey

http://lwn.net/Articles/391230/

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-11-2011, 12:51 PM
Herton Ronaldo Krzesinski
 
Default Calling all hotkey expertise...

Em Qui, 2011-02-10 ąs 19:58 -0200, Herton Ronaldo Krzesinski escreveu:
> - Video output switch
> only on newer bioses, and same as brightness keys, but bios disables its
> handling only if system is Windows 7 or newer, so you have to pass
> acpi_osi="!Windows 2009" on kernel command line.

Looking now, these are some bug reports related to this:
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/508847 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539477

> This is because recommendation Microsoft does to the vendors. I don't
> fully understand it, but the acpi_osi parameters make the bios take
> control again and are workarounds.
>

Also, I remembered now that there is a interesting thread with the guide
written by Thomas Renninger, but not only limited to hotkeys though, yet
may help as reference:
http://lkml.org/lkml/2008/7/24/291

I already tried too to find some documentation from Microsoft about any
of these too, but so far nothing specific, anyway could be interesting
to look at some pages like
http://www.microsoft.com/whdc/archive/_OSI-method.mspx , there are
others. As Linux advertises in acpi_osi as being windows (upstream
policy), it may be useful when having bugs like these.

> >
> > If you have *any* useful info, please can you forward it to me. I may
> > even get around to compiling it all into a Wiki page.
> >
> > Thanks!
> >
> > Colin
> > --
> > Colin King
> > Hardware Enablement Team - Kernel Team - Platform Team - Canonical
> > Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
> >
> >
>
> --
> []'s
> Herton
>
>

--
[]'s
Herton


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-17-2011, 11:31 AM
Colin Ian King
 
Default Calling all hotkey expertise...

Thanks Herton,

On Thu, 2011-02-10 at 19:58 -0200, Herton Ronaldo Krzesinski wrote:
> Em Qui, 2011-02-10 ąs 21:00 +0000, Colin Ian King escreveu:
> > Hi there,
> >
> > I'm pulling together a document with Tony Espy on a BIOS recommendations
> > guide. I'm really interested in any documents, links, and helpful info
> > on how hotkeys work. It is a non-trivial issue and there are many
> > different ways it is implemented.
>
> From what I remember and from experience (correct me if I say something
> wrong), vendors usually implement hotkeys:
> - using a WMI interface, where a driver needs to be written. The driver
> receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
> the response/data so if the event is a hotkey it gets a code and
> translates it to input layer. It's a lot easier if the vendor gives
> information on its WMI implementation, as by nature of ACPI-WMI every
> vendor can choose what parameters/format to accept on WMI methods etc.

Yep, good one and becoming more frequent. As documented here:
https://wiki.ubuntu.com/Kernel/Reference/WMI

Personally, I'd like to write a MOF disassembler to extract a high level
view of the WMI configuration from the WQxx objects rather than by
poking around and figuring out how these work by trial-and-error...
when I have time.. :-)

> - using a vendor specific device HID. The vendor implements its own acpi
> device in DSDT, with a HID name it choses. A specific platform driver
> needs to be written too. Methods and way to work with this device are
> totally defined by the vendor. One example is topstar_laptop in the
> kernel. Also it's easier if vendor gives info/spec on every aspect of
> what it implemented in BIOS/dsdt, otherwise we have to discover by
> reading DSDT and do experiments (trial and error).

Thanks for the pointer to this user example.

> - sending codes directly via the keyboard controller (so implemented
> directly in embedded controller, also some people call it as keyboard
> bios, but anyway I think should be on ec firmware). So kernel directly
> receive keyboard codes on keyboard input device, no need to extra
> driver, but many times the codes have to be remaped on user space to the
> real key code meaning/value (udev keymaps)

I wonder if there are any standard configurations we can recommend for
this
method of hotkeys? Any ideas anyone?


>
> It seems we already have some documentation on this:
> https://wiki.edubuntu.org/Hotkeys/Architecture
>
> Also there are cases of some hotkeys where the Vendor implements it on
> BIOS or let the OS control it:
> - Brightness keys
> some vendors put brightness handling on bios, but if the system reports
> as being Windows Vista or newer via acpi_os (which Linux does), it
> disables its brightness handling and let OS do it, so sometimes you have
> to pass acpi_osi="!Windows 2006" on kernel command line to brightness
> keys to work.
> - Video output switch
> only on newer bioses, and same as brightness keys, but bios disables its
> handling only if system is Windows 7 or newer, so you have to pass
> acpi_osi="!Windows 2009" on kernel command line.
> This is because recommendation Microsoft does to the vendors. I don't
> fully understand it, but the acpi_osi parameters make the bios take
> control again and are workarounds.
>
> >
> > If you have *any* useful info, please can you forward it to me. I may
> > even get around to compiling it all into a Wiki page.
> >
> > Thanks!
> >
> > Colin
> > --
> > Colin King
> > Hardware Enablement Team - Kernel Team - Platform Team - Canonical
> > Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
> >
> >
>



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-17-2011, 11:15 PM
Herton Ronaldo Krzesinski
 
Default Calling all hotkey expertise...

Em Qui, 2011-02-17 ąs 12:31 +0000, Colin Ian King escreveu:
> Thanks Herton,
>
> On Thu, 2011-02-10 at 19:58 -0200, Herton Ronaldo Krzesinski wrote:
> > Em Qui, 2011-02-10 ąs 21:00 +0000, Colin Ian King escreveu:
> > From what I remember and from experience (correct me if I say something
> > wrong), vendors usually implement hotkeys:
> > - using a WMI interface, where a driver needs to be written. The driver
> > receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
> > the response/data so if the event is a hotkey it gets a code and
> > translates it to input layer. It's a lot easier if the vendor gives
> > information on its WMI implementation, as by nature of ACPI-WMI every
> > vendor can choose what parameters/format to accept on WMI methods etc.
>
> Yep, good one and becoming more frequent. As documented here:
> https://wiki.ubuntu.com/Kernel/Reference/WMI
>
> Personally, I'd like to write a MOF disassembler to extract a high level
> view of the WMI configuration from the WQxx objects rather than by
> poking around and figuring out how these work by trial-and-error...
> when I have time.. :-)

Nice, would be great to have such tool.

I remembered now, there is also the paramters of wmi module that were
added "recently" to the kernel (2.6.35) and are very useful, specially
in detecting if the machine has wmi objects and if we are receiving
things through wmi.
wmi.debug_dump_wdg=1 to list wmi interfaces
wmi.debug_event=1 to show on dmesg events we received

Especially when hotkeys doesn't work, is useful to enable debug_event
because if it's implemented by wmi, when we press the hotkey information
will appear on dmesg. May be it isn't useful for vendor documentation,
but is useful to us and users when hotkeys doesn't work and we want to
check if it's done by wmi or testing when developing.

> > - sending codes directly via the keyboard controller (so implemented
> > directly in embedded controller, also some people call it as keyboard
> > bios, but anyway I think should be on ec firmware). So kernel directly
> > receive keyboard codes on keyboard input device, no need to extra
> > driver, but many times the codes have to be remaped on user space to the
> > real key code meaning/value (udev keymaps)
>
> I wonder if there are any standard configurations we can recommend for
> this
> method of hotkeys? Any ideas anyone?

Well, I think at least use the common known 0xe0 scan codes for
multimedia etc. If we look at some of the keymaps in udev, there are
some multimedia keys which could have been reported using a common known
scancode which atkbd recognizes (the so called "Windows Multimedia Scan
Codes"). But instead the vendor chose a non-standard scan code, which
have to be remmaped.

I did a test program (attached for reference) which prints current
extended scan codes which atkbd translates to input layer. Here I paste
only the relevant entries, first column is the key sent to user space
(last column its respective numeric value):

E0 Scan Code Set 1 - scancodes

PreviousSong - key, press == 0xe0 0x10, release == 0xe0 0x90, ScanCode == 0x90, keycode == 165
NextSong - key, press == 0xe0 0x19, release == 0xe0 0x99, ScanCode == 0x99, keycode == 163
Mute - key, press == 0xe0 0x20, release == 0xe0 0xa0, ScanCode == 0xa0, keycode == 113
Calc - key, press == 0xe0 0x21, release == 0xe0 0xa1, ScanCode == 0xa1, keycode == 140
PlayPause - key, press == 0xe0 0x22, release == 0xe0 0xa2, ScanCode == 0xa2, keycode == 164
StopCD - key, press == 0xe0 0x24, release == 0xe0 0xa4, ScanCode == 0xa4, keycode == 166
VolumeDown - key, press == 0xe0 0x2e, release == 0xe0 0xae, ScanCode == 0xae, keycode == 114
VolumeUp - key, press == 0xe0 0x30, release == 0xe0 0xb0, ScanCode == 0xb0, keycode == 115
HomePage - key, press == 0xe0 0x32, release == 0xe0 0xb2, ScanCode == 0xb2, keycode == 172
Pause - key, press == 0xe0 0x45, release == 0xe0 0xc5, ScanCode == 0xc5, keycode == 119
Pause - key, press == 0xe0 0x46, release == 0xe0 0xc6, ScanCode == 0xc6, keycode == 119
Power - key, press == 0xe0 0x5e, release == 0xe0 0xde, ScanCode == 0xde, keycode == 116
Sleep - key, press == 0xe0 0x5f, release == 0xe0 0xdf, ScanCode == 0xdf, keycode == 142
WakeUp - key, press == 0xe0 0x63, release == 0xe0 0xe3, ScanCode == 0xe3, keycode == 143
Search - key, press == 0xe0 0x65, release == 0xe0 0xe5, ScanCode == 0xe5, keycode == 217
Bookmarks - key, press == 0xe0 0x66, release == 0xe0 0xe6, ScanCode == 0xe6, keycode == 156
Refresh - key, press == 0xe0 0x67, release == 0xe0 0xe7, ScanCode == 0xe7, keycode == 173
Stop - key, press == 0xe0 0x68, release == 0xe0 0xe8, ScanCode == 0xe8, keycode == 128
Forward - key, press == 0xe0 0x69, release == 0xe0 0xe9, ScanCode == 0xe9, keycode == 159
Back - key, press == 0xe0 0x6a, release == 0xe0 0xea, ScanCode == 0xea, keycode == 158
Computer - key, press == 0xe0 0x6b, release == 0xe0 0xeb, ScanCode == 0xeb, keycode == 157
Mail - key, press == 0xe0 0x6c, release == 0xe0 0xec, ScanCode == 0xec, keycode == 155
Media - key, press == 0xe0 0x6d, release == 0xe0 0xed, ScanCode == 0xed, keycode == 226

E0 Scan Code Set 2 - scancodes

Search - key, press == 0xe0 0x10, release == 0xe0 0x90, ScanCode == 0x90, keycode == 217
PreviousSong - key, press == 0xe0 0x15, release == 0xe0 0x95, ScanCode == 0x95, keycode == 165
Bookmarks - key, press == 0xe0 0x18, release == 0xe0 0x98, ScanCode == 0x98, keycode == 156
Refresh - key, press == 0xe0 0x20, release == 0xe0 0xa0, ScanCode == 0xa0, keycode == 173
VolumeDown - key, press == 0xe0 0x21, release == 0xe0 0xa1, ScanCode == 0xa1, keycode == 114
Mute - key, press == 0xe0 0x23, release == 0xe0 0xa3, ScanCode == 0xa3, keycode == 113
Stop - key, press == 0xe0 0x28, release == 0xe0 0xa8, ScanCode == 0xa8, keycode == 128
Calc - key, press == 0xe0 0x2b, release == 0xe0 0xab, ScanCode == 0xab, keycode == 140
Forward - key, press == 0xe0 0x30, release == 0xe0 0xb0, ScanCode == 0xb0, keycode == 159
VolumeUp - key, press == 0xe0 0x32, release == 0xe0 0xb2, ScanCode == 0xb2, keycode == 115
PlayPause - key, press == 0xe0 0x34, release == 0xe0 0xb4, ScanCode == 0xb4, keycode == 164
Power - key, press == 0xe0 0x37, release == 0xe0 0xb7, ScanCode == 0xb7, keycode == 116
Back - key, press == 0xe0 0x38, release == 0xe0 0xb8, ScanCode == 0xb8, keycode == 158
HomePage - key, press == 0xe0 0x3a, release == 0xe0 0xba, ScanCode == 0xba, keycode == 172
StopCD - key, press == 0xe0 0x3b, release == 0xe0 0xbb, ScanCode == 0xbb, keycode == 166
Sleep - key, press == 0xe0 0x3f, release == 0xe0 0xbf, ScanCode == 0xbf, keycode == 142
Computer - key, press == 0xe0 0x40, release == 0xe0 0xc0, ScanCode == 0xc0, keycode == 157
Mail - key, press == 0xe0 0x48, release == 0xe0 0xc8, ScanCode == 0xc8, keycode == 155
NextSong - key, press == 0xe0 0x4d, release == 0xe0 0xcd, ScanCode == 0xcd, keycode == 163
Media - key, press == 0xe0 0x50, release == 0xe0 0xd0, ScanCode == 0xd0, keycode == 226
WakeUp - key, press == 0xe0 0x5e, release == 0xe0 0xde, ScanCode == 0xde, keycode == 143
Pause - key, press == 0xe0 0x77, release == 0xe0 0xf7, ScanCode == 0xf7, keycode == 119
Pause - key, press == 0xe0 0x7e, release == 0xe0 0xfe, ScanCode == 0xfe, keycode == 119

So, for example, if vendor implements keyboard sending by default Scan
Code Set 1 (Translated set 2 mode in atkbd), and he has a hotkey
Play/Pause, then instead of using an arbitrary code he should send the
raw scan code 0xe0 0x22 for press, 0xe0 0xa2 for release, as atkbd
already has a default mapping.

If vendor implements keyboard sending by default Scan Code Set 2, for
Play/Pause the codes should be 0xe0 0x34 / 0xe0 0xb4 (press/release).

I propose above based on documentation I found at
http://www.computer-engineering.org/ps2keyboard/ (explains about scan
codes etc.) and research I did today on atkbd code.

For keys which don't have scan code listed above, we can't do much, we
will have to remap and vendor choose some code, unless someone comes
with some standard for more scan code values, which then we can put into
atkbd keymaps.

To be more clear also, I tested to confirm with my notebook (reports
Scan Code Set 1) which send these standard multimedia scancodes, no
remapping needed. To check raw scan codes sent by keyboard, I did:
echo 0 > /sys/devices/platform/i8042/serio0/softraw
To disable the softraw mode so you can get the raw codes and use evtest:
evtest /dev/input/eventX

When I press the hotkey, I get the raw code, the emulated ScanCode
(index which atkbd uses to get the real input code from keycode array)
and the translated key code. This procedure of disabled softraw and
evtest I found very useful for testing.

If anyones sees something missing or other issue please feel free to add
more information.

--
[]'s
Herton
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2011, 08:04 AM
Andy Whitcroft
 
Default Calling all hotkey expertise...

On Thu, Feb 17, 2011 at 10:15:06PM -0200, Herton Ronaldo Krzesinski wrote:
> Em Qui, 2011-02-17 ąs 12:31 +0000, Colin Ian King escreveu:
> > Thanks Herton,
> >
> > On Thu, 2011-02-10 at 19:58 -0200, Herton Ronaldo Krzesinski wrote:
> > > Em Qui, 2011-02-10 ąs 21:00 +0000, Colin Ian King escreveu:
> > > From what I remember and from experience (correct me if I say something
> > > wrong), vendors usually implement hotkeys:
> > > - using a WMI interface, where a driver needs to be written. The driver
> > > receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
> > > the response/data so if the event is a hotkey it gets a code and
> > > translates it to input layer. It's a lot easier if the vendor gives
> > > information on its WMI implementation, as by nature of ACPI-WMI every
> > > vendor can choose what parameters/format to accept on WMI methods etc.
> >
> > Yep, good one and becoming more frequent. As documented here:
> > https://wiki.ubuntu.com/Kernel/Reference/WMI
> >
> > Personally, I'd like to write a MOF disassembler to extract a high level
> > view of the WMI configuration from the WQxx objects rather than by
> > poking around and figuring out how these work by trial-and-error...
> > when I have time.. :-)
>
> Nice, would be great to have such tool.
>
> I remembered now, there is also the paramters of wmi module that were
> added "recently" to the kernel (2.6.35) and are very useful, specially
> in detecting if the machine has wmi objects and if we are receiving
> things through wmi.
> wmi.debug_dump_wdg=1 to list wmi interfaces
> wmi.debug_event=1 to show on dmesg events we received

Many of these module parameters can be modified via /sys after the
module is loaded. Well they all can, but most have an effect after.
So you might be able to turn these on and off while booted for testing:

echo 1 >/sys/modules/wmi/parameters/debug_event
<testing>
echo 0 >/sys/modules/wmi/parameters/debug_event

Worth a test and adding to the docs if it works.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2011, 08:20 AM
Colin Ian King
 
Default Calling all hotkey expertise...

On Thu, 2011-02-17 at 22:15 -0200, Herton Ronaldo Krzesinski wrote:
> Em Qui, 2011-02-17 ąs 12:31 +0000, Colin Ian King escreveu:
> > Thanks Herton,
> >
> > On Thu, 2011-02-10 at 19:58 -0200, Herton Ronaldo Krzesinski wrote:
> > > Em Qui, 2011-02-10 ąs 21:00 +0000, Colin Ian King escreveu:
> > > From what I remember and from experience (correct me if I say something
> > > wrong), vendors usually implement hotkeys:
> > > - using a WMI interface, where a driver needs to be written. The driver
> > > receives a WMI notification and calls wmi_evaluate_method (WMXX) to get
> > > the response/data so if the event is a hotkey it gets a code and
> > > translates it to input layer. It's a lot easier if the vendor gives
> > > information on its WMI implementation, as by nature of ACPI-WMI every
> > > vendor can choose what parameters/format to accept on WMI methods etc.
> >
> > Yep, good one and becoming more frequent. As documented here:
> > https://wiki.ubuntu.com/Kernel/Reference/WMI
> >
> > Personally, I'd like to write a MOF disassembler to extract a high level
> > view of the WMI configuration from the WQxx objects rather than by
> > poking around and figuring out how these work by trial-and-error...
> > when I have time.. :-)
>
> Nice, would be great to have such tool.
>
> I remembered now, there is also the paramters of wmi module that were
> added "recently" to the kernel (2.6.35) and are very useful, specially
> in detecting if the machine has wmi objects and if we are receiving
> things through wmi.
> wmi.debug_dump_wdg=1 to list wmi interfaces
> wmi.debug_event=1 to show on dmesg events we received

Sweet. The firmware test suite has a WMI dump test:

sudo fwts wmi -

..but no event dumping. That's one I can add by watching for SCIs and
GPEs..

>
> Especially when hotkeys doesn't work, is useful to enable debug_event
> because if it's implemented by wmi, when we press the hotkey information
> will appear on dmesg. May be it isn't useful for vendor documentation,
> but is useful to us and users when hotkeys doesn't work and we want to
> check if it's done by wmi or testing when developing.
>
> > > - sending codes directly via the keyboard controller (so implemented
> > > directly in embedded controller, also some people call it as keyboard
> > > bios, but anyway I think should be on ec firmware). So kernel directly
> > > receive keyboard codes on keyboard input device, no need to extra
> > > driver, but many times the codes have to be remaped on user space to the
> > > real key code meaning/value (udev keymaps)
> >
> > I wonder if there are any standard configurations we can recommend for
> > this
> > method of hotkeys? Any ideas anyone?
>
> Well, I think at least use the common known 0xe0 scan codes for
> multimedia etc. If we look at some of the keymaps in udev, there are
> some multimedia keys which could have been reported using a common known
> scancode which atkbd recognizes (the so called "Windows Multimedia Scan
> Codes"). But instead the vendor chose a non-standard scan code, which
> have to be remmaped.
>
> I did a test program (attached for reference) which prints current
> extended scan codes which atkbd translates to input layer. Here I paste
> only the relevant entries, first column is the key sent to user space
> (last column its respective numeric value):
>
> E0 Scan Code Set 1 - scancodes
>
> PreviousSong - key, press == 0xe0 0x10, release == 0xe0 0x90, ScanCode == 0x90, keycode == 165
> NextSong - key, press == 0xe0 0x19, release == 0xe0 0x99, ScanCode == 0x99, keycode == 163
> Mute - key, press == 0xe0 0x20, release == 0xe0 0xa0, ScanCode == 0xa0, keycode == 113
> Calc - key, press == 0xe0 0x21, release == 0xe0 0xa1, ScanCode == 0xa1, keycode == 140
> PlayPause - key, press == 0xe0 0x22, release == 0xe0 0xa2, ScanCode == 0xa2, keycode == 164
> StopCD - key, press == 0xe0 0x24, release == 0xe0 0xa4, ScanCode == 0xa4, keycode == 166
> VolumeDown - key, press == 0xe0 0x2e, release == 0xe0 0xae, ScanCode == 0xae, keycode == 114
> VolumeUp - key, press == 0xe0 0x30, release == 0xe0 0xb0, ScanCode == 0xb0, keycode == 115
> HomePage - key, press == 0xe0 0x32, release == 0xe0 0xb2, ScanCode == 0xb2, keycode == 172
> Pause - key, press == 0xe0 0x45, release == 0xe0 0xc5, ScanCode == 0xc5, keycode == 119
> Pause - key, press == 0xe0 0x46, release == 0xe0 0xc6, ScanCode == 0xc6, keycode == 119
> Power - key, press == 0xe0 0x5e, release == 0xe0 0xde, ScanCode == 0xde, keycode == 116
> Sleep - key, press == 0xe0 0x5f, release == 0xe0 0xdf, ScanCode == 0xdf, keycode == 142
> WakeUp - key, press == 0xe0 0x63, release == 0xe0 0xe3, ScanCode == 0xe3, keycode == 143
> Search - key, press == 0xe0 0x65, release == 0xe0 0xe5, ScanCode == 0xe5, keycode == 217
> Bookmarks - key, press == 0xe0 0x66, release == 0xe0 0xe6, ScanCode == 0xe6, keycode == 156
> Refresh - key, press == 0xe0 0x67, release == 0xe0 0xe7, ScanCode == 0xe7, keycode == 173
> Stop - key, press == 0xe0 0x68, release == 0xe0 0xe8, ScanCode == 0xe8, keycode == 128
> Forward - key, press == 0xe0 0x69, release == 0xe0 0xe9, ScanCode == 0xe9, keycode == 159
> Back - key, press == 0xe0 0x6a, release == 0xe0 0xea, ScanCode == 0xea, keycode == 158
> Computer - key, press == 0xe0 0x6b, release == 0xe0 0xeb, ScanCode == 0xeb, keycode == 157
> Mail - key, press == 0xe0 0x6c, release == 0xe0 0xec, ScanCode == 0xec, keycode == 155
> Media - key, press == 0xe0 0x6d, release == 0xe0 0xed, ScanCode == 0xed, keycode == 226
>
> E0 Scan Code Set 2 - scancodes
>
> Search - key, press == 0xe0 0x10, release == 0xe0 0x90, ScanCode == 0x90, keycode == 217
> PreviousSong - key, press == 0xe0 0x15, release == 0xe0 0x95, ScanCode == 0x95, keycode == 165
> Bookmarks - key, press == 0xe0 0x18, release == 0xe0 0x98, ScanCode == 0x98, keycode == 156
> Refresh - key, press == 0xe0 0x20, release == 0xe0 0xa0, ScanCode == 0xa0, keycode == 173
> VolumeDown - key, press == 0xe0 0x21, release == 0xe0 0xa1, ScanCode == 0xa1, keycode == 114
> Mute - key, press == 0xe0 0x23, release == 0xe0 0xa3, ScanCode == 0xa3, keycode == 113
> Stop - key, press == 0xe0 0x28, release == 0xe0 0xa8, ScanCode == 0xa8, keycode == 128
> Calc - key, press == 0xe0 0x2b, release == 0xe0 0xab, ScanCode == 0xab, keycode == 140
> Forward - key, press == 0xe0 0x30, release == 0xe0 0xb0, ScanCode == 0xb0, keycode == 159
> VolumeUp - key, press == 0xe0 0x32, release == 0xe0 0xb2, ScanCode == 0xb2, keycode == 115
> PlayPause - key, press == 0xe0 0x34, release == 0xe0 0xb4, ScanCode == 0xb4, keycode == 164
> Power - key, press == 0xe0 0x37, release == 0xe0 0xb7, ScanCode == 0xb7, keycode == 116
> Back - key, press == 0xe0 0x38, release == 0xe0 0xb8, ScanCode == 0xb8, keycode == 158
> HomePage - key, press == 0xe0 0x3a, release == 0xe0 0xba, ScanCode == 0xba, keycode == 172
> StopCD - key, press == 0xe0 0x3b, release == 0xe0 0xbb, ScanCode == 0xbb, keycode == 166
> Sleep - key, press == 0xe0 0x3f, release == 0xe0 0xbf, ScanCode == 0xbf, keycode == 142
> Computer - key, press == 0xe0 0x40, release == 0xe0 0xc0, ScanCode == 0xc0, keycode == 157
> Mail - key, press == 0xe0 0x48, release == 0xe0 0xc8, ScanCode == 0xc8, keycode == 155
> NextSong - key, press == 0xe0 0x4d, release == 0xe0 0xcd, ScanCode == 0xcd, keycode == 163
> Media - key, press == 0xe0 0x50, release == 0xe0 0xd0, ScanCode == 0xd0, keycode == 226
> WakeUp - key, press == 0xe0 0x5e, release == 0xe0 0xde, ScanCode == 0xde, keycode == 143
> Pause - key, press == 0xe0 0x77, release == 0xe0 0xf7, ScanCode == 0xf7, keycode == 119
> Pause - key, press == 0xe0 0x7e, release == 0xe0 0xfe, ScanCode == 0xfe, keycode == 119
>
> So, for example, if vendor implements keyboard sending by default Scan
> Code Set 1 (Translated set 2 mode in atkbd), and he has a hotkey
> Play/Pause, then instead of using an arbitrary code he should send the
> raw scan code 0xe0 0x22 for press, 0xe0 0xa2 for release, as atkbd
> already has a default mapping.
>
> If vendor implements keyboard sending by default Scan Code Set 2, for
> Play/Pause the codes should be 0xe0 0x34 / 0xe0 0xb4 (press/release).
>
> I propose above based on documentation I found at
> http://www.computer-engineering.org/ps2keyboard/ (explains about scan
> codes etc.) and research I did today on atkbd code.
>
> For keys which don't have scan code listed above, we can't do much, we
> will have to remap and vendor choose some code, unless someone comes
> with some standard for more scan code values, which then we can put into
> atkbd keymaps.
>
> To be more clear also, I tested to confirm with my notebook (reports
> Scan Code Set 1) which send these standard multimedia scancodes, no
> remapping needed. To check raw scan codes sent by keyboard, I did:
> echo 0 > /sys/devices/platform/i8042/serio0/softraw
> To disable the softraw mode so you can get the raw codes and use evtest:
> evtest /dev/input/eventX
>
> When I press the hotkey, I get the raw code, the emulated ScanCode
> (index which atkbd uses to get the real input code from keycode array)
> and the translated key code. This procedure of disabled softraw and
> evtest I found very useful for testing.
>
> If anyones sees something missing or other issue please feel free to add
> more information.
>



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 09:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org