RFC: Use libxkbcommon in Xorg

[ext Tiago Vignatti]

On Fri, Oct 29, 2010 at 06:48:43PM +0300, ext Tiago Vignatti wrote:
> Hi Kristian.
> 
> I tried the library. First impression is good - it works :) I had some
> comments bellow though.
> 
> On Fri, Oct 22, 2010 at 04:26:38AM +0200, ext Kristian H�gsberg wrote:
> > 
> > At this point libxkbcommon only depends on xproto (for keycodes and a few
> > other defines) and kbproto. 
> 
> it seems that "only" here is a lot actually. I mean, I thought the real
> motivation of the library was to get rid of X11 dependency, so one could use
> for instance with Wayland. Otherwise, it seems that we would be just moving
> code around. So, the plan next is to keep digging towards the X11 removal or
> what?
> 
> BTW, did you tried already do glue the library with Wayland already?
> 
> 
> > I added a flex generated lexer instead of the handcoded one in xkbcomp -
> > sadly this didn't give much of a performance boost.  It did make it easy to
> > make the compiler read from a string, which avoids messing with pipes/temp
> > files.
> > 
> > The Xorg side of the work is over here:
> > 
> >   http://cgit.freedesktop.org/~krh/xserver/log/?h=xkbcommon
> 
> BTW, I needed this:
> http://people.freedesktop.org/~vignatti/tmp/0001-xkb-fix-missing-xkbcommon-conversion.patch

arrrgh, Dirk Wallenstein just sent the same...

  
> I had also some different warnings on Xorg log, that using xkbcomp I didn't
> have:
> Internal error:   Could not resolve keysym SunProps
> Internal error:   Could not resolve keysym SunFront
> Internal error:   Could not resolve keysym SunOpen
> 
> 
> > and the diffstat for the changes look pretty good:
> > 
> >   [krh at hinata xserver]$ git diff --shortstat origin/master HEAD
> >    66 files changed, 1554 insertions(+), 5845 deletions(-)
> 
> again, this seems a false illusion - if we're still hook up with X prototypes
> then it's just moving things around.
> 
>  
> > 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.
> 
> as the guys already commented on, I'd not expect xkb2 (whatever it will be) to
> release the library.
> 
>  
> > The remaining issues are smaller and easier to sort out;
> > 
> > 1) the libxkbcommon API still needs review cleaning up from an
> > namespace point of view.
> > 
> > 2) I'm considering whether to include a copy of the Xorg keysym under
> > a XKB_KEY_* namespace to break the dependency on xproto?
> 
> I'm in favour, exactly. That what I meant before! :) Then we should get rid of
> kbproto.h also, right?
> 
> BTW, what are you using setxkbmap to change the settings or what? setxkbmap
> seems to be very self-contained, not using much X stuff.
> 
> 
> > 3) Right now libxkbcommon is essentially just an xkb keymap parser
> > library, should we include the xkb state machine logic too (basically
> > the action processing from xkbAction.c and the keysym lookup logic
> > from libX11)? Any user of libxkbcommon (xcb, wayland, clutter with
> > evdev input on kms etc) will have to implement this logic...
> > 
> > 4) One of the big chunks of code left in the xkb modules deals with
> > writing out an xkb keymap based on a struct xkb_desc and a few changes
> > only to then parse it back into a new struct xkb_desc
> > (XkbWriteXKBKeymapForNames followed by xkb_compile_keymap_from_string
> > in XkbDDXLoadKeymapByNames).  If we moved this to libxkbcommon, we
> > could avoid the dump+parse step and just create the struct xkb_desc
> > directly... not sure if it's worth it.
> > 
> > and I'm sure there's more.  Like, exposing an API that's 90% hairy
> > structs is recipe for disaster, but it's kinda late to change that.
> > Anyway, looking forward to some feedback.
> 
> Thanks!
> 
>              Tiago
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
             Tiago