[PATCH v3 0/9] Hardware keyboard input for input methods v3

[Jan Arne Petersen]

On 11/28/2012 03:50 AM, Kristian Høgsberg wrote:
> On Tue, Nov 27, 2012 at 03:11:17PM -0500, Kristian Høgsberg wrote:
>> On Sun, Nov 18, 2012 at 07:06:41PM +0100, Jan Arne Petersen wrote:
>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>>
>>>>>>   text: Rename and extend text_model key event
>>>>> I'm holding off on this one and the remaining patches.  I think you're
>>>>> right that it's better to just add the events to text_model, but
>>>>> there's more to it than that.  We need a better approach to modifiers
>>>>> than what you have in the keysym event.  It needs to be compatible
>>>>> with the wl_keyboard modifier model.  That's a bitmask too, but you
>>>>> need the xkb keymap to understand what the bits mean
>>>>> (xkb_map_mod_get_index).  So we could add a keymap event to
>>>>> text_model, but it's a little expensive to send out and re-parse the
>>>>> xkb map, so I'd rather the text_model could grab it from the
>>>>> associated wl_keyboard (from wl_seat in text_model.enter).  I'd also
>>>>> rather use a modifier event like wl_keyboard than send the modifiers
>>>>> with each keysym event.
>>>>>
>>>>> Now if we use the keymap from the associated wl_seat, have a modifier
>>>>> event and the keysym event, do we still need text_model.get_keyboard?
>>>>> Do we ever need the key codes at this level?  And if we do, can we
>>>>> just get them from the real wl_keyboard?  That is, send out the
>>>>> keycode from wl_keyboard interface and the keysym from text_model?
>>>>>
>>>>> Hmm, and if we rely on wl_keyboard in text_model (for the keymap)
>>>>> should we just get modifier events from wl_keyboard as well?  That is,
>>>>> we only add the keysym event to text_model and keymap and modifiers
>>>>> come from the underlying wl_keyoard.
>>>>
>>>> My current idea would be to add a modifier_names event to text_model, so
>>>> that an input method sends an array of known modifier names (which would
>>>> be the same used by xkb_keymap_mod_get_index). The mapping to a bitmask 
>>>> is than just done by the index of that modifier name in the array.
>>>
>>> I implemented it that way in this patch series.
>>
>> Yup, it looks fine now.  I ended up moving a few things around in the
>> weston-simple-im client.  Mainly I removed the keyboard-utils.[ch]
>> split and just included that in weston-simple-im, and removing the
>> extra abstraction layer.  The other change was making it not depend on
>> toytoolkit.  With these changes, I think weston-simple-im could be
>> developed into a real-world table based IM.
> 
> Oh, just realized a problem with the way we grab the keyboard: when
> the IM grabs the keyboard, we block compositor keybindings.
> Ctrl-Alt-Backspace and the debug bindings (Shift-Mod-Space S etc)
> don't work while the editor fields has focus.

Oh yes, there is only ever one active grab. We could modify the
default_grab in text-backend instead of using wl_keyboard_start_grab,
but I am not sure that is a good solution. I will create a patch so we
can see from there.

Jan Arne

-- 
Jan Arne Petersen
Openismus GmbH
http://www.openismus.com