Even with "Grab all keys" option checked, dead keys don't work properly. They are simply ignored, other than with a following space bar, which generates only the corresponding diacritic: ['] + [ ] generates ['], ['] + [e] generates [e], and so on.
Is there some other configuration parameter that may affect the keyboard behavior I should consider?
Remmina 1.4.5 on Uqbuntu 20.04; connection with Windows 8.1
Possibly related question:
https://unix.stackexchange.com/questions/57725/remmina-doesnt-eat-keys
It seems that the 'Use the client keyboard layout' general option (RDP section) also matters; when checked, dead keys don't work properly (as described), even if both keyboard layouts are the same (US International).
Unchecking it resolves the problem.
Related
I installed Cinnamon Manjaro linux on my 2017 QWERTY Macbook Air. Kernel: 5.4.27-1-MANJARO.
I've tried changing my keyboard languages, but my compose key always produces the same behavior -- that of a US (intl) keyboard. I don't know why.
I've tried setting my compose key to different things, like LWin or RAlt, no luck.
Ideally, I want the same key behavior as that on Mac. My current keyboard layout is English (Macintosh). Everything works, except for all of the compose key combos / accents, which all seem to produce US(intl) dead key outputs.
Things I've tried:
changing my keyboard layouts, from GUI to setxkbmap.
changing my compose key
manually setting the value of Option "Xkblayout" "mac" in /etc/X11/xorg.conf.d/00-keyboard.conf
Failing to understand how to manually force set the accent keys I want via xmodmap :(
Thanks for the help.
Solved: I realized that there was another keyboard which Xorg was somehow (I don't know how) set to, other than English (Macbook). I ran setxbmap -option which had the effect of "resetting" my keyboard to the layout I'd correctly chosen via the GUI.
I don't much understand how / why Xorg persisted in using another keyboard layout despite what I had entered in the GUI keyboard settings -- somehow it survived a reset through multiple computer restarts throughout these past days. But it works.
I'm having a bit of an odd problem... recently I've been having some odd situations arising whilst using CoqIDE, namely:
I can't type the letter "v" without holding down the windows/super key.
Pressing backspace moves the focus to the previous tab if multiple windows are open, I can't delete things with it. CTRL+backspace works for deleting chunks though.
The first of the two (may have) happened after I changed my keymap from US to GB but switching back and forth hasn't solved the problem.
Running ARCH linux, everything is up to date and no other applications are affected, I don't have sticky keys on.
Thanks for any suggestions!
EDIT: Tried a reinstall, didn't help...
Solved Edit: Yep, you're completely right I seem to have done some super-fast rebind without noticing. I also learnt that package manager will essentially never touch .config files as they're generated by the app and so aren't under the manager's jurisdiction. Solved!
CoqIDE key bindings and other preferences are stored in .coq/ or .config/coq. They are not deleted on uninstall and are shared if you have various versions of Coq installed at the same time (and this may be a problem).
If you are not worried about losing any specific preferences that you configured, I would advise to just delete this directory and let CoqIDE create it fresh again.
If you are worried, then just have a look at the files (quite long but also quite readable). For instance:
cat .config/coq/coqide.keys | grep "tab"
yields the following on my machine:
; (gtk_accel_path "<Actions>/View/Previous tab" "<Alt>Left")
; (gtk_accel_path "<Actions>/View/Next tab" "<Alt>Right")
PS: your problem might have arisen because key bindings are so easy to redefine in CoqIDE that you can do it without noticing: just open a menu (example: View), hover some option (for instance: Previous tab), type something on the keyboard (for instance v) and voilà v is now a shortcut for Previous tab.
I am looking to develop the raspberry pi into something that I would be able to run a free use public web terminal which would be locked to a certain domain. This is for my employer, a township, who wants to set up terminals around the township so that the less fortunate in our community will be able to contact and interact with the various services that the township provides without having to find a way to the Administration center.
I have been able to get most of what I want working, but I want to disable the Alt key on the keyboard. This will stop users from being able to Ctrl+Alt+Del or Alt+F4 out of the browser environment, and various other features of LXDE that smart users could use to break my kiosk (like virtual terminals). I thought that I had found the method to do this, with xmodmap, but when I ran this command
xmodmap -e "keycode 204 = "
Which to my knowledge should set all mappings for the right Alt key to nothing, still lets me Alt+F4 in chromium and other things.
I also attempted to edit my ~/.config/openbox/lxde-rc.xml and change the keyboard bindings in it. I was able to disable the Ctrl+Alt+Del through that, but when I change or erase other key bindings in there, nothing happens. So I'm trying to figure out other options I have to disable the Alt key on this application. Any ideas?
Soo, I actually just answered my own question. Fixing the problem indeed lies in the ~/.config/openbox/lxde-rc.xml file, but I was not doing it right. To set the Ctrl Alt Delete option, you need to change the value between <command></command> to false (or a program that pops up a finger wag to the user).
The problem was, only four or so of the keys entries have a <command> field to them, and all of the other use an <action="whatever"></action> field to define the action that is being performed by the key. I was changing the value of "whatever" to false and was under the impression that would have the same effect as changing the command field.
But really, what you need to do is change the value of "whatever" to "Execute", and then nest a set of <command></command> with a value set to false and it will set the key's mapping to false. I guess there must be a set of default values that are used to override improper changes to the lxde-rc.xml files, and that's why things kept working after removing the entries.
Business as usual: I've logged into my Linux machine from my MacBook Pro using NX, opened a terminal, and ... key bindings with M- (Meta-) do not work. (Talking about bash, of course.) Wait for it. I'm using a PC keyboard hooked up to my Mac (I cannot work on a cramped laptop keyboard). So I decided to investigate: used xev to capture events. When I press left 'Alt' on the PC keyboard, 'xev' reports that 'Meta_L' got depressed. Problem is, it seems that it gets ignored for some reason (no idea why).
It is really annoying, because the same is true for Eclipse. Practically all key bindings with Alt- in them are gone.
My hunch would be to use xmodmap to force the left Alt key to actually emit 'Alt_L', but I wanted to hear a second opinion.
It turns out, the problem was that, according to 'xmodmap -pm', Meta_L and Meta_R were not in Mod1 special modifier category. When I moved them there, everything started to work. (Turns out, some programs assume, incorrectly, that 'Mod1' is Meta/Alt, and ignore keysyms like Meta_L.)
I've noticed a problem with Vim, where the keyboard mapping would unexpectantly change (to French I think, but I'm not sure). For example, the character 'É' appears when the key '?' is pressed.
My keyboard is set to English, and I don't have any other languages on my computer.
Restarting Vim fixes this problem temporarily, but the problem reappears after a while.
What could be causing this, and what can I do to fix it?
I found this blog post on the same problem. Apparently left-alt + shift will do it. Removing that from the Windows "Advanced Key Settings" dialog and/or removing all unwanted keymaps should fix the problem.
I am not on a Windows system at the moment so cannot verify this.
Update
I have tried it on a Windows system and can verify that this is the problem - alt+shift defaults to cycling through the all the keyboard configurations.
It can be changed from (deep breath...)
Control Panel -> Regional & Language Options -> Languages Tab -> Details button -> Key Settings -> Switch between input languages
Unselect both tickboxes on the final dialog.
I find it astonishing that anyone at Microsoft thought it would be a good idea to have a simple key combination that silently changes the keyboard mapping and other language settings, and only for the current program. How often has anyone wanted to do that?