Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Wed, May 09, 2012 at 12:10:57PM -0400, Kristian Høgsberg wrote: > Hi Ran, Hi. > Let me just point you to this branch as well: > > http://cgit.freedesktop.org/~krh/libxkbcommon/log/?h=keysyms > > I've been talking with Daniel about this in IRC, but I thought you > might want to take a look too. With those patches the API is > completely self-contained. We still need xproto, kbproto and > Xfuncproto at compile time, but none of that leaks through the > exported API. This is very nice, thanks. I only have a couple of suggestions, please see the following patches. Also, might be worth mentioning that we now define both XKB_KEY_UP and XKB_KEY_Up (down as well): one for enum xkb_key_direction and one for the keysym. I don't see much room for confusion, though. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Wed, May 09, 2012 at 06:20:35PM +0100, Daniel Stone wrote: > On 9 May 2012 16:13, Ran Benita wrote: > > On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote: > >> Thanks a bunch for all your last changes too, I've merged everything > >> except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests. Again > >> for the Unicode tests I want to use UTF-8 rather than UCS-4 and will > >> get to this really quite soon now I promise (finally have some time to > >> poke back at xkbcommon). > > > > Yes, but I think having UCS-4 makes sense as well, by which I mean that > > are applications (mine..) which have good reasons to use it. Since the > > existing implemantations (the libX11 one and the Markus Kuhn one) > > convert to uint32_t anyway, why not expose it in addition to UTF-8? So > > when you implement it please have a UCS-4 one :) > > Ah, crap, I didn't realise people actually used that outside of > Windows. Yeah, we can do both, I'll get to that RSN (after I've > finished up some Wayland core stuff), and merge Kristian's keysym > stuff at the same time. Windows uses UTF-16, which is indeed crap. One-to-one mapping between the encoding and the codepoint is nice sometimes (and it's what wchar_t uses, outside of Windows at least). > >> autotools makes me sad sometimes. > > > > Didn't know that; good that you caught it. > > While we're here, the -I$(top_builddir)/src/xkbcomp is needed as > parser.h is generated during the build; it's slipped out of your > patches a couple of times and I've had to re-add it. No biggie, but > just so you know. Yes, I didn't notice you reverted it the first time, although I was sure I had changed it :) Anyway thanks for teaching me something (I usually just rely on make distcheck working). > >> Yeah, I think we should have a global file and a per-user override > >> too. I'd like to see the following be possible: > >> * xkbrc (or something): set the default names, which would allow > >> us to pass NULL to the compilation functions and get the default > >> * rules.local: amend the rules file > >> * keymap.local: amend the compiled keymap > >> > >> This way hopefully no-one even remembers xmodmap exists. > > > > This sound good. I might try it some day. > > > > Finally, I had some time today to finish some stuff I started to remove > > more global state. It wasn't very fun but I managed to move > > xkb_intern_atom and friends into the context. I've now also put the > > patch mentioned above, and as always tried to sneak in a stylistic > > change :) It's based on your recent master: > > g...@github.com:bluetech/libxkbcommon.git contextualize > > https://github.com/bluetech/libxkbcommon/tree/contextualize > > Have a look when you've got time. > > Cool! Yeah, I like it and have merged it. Hilariously, at almost the > exact point in time (this morning, while I was on the train with no > internet access) you were changing context to ctx, I was changing xkb > (for xkb_keymaps) everywhere to keymap. So I've merged this now but > there were a pretty staggering amount of conflicts. Still, I now have > everything on your contextualize branch. > > I think the only API issue I have now is renaming groups to layouts. > There's still a few bits internally but hopefully we should be good to > go pretty soon. > > Since our trees seem to have mostly settled down by now, any > objections to me running uncrustify after I merge the keysym -> > Unicode stuff? Absolutely no objections. It might even make the code in rules.c readable :) Thanks for merging and handling the conflicts! ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi, On 9 May 2012 16:13, Ran Benita wrote: > On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote: >> Thanks a bunch for all your last changes too, I've merged everything >> except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests. Again >> for the Unicode tests I want to use UTF-8 rather than UCS-4 and will >> get to this really quite soon now I promise (finally have some time to >> poke back at xkbcommon). > > Yes, but I think having UCS-4 makes sense as well, by which I mean that > are applications (mine..) which have good reasons to use it. Since the > existing implemantations (the libX11 one and the Markus Kuhn one) > convert to uint32_t anyway, why not expose it in addition to UTF-8? So > when you implement it please have a UCS-4 one :) Ah, crap, I didn't realise people actually used that outside of Windows. Yeah, we can do both, I'll get to that RSN (after I've finished up some Wayland core stuff), and merge Kristian's keysym stuff at the same time. >> autotools makes me sad sometimes. > > Didn't know that; good that you caught it. While we're here, the -I$(top_builddir)/src/xkbcomp is needed as parser.h is generated during the build; it's slipped out of your patches a couple of times and I've had to re-add it. No biggie, but just so you know. >> Yeah, I think we should have a global file and a per-user override >> too. I'd like to see the following be possible: >> * xkbrc (or something): set the default names, which would allow >> us to pass NULL to the compilation functions and get the default >> * rules.local: amend the rules file >> * keymap.local: amend the compiled keymap >> >> This way hopefully no-one even remembers xmodmap exists. > > This sound good. I might try it some day. > > Finally, I had some time today to finish some stuff I started to remove > more global state. It wasn't very fun but I managed to move > xkb_intern_atom and friends into the context. I've now also put the > patch mentioned above, and as always tried to sneak in a stylistic > change :) It's based on your recent master: > g...@github.com:bluetech/libxkbcommon.git contextualize > https://github.com/bluetech/libxkbcommon/tree/contextualize > Have a look when you've got time. Cool! Yeah, I like it and have merged it. Hilariously, at almost the exact point in time (this morning, while I was on the train with no internet access) you were changing context to ctx, I was changing xkb (for xkb_keymaps) everywhere to keymap. So I've merged this now but there were a pretty staggering amount of conflicts. Still, I now have everything on your contextualize branch. I think the only API issue I have now is renaming groups to layouts. There's still a few bits internally but hopefully we should be good to go pretty soon. Since our trees seem to have mostly settled down by now, any objections to me running uncrustify after I merge the keysym -> Unicode stuff? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi Ran,
Let me just point you to this branch as well:
http://cgit.freedesktop.org/~krh/libxkbcommon/log/?h=keysyms
I've been talking with Daniel about this in IRC, but I thought you
might want to take a look too. With those patches the API is
completely self-contained. We still need xproto, kbproto and
Xfuncproto at compile time, but none of that leaks through the
exported API.
Krisitian
On Wed, May 9, 2012 at 11:13 AM, Ran Benita wrote:
> On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
>> Hi Ran,
>> Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.
>
> Hi!
>
>> Thanks a bunch for all your last changes too, I've merged everything
>> except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests. Again
>> for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
>> get to this really quite soon now I promise (finally have some time to
>> poke back at xkbcommon).
>
> Yes, but I think having UCS-4 makes sense as well, by which I mean that
> are applications (mine..) which have good reasons to use it. Since the
> existing implemantations (the libX11 one and the Markus Kuhn one)
> convert to uint32_t anyway, why not expose it in addition to UTF-8? So
> when you implement it please have a UCS-4 one :)
>
>> As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
>> unfortunately it's the only way for it to work properly, since just
>> substituting from within configure doesn't always perform enough
>> expansion. On some versions you'll be left with the string being
>> "${datarootdir}/share/X11/xkb" or similar. The 'fix' there is to just
>> do more rounds of expansion, but the upstream-recommended method is
>> actually to do it as we're doing it now, believe it or not.
>>
>> autotools makes me sad sometimes.
>
> Didn't know that; good that you caught it.
>
>> As for the rest -
>>
>> On 11 April 2012 19:58, Ran Benita wrote:
>> > On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
>> >> Right, so allow it to call through arbitrary function pointers? I was
>> >> considering doing that, but wasn't particularly feeling like dealing
>> >> with the intracacies of varargs again that day.
>> >
>> > Varags aren't so bad. I had some fun abusing them here:
>> > https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
>> > That said, you can look at the libabc example code, if you think that's
>> > a better approach.
>>
>> Yeah, the tests look really good and we should definitely be doing
>> that, I'm going to merge in a really minimal dataset too so we're not
>> relying on an installed dataset for all our tests. At that point we
>> can go all-out and throw in a lot more tests for esoteric stuff like
>> locking modifiers.
>>
>> I don't know if I'll have too much time to poke at the log stuff
>> anytime soon, but it definitely sounds good.
>>
>> >> I'd like to be able to support full dumps (e.g. generated from xkbcomp
>> >> -xkb :0 foo.txt) being loaded in to xkbcommon without triggering
>> >> parsing errors because it doesn't have natural support for floats.
>> >> That was the best way I found to do that; is there something I'm
>> >> missing?
>> >
>> > Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
>> > sections (which we treat as files). So the scanner should be able to lex
>> > them, but the parser can just skip the section and not have to know
>> > anything "inside" it. I'm not sure yacc does that off hand, I'll try it.
>> > Of course, it may be worth keeping for completeness or whatever.
>>
>> Hmm. If it works then it'd definitely be a net win. :)
>
> Of course I didn't take a compiler class yet and so I hadn't realized
> yacc does bottom-up parsing, making this impossible... (at least in a
> straightforward way)
>
>> > Another question than :) We currently support three types of "aggregate"
>> > files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
>> > can include all components (i.e. keycodes, symbols...), and the other
>> > two only one or two (mandatory / optional - see XKBcommonint.h
>> > #defines). Looking in /usr/share/X11/xkb, the layout type is completely
>> > unused, and there are a couple semantics files (which seem unused). So,
>> > is it worth keeping those? I don't think they serve any useful purpose?
>> > (unless someone tries to load them, but I don't think anyone has them
>> > lying around).
>>
>> No, we can jettison the other two. In theory we need them for
>> compatibility, but in reality they don't exist and I don't care.
>
> I have done this now. I've kept backward compatibility by just treating
> them as xkb_keymap in the parser. See the branch below.
>
>> > And lastly (I promise :), I'm thinking about a situation where there are
>> > several users of the library (say xserver, wayland/weston, kmscon,
>> > toolkits) and they all load a keymap from an rmlvo. Currently it seems
>> > like the end user would have to configure her preferred rmlvo separately
>> > for each one,
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Tue, May 08, 2012 at 05:35:23PM +0100, Daniel Stone wrote:
> Hi Ran,
> Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.
Hi!
> Thanks a bunch for all your last changes too, I've merged everything
> except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests. Again
> for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
> get to this really quite soon now I promise (finally have some time to
> poke back at xkbcommon).
Yes, but I think having UCS-4 makes sense as well, by which I mean that
are applications (mine..) which have good reasons to use it. Since the
existing implemantations (the libX11 one and the Markus Kuhn one)
convert to uint32_t anyway, why not expose it in addition to UTF-8? So
when you implement it please have a UCS-4 one :)
> As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
> unfortunately it's the only way for it to work properly, since just
> substituting from within configure doesn't always perform enough
> expansion. On some versions you'll be left with the string being
> "${datarootdir}/share/X11/xkb" or similar. The 'fix' there is to just
> do more rounds of expansion, but the upstream-recommended method is
> actually to do it as we're doing it now, believe it or not.
>
> autotools makes me sad sometimes.
Didn't know that; good that you caught it.
> As for the rest -
>
> On 11 April 2012 19:58, Ran Benita wrote:
> > On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
> >> Right, so allow it to call through arbitrary function pointers? I was
> >> considering doing that, but wasn't particularly feeling like dealing
> >> with the intracacies of varargs again that day.
> >
> > Varags aren't so bad. I had some fun abusing them here:
> > https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
> > That said, you can look at the libabc example code, if you think that's
> > a better approach.
>
> Yeah, the tests look really good and we should definitely be doing
> that, I'm going to merge in a really minimal dataset too so we're not
> relying on an installed dataset for all our tests. At that point we
> can go all-out and throw in a lot more tests for esoteric stuff like
> locking modifiers.
>
> I don't know if I'll have too much time to poke at the log stuff
> anytime soon, but it definitely sounds good.
>
> >> I'd like to be able to support full dumps (e.g. generated from xkbcomp
> >> -xkb :0 foo.txt) being loaded in to xkbcommon without triggering
> >> parsing errors because it doesn't have natural support for floats.
> >> That was the best way I found to do that; is there something I'm
> >> missing?
> >
> > Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
> > sections (which we treat as files). So the scanner should be able to lex
> > them, but the parser can just skip the section and not have to know
> > anything "inside" it. I'm not sure yacc does that off hand, I'll try it.
> > Of course, it may be worth keeping for completeness or whatever.
>
> Hmm. If it works then it'd definitely be a net win. :)
Of course I didn't take a compiler class yet and so I hadn't realized
yacc does bottom-up parsing, making this impossible... (at least in a
straightforward way)
> > Another question than :) We currently support three types of "aggregate"
> > files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
> > can include all components (i.e. keycodes, symbols...), and the other
> > two only one or two (mandatory / optional - see XKBcommonint.h
> > #defines). Looking in /usr/share/X11/xkb, the layout type is completely
> > unused, and there are a couple semantics files (which seem unused). So,
> > is it worth keeping those? I don't think they serve any useful purpose?
> > (unless someone tries to load them, but I don't think anyone has them
> > lying around).
>
> No, we can jettison the other two. In theory we need them for
> compatibility, but in reality they don't exist and I don't care.
I have done this now. I've kept backward compatibility by just treating
them as xkb_keymap in the parser. See the branch below.
> > And lastly (I promise :), I'm thinking about a situation where there are
> > several users of the library (say xserver, wayland/weston, kmscon,
> > toolkits) and they all load a keymap from an rmlvo. Currently it seems
> > like the end user would have to configure her preferred rmlvo separately
> > for each one, which can get annoying (already..). Since you mentioned
> > loading files from ~/.xkb/, would it make sense to support some simple
> > config file for that? That way if the end user didn't explicitly
> > override through the application, and the config file exists, it should
> > be used as the default instead of some "us" layout.
> >
> > And if it makes sense, should libxkbcommon be the one doing it anyway?
>
> Yeah, I think we should have a global file and a per-user override
> too. I'd like to see the following be possible:
> * xkbrc
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi Ran,
Sorry for the delay, have been sidetracked by core Wayland stuff for a bit.
Thanks a bunch for all your last changes too, I've merged everything
except the DFLT_XKB_CONFIG_ROOT change and the Unicode tests. Again
for the Unicode tests I want to use UTF-8 rather than UCS-4 and will
get to this really quite soon now I promise (finally have some time to
poke back at xkbcommon).
As for the DFLT_XKB_CONFIG_ROOT change, it's ugly as sin but
unfortunately it's the only way for it to work properly, since just
substituting from within configure doesn't always perform enough
expansion. On some versions you'll be left with the string being
"${datarootdir}/share/X11/xkb" or similar. The 'fix' there is to just
do more rounds of expansion, but the upstream-recommended method is
actually to do it as we're doing it now, believe it or not.
autotools makes me sad sometimes.
As for the rest -
On 11 April 2012 19:58, Ran Benita wrote:
> On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote:
>> Right, so allow it to call through arbitrary function pointers? I was
>> considering doing that, but wasn't particularly feeling like dealing
>> with the intracacies of varargs again that day.
>
> Varags aren't so bad. I had some fun abusing them here:
> https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c
> That said, you can look at the libabc example code, if you think that's
> a better approach.
Yeah, the tests look really good and we should definitely be doing
that, I'm going to merge in a really minimal dataset too so we're not
relying on an installed dataset for all our tests. At that point we
can go all-out and throw in a lot more tests for esoteric stuff like
locking modifiers.
I don't know if I'll have too much time to poke at the log stuff
anytime soon, but it definitely sounds good.
>> I'd like to be able to support full dumps (e.g. generated from xkbcomp
>> -xkb :0 foo.txt) being loaded in to xkbcommon without triggering
>> parsing errors because it doesn't have natural support for floats.
>> That was the best way I found to do that; is there something I'm
>> missing?
>
> Hmm, if I get it right, floats etc, can only appear inside xkb_geometry
> sections (which we treat as files). So the scanner should be able to lex
> them, but the parser can just skip the section and not have to know
> anything "inside" it. I'm not sure yacc does that off hand, I'll try it.
> Of course, it may be worth keeping for completeness or whatever.
Hmm. If it works then it'd definitely be a net win. :)
> Another question than :) We currently support three types of "aggregate"
> files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap
> can include all components (i.e. keycodes, symbols...), and the other
> two only one or two (mandatory / optional - see XKBcommonint.h
> #defines). Looking in /usr/share/X11/xkb, the layout type is completely
> unused, and there are a couple semantics files (which seem unused). So,
> is it worth keeping those? I don't think they serve any useful purpose?
> (unless someone tries to load them, but I don't think anyone has them
> lying around).
No, we can jettison the other two. In theory we need them for
compatibility, but in reality they don't exist and I don't care.
> And lastly (I promise :), I'm thinking about a situation where there are
> several users of the library (say xserver, wayland/weston, kmscon,
> toolkits) and they all load a keymap from an rmlvo. Currently it seems
> like the end user would have to configure her preferred rmlvo separately
> for each one, which can get annoying (already..). Since you mentioned
> loading files from ~/.xkb/, would it make sense to support some simple
> config file for that? That way if the end user didn't explicitly
> override through the application, and the config file exists, it should
> be used as the default instead of some "us" layout.
>
> And if it makes sense, should libxkbcommon be the one doing it anyway?
Yeah, I think we should have a global file and a per-user override
too. I'd like to see the following be possible:
* xkbrc (or something): set the default names, which would allow
us to pass NULL to the compilation functions and get the default
* rules.local: amend the rules file
* keymap.local: amend the compiled keymap
This way hopefully no-one even remembers xmodmap exists.
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Mon, Apr 02, 2012 at 12:04:25PM +0100, Daniel Stone wrote: > Hi, > > On 1 April 2012 16:31, Ran Benita wrote: > > 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. > > Right, so allow it to call through arbitrary function pointers? I was > considering doing that, but wasn't particularly feeling like dealing > with the intracacies of varargs again that day. Varags aren't so bad. I had some fun abusing them here: https://github.com/bluetech/libxkbcommon/blob/tests2/test/keyseq.c That said, you can look at the libabc example code, if you think that's a better approach. > > Semi-related quastion: why did you leave the geometry bits in the > > parser? Would it not be enough to just skip the entire XkbFile if its > > type is geometry? > > I'd like to be able to support full dumps (e.g. generated from xkbcomp > -xkb :0 foo.txt) being loaded in to xkbcommon without triggering > parsing errors because it doesn't have natural support for floats. > That was the best way I found to do that; is there something I'm > missing? Hmm, if I get it right, floats etc, can only appear inside xkb_geometry sections (which we treat as files). So the scanner should be able to lex them, but the parser can just skip the section and not have to know anything "inside" it. I'm not sure yacc does that off hand, I'll try it. Of course, it may be worth keeping for completeness or whatever. Another question than :) We currently support three types of "aggregate" files, which are xkb_keymap, xkb_layout and xkb_semantics. The keymap can include all components (i.e. keycodes, symbols...), and the other two only one or two (mandatory / optional - see XKBcommonint.h #defines). Looking in /usr/share/X11/xkb, the layout type is completely unused, and there are a couple semantics files (which seem unused). So, is it worth keeping those? I don't think they serve any useful purpose? (unless someone tries to load them, but I don't think anyone has them lying around). > >> Did you have anything else in mind that you needed, especially with > >> the structs/macros having been sealed now? > > > > Well, since you ask :) Something I've done twice now already is to > > implement a keysym-to-unicode function, using either the imKStoUCS.c > > file from libX11 or the keysym2ucs.c file from Markus Khan: > > https://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c > > > > Would you consider importing one of these and adding a > > xkb_keysym_to_ucs4 or xkb_keysym_to_unicode function? It's not directly > > related to XKB but quite useful for the library users. > > Yeah, absolutely, that'd be pretty useful indeed. Bonus points for > (also?) having a xkb_keysymS_to_utf8. :) And lastly (I promise :), I'm thinking about a situation where there are several users of the library (say xserver, wayland/weston, kmscon, toolkits) and they all load a keymap from an rmlvo. Currently it seems like the end user would have to configure her preferred rmlvo separately for each one, which can get annoying (already..). Since you mentioned loading files from ~/.xkb/, would it make sense to support some simple config file for that? That way if the end user didn't explicitly override through the application, and the config file exists, it should be used as the default instead of some "us" layout. And if it makes sense, should libxkbcommon be the one doing it anyway? Thanks! Ran ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi, On 2 April 2012 11:30, Michal Suchanek wrote: > 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. Yes, XI2 supports that exact situation you've described (with some small caveats, but the state from pointer events is derived from the state of its associated master keyboard), and Wayland will do so more directly. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi, On 1 April 2012 16:31, Ran Benita wrote: > On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote: >> > 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. Sure. :) It's been available in both Linux and BSD for some time now, and is in 2001 POSIX, so why not. >> > 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. Well, since an xkb_desc is necessarily generated from a context, it would 'just' be a matter of an enormous regex, and then getting indent/uncrustify to clean up the result. But yes, definitely a job for a rainy day. :) > 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. Right, so allow it to call through arbitrary function pointers? I was considering doing that, but wasn't particularly feeling like dealing with the intracacies of varargs again that day. >> - 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 The answer is '??'. It really depends; Wayland will want to share state between all devices in the same group, X generates events twice and keeps separate state for master (aggregate) and slave (individual) devices, some people will want to keep state completely separate across all keyboards, etc. Since there's no universally correct answer, I'd rather support both and let the user decide on the policy. (The really comic one is when you have footpedals, for disabled users to be able to trigger modifiers with a separate foot device, then type keys on a normal keyboard!) >> - more warnings when compiling a keymap which uses >> deprecated/removed functionality (e.g. message/redirect actions, >> non-default key behaviours) > > Semi-related quastion: why did you leave the geometry bits in the > parser? Would it not be enough to just skip the entire XkbFile if its > type is geometry? I'd like to be able to support full dumps (e.g. generated from xkbcomp -xkb :0 foo.txt) being loaded in to xkbcommon without triggering parsing errors because it doesn't have natural support for floats. That was the best way I found to do that; is there something I'm missing? >> Did you have anything else in mind that you needed, especially with >> the structs/macros having been sealed now? > > Well, since you ask :) Something I've done twice now already is to > implement a keysym-to-unicode function, using either the imKStoUCS.c > file from libX11 or the keysym2ucs.c file from Markus Khan: > https://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c > > Would you consider importing one of these and adding a > xkb_keysym_to_ucs4 or xkb_keysym_to_unicode function? It's not directly > related to XKB but quite useful for the library users. Yeah, absolutely, that'd be pretty useful indeed. Bonus points for (also?) having a xkb_keysymS_to_utf8. :) Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On 1 April 2012 17:31, Ran Benita wrote: > On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote: >> Hi Ran, >> >> On 24 March 2012 15:24, Ran Benita 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 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Wed, Mar 28, 2012 at 07:07:57PM +0100, Daniel Stone wrote: > Hi, > > On 27 March 2012 14:59, Daniel Stone wrote: > > 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): > > Found my TODO list! Hurrah for incremental backups. > > The only major item, aside from getting as independent from X11 as > possible (although I'm loathe to duplicate the keysym headers, so > xproto might remain as a build dependency, but not runtime), is to > rename xkb_desc to xkb_keymap, and reindent the whole codebase, likely > to the same settings as the X server. > > Obviously I'll hold off the reindent until neither of us have any > outstanding changes or branches to merge, so let me know when would be > a good time for you. I don't have any private branches which didn't fail miserably. I do have a branch with some changes to the test suite and fixes for subsequently found bugs. I'll rebase and send a pull request once you push your latest changes. (The branch is here btw: https://github.com/bluetech/libxkbcommon/tree/tests The big commit should probably be split but I'm lazy..). In other words, don't hold the reindent for me. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
On Tue, Mar 27, 2012 at 02:59:13PM +0100, Daniel Stone wrote: > Hi Ran, > > On 24 March 2012 15:24, Ran Benita 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 > - more warnings when compiling a keymap which uses > deprecated/removed functionality (e.g. message/redirect actions, > non-default key behaviours) Semi-related quastion: why did you leave the geometry bits in the parser? Would it not be enough to just skip the entire XkbFile if its type is geometry? > - xkb_map_foreach_mod() and xkb_state_foreach_active_mod() API + > the group equivalents > - some other stuff which I've subsequently forgotten ... damnit ... > - any additions/changes needed to make a GTK+ port work ;) > Did you have anything else in mind that you needed, especially with > the structs/macros having been sealed now? Well, since you ask :) Something I've done twice now already is to implement a keysym-to-unicode function, using either the imKStoUCS.c file from libX11 or the keysym2ucs.c file from Markus Khan: https://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c Would you consider importing one of these and adding a xkb_keysym_to_ucs4 or xkb_keysym_to_unicode function? It's not directly related to XKB but quite useful for the library users. > Cheers, > Daniel Thanks! Ran ___ xorg-devel@lists.x.org:
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi, On 27 March 2012 14:59, Daniel Stone wrote: > 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): Found my TODO list! Hurrah for incremental backups. The only major item, aside from getting as independent from X11 as possible (although I'm loathe to duplicate the keysym headers, so xproto might remain as a build dependency, but not runtime), is to rename xkb_desc to xkb_keymap, and reindent the whole codebase, likely to the same settings as the X server. Obviously I'll hold off the reindent until neither of us have any outstanding changes or branches to merge, so let me know when would be a good time for you. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL libxkbcommon] Some more fixes and minor enhancements
Hi Ran, On 24 March 2012 15:24, Ran Benita 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. > 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. > 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(). > 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 - more warnings when compiling a keymap which uses deprecated/removed functionality (e.g. message/redirect actions, non-default key behaviours) - xkb_map_foreach_mod() and xkb_state_foreach_active_mod() API + the group equivalents - some other stuff which I've subsequently forgotten ... damnit ... - any additions/changes needed to make a GTK+ port work ;) Did you have anything else in mind that you needed, especially with the structs/macros having been sealed now? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL libxkbcommon] Some more fixes and minor enhancements
There's some unrelated groups of commits here. I've tried to arrange
them such that they can be picked selectively if needed.
The following commits are simple bug fixes and cleanup:
Mention xkb_state_new can return NULL
Properly free xkb_state's
Fix latin8 upper/lower case check
Update gitignore for 'state' test
Fix incorrect usage of && instead of &
Add xkb test file to EXTRA_DIST
Remove a few remaining uses of the KeySym type
Remove remaining uses of X11/X.h modifier masks
Fix a scanf type mismatch
These are meant to clean up the helper util files to something more
reasonable and less ancient-looking:
Move utils.{c,h} to be used by the entire project
Have a sane fallback strcasecmp
Remove useless stuff from utils
Rewrite recalloc to the correct type
Remove some more useless stuff
Move utility macro from XKBcommonint.h to utils.h
Use strcasecmp consistently instead of uStrCaseCmp
Remove logging implementation boilerplate
Fixes some warning, nice to have:
Silence -Wcast-qual warnings
Fix all -Wsign-compare warnings
Some changes to reduce libxkbcommon dependency on xproto a bit. Not
entirely sure if duplicating NoSymbol is the right thing, but did it
anyway.
Define our own None atom value
Duplicate the *MapIndex defines from X11/X.h
Define our own NoSymbol value and use it
Replace XKB_COMMON_ prefix with XKB_
This turns consolidated the makefiles to a single non recursive one. I
thought I'd give it a shot :)
Make build non-recursive
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
(Sorry for the code-dump style of this; I can only work on this on the
weekend and holding off seems kinda silly.)
Thanks,
Ran
The following changes since commit 3d672fcfea6b823db4793b9ad1c3aadc4b547a08:
Add LED state API (2012-03-22 14:32:53 +)
[...]
are available in the git repository at:
https://github.com/bluetech/libxkbcommon for-daniel
for you to fetch changes up to c91e5c2878b309d4972e79ae688a9f279183:
Handle group lock actions (2012-03-24 16:39:08 +0200)
.gitignore|2 +
Makefile.am | 76 -
configure.ac | 14 +--
include/Makefile.am |1 -
include/xkbcommon/xkbcommon.h | 21 ++--
makekeys/Makefile.am |8 --
makekeys/makekeys.c | 22 ++--
src/Makefile.am | 29 -
src/XKBcommonint.h| 24 ++--
src/alloc.c | 54 -
src/atom.c| 12 +-
src/geom.c| 176
src/keysym.c | 11 +-
src/malloc.c | 59 +-
src/map.c | 22 ++--
src/maprules.c| 62 +-
src/misc.c| 48
src/state.c | 44 ++-
src/text.c|2 +-
src/utils.c | 102 +
src/utils.h | 87 ++
src/xkballoc.h|5 +-
src/xkbcomp/Makefile.am | 37 --
src/xkbcomp/action.c | 10 +-
src/xkbcomp/compat.c | 47
src/xkbcomp/expr.c| 46
src/xkbcomp/indicators.c | 35 +++---
src/xkbcomp/keycodes.c| 28 ++---
src/xkbcomp/keytypes.c| 42 +++
src/xkbcomp/misc.c|8 +-
src/xkbcomp/misc.h|2 +-
src/xkbcomp/parseutils.c | 16 +--
src/xkbcomp/symbols.c | 132 ++---
src/xkbcomp/utils.c | 252 -
src/xkbcomp/utils.h | 163 --
src/xkbcomp/vmod.c|1 -
src/xkbcomp/xkbcomp.c |7 +-
src/xkbcomp/xkbcomp.h | 16 +--
src/xkbcomp/xkbparse.y|8 +-
src/xkbcomp/xkbpath.c | 22 ++--
src/xkbcomp/xkbpath.h |1 -
src/xkbcomp/xkbscan.l |3 +-
src/xkbmisc.h |3 +-
src/xkbrules.h|3 -
test/.gitignore |1 +
test/Makefile.am |7 +-
test/filecomp.c |4 +-
test/namescomp.c |4 +-
test/rulescomp.c |3 +-
test/state.c |4 +-
test/xkey.c |8 +-
51 files changed, 705 insertions(+), 1089 deletions(-)
delete mode 100644 include/Makefile.am
create mode 100644 m4/.gitkeep
delete mode 100644 makekeys/Makefile.am
delete mode 100644 src/Makefile.am
delete mode 100644 src/geom.c
create mode 100644 src/utils.c
create mode 100644 src/utils.h
delete mode 100644 src/xkbcomp/Makefile.am
de
