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

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

 



On Tue, Jul 1, 2014 at 9:18 PM, Andreas Färber <afaerber@xxxxxxx> wrote:
> 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?

I guess Ctrl+U is not working either.

That's the combination of 2 factors :
a. a magic feature on Spring
b. a pre-existing bug in the cros_ec_keyb keyboard driver

a. On Spring, the AC adapter events are exported as a virtual key in
the keyboard matrix
(mapped as KEY_BATTERY in the ChromeOS kernel)
b. the de-ghosting algorithm in the driver is slightly wrong.

In your case, the driver is seeing a (non existing) ghost when Ctrl +
O + KEY_BATTERY are pressed, and discarding the key press. As
KEY_BATTERY is a virtual key, this ghost obviously cannot exist.
To verify that hypothesis, you can try to disconnect your charger (or
connect it), and see if the key combination is now working.

We might need to upstream a patch similar to :
https://chromium-review.googlesource.com/#/c/178539/
to fix the de-ghosting and exclude KEY_BATTERY.

>> 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