This replaces int glamor parameter with a new enum to be more clean
and prepare for more glamor options.
No functional change.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
It is useful to know on what context we are running, and
we need to show it into xorg.log
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
This allows to choose between Glamor on OpenGL and Glamor on OpenGL ES
via an option.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
When you set the auto repeat rate trough xset to something like 250 40:
`xset r rate 250 40`
Is setting the first delay to 250ms and set the rate to 40hz (25ms)
However, if you were to apply this configuration from a xorg config file,
the result would be the first delay being applied correctly,
but the repeat rate would be set to 25Hz instead. This is because the config
option is using a rate of repeats per second but XKB stores it as interval.
Make sure this is converted correctly.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1558
Signed-off-by: EXtremeExploit <pedro.montes.alcalde@gmail.com>
On Mesa, when we request GBM_FORMAT_XRGB8888, driver set surface storage
format to GL_RGB8, which breaks GL ES rendering (on any GL ES version).
If we force set gbm_format to GBM_FORMAT_ARGB8888, then rendering
will happen and working.
Fixes#1288Fixes#1356
PointerWindows[] keeps a reference to the last window our sprite
entered - changes are usually handled by CheckMotion().
If we switch between screens via XWarpPointer our
dev->spriteInfo->sprite->win is set to the new screen's root window.
If there's another window at the cursor location CheckMotion() will
trigger the right enter/leave events later. If there is not, it skips
that process and we never trigger LeaveWindow() - PointerWindows[] for
the device still refers to the previous window.
If that window is destroyed we have a dangling reference that will
eventually cause a use-after-free bug when checking the window hierarchy
later.
To trigger this, we require:
- two protocol screens
- XWarpPointer to the other screen's root window
- XDestroyWindow before entering any other window
This is a niche bug so we hack around it by making sure we reset the
PointerWindows[] entry so we cannot have a dangling pointer. This
doesn't handle Enter/Leave events correctly but the previous code didn't
either.
CVE-2023-5380, ZDI-CAN-21608
This vulnerability was discovered by:
Sri working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The handling of appending/prepending properties was incorrect, with at
least two bugs: the property length was set to the length of the new
part only, i.e. appending or prepending N elements to a property with P
existing elements always resulted in the property having N elements
instead of N + P.
Second, when pre-pending a value to a property, the offset for the old
values was incorrect, leaving the new property with potentially
uninitalized values and/or resulting in OOB memory writes.
For example, prepending a 3 element value to a 5 element property would
result in this 8 value array:
[N, N, N, ?, ?, P, P, P ] P, P
^OOB write
The XI2 code is a copy/paste of the RandR code, so the bug exists in
both.
CVE-2023-5367, ZDI-CAN-22153
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This tests will pass after previous commit will be merged,
so, mark this tests now as PASS.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
If texture can be uploaded to GL using glTexImage2D normally, but
cannot be read back using glReadPixels, we still can accelerate it,
but we cannot create pixmap with FBO using this texture type. So,
add a flag to avoid such creations.
This allow us to accelerate 8-bit glyph masks on GL ES 2.0, because those
masks are used only as textures, and in next stages are rendered on RGBA
surfaces normally, so, we do not need to call glReadPixels on them.
This is needed for correctly working fonts on GL ES 2.0, due to inability
to use GL_RED and texture swizzle. We should use GL_ALPHA there, and
with this format we cannot have a complete framebuffer. But completed
framebuffer, according to testing, is not required for fonts anyway.
Also it fixes all 8-bit formats for GLES2.
Fixes#1362Fixes#1411
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
Xwayland maintains a connection to EI up for 10 minutes after an X11
client has vanished, to avoid going through the connection phase every
time a short lived X11 client comes and goes.
However, if the EI client gets freed (through some other event, e.g. the
user decides to terminate the EI session), Xwayland would still keep the
callback alive and end up trying to free an already freed EI client:
Invalid read of size 4
at 0x4C5E6F9: object_unref (util-object.h:89)
by 0x4C5E6F9: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404)
by 0x5E63FF: DoTimer (WaitFor.c:276)
by 0x5E6463: DoTimers (WaitFor.c:290)
by 0x5E6164: check_timers (WaitFor.c:133)
by 0x5E61E9: WaitForSomething (WaitFor.c:195)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd
at 0x48452AC: free (vg_replace_malloc.c:974)
by 0x4C5E729: object_destroy (util-object.h:73)
by 0x4C5E729: object_unref (util-object.h:91)
by 0x4C5E729: ei_unref (libei.c:77)
by 0x429525: free_ei (xwayland-xtest.c:224)
by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804)
by 0x5EA977: HandleNotifyFd (connection.c:809)
by 0x5EE8E3: ospoll_wait (ospoll.c:657)
by 0x5E624D: WaitForSomething (WaitFor.c:208)
by 0x4AD50E: Dispatch (dispatch.c:487)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
Block was alloc'd at
at 0x484782C: calloc (vg_replace_malloc.c:1554)
by 0x4C5E777: ei_create (libei.c:73)
by 0x4C5E777: ei_create_context (libei.c:97)
by 0x42994B: setup_ei (xwayland-xtest.c:366)
by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658)
by 0x54ED4C: ProcXTestFakeInput (xtest.c:441)
by 0x54EE56: ProcXTestDispatch (xtest.c:475)
by 0x4AD6E6: Dispatch (dispatch.c:546)
by 0x4BBA0B: dix_main (main.c:272)
by 0x43615D: main (stubmain.c:34)
To avoid that issue, make sure to cancel the timer as soon as a EI
client is freed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
See-also: https://bugzilla.redhat.com/2243076
Some hardware (preferably mobile) working on GLES3 way faster than
on desktop GL and supports more features. This commit will allow using
GLES3 if glamor is running over GL ES, and version 3 is supported.
Changes are the following:
1. Add compatibility layer for 120/GLES2 shaders with defines in and out
2. Switch attribute and varying to in and out in almost all shaders
(aside gradient)
3. Add newGL-only frag_color variable, which defines as gl_FragColor on
old pipelines
4. Switch all shaders to use frag_color.
5. Previous commit is reverted, because now we have more than one GL ES
version, previous commit used to set version 100 for all ES shaders, which
is not true for ES 3
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
This script runs with -e, so if the timeout command returns a non-0
exit status (meaning the while loop timed out), the script exits
immediately as well.
This would leave weston running in the background, which resulted in
meson waiting for weston to terminate until hitting meson's own timeout.
Instead, explicitly kill weston whenever the shell exits. This results
in meson recording the test as failed immediately.
As a bonus, we can drop the special handling around run-piglit.sh.
v2:
* Use trap (José Expósito)
v3:
* Explicitly use bash, and document a bashism we rely on
(Olivier Fourdan)
If we fail to setup EI, give up on using EI for XTEST and restore the
default XTEST handlers.
This happens when neither the portal nor the socket backends are usable.
This does not affect the portal operation though, if the user choose not
to allow a particular client, Xwayland would continue to use EI.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
With EI support wired to XTEST, and oeffis being enabled unconditionally
means that Xwayland will always go through the XDG portal for XTEST when
supported.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Xwayland itself, as a regular Wayland client, has no way to tell that it
is running on a nested compositor.
So to keep backward compatibility with existing (and also common) use
cases such as nested compositors, best is to disable support for the XDG
portal by default, and add a new command line option "-enable-ei-portal"
for the Wayland compositors (who spawn Xwayland rootless) to explicitly
enable support for the input emulation XDG portal in Xwayland.
A Wayland compositor running nested should not use that command line
option with Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Fixes: a1333342 - xwayland: Add XTEST support using EIS
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Some drivers might not support explicit format modifiers. On these
drivers `gbm_bo_create_with_modifiers()` will fail and the
`gbm_bo_create()` code path will be used instead.
In this case, if the LINEAR modifier is advertised (and the INVALID
modifier is not) add the `GBM_BO_USE_LINEAR` flag.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1438
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito's avatarJosé Expósito <jexposit@redhat.com>
When running the xserver:xwayland / XTS test in an environment where
an X server is running for :0, Xwayland fails to start with error:
(EE)
Fatal server error:
(EE) Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
(EE)
And the `timeout` command fails instead of waiting for Weston to
initialize.
Add the `-displayfd` parameter to Xwayland to avoid this issue.
The `-displayfd` parameter lets Xwayland pick an unused display number,
avoiding the start up error when an X server is already active for :0,
the default display number.
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
This can happen if the window has never completed a Present operation.
Fixes: 4230176080 ("xwayland/present: Embed present_vblank_rec in xwl_present_event")
GLES3.2 spec, page 126:
> The variable gl_PointSize is intended for a shader to write
> the size of the point to be rasterized. It is measured in pixels.
> If gl_PointSize is not written to, its value
> is undefined in subsequent pipe stages.
If glamor shader is use points, we should define gl_PointSize for GLES.
On Desktop GL, it "just work" due to default gl_PointSize is 1.
As @anholt requested, define this only for minimal amount of shaders
(point and glyphbit ones), to make sure than performance will not
affected
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Konstantin <ria.freelander@gmail.com>
If there is no quads to draw, then we have a possibility to call
glDrawElements with type as zero, which will generate
GL_INVALID_ENUM error. While this error is harmless, it is annoying.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When neither `wayland-info` nor `weston-info` are installed, the
`xwayland-piglit.sh` script will wait indefinitely for the compositor
to start.
Use `Xwayland -pogo` instead to wait until weston is initialized.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1536
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
If a client tries to send XTEST events while there is no sendEventsProc
defined for the given device, Xwayland would call into 0x0 and crash.
Make sure the handler is defined before trying to use it, to avoid the
crash.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1574
This is more portable than libbsd as everything Just Works, even on BSD systems,
and is the recommended method of consuming libbsd nowadays.
It also helpfully lets things work with glibc-provided functions for new
enough glibc.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/973
Co-authored-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Sam James <sam@gentoo.org>
We specify a sensible default geometry for decorated rootful windows,
but not for undecorated ones. Make the default geometry apply to rootful
windows in general.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
While we now have support for resize of the root window through
libdecor, we still ignore toplevel configure dimensions when libdecor is
not in use. This ignores user intent in many Wayland servers, and some
xdg_toplevel states when active have strong requirements for adherence
to configure dimensions.
Resize in response to xdg_toplevel configure dimensions like we do for
libdecor configure events.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
The upcoming handling of plain xdg_toplevel.configure events will need
to use the xwl_window resize helper. Move it outside XWL_HAS_LIBDECOR,
move the remaining dimension logic from handle_libdecor_configure into
it and update the name accordingly.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
When handling libdecor configure, we first update our xwl output and
screen if dimensions differ from the current xwl_screen, and then commit
a new libdecor frame which acknowledges the xdg_surface.configure event.
If the initial configure events contains non-zero dimensions, we will
update the xwl output before acknowledging the initial configure. As we
attach a buffer and commit the surface when updating the output, this
leads to a protocol error.
Instead, move the surface commit till the end of the configure handler
so it always happens after the ack.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Similar to commit 94deed272 - " xwayland: Use sensible defaults for
rootful size", mark fullscreen mode as fixed so that the actual monitor
layout is not reflected in the single fullscreen rootful window.
Without this, if "-fullscreen" is used without "-geometry", the XRandR
configuration is taken from the compositor via wl_output/xdg-output and
cannot be changed by the X11 clients.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Enforce sensible min/max values for the window size when using libdecor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This is to avoid repeating the same code in two places.
This is essentially a cosmetic change, not a functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Allow passing an optional libdecor configuration pointer to
xwl_window_update_libdecor_size() so that we can reuse it from more than
one place and avoid duplicating that code.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The configure handler in libdecor is triggered any time a new
configuration is received.
According to the documentation from libdecor, an application should
respond to that event by creating a suitable libdecor_state, and apply
it using libdecor_frame_commit().
So we ought to attach a new buffer matching the new size and commit
the Wayland surface.
The actual content of the window does not need to be explicitly
repainted, that occurs through the call to SetRootClip():
xwl_output_set_mode_fixed()
-> update_screen_size()
-> SetRootClip()
-> miHandleValidateExposures()
-> miWindowExposures()
-> miPaintWindow()
This fixes an issue with mutter where maximizing a window and then
switching to another window would sometimes resize the Xwayland window
back to its pre-maximized size, or with Weston where the Xwayland window
would initially show up black until the pointer moves to the window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This moves the code which updates the XRandR modes and sets the root
window size to its own function.
This preparation work for the next commit, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The configure handler for libdecor, namely handle_libdecor_configure(),
is where both the content and the decorations get resized (when needed).
If for any reason, the actual size of the Xwayland screen fails to be
updated, we would still appy the expected size rather than the actual
one for the libdecor state.
To avoid this, use the actual xwl_screen width/height for the libdecor
state.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Konstantin
Pedro Montes Alcalde
Balló György
Peter Hutterer
John Kennedy
Austin Shafer
Peter Grehan
Gleb Popov
Niclas Zeising
Olivier Fourdan
Jeffy Chen
Michel Dänzer
José Expósito
Sam James
Kenny Levinsen