The autoconf build for the modesetting driver still relied on
xorg-macros.m4 for string replacements and did not include the
top-level manpages.am. As a result, no substitutions took place after
commit 2e497bf887.
This should be a candidate for the 1.20 branch.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
There's not really a good reason to keep these separate, the vbe code
requires int10 and is not very large. This change eliminates the
build-time options for vbe; if you build int10, you get vbe.
Gitlab: https://gitlab.freedesktop.org/xorg/xserver/issues/692
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
i965 and radeonsi, respectively, are the drivers that have been
receiving new hardware support. It's really silly to need to update the
server side to know specific new devices IDs every time a new ASIC comes
out.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This might be an error or not, for example refusing to work on llvmpipe
is normal and expected. glamor_egl_init() will print X_ERROR messages if
appropriate, so we don't need to here.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This fixes 'non-desktop' displays staying powered on after their lease
has been revoked.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111620
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
In non-rootless mode, not all pixmaps need a wl_buffer backing.
Suggested-by: Twaik Yont (@twaik) in #834
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The compositor may send DRM_FORMAT_MOD_INVALID instead of a list of
modifiers for various reasons. Handle this gracefully by ignoring it.
Without this, if a compositor would send DRM_FORMAT_MOD_INVALID, it'd
result in empty windows provided by Xwayland.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Add an -icon option to set the screen window icon in windowed mode
Allow cygwin paths in an icon-specification
Update man pages and system.XWinrc appropriately
Also, log an error if the icon specified for TRAYICON cannot be loaded
Also, fix a bug in appending a '\' to IconDirectory only if it doesn't
already end with one, which was fortunately benign.
Note: LoadImageComma would be simpler if we just stated that XWinrc
paths are Cygwin paths on Cygwin, Windows paths on MinGW, but that could
break existing .XWinrc files
Note: Given that we can specify paths in an icon-specifier, I'm not sure
what IconDirectory wins us.
v2:
Fix formatting problems in man page additions
v3:
Fix some more s/_/@/g in man pages
This FD also triggers the "wait for WM_S0" paths, so that the
compositor may set up a "maintenance line" for Xwayland, for
services that are essential to run before any client (eg. xrdb).
Those services would use this FD, disguised as an extra display
connection.
This -initfd can be seen as a generalization of -wm, a Wayland
compositor may use -initfd to launch its WM and any other clients
that should start up, or it may use -wm as a dedicated connection for
the WM and optionally use -initfd for the misc. startup clients.
If either of -wm or -initfd is passed, Xwayland will expect a selection
notification on WM_S0 before incorporating the FDs in -listen to the
poll list.
Also, correct a minor typo in the listenfd argument output,
give → given.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
If Xwayland gets to realize a window meant for composition before the
compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
yet), the window would stay "invisible" as we wouldn't create a
wl_surface/wl_shell_surface for it at any later point.
This scenario may happen if the wayland compositor sets up a X11 socket
upfront, but waits to raise Xwayland until there are X11 clients. In this
case the first data on the socket is the client's, the compositor can hardly
beat that in order to redirect subwindows before the client realizes a
Window.
In order to jump across this hurdle, allow the late creation of a matching
(shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
to be created after the compositor set up redirection.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This will be dissociated in future commits to handle the cases
where windows are being realized before there is a compositor
handling redirection.
In that case, we still want the DamagePtr to be registered upfront
on RealizeWindowProc before a corresponding xwl_window might be
created. Most notably, it cannot be lazily created on
SetWindowPixmapProc as damage accounting gets broken.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
This adds support for xdg-output-unstable-v1 version 3, added in [1].
This new version deprecates zxdg_output_v1.done and replaces it with
wl_output.done. If the version is high enough, there's no need to wait for both
an xdg_output.done event and a wl_output.done event -- we only care about
wl_output.done.
[1]: 962dd53537
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
The atomic driver has issues with modesetting when stealing
connectors from a different crtc, a black screen when doing rotation
on a different crtc, and in general is just a mapping of the legacy
helpers to atomic. This is already done in the kernel, so just
fallback to legacy by default until this is fixed.
Please backport to 1.20, as we don't want to enable it for everyone
there. It breaks for existing users.
The fixes to make the xserver more atomic have been pending on the
mailing list for ages.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110375
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110030
References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36/commits
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Old behavior was to translate the middle mouse button, as well as
every other button that isn't the left or right mouse button,
to act as the middle mouse button (2).
New behavior is to translate only the middle mouse button to 2,
and translate higher-numbered buttons to 8 and higher.
This allows additional mouse buttons to behave under XQuartz
more like they do by default under X11 on other platforms
(e.g. Linux and BSD distributions).
Signed-off-by: Christopher Chavez <chrischavez@gmx.us>
Dynamically added outputs should have their properties
properly updated as well. Otherwise we're left with an output
with many of its propeties not exposed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Some modules are required in multiple places in the meson file.
Move the actual requirements to the top of the file as a variable so
that updating a version does not require changing the actual value in
multiple places.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Only log 1 error for consecutive flip failures, instead of filling the
log and the disk with errors for each attempted flip.
Despite our best efforts we may end up with a BO which gets refused
when we try to import it as a framebuffer, see e.g. :
https://bugs.freedesktop.org/show_bug.cgi?id=111306
This should not happen, but as the above bugs shows sometimes it does
and chances are it will happen again.
Note ideally we should check if the import is possible at
ms_present_check_flip time, like the amdgpu code is doing since:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/35
but that requires a chunk of refactoring work on the modesetting driver,
so for now this will have to do.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Before this commit ms_do_pageflip logged a single error for both the
drmmode_bo_import failure path as well as for the queue_flip_on_crtc
path. This commit splits this into 2 separate error logs so that it is
clear what the cause of the flip-failure is.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently on present-flip failures we log 2 messages for each failure,
1 from ms_do_pageflip and then another one from ms_present_flip which
is the caller of ms_do_pageflip. This commit adds a log_prefix argument
to ms_do_pageflip so that its log messages can show if it is a DRI2 or
a Present flip which fails and removes the redundant error message from
ms_present_flip.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a modified version of a patch we've been carry-ing in Fedora and
RHEL for years now. This patch automatically adds secondary GPUs to the
master as output sink / offload source making e.g. the use of
slave-outputs just work, with requiring the user to manually run
"xrandr --setprovideroutputsource" before he can hookup an external
monitor to his hybrid graphics laptop.
There is one problem with this patch, which is why it was not upstreamed
before. What to do when a secondary GPU gets detected really is a policy
decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
as such should be under control of the Desktop Environment.
Unconditionally adding autobinding support to the xserver will result
in races between the DE dealing with the hotplug of a secondary GPU
and the server itself dealing with it.
However we've waited for years for any Desktop Environments to actually
start doing some sort of autoconfiguration of secondary GPUs and there
is still not a single DE dealing with this, so I believe that it is
time to upstream this now.
To avoid potential future problems if any DEs get support for doing
secondary GPU configuration themselves, the new autobind functionality
is made optional. Since no DEs currently support doing this themselves it
is enabled by default. When DEs grow support for doing this themselves
they can disable the servers autobinding through the servers cmdline or a
xorg.conf snippet.
Signed-off-by: Dave Airlie <airlied@gmail.com>
[hdegoede@redhat.com: Make configurable, fix with nvidia, submit upstream]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
---
Changes in v2:
-Make the default enabled instead of installing a xorg.conf
snippet which enables it unconditionally
Changes in v3:
-Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
looking at xf86CrtcConfig->provider. This fixes the autoconfig not
working with the nvidia binary driver
The miPointerSpriteFunc swcursor code expects there to only be a single
framebuffer and when the cursor moves it will undo the damage of the
previous draw, potentially overwriting what ever is there in a new
framebuffer installed after a flip.
This leads to all kind of artifacts, so we need to disable pageflipping
when a swcursor is used.
The code for this has shamelessly been copied from the xf86-video-amdgpu
code.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/828
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fix the following compiler warning:
drmmode_display.c: In function ‘drmmode_create_bo’:
drmmode_display.c:1019:9: warning: ISO C90 forbids mixed declarations and code [
1019 | uint32_t num_modifiers;
| ^~~~~~~~
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When the pixmapPrivateKeyRec was moved from a global to being embedded
inside the drmmode_rec these 2 where missed, clean them up.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The modesetting driver (which now often is used with Intel GPUs),
relies on DRI2ScreenInit() to setup the DRI and VDPAU driver names.
Before this commit it would always assign the same name to the 2 names,
but the VDPAU driver for i965 GPUs should be va_gl.
This commit adds a special case for the i965 case, replacing the
VDPAU driver name with "va_gl" if the GPU is using the i965 driver
for DRI.
Note this commit adds a FIXME comment for a related memory leak, that leak
was already present and fixing it falls outside of the scope of this commit.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1413733
Cc: kwizart@gmail.com
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This script generates a header that has a comment containing the build path for
no real reason. As this source can end up deployed on targets in debug packages
this means there is both potentially sensitive information leakage about the
build environment, and a source of change for reproducible builds.
Stop trying to link to a shared library we no longer build
Fixes: commit c1703cdf3b - "xfree86: Link fb statically"
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Building Xwayland without glamor support would raise a warning at build
time:
xwayland.c: In function ‘xwl_screen_init’:
xwayland.c:980:10: warning: unused variable ‘use_eglstreams’
980 | Bool use_eglstreams = FALSE;
| ^~~~~~~~~~~~~~
When building without glamor support, we cannot have EGL Streams support
either, the two being related. So we do not need to declare the variable
`use_eglstreams` if glamor is not enabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When building Xwayland without glamor support enabled using automake,
the build would fail at link time trying to find `glamor_block_handler`:
/usr/bin/ld: xwayland-glx.o: in function `egl_drawable_wait_x':
hw/xwayland/xwayland-glx.c:102: undefined reference to
`glamor_block_handler'
Make sure we don't try to build `xwayland-glx.c` without glamor in the
Xwayland Makefile.
Note: Meson build is fine because it's already build only with glamor
enabled.
Fixes: commit 8469241 - "xwayland: Add EGL-backed GLX provider"
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Both `gbm_bo_create()` and `gbm_bo_create_with_modifiers()` can fail and
return `NULL`.
If that occurs, `xwl_glamor_gbm_create_pixmap()` will not create a
pixmap for the (NULL) GBM bo, but would still try to free the bo which
leads to a crash in mesa:
[...]
#7 <signal handler called>
#8 in gbm_bo_destroy (bo=0x0) at ../src/gbm/main/gbm.c:439
#9 in xwl_glamor_gbm_create_pixmap () at xwayland-glamor-gbm.c:245
#10 in ProcCreatePixmap () at dispatch.c:1440
#11 in Dispatch () at dispatch.c:478
#12 in dix_main () at main.c:276
To avoid the crash, only free the GBM bo if not `NULL`.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Bugzilla: https://bugzilla.redhat.com/1729925
"bool" conflicts with C++ (meh) and stdbool.h (ngh alright fine). This
is a driver-visible change and will likely break the build for mach64,
but it can be fixed by simply using xf86ReturnOptValBool like every
other driver.
Signed-off-by: Adam Jackson <ajax@redhat.com>
mate-terminal apparently requires these to be present to work
We just set them to describe one desktop, for the moment.
It seems we can safely ignore the _NET_WM_DESKTOP property on child
windows, and any _NET_WM_DESKTOP messages, as we only support one
desktop for windows to be on.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
WM_WM_MAP was removed in 52e05b92
Rename WM_WM_MAP2 as WM_WM_MAP_UNMANAGED (meaning an override-redirect
window, which manages it's own activation)
Rename WM_WM_MAP3 as WM_WM_MAP_MANAGED (meaning a normal window, which
is activated when clicked)
There's not really a good way to query this from the wayland server, so
just set the maximum to the X11 protocol limits. While we're at it,
lower the minimum screen size to something implausibly small too, just
in case.
Fixes: xorg/xserver#850
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
<sys/io.h> on ARM hasn't worked for a long, long time, so it was removed
it from glibc upstream.
Remove the include to avoid a compilation failure on ARM with glibc.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/840
Running Xwayland non-rootless and resizing the output would lead to a
crash while trying to update the larger areas of the root window.
Make sure we resize the backing pixmap according to the new output size
to avoid the crash.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/834
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Don't link against fb, it's the driver's responsibility to load that
first. Underlinking like this is unpleasant but this matches what
autotools does.
Fixes: xorg/xserver#540
Copied from Mesa with no modifications.
This update brings in a significant number of new platform ID's.
Syncs with mesa up to commit e334a595e ("intel/icl: Add new ICL
PCI-IDs").
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Set a linear gamma ramp. This avoids the xrandr command always warning
'Failed to get size of gamma for output default'
(perhaps we should be using GDI GetDeviceGammaRamp(), if possible?)
Make CRTC report non-zero physical dimensions initially
