2010/10/26 Jon TURNEY <jon.tur...@dronecode.org.uk>: > > > 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.
Indeed, it should be an even bigger win on windows. > A couple of minor build fix patches to follow. Thanks, applied, though I didn't see the 2/2 patch for Xorg - stuck in moderation somewhere? Kristian _______________________________________________ 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