[PULL libxkbcommon] Some more fixes and minor enhancements

[Michal Suchanek]

On 1 April 2012 17:31, Ran Benita <ran234 at gmail.com> wrote:
> On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote:
>> Hi Ran,
>>
>> On 24 March 2012 15:24, Ran Benita <ran234 at gmail.com> wrote:
>> > There's some unrelated groups of commits here. I've tried to arrange
>> > them such that they can be picked selectively if needed.
>>
>> Great stuff, thanks.  I've pulled most of it, aside from:
>>
>> >      Remove remaining uses of X11/X.h modifier masks
>> >      Duplicate the *MapIndex defines from X11/X.h
>>
>> I'm planning to remove X11 modifier stuff completely, so virtual mods
>> are the only modifiers exposed through the API.  Since some modifiers
>> are more useful than others (e.g. you want your keybindings to be
>> sensitive to the Alt vmod, but not really Left Alt and Right Alt),
>> this would also give an xkb_map_mod_is_primary() flag that specifies
>> whether or not you should ignore it.
>>
>> Either way, the static masks are on their way out.
>
> Sounds great.
>
>> >      Have a sane fallback strcasecmp
>>
>> Eh, if your system doesn't have strcasecmp, then I'm pretty sure it's
>> not my problem.  I've removed the fallback entirely.
>
> Always better. I assume strtok_r is fine as well? I've done a patch for
> that now.
>
>> >      Remove logging implementation boilerplate
>>
>> Funny you should mention this in your commit, I do actually have a
>> context API on the go which would allow you to do this properly, with
>> xkb_context_log_set_fd() and xkb_context_log_set_level().
>
> Hah, I've looked into that, but it seemed like too much messing around
> for a sunny weekend. Do you intend to replace all of the existing
> ACTION, WARN.. with proper logging? That would mean you'd have to get
> your context to all these places, and that seemed too much even for
> our friend xkb_desc.
>
> Also, I might as well mention that I rather like the following interface
> from the libabc demo library (it's public domain):
> https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=blob;f=src/libabc-private.h
>
> Seems a bit better than a set_fd method, since the application may want
> to add its prefix or do some arbitrary crazy stuff.
>
>> > And this is just to make my group switching work. Since it was #ifdef'ed
>> > away, I assume it's not so simple, but from some testing I did it works.
>> >      Handle group lock actions
>>
>> Oh, it probably is that simple, I just hadn't got around to checking
>> it.  (Nor have I checked modifier latching ...)
>>
>> > (Sorry for the code-dump style of this; I can only work on this on the
>> > weekend and holding off seems kinda silly.)
>>
>> No problem, it's all great stuff! I'll try to push at ~end of the day,
>> thanks again.  Sorry in advance about the conflicts -- some of it
>> conflicted with other stuff I'd committed since you branched, and some
>> are caused by the selective cherry-picking.
>>
>> In terms of what I have coming up, aside from the context API and vmod
>> merging, I've got a branch that actually adds multiple-keysym support
>> that I just need to fix up and put in.  After that, my rough TODO list
>> is (rough because I just lost my actual TODO file in a tragic vim swap
>> file accident):
>>     - add support for a ~/.xkb/rules.local and ~/.xkb/keymap.local
>> which would override any definitions in the compiled rules and keymap,
>> respectively
>>     - add a refcnt into the mod/group sections for xkb_state so you
>> can use a single state object across multiple devices, provided they
>> share a keymap
>
> I've wondered (briefly :) about that, the interaction between different
> devices. Say that you hold Shift on one keyboard, should it affect the
> other? In the end I just used a single keymap with one state per device.
> So what's the expected behaviour with multiple keyboards? Maybe I should
> ask these guys: :)
> http://farm4.staticflickr.com/3164/3285787276_34bb157758_z.jpg
> http://www.arubaqth.com/Images/2010_large/R927xi_434_750.jpg
>

I guess the expectations of different people will differ. However,
CapsLock and NumLock are shared in all systems I tried connecting
multiple keyboards to so I don't see why Shift should be different.

Note that there are multi-seat and multi-input configurations so I
guess the modifiers should be shared for one 'input point'. That's not
the same as 'master device' since every 'input point' has master
keyboard and master pointer, unfortunately. Then people who want
independent shifts can split the devices into multiple 'input points',
and for something weird write an app that listens for events in
multiple points and does something weird.

That requires that an application can listen to multiple 'input
points' and tell from which the event came.

Thanks

Michal