The new names (`dead_schwa` and `dead_SCHWA`) fit much better with
the `dead_a`, `dead_A` scheme for the other vowels, and also with
how other upper- and lowercase schwa symbols are named.
The old names are deprecated, and can be removed quite soon because
they are not used anywhere -- not in xkeyboard-config at least.
(The dead vowel symbols were introduced fifteen years ago in commit
935dd37be4, to support compose sequences for Amharic, but neither
libX11 nor xkeyboard-config were ever updated to make use of them.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Ten years ago, in commit 6d4acb0e3a, these four keysyms were added
to support new compose sequences that then could be typed with the
newish German T3 layout -- or at least, that was the intention.
The commit was in response to https://bugs.freedesktop.org/62189,
right before I retracted the patch after learning that there are no
precomposed characters that use those four symbols as diacritics.
The commit should have been reverted then, but... it lingered and
was forgotten. No layout in xkeyboard-config uses these symbols
(obviously, as they serve no purpose) and meanwhile the T3 layout
itself has become obsolete [1], so... it's time to clean up.
[1] https://de.wikipedia.org/wiki/DIN_2137#Neufassung_2018
"die Belegung T3 wird nicht mehr definiert, da die Erfahrung gezeigt
hat, dass eine solche Tastatur ohnehin nicht produziert wird"
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
They have been deprecated for more than twenty years,
and were either misspelled or too specifically named.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The symbolic name for the feminine ordinal indicator is 'ordfeminine',
so the name for the masculine ordinal indicator should be 'ordmasculine'
instead of just 'masculine'. Deprecate this latter form.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
And deprecate the misspelled ones -- guillemots are seabirds [1],
guillemets are the sideways double chevrons [2].
[1] https://en.wikipedia.org/wiki/Guillemot
[2] https://en.wikipedia.org/wiki/Guillemet
This will allow to finally use properly spelt symbol names
in the layouts of xkeyboard-config.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Fixes compiler errors of "unexpected ';' before ')'" when calling
the SIZEOF macro on XvMC requests.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
We could not find any evidence it was ever used, but defining it
caused C++11 compilers to complain:
/usr/X11R6/include/X11/Xfuncproto.h:173:24:
warning: ISO C does not permit named variadic macros [-Wvariadic-macros]
#define _X_NONNULL(args...) __attribute__((nonnull(args)))
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This extension exists to serve one purpose: reliably identifying
Xwayland. Previous attempts at doing so included querying root window
properties, output names or input device names. All these attempts are
somewhat unreliable. Instead, let's use an extension - where that
extension is present we have an Xwayland server.
Clients should never need to do anything but check whether the extension
exists through XQueryExtension/XListExtensions.
This extension provides a single QueryVersion request only, and
that is only to provide future compatibility if we ever need anything
other than "this extension exists" functionality.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Workaround the collision between ControlMask #defined in X11/X.h and
ControlMask used as the name of a structure member in
w32api/processthreadsapi.h in w32api 10.0.0
DRI3SetDRMDeviceInUse is a hint that lets a client tell the server
what DRM device it is currently using. This lets the server make
more informed decisions for what modifiers to return to the client.
This is needed for proper linux dmabuf feedback with Xwayland
All modern compilers (GCC>=4.6, Clang>=3.0) define this macro, so we can
use it to detect 64-bit longs without adding to the architecture list.
This change allows me to successfully run a simple X11 window on a
64-bit FreeBSD RISC-V QEMU VM via SSH forwarding. Without this change
I get an error that DISPLAY cannot be opened.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
The Xserver itself is capable of terminating itself once all X11 clients
are gone, yet in a typical full session, there are a number of X11
clients running continuously (e.g. the Xsettings daemon, IBus, etc.).
Those always-running clients will prevent the Xserver from terminating,
because the actual number of X11 clients will never drop to 0.
To solve this issue directly at the Xserver level, this add new entries
to the XFixes extension to let the X11 clients themselves specify the
disconnect mode they expect.
Typically, those X11 daemon clients would specify the disconnect mode
XFixesClientDisconnectFlagTerminate to let the Xserver know that they
should not be accounted for when checking the remaining clients prior
to terminate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
These keysyms were already present in 2.6.11 which is the first tag in git.
A few notes on specific keys here:
- KEY_EJECTCLOSECD is theoretically different to XF86XK_Eject (kernel
KEY_EJECTCD) but the actual usage in the hwdb remappings seems to be
random. Either way it's already mapped to XF86XK_Eject in
symbols/inet so let's just add an entry for the sake of documenting it.
- XF86XK_CycleAngle seems like the best match for KEY_ANGLE
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few notes on specific keys here:
- Some existing keysyms used some brand names. e.g. KEY_WORDPROCESSOR ->
existing XF86XK_Word. This introduces some minor inconsistency with
unbranded new keys like KEY_GRAPHICSEDITOR -> XF86XK_GraphicsEditor.
- XF86XK_DisplayToggle is *not* XF86XK_Display (which represents
KEY_SWITCHVIDEOMODE)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few notes on specific keys here:
- There are exiting XF86XK_ZoomIn/Out keys, but they don't seem appropriate
for KEY_CAMERA_ZOOMIN and friends. New symbols are introduced here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ALSToggle has a terrible name, it's the Ambient Light Sensor. But it matches
the kernel define so...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Linux kernel adds a few evdev keycodes roughly every other release. These
aren't available as keysyms through XKB until they have been added as keycode
in xkeyboard-config and mapped there to a newly defined keysym in the X11
proto headers.
In the past, this was done manually, a suitable keysym was picked at
random and the mapping updated accordingly. This doesn't scale very well and,
given we have a large reserved range for XF86 keysyms anyway, can be done
easier.
Let's reserve the range 0x10081XXX range for a 1:1 mapping of Linux kernel
codes. That's 4095 values, the kernel currently uses only 767 anyway. The
lower 3 bytes of keysyms within that range have to match the kernel value to
make them easy to add and search for. Nothing in X must care about the actual
keysym value anyway.
Since we expect this to be parsed by other scripts for automatic updating, the
format of those #defines is quite strict. Add a script to generate keycodes as
well as verify that the existing ones match the current expected format.
The script is integrated into the CI and meson test, so we will fail if an
update breaks the expectations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We've been adding to those over the last few years. Not a huge amount but
enough that we should stop pretending we don't touch that header.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They are fixed length (4 characters), and don't need NUL-terminators.
This makes gcc stop warning when they're not NUL-terminated, and instead
warn if they are passed to functions expecting NUL-terminated strings.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
As of version 7.7, the X protocol does not define a Unicode equivalent for
them. The U+27E8 and U+27E9 equivalents were introduced by 618956f1f ("The
big keysym cleanup, to bring implementation in line with the recent revision
of Appendix A of the protocol spec."), but as xterm Patch #226 explicitly
notes, U+2329 and U+232A should be used rather than U+27E8 and U+27E9. Gtk
also inherited this.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Add XF86XK_FullScreen keysym, to be used as mapping for evdev's
KEY_FULL_SCREEN.
Chromebooks have a special media key for toggling full screen mode.
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
