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>
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>
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>
"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>
<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
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>
Promote the generated file containing the date & time build was
configured to top-level.
Rename it from xf86Build.h to buildDateTIme.h.
Use it as well in XQuartz, stringize BUILD_DATE when needed.
If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
macro evaluating to -1 by systemd-logind.h, leaving paused
uninitialized.
../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’:
../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition]
Drivers may need to loop over the allocated screens during PreInit, for example
to consolidate xorg.conf options that apply to a GPU device as a whole.
Currently, this works for protocol screens becuase x86Screens is exported, but
does not work for GPU screens.
Export xf86GPUScreens and xf86NumGPUScreens for consistency with xf86Screens and
xf86NumScreens.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
If the user sets Option "Enable" "TRUE" for a monitor, the X
server will connect the connector a crtc but tell the user it
is disconnected.
However the user in this case is mutter, when it gets it's view
of the output configuration it sees the output is disconnected
and never sets it up again, which seems like the right thing to do.
If we let the user enable a monitor, lets just set it as always
connected.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
systemd-logind since version 234 (released 2017-07-12) supports being
restarted without losing state [1]. From the systemd NEWS file [2]:
* systemd-logind may now be restarted without losing state. It stores
the file descriptors for devices it manages in the system manager
using the FDSTORE= mechanism. Please note that further changes in
other components may be required to make use of this (for example
Xorg has code to listen for stops of systemd-logind and terminate
itself when logind is stopped or restarted, in order to avoid using
stale file descriptors for graphical devices, which is now
counterproductive and must be reverted in order for restarts of
systemd-logind to be safe. See
https://cgit.freedesktop.org/xorg/xserver/commit/?id=dc48bd653c7e101.)
This reverts commit dc48bd653c.
Closes: #531
[1] https://github.com/systemd/systemd/pull/5600
[2] 9f09a95a7e
Normally, the X server infers the initial screen size based on any
connected outputs. However, if no outputs are connected, the X server
picks a default screen size of 1024 x 768. This option overrides the
default screen size to use when no outputs are connected. In contrast
to the "Virtual" Display SubSection entry, which applies unconditionally,
"NoOutputInitialSize" is only used if no outputs are detected when the
X server starts.
Parse this option in the new exported helper function
xf86AssignNoOutputInitialSize(), so that other XFree86 loadable drivers
can use it, even if they don't use xf86InitialConfiguration().
Signed-off-by: Andy Ritger <aritger@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Since the Solaris kernel tracks IOPL per thread, and doesn't inherit
raised IOPL levels when creating a new thread, we need to turn it on
in the input thread for input drivers like vmmouse that need register
access to work correctly.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Keeping track of kernel state in user space doesn't buy us anything,
and introduces bugs, as we were keeping global state but the Solaris
kernel tracks IOPL per thread.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The VGA arbiter controls the PCI bus' routing of legacy VGA resources,
specifically the video memory aperture at 0xa0000-0xb0000 (640k should
be etc.) and a handful of I/O ports. Since 128k is far too small for a
real framebuffer these days, every driver instead maps a linear version
of VRAM through the PCI BAR. And no DRI2 drivers ever need I/O port
access, because all operations they might be used for (legacy VGA CRTC
setup, mostly) happen on the kernel side.
In other words, this just works, and we can stop breaking it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
A user of Adélie Linux reported that modesetting wasn't working properly on
their Intel i7-9700K-integrated UHD 630 GPU. Xorg.0.log showed:
[ 131.902] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x3e98
[ 131.902] (EE) modeset(0): Failed to initialize the DRI2 extension.
Indeed, that PCI ID is missing from i965_pci_ids. Adding it fixed the issue
and allowed the system to work with i965_dri under modesetting.
All of the null checks here are redundant, you can't get to those paths
unless RANDR's already been initialized. Delete them, and remove the
pointer too.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the driver calls xf86HandleColormaps, CMapChangeGamma updates the HW
gamma LUT of all CRTCs via xf86RandR12LoadPalette. However,
xf86RandR12ChangeGamma was then clobbering the gamma LUT of the RandR
1.2 compatibility output's CRTC with the gamma curves computed from the
screen's global gamma values.
Fix this by bailing if xf86RandR12LoadPalette is installed.
Fixes: 02ff0a5d7e "xf86RandR12: Fix XF86VidModeSetGamma triggering a
BadImplementation error"
Noticed when porting this logic to xf86-video-nouveau, and valgrind
complained about conditional jump based on uninitialized data.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Gitlab very kindly exposes the details of the git commit message (among
much else) in the environment. Unfortunately, piglit tries to handle the
environment in non-UTF8-safe ways, which means if the top-of-tree commit
mentions non-ASCII characters (say, in the author's name) then all the
tests fail and so does the pipeline.
Fortunately none of those variables are things our piglit invocation
needs. Since I've failed to rebuild the docker image as yet, just clear
the likely variables from the environment before running piglit.
This-makes-me: ☹
Believe it or not, somehow we've never done this in legacy mode! We
currently simply change the DPMS property on the CRTC's output's
respective DRM connector, but this means that we're just setting the
CRTC as inactive-not disabled. From the perspective of the kernel, this
means that any shared resources used by the CRTC are still in use.
This can cause problems for drivers that are not yet fully atomic,
despite using the atomic helpers internally. For instance: if CRTC-1 and
CRTC-2 are still enabled and use shared resources within the kernel (an
MST topology, for example), and then userspace tries to go enable CRTC-3
on the same topology this might suddenly fail if CRTC-3 needs the shared
resources CRTC-1 and CRTC-2 are using. While I don't know of any
situations in the mainline kernel that actually trigger this, future
plans for reworking the atomic check of MST drivers are absolutely
going to make this into a real issue (they already are in my WIP
branches for the kernel).
So: actually do the right thing here and disable CRTCs when they're not
going to be used anymore, even in legacy mode.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Some Broadcom set-top-box boards have PCI busses, but the GPU is still
probed through DT. We would dereference a null busid here in that
case.
Signed-off-by: Eric Anholt <eric@anholt.net>
Lifted from vfb. xfree86 had almost the same thing but unparameterized,
port it to the vfb style.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Could cause privilege elevation and/or arbitrary files overwrite, when
the X server is running with elevated privileges (ie when Xorg is
installed with the setuid bit set and started by a non-root user).
CVE-2018-14665
Issue reported by Narendra Shinde and Red Hat.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
At the point where xf86BusProbe runs we haven't yet taken our own VT,
which means we can't perform drm "master" operations on the device. This
is tragic, because we need master to fish the bus id string out of the
kernel, which we can only do after drmSetInterfaceVersion, which for
some reason stores that string on the device not the file handle and
thus needs master access.
Fortunately we know the format of the busid string, and it happens to
almost be the same as the ID_PATH variable from udev. Use that instead
and stop calling drmSetInterfaceVersion.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the X server is terminated while its VT is not active, it should
not change the current VT.
v2: Query current state in xf86CloseConsole using VT_GETSTATE instead of
keeping track in xf86VTEnter/xf86VTLeave/etc.
This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
These are so close to identical that most DDXes implement one in terms
of the other. All the relevant cases can be distinguished by the error
code, so merge the functions together to make things simpler.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
No supported driver supports 1bpp anymore, nor has in a very long time.
This option only worked with vgahw anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>
60ec8ead broke the autotools build:
sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
collect2: error: ld returned 1 exit status
Makefile:811: recipe for target 'Xorg' failed
Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>
If it's really this important we should just do it and not complain. We
never do it so it must not matter.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I'm sure printing the address of function pointers in modules you'd
loaded might have made sense back when we rolled our own dlopen, but we
got better.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The old code would not in fact validate the option value, though it
might complain about it in the log. It also didn't let you set some
legal values that the -maxclients command line option would.
Signed-off-by: Adam Jackson <ajax@redhat.com>
DGAShutdown() walks every screen and attempts to reset the mode. That's
maybe a reasonable thing to do, although the explicit loop is certainly
a bad smell.
In ddxGiveUp it's called after we've torn down the vga arbiter - and in
fact most of the rest of screen state - which is... very very bad. The
other place it's called is from the Control-Alt-BackSpace handler, where
we don't even attempt to do vga arb setup, and where in any case we're
going to escape the main loop eventually anyway.
Move all that cleanup work inside DGACloseScreen. This means it happens
earlier in server teardown than previously, but not in a way you're ever
going to be upset about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The X will be crashed on the system with other DDX driver,
such as amdgpu.
show the log like:
randr: falling back to unsynchronized pixmap sharing
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
(EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
(EE)
(EE) Segmentation fault at address 0x0
(EE)
The issue is that modesetting as the master, and amdgpu as the slave.
Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(),
problems result due to the fact that it's accessing AMD's 'ppriv' using the
modesetting structure definition.
Apart from fixing crash issue, the patch fix other issue in master interface
in which driver should refer to master pixmap.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
This makes us match the featureset of autotools, and also fixes the
non-Linux default value to match.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
I don't have a BSD to test on, but this should do the same as what
autotools did.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have pm_noop.c being built most of the time for the
no-OS-PM case, so just switch to always using it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of having every video driver loop over any pending leases to
free them during CloseScreen, do this up in the DIX layer by
terminating leases when a leased CRTC or Output is destroyed and
(just to make sure), also terminating leases in RRCloseScreen. The
latter should "never" get invoked as any lease should be associated
with a resource which was destroyed.
This is required as by the time the driver's CloseScreen function is
invoked, we've already freed all of the DIX randr structures and no
longer have any way to reference the leases
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
Cc: Thomas Hellstrom <thellstrom@vmware.com>
The recent rewrite of modesetting driver broke the 24bpp support.
As typically found on cirrus KMS, it leads to a blank screen, spewing
the error like:
failed to add fb -22
(EE) modeset(0): failed to set mode: Invalid argument
The culript is that the wrong bpp value of the front buffer is passed
to drmModeAddFB(). Fix it by replacing with the back buffer bpp,
drmmode->kbpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When setting DefaultDepth to 16 in the Screen section, the current
code requests a 32 bpp framebuffer, however the X-Server seems to
assumes 16 bpp.
Fixes commit 21217d0216 ("modesetting: Implement 32->24 bpp
conversion in shadow update")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
If we're using atomic modesetting, then we're also using universal
planes, and so the lease we create needs to include the plane.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We don't want universal_planes unless we're using atomic APIs for
modesetting, and the kernel already enables universal_planes
automatically when atomic is enabled.
If we enable universal_planes when we're not using atomic, then we
won't have selected a plane for each crtc, and this will break lease
creation which requires planes for each output when universal_planes
is enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The DIX crtc and output structures are freed when their resources are
destroyed, which happens before CloseScreen is called. As a result, we
know these pointers are invalid and referencing them during any of the
remaining CloseScreen sequence will be bad.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: thellstrom@vmware.com
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
This lets an application open a suitable DRM device and pass the file
descriptor to the mode setting driver through an X server command line
option, '-masterfd'.
There's a companion application, xlease, which creates a DRM master by
leasing an output from another X server. That is available at
git clone git://people.freedesktop.org/~keithp/xlease
v2:
Always print usage, but note that it can't be used if
setuid/gid
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
So, this did actually work on older kernels at one point in time,
however it seems that this working was a result of some of the Linux
kernel's atomic modesetting helpers not preserving the CRTC's enabled
state in the right spots. This was fixed in:
846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2")
As a result, atomic commits which simply disassociate a DRM connector
with it's CRTC while leaving the CRTC in an enabled state aren't enough
to disable the CRTC, and result in the atomic commit failing. This
currently can cause issues with MST hotplugging where X will end up
failing to disable the MST outputs after they've left the system. A
simple reproducer:
- Start up Xorg
- Connect an MST hub with displays connected to it
- Remove the hub
- Now there should be CRTCs stuck on the orphaned MST connectors, and X
won't be able to reclaim them.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
the format is not as expected, preventing from using a rotated output.
Change it to use the new function drmmode_bo_import() which takes care
of calling the drmModeAddFB2() API.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Tomas Pelka <tpelka@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Change the 'chown' statement in Makefile.am to use the numeric UID
of superuser instead of relying on the name 'root'.
Bugzilla: https://bugs.freedesktop.org/27726
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michał Górny <gentoo@mgorny.alt.pl>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In commit 9db2af6f75 (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.
Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
We don't want DRM file descriptors to leak to child processes.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
It was passing O_CLOEXEC as permission bits instead of as a flag.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Fixes using GL with the modesetting driver for me.
Seems we were way behind on this one, time to look into something
more scalable?
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Modifiers support needs gbm as a dependency. Without setting the dependency
included headers are not found reliably and the build might fail if the
headers are not placed in the default system include paths.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Maarten Lankhorst
Ville Syrjälä
Adam Jackson
Hans de Goede
Dave Airlie
Ross Burton
Alan Coopersmith
Olivier Fourdan
Matt Roper
brian
Jon Turney
Adam Richter
Aaron Plattner
Michael Biebl
Andy Ritger
A. Wilcox
Michel Dänzer
Maya Rashish
Ilia Mirkin
Lyude Paul
Eric Anholt
Matthieu Herrb
rpm-build
Michal Srb
Peter Hutterer
Julien Isorce
Jim Qu
Keith Packard
Takashi Iwai
Stefan Agner
Michał Górny
Matt Turner
Bas Nieuwenhuizen
Roman Gilg