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.
xkm sucks
let's drop this crap from xorg code:)
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
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?
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
8.04? I would humbly estimate it as very-very close to zero.
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.
I am reopening the bug. It is actually LATER - once 15540 is fixed, this one is fixed automatically
sorry, not happening for 7.4 due to dependency on #15540.
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.)
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.
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.
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.
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.
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
What's the status of this? It seems like a high priority bug that hasn't been touched in years...
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.
> 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?
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?
I assume it's relatively well known, but here's where I landed. My plan to fix this, was to bypass XKM support completely, by integrating the parser into the server. Currently the server forks xkbcomp to build a particular keymap, xkbcomp produces (lossy) XKM files, and then the server consumes XKM. xkbcommon was supposed to fix this (hence the name), but the problem is that the server wants very different things from xkbcommon than everyone else. Specifically, it wants to be able to mutate arbitrary parts of the keymap after construction, which is very messy. Ultimately we just kept xkbcommon for everyone _but_ the X server, with a much smaller API. The best thing to do for anyone who wants to pick this up is probably to look at importing xkbcommon circa https://github.com/xkbcommon/libxkbcommon/commit/ed18e65eacdabfeaeafee7c369891312af99c82d into the X server, in place of the xkbcomp entrypoint in xkb/ddxLoad.c. That particular commit is probably the most tractable balance between an actual functional xkbcommon without memory leaks, and one which hasn't changed the server-facing API and internals _too_ far away from what the server needs.
-- 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/297.
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.