It appears that people who developed EXA forgot that there used to be
graphics devices that used 24-bits (3 bytes) instead of 32-bits (4 bytes)
in order to display one pixel. The lack of 24-bit color support inside
exaGetPixmapFirstPixel causes SiS 6326 to crash when running Xfce since
SiS 6326 does not support 32-bit color.
Signed-off-by: Kevin Brace <kevinbrace@gmx.com>
Commit 91c42093b2 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits == 32, but these are not displayable on a
depth 24 screen, leading to visually corrupted desktops
under some compositors, e.g., fdo bug 104597 "Compton
weird colors" when running compton with
"compton --backend glx".
Be more conservative for now and only select fbconfigs with
8 bpc red, green, blue components for composite visuals.
Fixes: 91c42093b2 ("glx: Duplicate relevant fbconfigs for
compositing visuals")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104597
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit bebcc8477c)
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0
#1 0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000)
at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>,
avalue=<optimized out>) at ../src/x86/ffi64.c:525
#13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0
#14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0
#15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0
#16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0
#17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). While not against protocol, mutter ends
up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
makes the naïve assumption that we always have a valid seat, we end up
returning a pointer to the empty list itself instead of an actual seat
and causing ourselves to segfault.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 98edb9a35e)
ProcRRSetScreenSize() does bounds checking to ensure that none of the CRTCs have
a viewport that extends beyond the new screen size. In doing so, it accounts for
if the CRTC is rotated 90 or 270 degrees, swapping width and height.
However, it does so by testing if crtc->rotation is equal to RR_Rotate_90 or
RR_Rotate_270. crtc->rotation is a bit mask, and it includes reflection as well
as rotation. If a CRTC is reflected as well as rotated, it will incorrectly fail
this test, resulting in incorrect dimensions being used to verify the validity
of the new screen size. In some cases, this can cause valid uses of
ProcRRSetScreenSize() to fail with BadMatch.
This patch fixes the issue by testing that the bits RR_Rotate_90 or
RR_Rotate_270 are set, rather than testing for equality.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 6b26a7bda9)
- Avoid some needlessly complex equations for calculating the color at a
point in a gradient field.
- Avoid calculating certain values multiple times.
- Use similar variable names across the two versions of the get_color
function where practical.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ff410c56bf)
When compositing a no-reflect gradient, 'before' the gradient is empty,
but 'after' the gradient is padded with the final color. Both sides are
supposed to be empty.
This is fixed by moving the virtual stops to match the first and last
client-supplied stops for no-reflect gradients, then causing everything
'before' the initial virtual stop and 'after' the final virtual stop to
emit rgba(0,0,0,0). This does not impact gradients using the other
reflect modes.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 5815c7b595)
If _pt_distance is negative, it causes the final distance to be negative
in the repeat-reflect case. Moving the scaling by _pt_distance earlier
avoids this problem, and simplifies some equations as a bonus.
Bugzilla: https://bugs.freedesktop.org/98508
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 3e377e238f)
This is a rare occurrence of a crash in Xwayland for which I don't have
the reproducing steps, just a core file.
The backtrace looks as follow:
#0 raise () from /usr/lib64/libc.so.6
#1 abort () from /usr/lib64/libc.so.6
#2 OsAbort () at utils.c:1361
#3 AbortServer () at log.c:877
#4 FatalError () at log.c:1015
#5 OsSigHandler () at osinit.c:154
#6 <signal handler called>
#7 xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162
#8 xwl_screen_post_damage () at xwayland.c:514
#9 block_handler () at xwayland.c:665
#10 BlockHandler () at dixutils.c:388
#11 WaitForSomething () at WaitFor.c:219
#12 Dispatch () at dispatch.c:422
#13 dix_main () at main.c:287
The crash is caused by dereferencing “xwl_pixmap->buffer” in
xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL.
Reason for this is because the corresponding pixmap is from the root
window and xwayland is rootless by default.
This can happen if the window was mapped, redirected, damaged and
unredirected immediately, before the damage is processed by Xwayland.
Make sure to remove the dirty window from the damage list on unrealize
to prevent this from happening.
Credit goes to Adam Jackson <ajax@nwnk.net> and Daniel Stone
<daniel@fooishbar.org> for finding the root cause the issue.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit 3362422e84)
The inputthread is kept locked all the time while X server's VT is not active.
If the X server is terminated while not active, it will be stuck forever in
InputThreadFini waiting for the thread to join, but it wouldn't because it is
locked.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103782
Signed-off-by: Michal Srb <msrb@suse.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 71348e99a8)
If a window that is fully covered by an automatic-redirected descendant
(even implicitly, eg. via BackingStores) is reparented, the automatic
updates could be broken if the new parent is not marked as having
damaged descendants.
Fix this issue by propagating the damagedDescendants flag whenever a
window is reparented.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
(cherry picked from commit d5c23b2948)
Fixes double-free later in xf86XvMCCloseScreen, which would generally
cause fireworks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 75408f53d4)
Building with strict-aliasing rightly chirps here:
../os/xdmcp.c: In function ‘XdmcpRegisterConnection’:
../os/xdmcp.c:489:31: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
&((struct sockaddr_in6 *) &address)->sin6_addr.s6_addr[12];
^~~~~~~~~~~~
We have "const char *address", so &address here is a char ** (i.e., it
points to the slot on the stack containing the pointer to the character
array passed in as an argument). Casting that to a struct sockaddr_in6 *
is wrong, because it means that area of the stack will be reinterpreted
as a struct sockaddr_in6.
Instead, cast address, not &address.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 652913cd94)
When cross compiling, the value of MONOTONIC_CLOCK would be "cross
compiling", because AC_RUN_IFELSE doesn't work. However when enabling
wayland, a monotonic clock is required and configure aborts.
We change detection of CLOCK_MONOTONIC to degrade it gracefully from a
run check to a declaration check in case of cross compilation based on
the assumption that most systems will have a monotonic clock and those
that don't won't be able to run Xwayland anyway. The trade-off
essentially is either "always fail cross compilation" or "produce an
unusable Xwayland for unusual platform" and this commit switches to the
latter.
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
Bug-Debian: https://bugs.debian.org/882531
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit c601c8faf5)
Erroneous condition caused us to keep going with all devices that didn't have
ID_INPUT set.
Fixes: 5aad81445c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104382
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a309323328)
SAMPLE is a GLSL keyword in newer OpenGL version.
This fix issue with gnome-shell and playing video using xv
Signed-off-by: Corentin Rossignon <corentin.rossignon@gmail.com>
Bugzilla: https://bugs.freedesktop.org/104405
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit dbfbe58b94)
We weren't cancelling the old timer when changing cursors, making things
go all crashy. Logically we could always cancel the timer first, but
then we'd have to call TimerSet to re-arm ourselves, and GetTimeInMillis
is potentially expensive.
Reported-by: https://devtalk.nvidia.com/default/topic/1028172/linux/titan-v-ubuntu-16-04lts-and-387-34-driver-crashes-badly/post/5230967/#5230967
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
(cherry picked from commit de60245e05)
This is very slightly more efficient since the callback now doesn't need
to walk every input device, instead we know exactly which device's
cursor is being updated. AnimCurTimerNotify() gets outdented nicely as a
result. A more important side effect is that we can stop using the
TimerAbsolute mode and just pass in the relative delay.
In AnimCurSetCursorPosition, we no longer need to rearm the timer with
the new screen; it is enough to update the device's state. In
AnimCurDisplayCursor we need to notice when we're switching from
animated cursor to regular and cancel the existing timer.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 094a63d56f)
If the return value is non-zero here, DoTimer() will automatically rearm
the timer for the new (relative) delay. 'soonest' is in absolute time,
so subtract off 'now' and return that.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit cc3241a712)
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 3abbdb7318)
The install rule of Xorg.wrap is currently a dependency of the
install-data target instead of the install-exec target. The build also
uses install-exec-hook to change the ownership and set the SUID bit on
the Xorg.wrap binary. The problem is that install-exec-hook is only
ordered respective to the install-exec target, the rules of install-data
may or may not have been executed.
If install-exec-hook runs before the Xorg.wrap binary is in place,
a message similar to the following will be present in the build log:
chown: cannot access '/pkgdir/usr/lib/xorg-server/Xorg.wrap': No such file or directory
make[6]: [Makefile:1151: install-exec-hook] Error 1 (ignored)
All that needs to be done is to change the name of the program variable
to contain 'exec' for the install rule to depend on the install-exec
target.
Excerpt from the Automake manual, chapter 12.2 The Two Parts of Install:
"Any variable using a user-defined directory prefix with ‘exec’ in the
name (e.g., myexecbin_PROGRAMS) is installed by install-exec. All other
user-defined prefixes are installed by install-data."
https://bugs.freedesktop.org/show_bug.cgi?id=104419
Signed-off-by: Lukáš Krejčí <lskrejci@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit f615cb62d4)
When the Wayland compositor notifies of a new keymap, for the first X11
client using the keyboard, the last slave keyboard used might still not
be set (i.e. “lastSlave” is still NULL).
As a result, the new keymap is not applied, and the first X11 window
will have the wrong keymap set initially.
Apply the new keymap to the master keyboard as long as there's one.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383
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>
(cherry picked from commit 170c959785)
Previously, before GLX_OML_swap_method was fixed, both the X server and
client ignored the swapMethod fbconfig value, which meant that, if the dri
driver thought it exposed more than one swapMethod, it actually just
exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
and restricting the choice for built-in visuals to a single swap method
that meant we didn't have that many fbconfigs to choose from when pairing
the compositing visual with an fbconfig, resulting in the fbconfig paired
with the compositing visual becoming too restrictive for some applications,
(at least for kwin). This problem would also happen if the dri driver
only exposed a single swap method to begin with.
So, to make sure the compositing visual gets a good enough fbconfig,
duplicate fbconfigs that are suitable for compositing visuals and make
sure these duplicated fbconfigs can be used only by compositing visuals.
For duplicated fbconfigs not paired with a compositing visual, construct
new compositing visuals, making compositing clients able to choose visuals
/ fbconfig more adapted to their needs.
This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
GLX visualtype.
Fixes: 4486d199bd ("glx: Fix visual fbconfig matching with respect to
swap method")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Tested-By: Nick Sarnie <commendsarnex@gmail.com>
Tested-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit f84e59a4f4)
For the built in visuals, we'd typically select the "best" fbconfig
without considering the swap method. If the client then requests a
specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the
first fbconfig matching requirements would have been paired with the 32-bit
compositing visual, and the client would render a potentially transparent
window.
Fix this so that we try to match fbconfigs with the same swap method to all
built-in visuals. That would guarantee that selecting a specific swap-
method would not influence the chance of getting a compositing visual.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 4486d199bd)
The swapMethod config member would typically contain an arbitrary value
on older dri drivers. Fix this so that if we detect an illegal value,
return GLX_SWAP_UNDEFINED_OML.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 0fc26310d5)
Should you find yourself using a 16bpp display while also using a
compositor, you poor soul, you may find that your GLX applications
behave strangely; in particular, glxgears will be transparent. This is
because it clears to (0,0,0,0) which is transparent if you honor alpha,
and it will choose the synthetic visual because it has the most
available r/g/b bits.
To avoid this, bump synthetic visuals to a higher (less-preferred)
select group. Unless the client explicitly asks for non-zero alpha bits,
this will prefer any rgb565 visual ahead of the argb8888 visual.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ea483af99a)
We already send this for fbconfigs. Mesa happens to implement
glXChooseVisual relative to the fbconfig data, but that might not be
true of NVIDIA's libGL.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 43efaa6e4f)
As of ea483af9 we're calling this unconditionally from the GLX code so
the synthetic visual is in a lower select group. If Composite has been
disabled then GetCompScreen() will return NULL, and this would crash.
Rather than force the caller to check first, just always return FALSE if
Composite is disabled (which is correct, since none of the visuals will
be synthetic in that case).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
(cherry picked from commit f80119120c)
This comment is above compIsAlternateVisual, which used to be the only
thing determining whether implicit redirect was needed. It's not anymore
due to the redirection exception list. That job is now performed by
compImplicitRedirect, whose code is self-explanitory.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit bccbaf7c11)
Don't reuse cmd for strtok output to ensure the proper pointer is
freed afterwards.
The code incorrectly assumed the pointer returned by strtok(cmd, ":")
would always point to cmd. However, strtok(str, sep) != str if str
begins with sep. This caused an invalid-free crash when running
a program under X with a name beginning with a colon.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=104123
Signed-off-by: Tomasz Śniatowski <kailoran@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 6883ae43eb)
PtrCtrl really makes sense for relative pointing device only, absolute
devices such as touch devices do not have any PtrCtrl set.
In some cases, if the client issues a XGetPointerControl() immediatlely
after a ChangeMasterDeviceClasses() copied the touch device to the VCP,
a NULL pointer dereference will occur leading to a crash of Xwayland.
Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and
return the default control values otherwise, to avoid the NULL pointer
dereference.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 9f7a9be13d)
From the bug: "What happens if bits->width is less than 8? :)"
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit 97ac59b1ed)
Just never filled in, oops. Seems to have gone unnoticed because
normally glXQueryContext simply returns the values filled in by the
client library when the context was created. The only path by which you
normally get to a GLXQueryContext request is glXImportContext, and then
only if the context is already indirect.
However, that's a statement about Mesa's libGL (and anything else that
inherited that bit of the SGI SI more or less intact). Nothing prevents
a mischeivous client from issuing that request of a direct context, and
if they did we'd be in trouble because we never bothered to preserve the
associated fbconfig in the context state, so we'd crash looking up
GLX_VISUAL_ID_EXT. So let's fix that too.
v2: Fixed missing preservation of the config in DRI2 (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 5d667df6ea)
Terminate a dead session when -once was passed. Don't restart it.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Walter Harms <wharms@bfs.de>
(cherry picked from commit 918afeecbc)
We were sending the events to all clients listening for them on the
window. But clients can get confused by events from another client, and
I can't imagine any case where receiving events from other clients would
be required.
v2:
* Also restrict events sent to additional windows to the presenting
client
* Don't shorten line lengths
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 559954aaa8)
Similarly to bb766ef112, ensure that the
extra padding is set to 0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
(cherry picked from commit fb5ee77b91)
If the context is direct none of the GL commands were issued by this
process, the server couldn't flush them even if it wanted to.
v2: Fix embarassingly obvious boolean inversion (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 307c124d6b)
The CEA extension short video descriptors contain the VIC, which starts
at 1, not 0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
(cherry picked from commit 68556d74b4)
The trailing \n are just wrong here, __glXEnableExtension wants a string
without them.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit fd0eafb184)
Running Xephyr under valgrind reveals that we're sending some
uninitialized memory over the wire (particularly, the leftover padding
that comes from rounding extraLen to the next 32-bit multiple).
Solve by calloc()ing the memory instead of malloc()ing (the alternative
would be to memset just the padding, but I'm not sure it's more
convenient.)
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit bb766ef112)
This fixes some “Conditional jump depends on uninitialized value(s)”
errors spotted by valgrind.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
(cherry picked from commit b216701504)
I don't know how many times I've had a broken server due to a bad
directory to xkbcomp, and only finding the whole path has shown me
where I went wrong.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 30f4d440eb)
Historically we didn't need to care about this case but more devices are
having invalid types set and they cannot be unset with a hwdb entry (which
doesn't handle the empty string). Allow for "0" to mean "unset" because
anything else would be crazy anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5aad81445c)
Kevin Brace
Mario Kleiner
Lyude Paul
Alex Goins
Jeff Smith
Olivier Fourdan
Michal Srb
Peter Harris
Michel Dänzer
Martin Wilck
Adam Jackson
Helmut Grohne
Peter Hutterer
Corentin Rossignon
Lukáš Krejčí
Tapani Pälli
Thomas Hellstrom
Tomasz Śniatowski
Daniel Martin
Giuseppe Bilotta
Hector Martin
Eric Anholt