You are not logged in.
Or perhaps it's overridden by something?
What I have in /etc/X11/xorg.conf.d/00-keyboard.conf is as follows:
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "us,ru,el"
Option "XkbModel" "pc105"
Option "XkbVariant" ",phonetic,polytonic"
Option "XkbOptions" "ctrl:nocaps,grp:alt_shift_toggle,grp_led:scroll,terminate:ctrl_alt_bksp"
EndSectionIt's worked in the past, meaning pressing left alt shift toggles between layouts US, Russian phonetic, and Greek polytonic keyboards. And the keyboard LED's light as expected. And the idiotic caps lock key gets disabled.
Then it started working intermittently: sometimes, pressing left alt shift would just not do anything in terms of layout switching or keyboard LED lighting. Then, some hours or days later it would mysteriously start working again. But at the moment and for the last few days, nothing at all happens when I press left alt shift.
So I'm looking for tips on diagnosing this issue. I've done some on-line searching, including in forums here. And I've re-consulted the wiki. But I'm kind of at a loss atm as to what to try/read next. Input, anyone?
LATER EDIT: there's no DE involved here or any login manager. I just run jwm from .xinitrc for my graphical environment.
Last edited by jamtat (2023-12-08 15:37:52)
Offline
setxkbmap -print -query # "what do you actually get"
xev -event keyboard # => what does pressing alt+shift produce
xdotool key ISO_Next_Group # does that work?PSA: "compose:caps", https://wiki.archlinux.org/title/Xorg/K … ompose_key
Online
Thanks for your reply, Seth. I had run that first command to determine whether the system had registered the content of 00-keyboard.conf and confirmed it had. Sorry i didn't include that in my initial post. I don't believe I tried the other two options yet though. In any case, the output of the setxkbmap is
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+ru(phonetic):2+el(polytonic):3+inet(evdev)+ctrl(nocaps)+terminate(ctrl_alt_bksp)+group(alt_shift_toggle)" };
xkb_geometry { include "pc(pc105)" };
};
rules: evdev
model: pc105
layout: us,ru,el
variant: ,phonetic,polytonic
options: ctrl:nocaps,grp:alt_shift_toggle,grp_led:scroll,terminate:ctrl_alt_bkspThe command xev -event keyboard # followed by pressing left-alt shift gives the following result:
KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2493318931, (-558,945), root:(970,1030),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2493318931, (-558,945), root:(970,1030),
state 0x1, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2493319083, (-558,945), root:(970,1030),
state 0x9, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2493319091, (-558,945), root:(970,1030),
state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseAs for the command xdotool key ISO_Next_Group # the utility was not installed on my system. I installed it but running the command had no effect. By that I mean that I am returned to the command prompt, the terminal shows no resulting output, and pressing the specified keys for layout switching does not accomplish any switching.
Last edited by jamtat (2023-11-27 16:21:41)
Offline
Edit: no. shifts_toggle but alt_shift. Hit my head a bit to hard, I guess.
But the events are wrong, you should get Alt_L, not Meta_L - though it seems the correct modifier state (0x8)
Is that part of any keymap or do you xmodmap the keys/modifiers?
Edit #3: but you could test whether eg. the shifts_toggle works for you.
Last edited by seth (2023-11-27 16:33:45)
Online
Thanks Seth. Using the xev command I get
KeyRelease event, serial 28, synthetic NO, window 0x2e00001,
root 0x3d0, subw 0x0, time 2498108949, (172,11), root:(1715,95),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: Falsewhen I press left alt key only. But when I press left alt plus left shift, I get
KeyPress event, serial 28, synthetic NO, window 0x2e00001,
root 0x3d0, subw 0x0, time 2498266088, (-183,880), root:(1360,964),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 28, synthetic NO, window 0x2e00001,
root 0x3d0, subw 0x0, time 2498266088, (-183,880), root:(1360,964),
state 0x1, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2e00001,
root 0x3d0, subw 0x0, time 2498266216, (-183,880), root:(1360,964),
state 0x9, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2e00001,
root 0x3d0, subw 0x0, time 2498266216, (-183,880), root:(1360,964),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseWhich is kind of strange. Kind of like it's registering two sets of key presses instead of just the one set I'm doing, no? Not that I'm all that great at parsing xev output. Anyway I've gotta think about that some more to determine whether it relates to the fact that I've lost layout switching ability. I have had a few problems with keystroke timings on this keyboard (keys are too sensitive and I get repeat letters frequently when typing).
I've used xmodmap in the past but I don't believed it's currently enabled. At least it's not in .xinitrc, the place from which I've always invoked it in the past.
LATER EDIT: xset -r turns off keystroke repeats which should help with the unrelated problem of keyboard hypersensitivity although it has the undesirable side-effect of making multiple presses of arrow keys necessary for navigation. But it has no effect on the left-alt shift behavior I described.
Last edited by jamtat (2023-11-27 18:04:34)
Offline
The xev output has you press shift+meta_l, then release shift, then alt_l gets released.
I suspect that Shift+Alt=Meta, what's "normal" (Alt is meta on the first iso level shift)
Does this also happen if you switch the order and press actually Alt+Shift (ie. make sure to hit alt first)?
Online
Thanks again Seth. Yes, it is the case that if I am very careful about pressing alt before pressing shift, then xev output in the terminal shows the expected result, as follows:
KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2520150076, (36,133), root:(1563,400),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2520150204, (36,133), root:(1563,400),
state 0x8, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2520150372, (36,133), root:(1563,400),
state 0x9, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
root 0x3d0, subw 0x0, time 2520150404, (36,133), root:(1563,400),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseInteresting to note but it doesn't really help in getting some indication as to why my 00-keyboard.conf, despite being evidently registered by the system, does not seem to be allowing me to do layout switching, correct?
The only other possibly relevant thing I've observed is that when I try to disable the caps lock key by alternate means (using setxkbmap -option ctrl:nocaps) I get the error message "Error loading new keyboard description." Not sure if that's a red herring or related somehow.
Offline
Correct, it just tells us that your keyboard isn't generating spurious input.
What neatly brings us to "Error loading new keyboard description." and sth. I hadn't considered at all:
layout: us,ru,elWhere does the "el" come from (jaja, Ἑλλάς - I mean the definition)
That's not a thing in the default xkb symbols, the greek stuff is "gr" (incl. the polytonic variant)
Online
It's interesting to hear this about "el." Did "el" get changed to "gr" recently? That line was adapted some years ago from content I used to put in known-working xorg.conf files, back when X used to require a valid xorg.conf for a working display. I guess what I'm saying is that maybe it's a legacy specification that's lately been retired? This Arch forums post, for example, reveals that "el" was still being used to specifiy Greek keyboard input as of late 2013: https://bbs.archlinux.org/viewtopic.php?id=169397 I'll be investigating this further. Thanks for the tip
Offline
https://gitlab.freedesktop.org/xkeyboar … type=heads is there forever.
The el references google spits out seem all to date back to the X11R7.6 era…
https://www.x.org/releases/X11R7.6/doc/ … UTF-8.html
You can just symlink the the file and continue to use el or switch to gr, but I'd not be surprised if the invalid layout throws the layout switching off
Online
Thanks Seth. Well, changing "el" to "gr" and restarting the X server did cause xsetkbmap to stop throwing an error when I issue setxkbmap -option ctrl:nocaps. So now I'm at least able to manually implement that part of what I was trying to accomplish in my 00-keyboard.conf file. But there is still no layout switching happening when I use the left-alt shift key combination. So that mis-specification does not seem to have been interfering with layout switching. I guess I might have assumed that would be the case when I discovered that ctrl-alt-backpace killed the X server, as specified in 00-keyboard.conf. Perhaps I will try specifying some other key combination like left-ctrl shift as the trigger for layout switching to see if that will accomplish the aim?
Offline
I'd first try whether you can still toggle between two layouts (us,ru)
Online
Are you suggesting removing "gr" and "polytonic" from 00-keyboard.conf and restarting X to see whether I can switch between those 2? In other words, the revised 00-keyboard.conf would look like this:
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "us,ru"
Option "XkbModel" "pc105"
Option "XkbVariant" ",phonetic"
Option "XkbOptions" "ctrl:nocaps,grp:alt_shift_toggle,grp_led:scroll,terminate:ctrl_alt_bksp"
EndSectionJust wanting to clarify because currently alt-shift does nothing. I get only "us" layout/input, no matter how many times I try left-alt shift. According to the way this was working in the past, one left-alt shift would get me Cyrillic (phonetic) layout/input, two left-alt shifts would get me polytonic Greek layout/input, and three would return me to "us." Thanks
Offline
Yes, it's a more common config and simpler.
So we simplify the problem as much as possible, look for a solution and extrapolate from there.
For the records: what do you use to check the current layout?
Online
The revised config also does not allow me to do layout switching. Pressing left-alt shift has no effect: no keyoboard led's illumine and input remains "us." I think I've used localectl status and maybe another utility a couple of times to check current layout. Output of localectl status after restarting X with the revised 00-keyboard.conf is as follows (in case it's revelatory):
System Locale: LANG=en_US.UTF-8
VC Keymap: (unset)
X11 Layout: us,ru
X11 Model: pc105
X11 Variant: ,phonetic
X11 Options: ctrl:nocaps,grp:alt_shift_toggle,grp_led:scroll,terminate:ctrl_alt_bkspOffline
It appears that the content of 00-keyboard.conf is having its effect on the display. I just confirmed that, in fact, the caps lock key is now a dead key. Based on what I was seeing earlier, I believe that having "el" instead of "gr" may have been interfering with the ctrl:nocaps option getting applied, because the caps lock was definitely enabled on previous invocations of X. Also, I can confirm that terminate:ctrl_alt_bksp is in effect, since that's how I've killed X the last few times I've modified 00-keyboard.conf stooped/restarted the server in order to test whether revisions I was doing would cause layout switching to start working again (none of them did). So, although parts of 00-keyboard.conf seem to be implemented under X, the keys specified there that are supposed to invoke layout switching are not. Are we at the end of the road here in attempting to find out what is preventing layout switching from working on this system, then? Maybe I should modify the title of this thread to reflect that only some parts of 00-keyboard.conf are not getting applied? Something like "Parts of 00-keyboard.conf no longer seem to get applied?"
Last edited by jamtat (2023-11-28 22:52:03)
Offline
setxkbmap -print -querywill tell what's actually applied, I don't think that's the problem.
The primary problem is that Alt+Shift (still) doesn't seem to produce ISO_Next_Group for you.
I tried and both, alt+shift and shift+alt work itr for me (I tested de,us and that's easy because de is qwertz, not qwerty, so z/y give it away - also I activate the caps LED with it)
So that's the problem/symptom - we just don't know why.
Maybe really just try the shifts_toggle - the xdotool key still doesn't work?
Online
The command xdotool key ISO_Next_Group does not cause the next layout specified in 00-keyboard.conf to be implemented, no. Whether I run that command or not I still get "us" layout. Unfortunately replacing alt_shift_toggle with shifts_toggle and killing/restarting X had no effect on the layout-switching problem: pressing both shift keys simultaneously does not change the keyboard layout from "us." Thanks for the suggestions anyway though.
Thinking back on attempts I made some months ago to remedy what I would call hypersensitivity of keys on this keyboard (I didn't manage to resolve the problem), I wonder whether I might not have installed some utility that could be somehow interfering now as I try to re-implement layout switching? For example. I may have fiddled a bit with localectl, but that's something that comes along with systemd, right? So, not something I would have been likely to have installed separately as I was trying to address hypersensitivity.
Last edited by jamtat (2023-11-29 00:56:01)
Offline
Do you run a shurtcut daemon next to jwm?
What does your xinitrc look like?
What if you radically simplify that and start nothing but an xterm?
Do you have a spare keyboard?
Online
Here is .xinitrc:
#!/bin/sh
[[ -f ~/.Xresources ]] && xrdb -merge ~/.Xresources
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for f in /etc/X11/xinit/xinitrc.d/*; do
[ -x "$f" ] && . "$f"
done
unset f
fi
export EDITOR="$(if [[ -n $DISPLAY ]]; then echo 'nano'; else echo 'nano'; fi)"
remind -z /home/user/sys-maint.rem &
urxvtd -q -o -f &
exec /usr/bin/jwmYes, I do have another keyboard and have considered swapping it in to see what effect that might have. I'll be thinking some more about the other proposals. Thanks
Last edited by jamtat (2023-11-29 11:54:28)
Offline
A sort of semi-relevant development: I had the same problem of layout-switching not working on my laptop. Changing "el" to "gr" in the /etc/X11/xorg.conf.d/00-keyboard.conf then killing and restarting X did have the effect of causing keyboard layout switching via the alt-shift hotkey combination to begin working again on that machine. So this seems more and more to be related somehow to the keyboard I am using on my main home computer. Perhaps today I'll swap in an alternate keyboard to see whether it will have any effect on the issue I'm having with this machine.
Last edited by jamtat (2023-11-30 11:38:16)
Offline
After swapping in the alternate keyboard I can confirm that the simplified 00-keyboard.conf with just us,ru and shifts_toggle is effective. In other words, I can switch between "us" and "ru" by hitting the two shift keys simultaneously and the keyboard LED illuminates as an indicator.. So I guess what I need is help in determining why the preferred keyboard is giving me problems when it comes to layout switching. I bought this Falcon z-77 usb keyboard new 2 or 3 years ago because it had lighted keys and seemed to be well-constructed, though it is way down on the low end of quality keyboards and was priced accordingly (around 30USD if memory serves). Thanks
Last edited by jamtat (2023-12-02 04:42:24)
Offline
Does "grp:menu_toggle" work (ie. sth. that doesn't use a combination)
You can "synthetically" test this using "xev -event keyboard" since you need the toggle to produce "ISO_Next_Group"
Also make sure that the config is correct at any time (setxkbmap -print -query) because transitional changes (not in an xorg config) will get lost if the keyboard "flickers" and the "-option" syntax of setxkbmap is only additive, ie. to remove/replace an option you'll have to -option "" -option "all,the:options,you,want"
Online
I just now unplugged, in preparation for further experimentation with the original keyboard I'm hoping to use and with which I'd had problems when attempting to do layout switching, the keyboard I'd swapped in. After reconnecting the original keyboard, having not restarted the X server, I now note that hitting both shift keys continues to work for layout switching: using that combination, I can now switch layouts between the two variants us and ru listed in the modified provisional 00-keyboard.conf file. Thanks
Last edited by jamtat (2023-12-02 16:47:47)
Offline
I think I may have determined something informative. First, I restored the original 00-keyboard.conf but changed alt_shift_toggle to menu_toggle. Pressing the menu key did not cause the keyboard LED indicator light to illumine, nor did it switch layouts. Killing and restarting the X server did not cause layout switching to work with this modification, nor did rebooting the computer. Then I decided to, with the computer running, unplug and replug the keyboard. After I'd unplugged and replugged the keyboard, layout switching using the menu key now works, and the indicator LED on the keyboard does light up. I can get all 3 layouts, "us," "ru," and "gr."
What conclusion might I draw from this, and what sort of remedy might it indicate? Obviously I don't want to have to physically unplug and replug the keyboard every time I want to get layout switching to work. Any input on this? I will now try restoring the original key combination alt_shift_toggle and unplug/replug the keyboard to see whether layout switching will then work. Thanks
Offline