2012/5/1 Sergey Udaltsov <sergey.udalt...@gmail.com>: > XI2 does not exactly override XKB, functionally. So there must be some > kind of cooperation.
I didn't want to imply that. What I meant was that XI2 provides with better and more forward compatible event structures, that allow us to lift the restriction. > So, what does happen in xterm when the group number in xinput2 is 5? > How should X server be configured in order to provide 5 layouts from > xkeyboard-config? Obviously, this should be done on the server side, > not on the client side. For events, I'm not sure yet One possibility is to let old XKB behavior (XkbSetControls and GroupWrap) control this for legacy apps (so they would still see only 4 groups), while it would have no effect on new applications. If needed, a new request or event mask can be added to enable the extra groups on XI2/Xkb-aware apps. For keymap manipulation (so the XKB extension proper), I'd say it's not a backward-incompatible change to have XkbGetMap return keymaps with groups higher than 4, and same for XkbSetMap, although that needs testing. The xserver, xkeyboard-config, libxkbcommon, libxklavier, libgnomekbd and other internal libraries will of course need changes, as you for example will be compiling 5 groups instead of 4, but what I'm mostly concerned with it is not adding more protocol, so that applications (as opposed to session components) will work without changes. Giovanni > On Tue, May 1, 2012 at 2:00 PM, Giovanni Campagna > <scampa.giova...@gmail.com> wrote: >> 2012/5/1 Matthias Clasen <matthias.cla...@gmail.com>: >>> On Tue, May 1, 2012 at 7:12 AM, Giovanni Campagna >>> <scampa.giova...@gmail.com> wrote: >>> >>> >>>> >>>> So, assuming this is indeed a limit that we want to fix, why not >>>> fixing at the right level, i.e. Xorg? >>>> I recently looked at the Xkb and XI2 protocols, and I saw no >>>> particular limitations to using more than 4 groups (up to 255, which >>>> is a much more reasonable limit). There is indeed a limitation in the >>>> core protocol, but that's only used by legacy applications. >>>> In any case, I believe this discussion should be moved to xorg-devel, >>>> as the proposed solution (setxkbmap equivalent) not only has >>>> performance regressions, it will also cause problems with keybindings >>>> in non-latin layouts, as applications will no longer have another >>>> latin group to fallback on. >>> >>> The problem is that xkb uses 2 bits in the core event state mask to >>> communicate the group. That limitation very much affects xkb. A while >>> an xkb2 would be nice, it seems a pipe dream at this point. People >>> have been talking about it for years, nothing ever happened. >> >> Yes, I saw that, and that's what I meant when I talked about legacy >> applications. XInput2 uses 8 bit for the effective group, so it's not >> limited to 4, and that's what modern toolkits use. >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list