It had nothing left in it that was used but wasn't in dix-config.h.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The actual code was gone in 27819950e4,
but some checks remained.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
ajax deleted the evdev driver in the removal of fbdev and the linux
backend.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
No matter what libdrm version was installed, it always set
the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1.
This obviously leads to compilation problems.
Fixes: 9232835bd1 ("glamor: use drmGetDeviceNameFromFD2 when available")
Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-and-Tested-by: Qiang Yu <Qiang.Yu@amd.com>
There is no pixmap associated with source-only pictures.
Fixes Xephyr -fakexa crashing on startup.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by
running xrandr) would potentially keep adding the same modes, causing
the Monitor->Modes list to keep growing larger and using up more memory.
Fix this by calling xf86PruneDuplicateModes after adding the modes
returned by xf86DDCGetModes. This makes sure there's only one instance
of each unique mode in the list.
v2:
* Replace semicolon with {} for empty for loop (Emil Velikov)
* Slightly tweak commit log to avoid minor inaccuracy about what
xf86PruneDuplicateModes does
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99521
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
None of this is actually wired up to anything, so we can also remove the
devPrivates from the DamageRec. The DamageExtRec is what would need
devPrivates for selinux labeling, in principle.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If a client sends a RecordUnregisterClients request with an nClients
field larger than INT_MAX / 4, an integer overflow leads to an
out of boundary access in RecordSanityCheckClientSpecifiers.
An example line with libXtst would be:
XRecordUnregisterClients(dpy, rc, clients, 0x40000001);
Reviewed-by: Adam Jackson <ajax@redhat.com>
Same trick as in fb: just do a normal GetImage and deal with the
planemask on the CPU if you have to. Since the software fallback hit for
glamor is pretty brutal, this is a much more impressive win for glamor
than it was for fb:
11100.0 87700.0 (7.901) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
9840.0 47800.0 (4.858) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
1550.0 4240.0 (2.735) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
9450.0 78900.0 (8.349) (0xaaaaaaaa) GetImage 10x10 square
6910.0 30900.0 (4.472) (0xaaaaaaaa) GetImage 100x100 square
431.0 2020.0 (4.687) (0xaaaaaaaa) GetImage 500x500 square
Measured with Xephyr -glamor on Skylake GT3e.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Formerly we'd zero the image data and then pull out a plane at a time.
It's faster to apply the planemask after the fact, since that turns the
GetImage into a memcpy:
100000.0 101000.0 (1.010) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
42400.0 59400.0 (1.401) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
3040.0 5280.0 (1.737) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
96100.0 95200.0 (0.991) (0xaaaaaaaa) GetImage 10x10 square
29600.0 36800.0 (1.243) (0xaaaaaaaa) GetImage 100x100 square
1850.0 2620.0 (1.416) (0xaaaaaaaa) GetImage 500x500 square
Measured with Xvfb at depth 24 on Skylake i7-6560U.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Copied from Mesa with no modifications. Gives us Geminilake PCI IDs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
is raised, in which case the texture returned is zero.
But the texture value is not checked in glamor_create_fbo() and glamor
will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:
Truncated backtrace:
Thread no. 1 (10 frames)
#4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
#5 glamor_create_fbo_from_tex at glamor_fbo.c:112
#6 glamor_create_fbo at glamor_fbo.c:159
#7 glamor_create_fbo_array at glamor_fbo.c:210
#8 glamor_create_pixmap at glamor.c:226
#9 compNewPixmap at compalloc.c:536
#10 compAllocPixmap at compalloc.c:605
#11 compCheckRedirect at compwindow.c:167
#12 compRealizeWindow at compwindow.c:267
#13 RealizeTree at window.c:2617
Check the value returned by _glamor_create_tex() in glamor_create_fbo()
and return NULL in the texture is zero.
All callers of glamor_create_fbo() actually check the returned value and
will use a fallback code path if it's NULL.
Please cherry-pick this to active stable branches.
Bugzilla: https://bugzilla.redhat.com/1433305
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2:
- Require power-of-two bpp in ScreenInit
- Eliminate fbCreatePixmapBpp
v3
- Squash in the exa and glamor changes so we can remove pRotatedPixmap
in the same stroke.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently ignore the old options that would ask for it.
The cirrus alpine driver has been updated to default to 16bpp, and both
it and the i810 driver can now use the 32->24 conversion code in shadow
if they want. All other drivers support 32bpp. Configurations that
explicitly request 24bpp in order to fit in VRAM will be broken now
though.
v2: Fix command line options to silently ignore 24bpp rather than fail
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This ends up passing 0 as the bpp argument to fb screen setup, which is
not really the best plan.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This code is using GetImage to accumulate a logical view of the window
image (since the windows will be clipped to their containing screen),
and then PutImage to load that back into the pixmap. What it wasn't
doing was constructing a region for the obscured areas of the window and
emitting graphics exposures for same.
v2: Fix coordinate translation when the source is the root window
v3: Create sourceBox with the right coordinates initially instead of
translating (Keith Packard)
v4: Clamp the region to 15 bits to avoid overflow (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The fbo_array of a given glamor pixmap can be NULL in some cases, as
glamor_create_fbo_array() can fail to allocate the FBO array.
If this is the case, glamor_pixmap_fbo_at() will return NULL even though
the box index is valid, and glamor_set_destination_drawable() simply
assumes glamor_pixmap_fbo_at() will return an FBO prior to pass the
value to glamor_set_destination_pixmap_fbo(), which will segfault.
We need a way for glamor_set_destination_drawable() to fail safely and
let the caller know about the failure.
Add a boolean return value to glamor_set_destination_drawable() for that
purpose.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If the screen pixmap or the corresponding texture creation with glamor
fails, exit cleanly with an error message instead of segfaulting.
Fixes: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
glamor_create_pixmap() would return a NullPixmap if the given size is
larger than the maximum size of a pixmap.
But glamor_get_pixmap_texture() won't check if the given pixmap is
non-null, leading to a segfault if glamor_create_pixmap() failed.
This can be reproduced by passing Xephyr a very large screen width,
e.g.:
$ Xephyr -glamor -screen 32768x1024 :10
(EE)
(EE) Backtrace:
(EE) 0: Xephyr (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
(EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
(EE) 4: Xephyr (ephyrCreateResources+0x98)
(EE) 5: Xephyr (dix_main+0x275)
(EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 7: Xephyr (_start+0x2a)
(EE) 8: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Aborted (core dumped)
Bugzilla: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The linemarkers in the preprocessor output from gcc5 on Cygwin have
canonicalized paths to included files (e.g. xserver/build/../include/misc.h
is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
which causes the transformation performed by -fcanonical-system-headers to
be applied to all include pathnames)
These canonicalized paths won't match $topdir, so sdksyms doesn't look at
the contents of those headers for sdk exported symbols.
Workaround this by canonicalizing all the paths we consider, using readlink.
v2:
Keep a cache of readlink results so it isn't quite so dreadfully slow.
Reviewed-by: Adam Jackson <ajax@redhat.com>
ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
be protected against an integer overflow during length check. This is
already included in ProcRenderCreateLinearGradient since the fix for
CVE-2008-2362.
This can only be successfully exploited on a 32 bit system for an
out of boundary read later on. Validated by using ASAN.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Client resources can survive the client itself, in which case we
may end up in our sync callback trying to access client's data after
it's been freed/reclaimed.
Add a ClientStateCallback handler to monitor the client state changes
and clear the sync callback set up by the glamor drm code if any.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Tested-by: Mark B <mark.blakeney@bullet-systems.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This looks like it's always been wrong, but didn't matter before the single
test binary changes as the wrapper was only in place for tests which didn't
care about it's effects, so didn't forward to the real implementation. (see
the changes to protocol-xiselectevents.c in 773fc07e)
This fixes the protocol_xigetselectedevents_test for me. I'm a bit
surprised that passes for anyone at the moment.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is for glamor can support fd from DRM render node which is useful
for a render only DDX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.
Make sure to destroy the frame callback, if any, when that occurs, so
that next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Rui Matos <tiagomatos@gmail.com>
in XWayland, dri3_send_open_reply() is called from a sync callback, so
there is a possibility that the client might be gone when we get to the
callback eventually, which leads to a crash in _XSERVTransSendFd() from
WriteFdToClient() .
Check if clientGone has been set in the sync callback handler to avoid
this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99149
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1416553
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Mark B <mark.blakeney@bullet-systems.net>
timingsafe_memcmp.c:21:1: warning: no previous prototype for ‘timingsafe_memcmp’ [-Wmissing-prototypes]
timingsafe_memcmp(const void *b1, const void *b2, size_t len)
Signed-off-by: Adam Jackson <ajax@redhat.com>
This avoids recomputing the span data for every dash. x11perf thinks
this is a pretty modest speedup:
832919.4 840471.1 ( 1.009) 100-pixel dashed ellipse
672353.1 680652.2 ( 1.012) 100-pixel double-dashed ellipse
13748.9 24287.9 ( 1.767) 100-pixel wide dashed ellipse
9236.3 21298.2 ( 2.306) 100-pixel wide double-dashed ellipse
But part of the reason it's so modest there is that the arcs are
relatively small (100 pixel diameter at line width 10, so ~6000 pixels)
and the dashes relatively large (30 on 20 off so ~6 dashes per
quadrant).
With larger arcs and finer dashes this is much more impressive. A fairly
trivial testcase of a single 15000x13000 arc with the default {2, 2}
dash pattern drops from ~3500 milliseconds to 10 milliseconds.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
drawArc does some fairly expensive computation, but it's only sensitive
to arc width/height. Thread the span data up through the call chain so
it's at least possible for the caller to cache things.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Outdent, normalize comment formatting, and use 'goto out' idiom for
error paths. No functional change.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
keyboard_check_repeat() fetches the XWayland seat from the
dev->public.devicePrivate do do its thing.
If a key event is sent programmatically through Xtest, our device is the
virtual core keyboard and that has a dev->public.devicePrivate of NULL,
leading to a segfault in keyboard_check_repeat().
This is the case with "antimicro" which sends key events based on the
joystick buttons.
Don't set the checkRepeat handler on the VCK since it cannot possibly work
anyway and it has no effect on the actual checkRepeat intended functionality.
Bugzilla: https://bugzilla.redhat.com/1416244
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the shadow framebuffer overallocation bug fixed (ref below), Xorg +
fbdev has tens to hundreds of kilobytes more baseline memory usage than
Xfbdev. That's not nothing, but it's little enough that we should focus
our efforts on the server that actually gets development attention.
https://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/commit/?id=2c5eba8
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
- typo in #ifdef check
- also need to add AC_CHECK_FUNCS([arc4random_buf])
Reported-by Eric Engestrom. Thanks
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
During the InitInput() phase, the wayland events get dequeued so we
can possibly end up calling dispatch_pointer_motion_event().
If this occurs before xwl_seat->focus_window is set, it leads to a NULL
pointer derefence and a segfault.
Check for xwl_seat->focus_window in both pointer_handle_frame() and
relative_pointer_handle_relative_motion() prior to calling
dispatch_pointer_motion_event() like it's done in
pointer_handle_motion().
Bugzilla: https://bugzilla.redhat.com/1410804
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And the current code for MitToId has a use-after-free() issue.
[Also remove the actual implementations - ajax]
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Provide the function definition for systems that don't have it.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The input thread should generate events, not send them. Make it easier to
find the instances where it's doing so.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
