This add a new flag POINTER_RAWONLY for GetPointerEvents() which does pretty much the opposite of POINTER_NORAW. Basically, this tells GetPointerEvents() that we only want the DeviceChanged events and any raw events for this motion but no actual motion events. This is preliminary work for Xwayland to be able to use relative motion events for raw events. Xwayland would use absolute events for raw events, but some X11 clients (wrongly) assume raw events to be always relative. To allow such clients to work with Xwayland, it needs to switch to relative raw events (if those are available from the Wayland compositor). However, Xwayland cannot use relative motion events for actual pointer location because that would cause a drift over time, the pointer being actually controlled by the Wayland compositor. So Xwayland needs to be able to send only relative raw events, hence this API. Bump the ABI_XINPUT_VERSION minor version to reflect that API addition. v2: Actually avoid sending motion events (Peter) v3: Keep sending raw emulated events with RAWONLY (Peter) Suggested-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130 |
||
---|---|---|
.gitlab-ci | ||
Xext | ||
Xi | ||
composite | ||
config | ||
damageext | ||
dbe | ||
dix | ||
doc | ||
dri3 | ||
exa | ||
fb | ||
glamor | ||
glx | ||
hw | ||
include | ||
m4 | ||
man | ||
mi | ||
miext | ||
os | ||
present | ||
pseudoramiX | ||
randr | ||
record | ||
render | ||
test | ||
xfixes | ||
xkb | ||
.appveyor.yml | ||
.dir-locals.el | ||
.gitignore | ||
.gitlab-ci.yml | ||
.travis.yml | ||
COPYING | ||
Makefile.am | ||
README.md | ||
autogen.sh | ||
configure.ac | ||
devbook.am | ||
docbook.am | ||
manpages.am | ||
meson.build | ||
meson_options.txt | ||
xorg-server.m4 | ||
xorg-server.pc.in | ||
xserver.ent.in |
X Server
The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens" that the client program can draw into.
Windows are then composed on the actual screen by the X server (or by a separate composite manager) as directed by the window manager, which usually communicates with the user via graphical controls such as buttons and draggable titlebars and borders.
For a comprehensive overview of X Server and X Window System, consult the following article: https://en.wikipedia.org/wiki/X_server
All questions regarding this software should be directed at the Xorg mailing list:
https://lists.freedesktop.org/mailman/listinfo/xorg
The primary development code repository can be found at:
https://gitlab.freedesktop.org/xorg/xserver
For patch submission instructions, see:
https://www.x.org/wiki/Development/Documentation/SubmittingPatches
As with other projects hosted on freedesktop.org, X.Org follows its Code of Conduct, based on the Contributor Covenant. Please conduct yourself in a respectful and civilized manner when using the above mailing lists, bug trackers, etc: