Bug 19501 - Support for more than 4 groups in xkb
Summary: Support for more than 4 groups in xkb
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: Other All
: low enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Whiteboard: 2011BRB_Reviewed
: 56277 (view as bug list)
Depends on:
Reported: 2009-01-10 09:22 UTC by Andriy Rysin
Modified: 2018-12-13 18:37 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Description Andriy Rysin 2009-01-10 09:22:23 UTC
Some users need more than 4 layouts to switch between, so it would be nice if xkb could support more than 4 groups.

Forwarded from https://bugs.kde.org/show_bug.cgi?id=174753
Comment 1 Liviu 2009-03-27 04:25:23 UTC
For some users this is an important, to-have feature. There are users who turn away from Linux because of this limitation. An obvious example is translation agencies. Link to a relevant discussion:
Comment 2 Peter Hutterer 2009-05-24 15:47:59 UTC
Some information about this feature and why it hasn't been implemented yet:
The 4 group limit is forced by the protocol wire format. support for more than 4 groups can only be added by adding additional requests and events to XKB and rewriting clients to switch to this new XKB version.
In addition, compatibility to the old protocol must be ensured so that current XKB clients will still function correctly with the new XKB version.

This is both complex and very time-consuming. Volunteers to tackle this problem are of course very welcome.
Comment 3 Sergey V. Udaltsov 2009-05-24 15:55:27 UTC
Considering the number of users who actually cannot do without 5+ groups, I would not overestimate the probability of this bug being fixed... 
I mean the probability of coincidence of 3 prereqs: 
- The person needs (himself) 5+ groups
- C skills are high enough
- The person has enough time to dig rather deep into XKB code
Comment 4 Alex Dănilă 2009-05-24 16:30:18 UTC
Excuse my simplistic view, but isn't that just a number? 
Like instead of having const int layoutCountLimit = 4, you put a 10/20/xx? And do the same thing for the clients of xkb and do the same thing for X11 and call it X12? Then recompile and done.

Wikipedia says we have the current one since 1987. And I know there are other protocol limitations which need to be addressed in a future version, I just can't find that list :).
Comment 5 Peter Hutterer 2009-05-24 18:24:45 UTC
(In reply to comment #4)
> Excuse my simplistic view, but isn't that just a number? 

It's encoded in some bits on the protocol, with the other bits being used for other information. so you need extra bytes in the requests/events for anything above 4, and adding extra bytes requires bumping the protocol. And then you have to deal with those clients that only understand 4 groups and what to do with them if a keyboard is on group 5.

Comment 6 Michael Shigorin 2011-11-15 01:05:08 UTC
See also http://www.x.org/wiki/Development/X12
Comment 7 Daniel Stone 2011-11-15 02:01:02 UTC
On 15 November 2011 09:05,  <bugzilla-daemon@freedesktop.org> wrote:
> --- Comment #6 from Michael Shigorin <mike@altlinux.org> 2011-11-15 01:05:08 PST ---
> See also http://www.x.org/wiki/Development/X12

Note that apps/toolkits using Xi2 (i.e. the second version of the X
Input Extension, not the twelfth version of the X protocol) already
get a uint16_t for group numbers.  XKB, however, still needs to be
Comment 8 v_2e 2012-10-22 14:15:33 UTC
*** Bug 56277 has been marked as a duplicate of this bug. ***
Comment 9 GitLab Migration User 2018-12-13 18:37:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/262.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.