On 22/10/2010 03:26, Kristian Høgsberg wrote:
Now, it's all looking pretty promising, but there are a few open issues I'd like to throw to the list. First of all, there's the issue of how this intersects/dovetails/conflicts with xkb2. Part of the original plan for libxkbcommon as part of xkb2 was to also increase the size of certain datatypes in xkb: bump keycodes and virtual mods to 32 bits. We can't do that with the existing xkb protocol and will require xkb2 protocol with new requests to serialize the xkb descriptions and we need to rethink some of the ways we represent certain state (per keycode repeat info makes a pretty big bit vector for 32 bit keycodes). I don't think that's realistic for a 1.10 xserver release, and I've changed the libxkbcommon structs back to be compatible with the current xkb protocol and implementation. We can extend libxkbcommon to support bigger keycodes and vmods in a later release. It's not going to be as pretty as if we did it all in the first release, but I think there's too much potential here to block it on xkb2.
I can't really speak to the technical issues, but fwiw, I'd also rather not see this get blocked on xkb2, as forking xkbcomp on startup is particularly slow on cygwin due to the expensive fork emulation, and also unfortunately rather brittle.
A couple of minor build fix patches to follow. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
