Age | Commit message (Collapse) | Author |
|
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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
|
|
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
|
|
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This now matches the autotools installation
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Generated outputs are identical
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
Meson's pkg.generate() is not suitable for header only libraries
and using configure_file() allows for more fine tuned control.
This also makes the meson and autotools builds more in sync where
they both use the same .pc.in files.
v2: Drop exec_prefix.
|
|
Fixes: xorgproto#28
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Fails distcheck.
This reverts commit 032a3a16cd6c283fc596c6410c59665cfa1c6cab.
|
|
Fixes: xorgproto#28
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
This will allow applications to respond to changes of power level
of a monitor, e.g. an application may stop rendering and related
calculations when the monitor is off.
Bump DPMS version to 1.2, install dpmsproto.pc.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
|
|
The Meson and Autotools builds disagree about what extensions are legacy.
This patch makes the Meson build identical to autotools.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Closes: https://gitlab.freedesktop.org/xorg/proto/xorgproto/issues/21
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
If the Complete event has this mode, the client is not using
the more optimal format/modifier for the buffer allocation. The
client must explicitely inform the server that it understands
this mode by adding the PresentOptionSuboptimal flag when calling
PresentPixmap.
Its main usage as of now is to allow clients to re-fetch DRI3
format modifiers as some modifiers might allow direct scanout.
Bump presentproto version to 1.2.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
DRI3 version 1.2 adds support for explicit format modifiers,
including multi-planar buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
The RandR 1.6 patches were merged without the necessary meson changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Since 7.0.31 we've added four new keysyms (XF86XK_Keyboard, _WWAN,
_RFKill, and _AudioPreset).
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
These headers are in X11/dri but are included without a relative path.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Mostly this is is so the generated Xpoll.h can be emitted into a usable
directory when we build as a subproject.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
Builds on the work Dylan Baker did for glproto. Note that this does
not produce _quite_ identical pc files as the autotools build, but it
only affects the name and description strings which are only informative
anyway.
Just to be petty:
% time ( ./configure --prefix=/tmp/xorgproto && make install; ) >& /dev/null
2.42s user 1.67s system 107% cpu 3.804 total
% time ( meson setup build && meson configure build -Dprefix=/tmp/xorgproto && ninja -C build install ) >& /dev/null
0.55s user 0.11s system 100% cpu 0.658 total
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
This does everything the autotools build does except muck with your git
config. It does so much faster, and has an "ext_glproto" dependency that
is meant to be used with meson's wrap capability.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
|