Otherwise xcb will treat our attempt to send xv requests as a connection
error (quite reasonably: we're asking it to emit a request for which
there is no defined major opcode), and we'll die quietly the first time
we hit KdBlockhandler.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. modesetting was blindly asserting
it supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
No driver is using these, as far as I know.
v2: Tripwire the entity hook arguments to xf86Config*Entity, fix
documentation (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Most of this is a legacy of the old "extmod" design where you could load
_some_ extensions dynamically but only if the server had been built with
support for them in the first place.
Note that since we now only initialize the DPMS extension if at least
one screen supports it, we no longer need DPMSCapableFlag: if it would
be false, we would never read its value.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Following on from the previous change, this adds a DPMS hook to the
ScreenRec and uses that to infer DPMS support. As a result we can drop
the dpms stub code from Xext.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Rather than setting up a per-screen private, just conditionally
initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
that to determine whether DPMS is supported.
We also move the "turn the screen back on at CloseScreen" logic into the
DPMS extension's (new) reset hook. This would be a behavior change for
the non-xfree86 servers, if any of them had non-stub DPMS support.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
A null pointer dereference can occur in dmxSync, because TimerForce
does not handle a null pointer.
dmxSyncTimer is set to NULL a few lines above on a certain condition,
which happened on my machine. The explicit NULL check allowed me to
start Xdmx again without a segmentation fault.
Reviewed-by: Adam Jackson <ajax@redhat.com>
The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The X11 window manager (XWM) of a Wayland compositor can use the
_XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends
wl_surface.commit requests. If the property is not set, the behaviour
remains what it was.
XWM uses the property to inhibit commits until the window is ready to be
shown. This gives XWM time to set up the window decorations and internal
state before Xwayland does the first commit. XWM can use this to ensure
the first commit carries fully drawn decorations and the window
management state is correct when the window becomes visible.
Setting the property to zero inhibits further commits, and setting it to
non-zero allows commits. Deleting the property allows commits.
When the property is changed from zero to non-zero, there will be a
commit on next block_handler() call provided that some damage has been
recorded.
Without this patch (i.e. with the old behaviour) Xwayland can and will
commit the surface very soon as the application window has been realized
and drawn into. This races with XWM and may cause visible glitches.
v3:
- introduced a simple setter for xwl_window::allow_commits
- split xwl_window_property_allow_commits() out of
xwl_property_callback()
- check MakeAtom(_XWAYLAND_ALLOW_COMMITS)
v2:
- use PropertyStateCallback instead of XACE, based on the patch
"xwayland: Track per-window support for netwm frame sync" by
Adam Jackson
- check property type is XA_CARDINAL
- drop a useless memcpy()
Weston Bug: https://phabricator.freedesktop.org/T7622
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Fix the following warning due to --disable-glamor:
CC Xwayland-xwayland.o
In file included from /home/pq/local/include/wayland-client.h:40:0,
from xwayland.h:35,
from xwayland.c:26:
xwayland.c: In function ‘block_handler’:
/home/pq/local/include/wayland-client-protocol.h:3446:2: warning: ‘buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
wl_proxy_marshal((struct wl_proxy *) wl_surface,
^
xwayland.c:466:23: note: ‘buffer’ was declared here
struct wl_buffer *buffer;
^
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Refactor xwl_screen_post_damage() and split the window specific code
into a new function xwl_window_post_damage().
This is a pure refactoring, there are no behavioral changes. An assert
is added to xwl_window_post_damage() to ensure frame callbacks are not
leaked if a future patch changes the call.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
First, move them to the end of the struct, for marginally better cache
locality for the struct members that actually have meaning; move the
existing slots at the end of the struct up near some others with similar
meanings. Second, only keep four slots each of integer, data pointer,
and function pointer; we've rarely used this escape hatch so this is
still plenty.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Never set by the core, not used in any modern driver.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Just no.
The ddxDesign chunk removes the whole para about xf86FixPciResource,
since it turns out that function doesn't exist at all anymore.
The only drivers that reference this at all are i128 and mga, and even
then only in the non-pciaccess path.
v2:
- Update commentary about i128/mga
- Don't remove the BiosBase keyword from the config parser since that
would turn a no-op into a fatal error (Aaron Plattner)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Seriously not worth the effort of tracking this, especially now that
competent drivers don't have a limit. The sis driver does inspect this
member, but hilariously does so only so it can print the same information
as the core does.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Only mach64 and rendition actually use this feature. Everyone else just
checks it in their ValidMode hook, they can too.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We don't actually need (or intend) to keep this struct the same across
revisions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Previously, we would swap the width/height of the Xwayland output based
on the output rotation, so that the overall screen size would match the
actual rotation of each output.
Problem is the RandR's ConstrainCursorHarder() handler will also apply
the output rotation, meaning that when the output is rotated, the
pointer will be constrained within the wrong dimension.
Moreover, XRandR assumes the original output width/height are unchanged
when the output is rotated, so by changing the Xwayland output width and
height based on rotation, Xwayland causes XRandr to report the wrong
output sizes (an output of size 1024x768 rotated left or right should
remain 1024x768, not 768x1024).
So to avoid this issue and keep things consistent between Wayland and
Xwayland outputs, leave the actual width/height unchanged but apply the
rotation when computing the screen size. This fixes both the output size
being wrong in "xrandr -q" and the pointer being constrained in the
wrong dimension with rotated with weston.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If the Wayland compositor sets a rotation on the output, Xwayland
translates the transformation as an xrandr rotation for the given
output.
However, if the rotation is not supported by the CRTC, this is not
a valid setup and xrandr queries will fail.
Pretend we support all rotations and reflections so that the
configuration remains a valid xrandr setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
For some applications (like fullscreen games) it matters for XRandr
resolution to be correctly set and equal to root window resolution.
In XServer there is already hack for this, adapted it for XWayland.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574
Signed-off-by: Svitozar Cherepii <razotivs@gmail.com>
Tested-by: Svitozar Cherepii <razotivs@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back. Change this to only
permanently switch to a software cursor if -ENXIO is returned (which means
hardware cursors not supported), and to otherwise still try a hardware
cursor first every time a new one is set. This is needed because hardware
may be able to handle some cursors in hardware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not
others.
Changes since v1, v2 and v3:
* take into account the switch to load_cursor_argb_check
* keep the permanent software cursor fall-back if -ENXIO is returned
* move parts of v3 into separate patches
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Based on v4 by Alexandre Courbot <acourbot@nvidia.com>
There is currently no reliable way to report failure to set a HW
cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
ioctl fails (which currently happens at least with modesetting on Tegra
for format incompatibility reasons).
As failures are currently handled by setting the HW cursor size to
(0,0), the fallback to SW cursor will not happen until the next time the
cursor changes and xf86CursorSetCursor() is called again. In the
meantime, the cursor will be invisible to the user.
This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
_xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
This allows to propagate errors up to xf86CursorSetCursor(), which can
then fall back to using the SW cursor immediately.
v5:
- Removed parts of patch already committed as part of 14c21ea1.
- Adjusted code slightly to match surrounding code.
- Effectively reverted af916477 which is made unnecessary by this patch.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Based on v4 by Alexandre Courbot <acourbot@nvidia.com>
There is currently no reliable way to report failure to set a HW
cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
ioctl fails (which currently happens at least with modesetting on Tegra
for format incompatibility reasons).
As failures are currently handled by setting the HW cursor size to
(0,0), the fallback to SW cursor will not happen until the next time the
cursor changes and xf86CursorSetCursor() is called again. In the
meantime, the cursor will be invisible to the user.
This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
_xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
This allows to propagate errors up to xf86CursorSetCursor(), which can
then fall back to using the SW cursor immediately.
v5: Updated the patch to apply to current git HEAD, split up into two
patches (server and modesetting driver) and adjusted the code slightly
to match surrounding code. I also removed the new exported function
ShowCursorCheck(), as instead just changing ShowCursor() to return Bool
should not affect its current callers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
