xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2023-05-17T02:39:04Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1546XWayland apps can't read wayland keyboard layout using the xkb API (libxkbfile)2023-05-17T02:39:04ZNikolas SpiridakisXWayland apps can't read wayland keyboard layout using the xkb API (libxkbfile)I was trying to use an X11 app which uses libxkbfile to read the current keyboard layout. While it works fine on X11, on Xwayland it always reports "us" as the current (selected) layout. Doing a `setxkbmap -query` (which should theoretic...I was trying to use an X11 app which uses libxkbfile to read the current keyboard layout. While it works fine on X11, on Xwayland it always reports "us" as the current (selected) layout. Doing a `setxkbmap -query` (which should theoretically run under Xwayland) reveals that my keyboard layout settings are not inherited from wayland, but rather be the default "us" ones.
```
[nikolas@archlinux ~]$ setxkbmap -query
rules: evdev
model: pc105
layout: us
```
Thankshttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1155XTEST keyboard layout is not set properly on server startup2021-04-24T14:07:08ZToni SpetsXTEST keyboard layout is not set properly on server startupIf you have Xkb configuration set in xorg.conf for non-US layout it seems XTEST does not *really* honor it until you run `setxkbmap` without arguments.
To test this set the startup X server layout to EurKey (`eu`) and run xdotool with a...If you have Xkb configuration set in xorg.conf for non-US layout it seems XTEST does not *really* honor it until you run `setxkbmap` without arguments.
To test this set the startup X server layout to EurKey (`eu`) and run xdotool with a symbol that requires _ISO_Level3_Shift_:
Expected:
```
$ xdotool key adiaeresis
ä
```
Actual:
```
$ xdotool key adiaeresis
a
```
Testing this against `xev` shows that the correct modifier (ISO_Level3_Shift / AltGr) is being pressed down by xdotool before `a` to produce `ä` but it seems to be ignored by the server. This smells like the keyboard layout is in fact US on startup for XTEST. Running `setxkbmap` without arguments seems to fix this situation per session by resetting the layout options by reading them out and writing back in.
If you query with `setxkbmap` all devices (core as id=3, XTEST as id=5 and the physical keyboard) have the proper layout set on start, just querying does not cause the layout issue to be worked around per session:
```
$ setxkbmap -query -device 5
rules: evdev
model: pc105
layout: eu
options: caps:super
```
This rarely affects end users as most configure their layout on DE level which would issue a layout change after the server has started or they stick with US that wouldn't be affected by this. However if you use tools like `localectl` or `/etc/defaults/keyboard` on Debian-like systems to set system wide defaults this will pop up.
I noticed this when I was working on another program that uses XTEST other than xdotool and could confirm this behavior on both.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1052keyboard layout switching does not work with XWayland2022-01-17T05:02:14ZRichard B. Kreckelkeyboard layout switching does not work with XWaylandI've configured Gnome such that keyboard layout is switched from US to German while AltGr is being pressed. Under X11, this works for all applications but under Wayland it works for Wayland applications, but not for X11 applications.
I'...I've configured Gnome such that keyboard layout is switched from US to German while AltGr is being pressed. Under X11, this works for all applications but under Wayland it works for Wayland applications, but not for X11 applications.
I've reported this as Gnome [#2289](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2289) before and am bringing it here because Peter Hutterer [conjectured](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2289#note_859202) that it's due to XWayland missing some XKB notification to the clients.https://gitlab.freedesktop.org/xorg/xserver/-/issues/655Binding keys with keycodes > 127 to XKB modifiers doesn't work2019-03-10T18:55:19ZBugzilla Migration UserBinding keys with keycodes > 127 to XKB modifiers doesn't work## Submitted by Marius Gedminas
Assigned to **Xorg Project Team**
**[Link to original bug (#12401)](https://bugs.freedesktop.org/show_bug.cgi?id=12401)**
## Description
My Thinkpad T61 has a few keys that act strangely in X: Menu,...## Submitted by Marius Gedminas
Assigned to **Xorg Project Team**
**[Link to original bug (#12401)](https://bugs.freedesktop.org/show_bug.cgi?id=12401)**
## Description
My Thinkpad T61 has a few keys that act strangely in X: Menu, Workspace
Prev, Workspace Next. By "acting strangely" I mean:
1. xset -r disables autorepeat for all the keys on the keyboard except
for these three (and Fn).
2. It appears to be impossible to map these keys to modifiers (neither
with xmodmap, nor with custom xkb symbols files)
The Menu key sends keycode 227 (instead of the usual 117 I get from the
Menu key on a USB keyboard). I'm trying to map it to a ISO_Level3_Shift
with
xmodmap -e 'keycode 227 = ISO_Level3_Shift' -e 'add mod5 = ISO_Level3_Shift'
and xev shows me the keysym correctly, but the state remains 0x0. Why?
I had the same problem mapping keycode 234 to Alt, and I went as far as
to compile a custom XKB description so that xkbcomp :0 - showed me
identical configurations for it and the real Alt key.
I can map these extra keys to, e.g., Multi_key, but not to any of the modifiers.
The Menu key on a USB keyboard, the one that sends keycode 117, is also mapped
to ISO_Level3_Shift. It autorepeats, but despite that the state bit flips to
0x80 while I hold it down. xmodmap shows both 0xe3 (227) and 0x75 (117) among
the keys mapped to mod5.
The only difference I can think of is that one keycode is < 128, while
the other one needs full 8 bits. Just a blind guess, but could the XKB
code be using signed chars somewhere and sign-extending them to ints?
This is with xserver 1.3.0 (Ubuntu's xorg-server 2:1.3.0.0.dfsg-12ubuntu3).
I've had the problem with older versions as well.https://gitlab.freedesktop.org/xorg/xserver/-/issues/321rmlvo is just bolted on to xkb2018-12-13T18:39:34ZBugzilla Migration Userrmlvo is just bolted on to xkb## Submitted by Daniel Stone `@daniels`
Assigned to **Xorg Project Team**
**[Link to original bug (#6142)](https://bugs.freedesktop.org/show_bug.cgi?id=6142)**
## Description
Currently, we compile RMLVO to KcCGST with libxkbfile (...## Submitted by Daniel Stone `@daniels`
Assigned to **Xorg Project Team**
**[Link to original bug (#6142)](https://bugs.freedesktop.org/show_bug.cgi?id=6142)**
## Description
Currently, we compile RMLVO to KcCGST with libxkbfile (possibly the only thing
it's good for, though it still needs external assistance) on the client side,
then send KcCGST over the wire to the server. This is bad.
### Blocking
* [Bug 6141](https://bugs.freedesktop.org/show_bug.cgi?id=6141)
* [Bug 7913](https://bugs.freedesktop.org/show_bug.cgi?id=7913)https://gitlab.freedesktop.org/xorg/xserver/-/issues/320Autorepeat does not work for custom key defined via XKB2022-11-15T05:11:28ZBugzilla Migration UserAutorepeat does not work for custom key defined via XKB## Submitted by Hanno Zulla
Assigned to **Xorg Project Team**
**[Link to original bug (#78180)](https://bugs.freedesktop.org/show_bug.cgi?id=78180)**
## Description
Hi there.
There appears to be a bug with how X.org handles the "...## Submitted by Hanno Zulla
Assigned to **Xorg Project Team**
**[Link to original bug (#78180)](https://bugs.freedesktop.org/show_bug.cgi?id=78180)**
## Description
Hi there.
There appears to be a bug with how X.org handles the "repeat" setting in xkb definitions.
Bought a chromebook and installed a non-ChromeOS Linux distribution on it.
Chromebooks come with a limited set of keys for ease of use and then make missing keys available through modifiers, e.g.:
Up = `<UP>`
Prior = Alt+`<UP>`
Home = Ctrl+Alt+`<UP>`
(see https://support.google.com/chromebook/answer/1047364?hl=en)
I'm trying to get these keyboard shortcuts to work within my Linux system and fiddle with a custom, system-wide xkb setting right now.
(The ChromeOS guys used to use xkb for this purpose, as well. But some time ago, they have moved their re-mapping of these keys from xkb into the user space applications, instead: <http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git;a=commitdiff;h=9b26b7aba4402bf97cee5cae8333175748160f62>)
My current work-in-progress solution with xkb looks somewhat like this:
In types/pc, add:
type "CTRL+ALT_ACTUALLY" {
modifiers = Control+Alt+Shift;
map[None] = Level1;
map[Shift] = Level2;
map[Alt] = Level3;
map[Shift+Alt] = Level4;
map[Control+Alt] = Level5;
preserve[Shift] = Shift;
preserve[Shift+Alt] = Shift;
level_name[Level1] = "Base";
level_name[Level2] = "Shift";
level_name[Level3] = "Alt Base";
level_name[Level4] = "Shift Alt";
level_name[Level5] = "Ctrl+Alt";
};
// see https://bugs.freedesktop.org/show_bug.cgi?id=78139
In symbols/inet, add:
// Chromebook keyboards
partial alphanumeric_keys
xkb_symbols "chromebook" {
key `<UP>` {
type="CTRL+ALT_ACTUALLY",
repeat=yes,
symbols[Group1] = [ Up, Up, Prior, Prior, Home ]
actions[Group1] = [
NoAction(),
NoAction(),
RedirectKey(key=`<PGUP>`, clearmods=Alt),
RedirectKey(key=`<PGUP>`, clearmods=Alt),
RedirectKey(key=`<HOME>`, clearmods=Control+Alt)
]
};
// similar for other keys
};
This works, but autorepeat doesn't work for this custom `<UP>` definition.
I found a patch from the ChromeOS guys that seems to address this problem <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 commented out the two lines of code mentioned in the patch for the current version on my system, but that didn't fix the issue or I'm using it wrong.
So I kindly ask you to have a look at that patch or see if there is a better way to fix this issue.
I'm running x.org 7.7 as pre-packaged by Ubuntu for their 14.04 release (7.7+1ubuntu8).
Thanks!
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/xserver/-/issues/319xkbcomp has to be dropped2019-05-10T17:41:14ZBugzilla Migration Userxkbcomp has to be dropped## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#15540)](https://bugs.freedesktop.org/show_bug.cgi?id=15540)**
## Description
There is a number of issues which are in xkbcomp design (a...## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#15540)](https://bugs.freedesktop.org/show_bug.cgi?id=15540)**
## Description
There is a number of issues which are in xkbcomp design (and xkm format, and corresponding wire protocol). It has to be removed.
### Blocking
* [Bug 4927](https://bugs.freedesktop.org/show_bug.cgi?id=4927)
* [Bug 16164](https://bugs.freedesktop.org/show_bug.cgi?id=16164)https://gitlab.freedesktop.org/xorg/xserver/-/issues/318Xkb Configuration in xorg.conf for us+il(lyx)+compose key misbehaves2018-12-13T18:39:28ZBugzilla Migration UserXkb Configuration in xorg.conf for us+il(lyx)+compose key misbehaves## Submitted by Shlomi Fish
Assigned to **Xorg Project Team**
**[Link to original bug (#19718)](https://bugs.freedesktop.org/show_bug.cgi?id=19718)**
## Description
I'm on Mandriva Linux Cooker and I have the following in my
/etc...## Submitted by Shlomi Fish
Assigned to **Xorg Project Team**
**[Link to original bug (#19718)](https://bugs.freedesktop.org/show_bug.cgi?id=19718)**
## Description
I'm on Mandriva Linux Cooker and I have the following in my
/etc/X11/xorg.conf :
{{{{{{{{{{{{{{{{{{
Section "InputDevice"
Identifier "Keyboard1"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us,il"
Option "XkbCompat" ""
Option "XkbVariant" ",lyx"
Option "XkbOptions" "compose:rwin,grp:switch,grp:alt_shift_toggle,grp_led:scroll"
EndSection
.
.
.
Section "ServerLayout"
Identifier "layout1"
InputDevice "Keyboard1" "CoreKeyboard"
InputDevice "Mouse1" "CorePointer"
Screen "screen1"
EndSection
}}}}}}}}}}}}}}}}}}
After starting the X server I have the following setxkbmap -print:
{{{{{{{{{{{
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+il:2+inet(evdev)+group(alt_shift_toggle)+compose(rwin)" };
xkb_geometry { include "pc(pc104)" };
};
}}}}}}}}}}}
And then what happens is that the keyboard misbehaves when switching from
Hebrew to English and back - sometimes the LED is on when it's English
and vice versa.
When I run the following script:
{{{{
#!/bin/sh
# setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll -variant ",phonetic," 'us,ru,il'
setxkbmap \
-option "compose:rwin,grp:switch,grp:alt_shift_toggle,grp_led:scroll" \
-variant ",lyx" \
'us,il'
}}}}
I'm getting the following setxkbmap -print:
{{{{
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+il(lyx):2+inet(evdev)+group(switch)+group(alt_shift_toggle)+compose(rwin)" };
xkb_geometry { include "pc(pc104)" };
};
}}}}
Which behaves perfectly OK.
The xorg.conf worked up to a few weeks ago, so I don't understand why it
isn't working properly now.
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/316xset led 3 doesnt work2018-12-13T18:39:23ZBugzilla Migration Userxset led 3 doesnt work## Submitted by Dan Espen
Assigned to **Xorg Project Team**
**[Link to original bug (#27971)](https://bugs.freedesktop.org/show_bug.cgi?id=27971)**
## Description
Starting with Fedora Core 12, the command:
xset led 3
fails to tu...## Submitted by Dan Espen
Assigned to **Xorg Project Team**
**[Link to original bug (#27971)](https://bugs.freedesktop.org/show_bug.cgi?id=27971)**
## Description
Starting with Fedora Core 12, the command:
xset led 3
fails to turn on the scroll lock led.
I've been using this command for years to indicate I have mail waiting. After installing FC12 on 2 different machines, the scroll lock LED stopped lighting up.
I reported this issue to Red Hat and another user confirmed the same symptom.
I now see a similar problem report for Ubuntu so I think the command is broken for all users of recent versions of xset.
Please let me know if you can duplicate or if you need more information.
Thanks.
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=29168https://gitlab.freedesktop.org/xorg/xserver/-/issues/315[keyboard dell XPS] infinite xev loop + wrong keycodes?2018-12-13T18:39:20ZBugzilla Migration User[keyboard dell XPS] infinite xev loop + wrong keycodes?## Submitted by Eatdirt
Assigned to **Xorg Project Team**
**[Link to original bug (#10928)](https://bugs.freedesktop.org/show_bug.cgi?id=10928)**
## Description
Hi,
I have been trying to define a few multimedia keys on a laptop de...## Submitted by Eatdirt
Assigned to **Xorg Project Team**
**[Link to original bug (#10928)](https://bugs.freedesktop.org/show_bug.cgi?id=10928)**
## Description
Hi,
I have been trying to define a few multimedia keys on a laptop dell xps m1210 and encountered the following strange behavior. Only one key works but with a wrong keycode and all the others generate an infinite keypress event loop. I sum up the story for two keys, if someone has any idea how it could be fixed, please help... Sorry if this is just the result of my ignorance...
My Xorg is running on mandriva cooker:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: UNKNOWN
Current Operating System: Linux dru 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 x86_64
Build Date: 04 May 2007
The story:
1) the two magic keys I want to use (MediaDirect and Camera) as they appear in dmesg:
atkbd.c: Use 'setkeycodes e012 `<keycode>`' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0x95 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e015 `<keycode>`' to make it known.
2) Therefore I defined the keycodes as required (inspired by /usr/include/linux/input.h)
setkeycodes e012 226
setkeycodes e015 212
3) Now I want to see if they are detected in X, and I tested that with xev:
******
First for the MediaDirect key. It works but the keycode is wrong, there is always a shift between the one I set and the one reported (I tested various free keycodes with setkeycodes).
KeyPress event, serial 32, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2151022928, (100,103), root:(789,126),
state 0x0, keycode 237 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
Now, since I really want to use that key anyway I set the following with xmodmap:
keycode 237 = XF86VendorHome
I tested again with xev, and the log is:
KeyRelease event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2151762376, (42,106), root:(731,129),
state 0x0, keycode 237 (keysym 0x1008ff34, XF86VendorHome), same_screen YES,
XKeysymToKeycode returns keycode: 226
XLookupString gives 0 bytes:
XFilterEvent returns: False
The keycode 226 shows up again, so something seems to be broken there?
**********
Now for the camera key (e015), that's shorter. Only one press in xev triggers an infinite loop. Again, the keycode is wrong, 187 instead of 212? The same occurs with all the other funny keys (Fn+Hibernate; or Fn+Battery) which are detected by the kernel in dmesg. Once the loop is triggered, the only way to recover a keypress event with they key that started to loop is to restart the X server.
KeyPress event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161136, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161169, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161169, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161203, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161203, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161236, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 33, synthetic NO, window 0x3000001,
root 0x156, subw 0x0, time 2152161236, (65,83), root:(754,106),
state 0x0, keycode 187 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
etc.....
4) The pb does not occur on the console side. If I press the Camera key under "showkey", no loop appears. However, the result is also weird since it looks like if I had pressed three keys:
>showkey
keycode 0 press
keycode 1 release
keycode 84 releasehttps://gitlab.freedesktop.org/xorg/xserver/-/issues/314When xkb group switch key generates multiple presses led indicator is out of ...2018-12-13T18:39:18ZBugzilla Migration UserWhen xkb group switch key generates multiple presses led indicator is out of sync## Submitted by Andriy Rysin
Assigned to **Xorg Project Team**
**[Link to original bug (#19198)](https://bugs.freedesktop.org/show_bug.cgi?id=19198)**
## Description
If I enter the command
setxkbmap -layout us,ua -option -option ...## Submitted by Andriy Rysin
Assigned to **Xorg Project Team**
**[Link to original bug (#19198)](https://bugs.freedesktop.org/show_bug.cgi?id=19198)**
## Description
If I enter the command
setxkbmap -layout us,ua -option -option grp:lwin_toggle,grp_led:num
and try to keep left win key pressed the layout in x.org actually switches many times but the led indicator is changed only once. In the end if you release the button and see that the layout randomly chosen and if you have indicator like kxkb it'll have proper flag/label to what the input layout is, but the led indicator changes only once per press and thus may be wrong.
This does not happen with modifier-only switch like Alt or Ctrl or Ctrl+Shift, only for keys wich generate symbols when pressed (like Win).
Forwarded from https://bugs.kde.org/show_bug.cgi?id=177869
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/313xorg-server-1.16.4: alt+shift+<any> combinations not working if Alt+Shift is ...2018-12-13T18:39:17ZBugzilla Migration Userxorg-server-1.16.4: alt+shift+<any> combinations not working if Alt+Shift is set as layout switching## Submitted by Igor Filakhtov
Assigned to **Xorg Project Team**
**[Link to original bug (#91555)](https://bugs.freedesktop.org/show_bug.cgi?id=91555)**
## Description
Created attachment 117514
Patch, fixing the Alt+Shift behavior...## Submitted by Igor Filakhtov
Assigned to **Xorg Project Team**
**[Link to original bug (#91555)](https://bugs.freedesktop.org/show_bug.cgi?id=91555)**
## Description
Created attachment 117514
Patch, fixing the Alt+Shift behavior
I'm using Gentoo with xorg-server-1.16.4 and cinnamon-2.4.7, and am have multiple keyboard layouts.
I've set LeftAlt+LeftShift combination to switch between available layouts.
Since then I can't use keyboard shortcuts, with "Alt+Shift", for example Alt+Shift+Tab should switch between opened windows in reverse direction to Alt+Tab.
Attached patch fixes the problem.
Reproducible: Always
Steps to Reproduce:
1. Add multiple layouts
2. Set layout switch on Alt+Shift
3. Try to use Alt+Shift+Tab to switch between windows
Actual Results:
Keyboard layout is switched, windows switched only in forward direction.
Expected Results:
Keyboard layout stays the same, windows are switched in backward direction.
Originally reported to Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=556156
(Not sure if it is correctly implemented, but at least it works for me)
**Attachment 117514**, "Patch, fixing the Alt+Shift behavior":
[alt-shift-fix.txt](/uploads/d401c44ae9e1fa2c52c0fd1cd30d9163/alt-shift-fix.txt)https://gitlab.freedesktop.org/xorg/xserver/-/issues/312Option to apparently unlock the Lock modifier on press of Caps Lock2023-06-19T17:47:03ZBugzilla Migration UserOption to apparently unlock the Lock modifier on press of Caps Lock## Submitted by Andreas Wettstein
Assigned to **Xorg Project Team**
**[Link to original bug (#56491)](https://bugs.freedesktop.org/show_bug.cgi?id=56491)**
## Description
Created attachment 69187
Unlock 'Lock' on key press rather ...## Submitted by Andreas Wettstein
Assigned to **Xorg Project Team**
**[Link to original bug (#56491)](https://bugs.freedesktop.org/show_bug.cgi?id=56491)**
## Description
Created attachment 69187
Unlock 'Lock' on key press rather than release
In [bug 27903](https://bugs.freedesktop.org/show_bug.cgi?id=27903), it was requested that unlocking of the 'Lock' modifier already happen upon the second press of the Caps Lock key, rather than on the second release. The basic support to approximate this behaviour (for ALPHABETIC keys) was added to the Xorg server version 1.12. The attached patch adds the missing support in xkeyboard-config, and makes the feature available for average users.
**Attachment 69187**, "Unlock 'Lock' on key press rather than release":
[0001-Option-to-apparently-unlock-the-Lock-modifier-on-pre.patch](/uploads/de2d568834cc13be99c87dfb1c73902c/0001-Option-to-apparently-unlock-the-Lock-modifier-on-pre.patch)https://gitlab.freedesktop.org/xorg/xserver/-/issues/311Don’t unlatch latched keys due to release events from earlier press events2018-12-13T18:39:09ZBugzilla Migration UserDon’t unlatch latched keys due to release events from earlier press events## Submitted by James Cloos `@cloos`
Assigned to **Xorg Project Team**
**[Link to original bug (#16828)](https://bugs.freedesktop.org/show_bug.cgi?id=16828)**
## Description
Latched keys get unlatched by any KeyRelease event, even...## Submitted by James Cloos `@cloos`
Assigned to **Xorg Project Team**
**[Link to original bug (#16828)](https://bugs.freedesktop.org/show_bug.cgi?id=16828)**
## Description
Latched keys get unlatched by any KeyRelease event, even if the associated KeyPress event preceded the latched key’s KeyPress event.
Find a way to avoid that.https://gitlab.freedesktop.org/xorg/xserver/-/issues/310There is hard(?) limit on a number of types.2018-12-13T18:39:04ZBugzilla Migration UserThere is hard(?) limit on a number of types.## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#27988)](https://bugs.freedesktop.org/show_bug.cgi?id=27988)**
## Description
The file types/level5 contains 2 extra types which are cur...## Submitted by Sergey V. Udaltsov
Assigned to **Xorg Project Team**
**[Link to original bug (#27988)](https://bugs.freedesktop.org/show_bug.cgi?id=27988)**
## Description
The file types/level5 contains 2 extra types which are currently commented out. If these types enabled, X crashes. If any other types are commented - X is ok again. It does not matter if types are used or not.
This behaviour depends on some external aspects. For example, it manifests itself on Power G5 (Ubuntu 10.04) but not x86.
Version: 7.5 (2009.10)https://gitlab.freedesktop.org/xorg/xserver/-/issues/309"XkbOptions" "grp:alt_shift_toggle" breaks VT switch Alt+Ctrl+F1 and Alt+Ctrl...2018-12-13T18:39:03ZBugzilla Migration User"XkbOptions" "grp:alt_shift_toggle" breaks VT switch Alt+Ctrl+F1 and Alt+Ctrl+Backspace## Submitted by Karl Kästner
Assigned to **Xorg Project Team**
**[Link to original bug (#22725)](https://bugs.freedesktop.org/show_bug.cgi?id=22725)**
## Description
Created attachment 27599
auto generated xorg configuration
Swit...## Submitted by Karl Kästner
Assigned to **Xorg Project Team**
**[Link to original bug (#22725)](https://bugs.freedesktop.org/show_bug.cgi?id=22725)**
## Description
Created attachment 27599
auto generated xorg configuration
Switching the VT is is impossible for some valid xorg-configurations on openSuSe 11.1 (fresh installation).
All Ctrl+Alt combinations are broken on my machine for following configuration:
Option "XkbOptions" "grp:alt_shift_toggle"
It works fine for me using a different switch option:
Option "XkbOptions" "grp:ctrl_shift_toggle"
It seems as if many multiple language users are effected by this bug.
This is the SaX auto-configuration triggering the fault:
Section "InputDevice"
Driver "kbd"
Identifier "Keyboard[0]"
Option "Protocol" "Standard"
Option "XkbLayout" "de,ru"
Option "XkbModel" "microsoftpro"
Option "XkbOptions" "grp:alt_shift_toggle"
Option "XkbRules" "xfree86"
Option "XkbVariant" "basic,basic"
EndSection
uname -a
Linux linux-y3ct 2.6.27.23-0.1-pae #1 SMP 2009-05-26 17:02:05 -0400 i686 athlon i386 GNU/Linux
rpm -qa xorg-x11
xorg-x11-7.4-8.13
Machine:
Hp nx6325 Laptop
**Attachment 27599**, "auto generated xorg configuration":
[xorg.conf_sax](/uploads/ba365e671327d90d72bb57e640161d43/xorg.conf_sax)
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/307Symbols for Acer Aspire 48102018-12-13T18:38:57ZBugzilla Migration UserSymbols for Acer Aspire 4810## Submitted by Stephan Otto
Assigned to **Xorg Project Team**
**[Link to original bug (#37462)](https://bugs.freedesktop.org/show_bug.cgi?id=37462)**
## Description
I'd like to contribute these symbols for the Acer Aspire 4810.## Submitted by Stephan Otto
Assigned to **Xorg Project Team**
**[Link to original bug (#37462)](https://bugs.freedesktop.org/show_bug.cgi?id=37462)**
## Description
I'd like to contribute these symbols for the Acer Aspire 4810.https://gitlab.freedesktop.org/xorg/xserver/-/issues/306xkbprint may generate incorrect postscript files...2018-12-13T18:38:55ZBugzilla Migration Userxkbprint may generate incorrect postscript files...## Submitted by Sebastian Rasmussen
Assigned to **Xorg Project Team**
**[Link to original bug (#10810)](https://bugs.freedesktop.org/show_bug.cgi?id=10810)**
## Description
xkbprint fails to generate a proper postscript file if a ...## Submitted by Sebastian Rasmussen
Assigned to **Xorg Project Team**
**[Link to original bug (#10810)](https://bugs.freedesktop.org/show_bug.cgi?id=10810)**
## Description
xkbprint fails to generate a proper postscript file if a sufficiently
long XkbOptions line is used. This line gets trucated by xkbprint before
it is used in the resulting postscript file which causes the problem.
If I use the following configuration in xorg.conf for the keyboard input device:
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbOptions"
"altwin:swap_lalt_lwin,apple:goodmap,caps:internal_nocancel,compose:rctrl,ctrl:swapcaps,eurosign:e,grp:ctrl_shift_toggle,japan:kana_lock,keypad:legacy"
(I know that this configuration is bogus, but it highlights the problem) I
get a proper postscript file from xkbprint. When I add
lv3:ralt_switch_multikey however, as in this configuration:
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbOptions"
"altwin:swap_lalt_lwin,apple:goodmap,caps:internal_nocancel,compose:rctrl,ctrl:swapcaps,eurosign:e,grp:ctrl_shift_toggle,japan:kana_lock,keypad:legacy,lv3:ralt_switch_multikey"
I get a broken postscript file from xkbprint. Diffing the two resulting
postscript files indicates that the following rows are the culprit:
--- working.ps 2007-04-15 10:48:48.000000000 +0200
+++ broken.ps 2007-04-15 10:51:27.000000000 +0200
@@ -2588,10 +2588,10 @@
kby kbdscaleheight add 16 add
moveto
1 -1 scale (Group 1) show 1 -1 scale
-kbx kbdscalewidth 0 (Layout: pc(pc105)+us+altwin(swap_lalt_lwin)+group(ctrl_shift_toggle)+ctrl(swapcaps)+compose(rctrl)+eurosign) centeroffset pop add
+kbx kbdscalewidth 0 (Layout: pc(pc105)+us+altwin(swap_lalt_lwin)+group(ctrl_shift_toggle)+level3(ralt_switch_multikey)+ctrl(swap) centeroffset pop add
kby kbdscaleheight add 32 add
moveto
-1 -1 scale (Layout: pc(pc105)+us+altwin(swap_lalt_lwin)+group(ctrl_shift_toggle)+ctrl(swapcaps)+compose(rctrl)+eurosign) show 1 -1 scale
+1 -1 scale (Layout: pc(pc105)+us+altwin(swap_lalt_lwin)+group(ctrl_shift_toggle)+level3(ralt_switch_multikey)+ctrl(swap) show 1 -1 scale
kbx kbdscalewidth 0 (Generic 105) centeroffset pop add
kby kbdscaleheight add 48 add
moveto
As far as I know parenthesis in postscript must, since they are used to
delimit strings, balance in a string or be escaped with back-slash. I belive
this is the problem, no parentheses are escaped which means that they must
balance, but the option ctrl(swapcaps) is truncated to ctrl(swap at two places
which means that that two right parentheses are missing and therefore left and
right parentheses do not balance.
My best guess is that there may be other similar assumptions about balancing of
parentheses in the code that I have not encountered. This problem was stumbled
upon when attempting to verify that another bug concerning xkbprint had been
fixed (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295015).
Version: 7.1 (2006.05)https://gitlab.freedesktop.org/xorg/xserver/-/issues/305the auto-reset AudibleBell control does not work2018-12-13T18:38:54ZBugzilla Migration Userthe auto-reset AudibleBell control does not work## Submitted by beroal
Assigned to **Xorg Project Team**
**[Link to original bug (#93568)](https://bugs.freedesktop.org/show_bug.cgi?id=93568)**
## Description
If I request that AudibleBell is auto-reset to 1, set AudibleBell to 0...## Submitted by beroal
Assigned to **Xorg Project Team**
**[Link to original bug (#93568)](https://bugs.freedesktop.org/show_bug.cgi?id=93568)**
## Description
If I request that AudibleBell is auto-reset to 1, set AudibleBell to 0, and terminate the process, AudibleBell remains at 0 (no bell rings).
There is a similar bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806236 regarding "xkbevd".
The code of the process using XCB: {{{
/* request that AudibleBell is auto-reset to 1 */
pcf_cookie = xcb_xkb_per_client_flags(conn, XCB_XKB_ID_USE_CORE_KBD
, XCB_XKB_PER_CLIENT_FLAG_AUTO_RESET_CONTROLS, XCB_XKB_PER_CLIENT_FLAG_AUTO_RESET_CONTROLS
, XCB_XKB_BOOL_CTRL_AUDIBLE_BELL_MASK, XCB_XKB_BOOL_CTRL_AUDIBLE_BELL_MASK, XCB_XKB_BOOL_CTRL_AUDIBLE_BELL_MASK);
pcf_reply = xcb_xkb_per_client_flags_reply(conn, pcf_cookie, &error);
if (! pcf_reply) {
/* skipped */
} else {
printf("autoCtrls: %x, autoCtrlsValues: %x\n", pcf_reply->autoCtrls, pcf_reply->autoCtrlsValues);
fflush(stdout);
free(pcf_reply);
/* set AudibleBell to 0 */
xcb_xkb_set_controls(conn, XCB_XKB_ID_USE_CORE_KBD
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
, XCB_XKB_BOOL_CTRL_AUDIBLE_BELL_MASK, 0
, XCB_XKB_CONTROL_CONTROLS_ENABLED
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, per_key_repeat);
xcb_flush(conn);
}
}}}
It outputs "autoCtrls: 200, autoCtrlsValues: 200".
I may be a bug in XCB, but the bug in "xkbevd" was filed pretty recently (2015-11-25) and "xkbevd" uses Xlib, so I guess it's a bug in Xorg.
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/xserver/-/issues/304keyboard becomes inactive with overlay1_enabled2018-12-13T18:38:51ZBugzilla Migration Userkeyboard becomes inactive with overlay1_enabled## Submitted by Hugh Greenberg
Assigned to **Xorg Project Team**
**[Link to original bug (#93995)](https://bugs.freedesktop.org/show_bug.cgi?id=93995)**
## Description
Created attachment 121507
compat and symbol files for xkb over...## Submitted by Hugh Greenberg
Assigned to **Xorg Project Team**
**[Link to original bug (#93995)](https://bugs.freedesktop.org/show_bug.cgi?id=93995)**
## Description
Created attachment 121507
compat and symbol files for xkb overlay
I'm using an overlay to convert F keys to media keys. This works well, however, I have noticed that if I release the overlay key while holding the F key, the keyboard may no longer focus to any window. I can get the focus to return the same way. I have attached the compat and symbol files in case that helps.
**Attachment 121507**, "compat and symbol files for xkb overlay":
[file_93995.txt](/uploads/d75e07986a6e2a349c40e3a97ccf9056/file_93995.txt)