Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 23.06.2014 23:24, schrieb Andreas Färber:
> Am 23.06.2014 22:11, schrieb Benson Leung:
>> On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>>>> Also when the screen stayed on, the embedded controller's keymap seems
>>>> hardcoded to US English with system settings not taking effect; but
>>>> surely we don't want per-keyboard device tree files to remedy that.
>>>
>>> +Benson may be able to answer this.  I believe generally non-US
>>> keyboard layouts are handled at a higher level.
>>
>> There's no such thing as a notion of US versus non-US keyboard layouts
>> at the embedded controller level or even in the kernel. Indeed, this
>> should all be handled in user space.
>>
>> The chromeos firmware and kernel should return the correct key codes
>> for every key pressed on keyboards with the ANSI layout (US based), or
>> ISO (UK and most other countries).
>>
>> The only differences are :
>> * the ISO keyboard has an extra key, which is immediately to the right
>> of the Left Shift key. This must return KEY_102ND key code from the
>> input layer.
>> * the ISO keyboard has a  different location for the | \ key, which
>> accomodates the upside L shaped Enter key on the right side of the
>> keyboard. The keycode for this key is KEY_BACKSLASH.
>>
>> Basically, all of this should be verified using evtest to test that
>> the ec and kernel have the keys right.
> 
> Hm, we may be talking about two different things here? I have been doing
> a minimum system bring-up for 3.16, with openSUSE userspace.
> My YaST-selected system keymap (German with deadkeys) is not taking
> effect on German Spring at the *framebuffer console* (tty1) - evdev is
> not involved at that level AIUI.
> 
> Backspace and L-shaped enter keys work okay. The keymap here should be
> identical to that in the original German device and seemed to match that
> in the exynos5250-snow.dts file.
> 
> I just checked (w/ dp-controller, hdmi, fimd commented out in my patch):
> * An external USB keyboard does not work correctly either.
> * In X11 (xdm), both internal and USB keyboard work as expected.

Another observation: Ctrl+o does not work on the Chromebook keyboard,
whereas o and Shift+o or Ctrl+x do work as expected. On an external USB
keyboard it works just fine. Same at the console and in X11.

Testcases are nano (saving) and gEdit (opening).

I tried the new cros-ec-keyboard.dtsi, no change; and given that the key
itself works okay, I assume it's not the dt linux,keymap.

Anyone any suggestion how to debug?

Thanks,
Andreas

> Similar situation in ChromeOS IIRC, with keymap correct at graphical
> login but not on the right-arrow console - although I don't know the
> ChromeOS userland too well to judge if it was configured correctly.
> 
>> If you are having other problems with keyboard layout being stuck to
>> US QWERTY, please check your user space.
> 
> On my Raspberry Pi for instance, the equivalent openSUSE Factory works
> just fine with German keymap for USB keyboard. Might any related kernel
> config options be missing in exynos_defconfig? Anything in particular I
> should check in user space?
> 
> Cheers,
> Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux