| Summary: | repeat setting is lost once "action" is defined in symbols | ||
|---|---|---|---|
| Product: | xkeyboard-config | Reporter: | Hanno Zulla <kontakt> |
| Component: | General | Assignee: | xkb |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Hanno Zulla
2014-05-13 12:53:23 UTC
The explicit repeat should not disappear, so if it happens it's a bug that should be fixed. That said, the second approach (setting the keysyms directly without redirecting the key) seems like the correct one to take, and *should* work reliably; in what sort of applications does it not work for you? It seems to be a more general issue, see bug #9796. > That said, the second approach (setting the keysyms directly without redirecting the key) seems like the correct one to take, and *should* work reliably; in what sort of applications does it not work for you? I tried and saw failures with emacs (Xaw widgets), OpenOffice 3.2, TotalView, and urxvt. xterm did work. I cannot imagine how any non-XKB aware applications should work with Control and Alt as level selectors, so CLX based applications, XCB based applications (at least until recently), and applications running over an untrusted connection will likely not work with the second approach. From de(neo), which is simpler in the sense that it does not abuse modifiers applications might want to interpret for level selection, also problems with Java applications are reported. From my experience, cursor control and editing keysyms on a higher level only can be reliably implemented with Redirect. Back to the original problem, the problem is not in xkeyboard-config, but I have no idea where the problem exactly is. xkbcomp or the server? Right, I guess the higher groups will not trickle to the core state (but really if you want reasonable input, don't use core input, XKB is 20yo already..) > Back to the original problem, the problem is not in xkeyboard-config, but I > have no idea where the problem exactly is. xkbcomp or the server? Seems like bug #9796 would be the better place to handle the disappearing repeats. I'll a comment there. Hi Ran, hi Andreas, thanks for your responses. > in what sort of applications does it not work for you? I'm testing this in Firefox and LibreOffice a fairly normal Xubuntu 14.04 with a few minor Chromebook-related driver patches. However, Firefox, LibreOffice and X.org etc. are the standard binaries that come with the distibution. > the problem is not in xkeyboard-config, > but I have no idea where the problem exactly is. xkbcomp or the server? Don't know (and didn't debug further). I reported the same issue to X.org about two weeks ago at https://bugs.freedesktop.org/show_bug.cgi?id=78180 but didn't get any response so far (however, this bug report is a bit more straightforward than 78180 over there, where my findings were still a bit more work-in-progress). > but really if you want reasonable input, > don't use core input, XKB is 20yo already.. So what should I use instead of XKB? My plan was to replicate the behaviour of the ChromeOS keyboard. It's actually a really nice reduction of the old-style PC keyboard, they removed many of the weirder keys like PrintScreen or ScrollLock, and the removal of CapsLock has been long overdue. I would love to buy a non-ChromeOS laptop with that keyboard layout... ChromeOS is based on Linux and originally, they used XKB for remapping their keys as well. https://codereview.chromium.org/3365005/show However, they later removed it from there and moved the remapping into user space instead. https://codereview.chromium.org/10537175/show Someone else stumbled over the same problem as I describe here and asked about it: http://unix.stackexchange.com/questions/41724/how-to-make-custom-key-type-auto-repeat-in-xkb ...and his question on stackexchange got a reply that points to a patch from ChromeOS at http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git;a=blob;f=x11-base/xorg-server/files/1.7.6-fix-xkb-autorepeat.patch;h=8bad5abc5ad3958f6d73c55c67d3883ac775db18;hb=c3ce41719abc82a257e1fef1c499ea2e7c6b3c32 I tried to build a modified X.org with that patch and that didn't help, but it is possible that I didn't use the patch right. So now I'm not quite sure where to look and if it's a bug in my symbols/inet or a bug in XKB or the server or... > So what should I use instead of XKB? My plan was to replicate the behaviour of > the ChromeOS keyboard. I believe Ran wanted to say that applications should really support XKB today. Not all do, and this is one but not the only reason that you are right to use Redirect and, of course, XKB in general. Please try to use 'xset r keycode' to enable repeat for the key with keycode. For Linux, for the UP key, keycode is 111, as far as I see. You can find out with xev. I hope that gets you going, for now. Ran is probably right and bug #9796 is the better place to track the issue. If you agree, you might close this bug and add your findings to bug #9796. Just a small note: there's an issue with "second approach" beyond XKB vs. Core, which should explain why it doesn't work for the modern applications you mention (Firefox and LibreOffice, both of which use GTK which uses XKB). The correct keysym is generated (e.g. Home), but the application does not respect the "consumed modifiers" which XKB tells it to mask out. "Consumed modifiers" are modifiers which are used up in the key translation process (that is, appear in the Level which was used in the key type). So in effect you get e.g. "Ctrl+Alt+Home" which does not do what you want. So indeed the RedirectKey approach with clearmods is the better one here (modulo bug #9796). Hopefully Andreas' "xset r" suggestion works until that bug is fixed. I tried the patch that people discussed about back in 2007 in bug #9796, but that didn't help. Please see there. -- 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/xkeyboard-config/xkeyboard-config/issues/22. |
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.