On Wed, Apr 9, 2014 at 1:52 PM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:
Dear coreboot folks,
Google Parrot (Acer C7 Chromebook) has the following in `src/mainboard/google/parrot/ec.c` [1].
52 /* US Keyboard */ 53 ec_kbc_write_cmd(0x59); 54 ec_kbc_write_ib(0xE5);If the comment is correct, this is surprising to me in two ways:
- Normally such things are the payload’s or operating system’s job.
In this case, it's telling the EC how to interpret keystrokes it sees on the physical key matrix. For example, pressing a key which asserts a particular column and shorts a particular row will generate a particular keycode, which the EC translates into a byte that is sent to the host as a raw scancode.
From there, the payload or OS can define what the scancode actually means
(e.g. which language encoding to use).
This depends on the particular keyboard matrix which is used with the system. We assume that the keyboard is non-replaceable on a laptop, so it makes sense to set this in firmware.
2. The code is also used for Google Parrots with German keyboards.
Wouldn’t that cause conflicts?
Nah, the placement of keys is basically the same.
There are only a few standard key matrices used. If you look at a US keyboard and a German keyboard, the letters printed on top of the keys may be different in some places but the physical layout is basically the same. It's when you get into things like the Japanese keyboard with 109 keys versus the 13x8=104 key US standard that you need to tell the EC to scan more columns/rows and interpret things differently.
Could somebody please enlighten me? I did not work with embedded controllers yet and I am very interested how that all fits together.
http://pcbheaven.com/wikipages/How_Key_Matrices_Works/
Thanks,
Paul
[1] http://review.coreboot.org/2026
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot