| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 4d82a150b2ee29c1025408cdb9ece255452a81bd)
|
|
Allow OutputClass config snippets to modify the module-path.
Note that any specified ModulePaths will be pre-pended to the normal
ModulePath. The idea behind this is that any output hardware specific
modules should have preference over the normal modules.
One use-case for this is the nvidia binary driver, this allows a
config snippet like this:
Section "OutputClass"
MatchDriver "nvidia"
Modulepath "/usr/lib64/nvidia/modules"
EndSection
To get the nvidia glx specific glx module loaded, but only when the
nvidia kernel driver is loaded.
Together with the glvnd work done recently, this allows the nouveau
+ mesa and nvidia-binary userspace stacks to co-exist on the same
system without any ldconfig / xorg.conf tweaking and the xserver will
automatically do the right thing depending on which kernel driver
(nouveau or nvidia) is loaded.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit b5dffbbac193aa640ffcfa0a431c21b862854e53)
|
|
Allow using:
Option "PrimaryGPU" "yes"
In an OutputClass section to override the default primary GPU device
selection which selects the GPU used as output by the firmware.
If multiple output devices match an OutputClass section with
the PrimaryGPU option set, the first one enumerated becomes the
primary GPU.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit d75ffcdbf8c1e3c8e0d46debcd533a9f2560f0a8)
|
|
This is a preparation patch for allowing an OutputClass section to
override the default primary GPU device selection.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit ab1a65b7755d081b41188104b21f4d21eaa3187b)
|
|
Add support for setting options in OutputClass Sections and having these
applied to any matching output devices.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 9cd3cc75269d9196898487b5712ee47b8291e077)
|
|
Make OutputClassMatches directly take a xf86_platform_device as argument,
rather then an index into xf86_platform_devices. This makes things
easier for callers which already have a xf86_platform_device pointer.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 08b84d72878e43401e99059c3c926dfa42a360c3)
|
|
xf86MatchDevice returns a dynamically allocated list of GDevPtr-s,
free this when we're done with it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit c57c1e53ea3d76ebba5b2a23b7260817d3e6b921)
|
|
If we did not find any non GPU Screens, try again ignoring the notion
of any video devices being the primary device. This fixes Xorg exiting
with a "no screens found" error when using virtio-vga in a
virtual-machine and when using a device driven by simpledrm.
This is a somewhat ugly solution, but it is the best I can come up with
without major surgery to the bus and probe code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 75c4f6e412e07c5d416fa9ad8d7defd972d2baa9)
|
|
This is primarily a preparation patch for fixing the xserver exiting with
a "no screens found" error even though there are supported video cards,
due to the server not recognizing any card as the primary card.
This also fixes the (mostly theoretical) case of a platformBus capable
driver adding a device as GPUscreen before a driver which only supports
the old PCI probe method gets a chance to claim it as a normal screen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 7121b03d324fccf687d49b63c53da7c8d93038c9)
|
|
If foundScreen is TRUE, then all the code below the removed if
will not execute until we reach the return foundScreen; at the
end, so this entire if block is redundant.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit b72d161cad15bec9dd082d30521c5383be526c56)
|
|
Commit 91c42093b248 ("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: 91c42093b248 ("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 bebcc8477c8070ade9dd4be7299c718baeab3d7a)
|
|
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 98edb9a35e2cdd61355656b82975d7f2b6a9f0e6)
|
|
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 6b26a7bda9efa93440734ede0382a3e9a6761365)
|
|
- 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 ff410c56bfd6dcdf5d252ef0ba3f4c6fde91774b)
|
|
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 3bd17dff1ac5a4685a5da92a9982f621effee658)
|
|
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 5815c7b5951fd46d69e5c40144b64e516c7afdbf)
|
|
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 3e377e238f7257fd01e56a4a25dfd77e033673e4)
|
|
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 3362422e8413dd9f231cfac50ce0a0862525b1bf)
|
|
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 71348e99a8e6a95542e483b93839168ca8f51f81)
|
|
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 d5c23b29487d5ff440abf5ed0beb22c00f21e387)
|
|
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 75408f53d4e203e462b2f13ea4b06264f0e59ad2)
|
|
client"
This reverts commit 5c00e693631475679c1c2504e03177652ec7de28.
It broke the Gallium nine state tracker, which makes PresentPixmap
requests on one display connection and processes the corresponding
events on another one.
The issue that motivated this change is prevented on the client side by
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7b0e8264dd21ae05521d08d41fecd84139401fef
Bugzilla: https://bugs.freedesktop.org/104678
(cherry picked from commit 76732f498f1e73fb081841a04faf068660f3d5c7)
|
|
Improve the user experience for users with wide screens by adding standard
16:9 and 16:10 modes to extramodes, as suggested previously
(https://lists.x.org/archives/xorg-devel/2016-February/048866.html).
Tested successfully on my laptop. Feedback welcome.
See also https://bugs.freedesktop.org/show_bug.cgi?id=37858.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit a5e9bcad7ad0887f804905b482894b85751519fb)
|
|
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 652913cd9474946bcb29271602bacfd98f46ad0b)
|
|
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 c601c8faf54ff9e3bcbc653421828d71042deef7)
|
|
Erroneous condition caused us to keep going with all devices that didn't have
ID_INPUT set.
Fixes: 5aad81445c8c3d6
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 a309323328d9d6e0bf5d9ea1d75920e53b9beef3)
|
|
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 dbfbe58b94ec07a45fd6170f96bffec55051724e)
|
|
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 de60245e05c0d2528d4ff42557a044387e53315c)
|
|
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 094a63d56fbfb9e23210cc9ac538fb198af37cee)
|
|
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 cc3241a712684f8c7147f5688e9ee3ecb5a93b87)
|
|
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 3abbdb7318018584a27220737bd92081ce8ee67c)
|
|
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 f615cb62d47cb24ea31718e8226df53ce6651c91)
|
|
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 170c95978530f6373bdf4488116902b273f3abf4)
|
|
This fixes blending issues seen with kwin and gnome-shell when
32bit visual has sRGB capability set.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103699
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103646
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103655
(cherry picked from commit c2954b16c8730c7ed8441fd8dba25900f3aed265)
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
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: 4486d199bd3b ("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 f84e59a4f474d22860bac8aec2947798a86db69b)
|
|
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 4486d199bd3bcb5b2b8ad9bc54eb11604d9bd653)
|
|
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 0fc26310d5b09213c65f50bde444a1758172b016)
|
|
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 ea483af99a6351323afe00a0b630cd63310efdb1)
|
|
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 43efaa6e4fd903229dc9c508da4177ad4bbdd4d8)
|
|
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 f80119120c487581ac050ce741808f7c8f438f35)
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ef2345aaa28461a76f77c65240ce5facc180f98e)
|
|
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 bccbaf7c113b1300071601879002682ebbe8b1c1)
|
|
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 6883ae43eb72fe4e2651c1dca209563323fad2db)
|
|
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 9f7a9be13d6449c00c86d3035374f4f543654b3f)
|
|
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 97ac59b1ed3624f7c04e54dd3e3dadfa46a8f170)
|
|
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 5d667df6ea1634191a26f9a7c26bc883701d62b0)
|
|
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 918afeecbc63d70413e222efdb2ac4cfb16eae9e)
|
|
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 559954aaa8d811a22cf918cc16a7d618e12201a0)
|
|
Similarly to bb766ef11227bd8c71ac65845d1930edd0eda40d, 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 fb5ee77b91a93e27801006be8ee34d27984e7fa6)
|
