Bug 4927 - XKM files do not keep the information regarding the explicit vmodmap mask
XKM files do not keep the information regarding the explicit vmodmap mask
Status: NEW
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB
6.8.2
Other Linux (All)
: high major
Assigned To: Xorg Project Team
Xorg Project Team
2011BRB_Reviewed
:
Depends on: xkbcomp
Blocks: 7430 16164
  Show dependency treegraph
 
Reported: 2005-10-29 19:28 UTC by Sergey V. Udaltsov
Modified: 2013-05-17 10:28 UTC (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey V. Udaltsov 2005-10-29 19:28:41 UTC
The server map of explicit components may contain:
- types (per group)
- action
- autorepeat
- behaviour
- vmodmask

In XKB.h:
#define XkbExplicitKeyType1Mask   (1<<0)
#define XkbExplicitKeyType2Mask   (1<<1)
#define XkbExplicitKeyType3Mask   (1<<2)
#define XkbExplicitKeyType4Mask   (1<<3)
#define XkbExplicitInterpretMask  (1<<4)
#define XkbExplicitAutoRepeatMask (1<<5)
#define XkbExplicitBehaviorMask   (1<<6)
#define XkbExplicitVModMapMask    (1<<7)

But in XKM files, there is no place to store explicit vmodmap mask:
#define XkmKeyHasGroup1Type     (1<<0)
#define XkmKeyHasGroup2Type     (1<<1)
#define XkmKeyHasGroup3Type     (1<<2)
#define XkmKeyHasGroup4Type     (1<<3)
#define XkmKeyHasActions        (1<<4)
#define XkmKeyHasBehavior       (1<<5)
#define XkmRepeatingKey         (1<<6)
#define XkmNonRepeatingKey      (1<<7)

So it is not an issue in the input-output code, it is a bigger issue - in the
XKM format.
This causes problems when configuration is passed through binary files.

To demonstrate this problem, create any textual XKB file with explicit vmodmap,
then convert it to XKM and back to XKB - the information will be lost.
Comment 1 Daniel Stone 2006-04-02 11:10:07 UTC
xkm sucks
Comment 2 Sergey V. Udaltsov 2006-04-03 09:21:25 UTC
let's drop this crap from xorg code:)
Comment 3 Daniel Stone 2007-02-27 01:28:35 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 4 Sergey V. Udaltsov 2008-03-22 19:40:00 UTC
This problem is very visible now - the default GNOME switcher Alt-Alt is broken - because virtual modifiers RAlt/LAlt are not passed to X server. Any plans to fix it in the nearest future?
Comment 5 aldebx 2008-04-13 10:54:39 UTC
This bug has also been reported on launchpad.net:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-keyboard/+bug/203991

Are there any chances to have this bug fixed before Ubuntu 8.04 LTS release?
Thanks
Comment 6 Sergey V. Udaltsov 2008-04-13 13:54:07 UTC
8.04? I would humbly estimate it as very-very close to zero.
Comment 7 Daniel Stone 2008-04-16 11:03:45 UTC
flags is just a CARD8, so we can't fix this without breaking wire format, so this will only get solved when we dump xkbcomp, sadly.
Comment 8 Sergey V. Udaltsov 2008-04-16 14:40:57 UTC
I am reopening the bug. It is actually LATER - once 15540 is fixed, this one is fixed automatically
Comment 9 Daniel Stone 2008-04-16 15:01:21 UTC
sorry, not happening for 7.4 due to dependency on #15540.
Comment 10 Bryce Harrington 2008-06-17 14:15:17 UTC
Sergey/Daniel, could you please provide pointers to a todo list or discussion/plan of what needs to be done to move this and/or #15540 forward, esp. things other folks could do to help contribute to a solution?

Also, are there any potential hacks/workarounds that we could investigate as temporary workarounds at the distro level?  (E.g. such as appending another CARD32 flags variable at the end of the data file.)
Comment 11 Daniel Stone 2008-06-17 14:24:24 UTC
On Tue, Jun 17, 2008 at 02:15:18PM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #10 from Bryce Harrington <bryce@bryceharrington.org>  2008-06-17 14:15:17 PST ---
> Sergey/Daniel, could you please provide pointers to a todo list or
> discussion/plan of what needs to be done to move this and/or #15540 forward,
> esp. things other folks could do to help contribute to a solution?

The main thing to be done in rewriting xkbcomp is to rewrite xkbcomp.

> Also, are there any potential hacks/workarounds that we could investigate as
> temporary workarounds at the distro level?  (E.g. such as appending another
> CARD32 flags variable at the end of the data file.)

At the expense of breaking every statically-linked application, everything
run from within a chroot, everything run remotely, and everything else
that just conforms to the spec, you could bump flags from CARD8 to
CARD16, yes.
Comment 12 Ilya Chernykh 2008-06-17 14:42:21 UTC
Hey guys why simply not to rollback to the previous versions of the software before the issue is resolved? My Fedora 9 worked well until it got updated. Why not simply prohibit updating of certain packages?

Also note that it can be made a post-install script/GUI tool to write the preferences directly to xorg.conf, which solution is proven to work.
Comment 13 Sergey V. Udaltsov 2008-06-18 15:34:33 UTC
There is no "previous version" here. This problem was always there (somewhat hidden except for exotic configs). But it came to surface recently, when xkeyboard-config fixed another bug - and made this bug visible. Reverting xkeyboard-config code is not an option - it will return another bug. And since the current code over in xk-c is correct, I prefer to keep this bug visible (till it is fixed) rather than reverting to the broken code which, as a side affect, exposes another bug.
Comment 14 Andriy Gapon 2008-08-22 05:12:07 UTC
Sergey, just out of curiosity, could you point to xkeyboard-config bug or change that provoked this bug? Anything will do - a bug, a commit, a description.
Thank you.
Comment 15 Peter Hutterer 2008-08-23 09:09:00 UTC
On Fri, Aug 22, 2008 at 05:12:08AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #14 from Andriy Gapon <avg@icyb.net.ua>  2008-08-22 05:12:07 PST ---
> Sergey, just out of curiosity, could you point to xkeyboard-config bug or
> change that provoked this bug? Anything will do - a bug, a commit, a
> description.
> Thank you.

a8551efb70 in xkeyboard-config
Comment 16 Jeremy Huddleston 2011-10-17 16:07:47 UTC
What's the status of this?  It seems like a high priority bug that hasn't been 
touched in years...
Comment 17 Daniel Stone 2011-12-06 04:13:15 UTC
Unfortunately we can't fix this for anything that uses XKM, since it would be a format break to do so.  What we _can_ do is to more aggressively deprecate the use of XKM, which means having the server use xkbcommon (which I'm working on, more or less) in particular.
Comment 18 Sergey V. Udaltsov 2011-12-06 15:40:54 UTC
> use of XKM, which means having the server use xkbcommon (which I'm working on,
> more or less) in particular.
Any kind of ETA? Is there some open bug so that we could mark this one as dependent?
Comment 19 Quentin "Sardem FF7" Glidic 2013-03-21 09:34:33 UTC
This bug is still annoying for at least i3lock users (see http://bugs.i3wm.org/report/ticket/953).

Is there any chance to get that fixed or should it be fixed at some other place instead?