Not called by anybody and been just a dummy for quite a while,
so no need to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The list of the associated provider's capabilities was always swapped
unconditionally, while it should only be in case of client having
opposite endianess.
Fixes: 426bc0a28e
Reported-By: dasha_uwu
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1977>
Mixed up reply vs request. Obviously, the size substracted from reply
struct's one has to be the one of the generic reply, not generic requst :o
Background: the meaning of the length field isn't entirely intuitive.
a) the size is in 4-byte units, instead of bytes (therefore passing through
bytes_to_int32() call)
b) it's not the total packet size, but only the *extra* payload size, ergo:
how much is the packet longer than a xGenericReply = 8 units = 32 bytes.
(min. packet size is 32 bytes -> length = 0)
In order to prevent those kind of coding errors ever happening again, it might
be a good idea putting that into a generic macro.
Fixes: c6f1b8a735
Fixes: 0ca5aaba50
Issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1845>
The whole struct is already allocated by calloc(), so no need to explicitly
zero-out individual fields.
Fixes: 479b2be4ba - Clear allocated RandR screen private structure
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Harmonize it with all the other reply struct fields, so we can later
use generic macros for final preparation and writeout.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
We can rely on everything being cleared. And usually even faster, as the
compiler can emit optimized instructions for clearing a whole block at once.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
We can rely on everything being cleared. And usually even faster, as the
compiler can emit optimized instructions for clearing a whole block at once.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Instead of arbitrary count of individual WriteToClient() calls on small
chunks, collect the whole payload in a buffer and write it out all at once.
This also makes possible to use generic macros for reply sending, as well
as further simplifications in the write-out path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
WriteSwappedDataToClient() calls a callback on each single field.
We can have it easier and more efficient by just using SwapLongs()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Using struct initializer for the reply header and only allocating the
payload on heap. This allows using generic macros for reply preparation
and send-out later.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
Improve readability, move the declarations to where they're needed first
and get rid of extra individual assignments. In some cases this should also
allow the compiler to produce a bit more efficient code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
No need to go indirectly through a vector table, since everything's fixed
anyways. It's not a pretty robust programming style: any changes need great
care, in order to not mix up things.
Replacing this by direct switch/case statement, which is using the defines
from the xrandr protocol headers. Also adding a little bit more protection
against subtle programming errors and reducing cognitive load (source size)
on understanding the code by using a tiny macro for deducing define name and
function name from the request's name.
This approach actually uncovered some subtle bug that had been waiting in
the dark for over 15 years.
As collateral benefit, getting a tiny bit better performance.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
No need to go indirectly through a vector table, since everything's fixed
anyways. It's not a pretty robust programming style: any changes need great
care, in order to not mix up things.
Replacing this by direct switch/case statement, which is using the defines
from the xrandr protocol headers. Also adding a little bit more protection
against subtle programming errors and reducing cognitive load (source size)
on understanding the code by using a tiny macro for deducing define name and
function name from the request's name.
This approach actually uncovered some subtle bug that had been waiting in the
dark for over 15 years (see commit b87314c876)
As collateral benefit, getting a tiny bit better performance.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
No need to go indirectly through an vector table. It's much clearer and
easier to understand when calling them directly. And a tiny bit performance
improvement as collateral benefit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1794>
The OS abstraction isn't really the right place for those flags,
they are're probably better off in their corresponding extensions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1519>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
PANORAMIX was the original working title of the extension, before it became
official standard. Just nobody cared about fixing the symbols to the official
naming.
For backwards compatibility with drivers, the old PANORAMIX symbol will
still be set.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1258>
ProcRRGetScreenResources() vs. RRGetScreenResourcesCurrent() have different
semantics - this also must be followed in byte-swapped case.
Fixes: fc70839431 - Add server support for RRGetScreenResourcesCurrent
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1630>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Over 1.5 decades ago, pixmap handling was moved to using pixman library,
but there's still a bit fallout from that left. Cleaning it up now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
In commit 7e1f86d4 monitor support was added to randr. At this time it seemed to be reasonable not to have
more than one (virtual) monitor on a particular physical display. The code was never changed since.
Nowadays, extremely large displays exists (4k displays, ultra-wide displays). In some use cases it makes sense to
split these large physical displays into multiple virtual monitors. An example are ultra-wide screens that can be
split into 2 monitors. The change in this commit makes this work.
Besides that, removing a monitor in a function that is called "RRMonitorAdd" is bad practice and causes
unexpected behaviour.
When calling RRSetMonitor, an existing monitor name is allowed.
"If 'name' matches an existing Monitor on the screen, the existing one
will be deleted as if RRDeleteMonitor were called."
https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
It looks like the check was added by mistake, because in the next 'for'
the monitor is deleted if it is in this list.
Steps to reproduce:
Try RRSetMonitor with existing monitor name and other valid params
OBSERVED RESULT:
RRSetMonitors returns BadValue
EXPECTED RESULT:
RRSetMonitors returns OK
Amend: 7e1f86d42b
Signed-off-by: Ilya Pominov <ipominov@astralinux.ru>
Affected are ProcRRChangeProviderProperty and ProcRRChangeOutputProperty.
See also xserver@8f454b79 where this same bug was fixed for the core
protocol and XI.
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->nUnits value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->num_items bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->nUnits bytes, i.e. 4GB.
CVE-2023-6478, ZDI-CAN-22561
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The handling of appending/prepending properties was incorrect, with at
least two bugs: the property length was set to the length of the new
part only, i.e. appending or prepending N elements to a property with P
existing elements always resulted in the property having N elements
instead of N + P.
Second, when pre-pending a value to a property, the offset for the old
values was incorrect, leaving the new property with potentially
uninitalized values and/or resulting in OOB memory writes.
For example, prepending a 3 element value to a 5 element property would
result in this 8 value array:
[N, N, N, ?, ?, P, P, P ] P, P
^OOB write
The XI2 code is a copy/paste of the RandR code, so the bug exists in
both.
CVE-2023-5367, ZDI-CAN-22153
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo
reply. One use case is to allow Xwayland to return the current emulated
mode for the specific client instead of the global mode.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
When RANDR is emulated as with Xwayland, the actual output configuration
does not change as RANDR is emulated using viewports.
As a result, changes to the CRTC may be skipped, resulting in the
configuration being (wrongly) assumed to be unchanged.
Add a new output property "RANDR Emulation" that the DDX can set to
force RRCrtcSet() to reconfigure the CRTC regardless of the change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The function rrGetPixmapSharingSyncProp() will check for the PRIME sync
property "PRIME Synchronization" on each output and return false if
any of the output has this property set to false.
To do so, it will call RRGetOutputProperty() twice for each output, once
with pending true and once with pending false to cover both
possibilities.
However, reading the implementation of RRGetOutputProperty(), it appears
that if the property is not pending, the code will return the current
value even if invoked with pending true.
So the second call to RRGetOutputProperty() with pending false seems
superfluous.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: df8e86931e - randr: Add ability to turn PRIME sync off
Reviewed-by: Alex Goins <agoins@nvidia.com>
Tested-by: Alex Goins <agoins@nvidia.com>
Add a new interface to _rrScrPriv to make it possible for the server to
delay answering a lease request, at the cost of blocking the client. This
is needed for implementing drm-lease-v1, as the Wayland protocol has no
defined time table for responding to lease requests.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Due to a switched order of parameters in the xorg_list_add()
call inside ProcRRCreateLease(), adding a new lease for RandR
output leasing does not actually add the new RRLeasePtr lease
record to the list of existing leases for a X-Screen, but instead
replaces the existing list with a new list that has the new lease
as the only element, and probably leaks a bit of memory.
Therefore the server "forgets" all active leases for a screen,
except for the last added lease. If multiple leases are created
in a session, then destruction of all leases but the last one
will fail in many cases, e.g., during server shutdown in
RRCloseScreen(), or resource destruction, e.g., in
RRCrtcDestroyResource().
Most importantly, it fails if a client simply close(fd)'es the
DRM master descriptor to release a lease, quits, gets killed or
crashes. In this case the kernel will destroy the lease and shut
down the display output, then send a lease event via udev to the
ddx, which e.g., in the modesetting-ddx will trigger a call to
drmmode_validate_leases().
That function is supposed to detect the released lease and tell
the server to terminate the lease on the server side as well,
via xf86CrtcLeaseTerminated(), but this doesn't happen for all
the leases the server has forgotten. The end result is a dead
video output, as the server won't reinitialize the crtc's
corresponding to the terminated but forgotten lease.
This bug was observed when using the amdvlk AMD OSS Vulkan
driver and trying to lease multiple VKDisplay's, and also
under Mesa radv, as both Mesa Vulkan/WSI/Display and amdvlk
terminate leases by simply close()ing the lease fd, not by
sending explicit RandR protocol requests to free leases.
Leasing worked, but ending a session with multiple active
leases ended in a lot of unpleasant darkness.
Fixing the wrong argument order to xorg_list_add() fixes the
problem. Tested on single-X-Screen and dual-X-Screen setups,
with one, two or three active leases.
Please merge this for the upcoming server 21.1 branch.
Merging into server 1.20 would also make a lot of sense.
Fixes: e4e3447603
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Keith Packard <keithp@keithp.com>
Since crtc can belong to secondary output that may not have present
extension enabled we should fallback to first enabled crtc or fake crtc.
Fix for issue xorg/xserver#1195
This can happen if RRTellChanged is called during initialization.
Continuing in that case makes no sense conceptually:
* Any event sent over the wire requires a corresponding window.
* No root window probably means there can't be any clients which could
receive the events.
In practice, it would result in a crash down the road due to
dereferencing the NULL ScreenRec::root pointer.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Instead of getting the current msc value from the window crtc,
which not exist take the last saved msc value saved in
the window_priv struct
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
RRHasScanoutPixmap() is called from xf86CheckHWCursor(), regardless of whether
or not RandR has been initialized.
As mentioned in commit 4226c6d, it's possible that RandR has not been
initialized if the server is configured with Xinerama and there is more than one
X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:
Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
key->initialized' failed.
Just as in commit 4226c6d, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>
RRProviderAutoConfigGpuScreen() is called from outside RandR, so there is no
guarantee that RandR has been initialized when it is called.
As mentioned in commit 4226c6d, it's possible that RandR has not been
initialized if the server is configured with Xinerama and there is more than one
X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:
Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
key->initialized' failed.
Just as in commit 4226c6d, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>
When a GPU is auto-bound adding more outputs to a screen, that needs to count
as a configuration change on that screen so that a WM listening for
RRScreenChangeNotify gets notified and handles it as a hotplug. This is
particularly for cases where the outputs are already connected. Otherwise
nothing might happen.
Issue #909 describes a real world case where plugging in a DisplayLink dock
with a monitor already connected is sometimes left inactive by GNOME. That
issue is a race, and requires adding a sleep(5); as the first thing in
NewGPUDeviceRequest() to reproduce reliably. With the sleep, the monitor in the
dock will never activate automatically. Add this fix over the sleep, and the
issue is gone.
This fix was originally developed on a branch replicating Ubuntu 19.04 patch
set based on xserver 1.20.4. Testing on master branch was impossible due to
xorg/xserver#910.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/909
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
During server teardown, mrootdraw is NULL, which can cause segfaults if
master->Stop{,Flipping}PixmapTracking() don't do NULL checking. In this case we
shouldn't need to do master->Stop{,Flipping}PixmapTracking() anyway, so just
skip it.
Signed-off-by: Alex Goins <agoins@nvidia.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 purpose of rrCheckPixmapBounding() is to make sure that the fb is large
enough to accommodate the region scanned out by a GPU screen. Currently, however,
it will actually shrink the fb if it's larger than it needs to be.
This is a problem when combining PRIME output slaving with arbitrary transforms
with xrandr.
Although arbitrary transforms are not supposed to constrain the size of the fb
(https://lists.freedesktop.org/archives/xorg-devel/2018-January/055563.html),
xrandr will use RRSetScreenSize to resize the desktop to accommodate scaling
transforms, e.g. scaling a 1920x1080 display to 3840x2160 will result in a
desktop size of 3840x2160.
In the case of PRIME, rrCheckPixmapBounding() will be called after
RRSetScreenSize() and it will resize the fb back down to what it would be
without the scaling transform, e.g. 1920x1080. This represents divergence in
behavior between PRIME and non-PRIME outputs.
I had originally made rrCheckPixmapBounding() account for arbitrary transforms,
but realized that the fb being large enough to accommodate arbitrary transforms
is not a hard requirement enforced in the server. Instead, this change simply
makes it so that rrCheckPixmapBounding() will only resize the fb to be larger
than it already is, preventing it from stepping on prior requests to increase
the size of the fb.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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>
commit 56c90e29f0 [1.10.99.901]
Author: Adam Jackson <ajax@redhat.com>
Date: Mon Nov 15 14:29:14 2010 -0500
randr: Add RRConstrainCursorHarder
introduced a regression as it ignored the effect of panning and
transforms upon the crtc bounds. The result was that the cursor would be
constrained to the visible area even though the panning arena was much
bigger, or the cursor was constrained to a region that did not even
match the visible area when the output was transformed or reflected.
This supercedes the hack introduced by
commit 1bf81af4a6 [1.12.99.904]
Author: Rui Matos <tiagomatos@gmail.com>
Date: Mon Jul 30 14:32:12 2012 -0400
xf86RandR12: Don't call ConstrainCursorHarder() if panning is enabled
which disabled the cursor constraints if a panning mode was active, but
did not fix the regression with arbitrary output transforms.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39949
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: Rui Matos <tiagomatos@gmail.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Flagged by valgrind:
==13695== Conditional jump or move depends on uninitialised value(s)
==13695== at 0x22461C: RRNoticePropertyChange (rrproperty.c:150)
==13695== by 0x22461C: RRChangeOutputProperty (rrproperty.c:263)
==13695== by 0x222FC4: RROutputSetNonDesktop (rroutput.c:333)
==13695== by 0x22319C: RROutputCreate (rroutput.c:122)
==13695== by 0x1E1CE9: xf86RandR12CreateObjects12 (xf86RandR12.c:1734)
==13695== by 0x1E1CE9: xf86RandR12Init12 (xf86RandR12.c:2375)
==13695== by 0x1E1CE9: xf86RandR12Init (xf86RandR12.c:895)
==13695== by 0x1D469B: xf86CrtcScreenInit (xf86Crtc.c:778)
==13695== by 0xC095A54: RADEONScreenInit_KMS (radeon_kms.c:2436)
==13695== by 0x161444: AddGPUScreen (dispatch.c:3966)
==13695== by 0x1A3E46: InitOutput (xf86Init.c:763)
==13695== by 0x1654A7: dix_main (main.c:193)
==13695== by 0x7041A86: (below main) (libc-start.c:310)
==13695== Uninitialised value was created by a heap allocation
==13695== at 0x4C2CB8F: malloc (vg_replace_malloc.c:299)
==13695== by 0x223083: RROutputCreate (rroutput.c:83)
==13695== by 0x1E1CE9: xf86RandR12CreateObjects12 (xf86RandR12.c:1734)
==13695== by 0x1E1CE9: xf86RandR12Init12 (xf86RandR12.c:2375)
==13695== by 0x1E1CE9: xf86RandR12Init (xf86RandR12.c:895)
==13695== by 0x1D469B: xf86CrtcScreenInit (xf86Crtc.c:778)
==13695== by 0xC095A54: RADEONScreenInit_KMS (radeon_kms.c:2436)
==13695== by 0x161444: AddGPUScreen (dispatch.c:3966)
==13695== by 0x1A3E46: InitOutput (xf86Init.c:763)
==13695== by 0x1654A7: dix_main (main.c:193)
==13695== by 0x7041A86: (below main) (libc-start.c:310)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
RRSetChanged (immediately above) was immune to screens with no master,
but RRTellChanged was not:
Thread 1 "X" received signal SIGSEGV, Segmentation fault.
RRTellChanged (pScreen=<optimized out>) at ../../randr/randr.c:576
576 mastersp = rrGetScrPriv(master);
(gdb) bt
#0 RRTellChanged (pScreen=<optimized out>) at ../../randr/randr.c:576
#1 0x000055555566f1e9 in RRNoticePropertyChange (value=0x555555bfbf28, property=70, output=0x555555bfef10) at ../../randr/rrproperty.c:153
#2 RRChangeOutputProperty (output=output@entry=0x555555bfef10, property=<optimized out>, type=type@entry=19, format=format@entry=32, mode=<optimized out>, mode@entry=0, len=len@entry=1, value=0x7fffffffe77c, sendevent=1, pending=0)
at ../../randr/rrproperty.c:263
#3 0x000055555566dba5 in RROutputSetNonDesktop (output=output@entry=0x555555bfef10, nonDesktop=nonDesktop@entry=0) at ../../randr/rroutput.c:333
...
Reported-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This adds support for RandR CRTC/Output leases through the modesetting
driver, creating a lease using new kernel infrastructure and returning
that to a client through an fd which will have access to only those
resources.
v2: Restore CRTC mode when leases terminate
When a lease terminates for a crtc we have saved data for, go
ahead and restore the saved mode.
v3: Report RR_Rotate_0 rotations for leased crtcs.
Ignore leased CRTCs when selecting screen size.
Stop leasing encoders, the kernel doesn't do that anymore.
Turn off crtc->enabled while leased so that modesetting
ignores them.
Check lease status before calling any driver mode functions
When starting a lease, mark leased CRTCs as disabled and hide
their cursors. Also, check to see if there are other
non-leased CRTCs which are driving leased Outputs and mark
them as disabled as well. Sometimes an application will lease
an idle crtc instead of the one already associated with the
leased output.
When terminating a lease, reset any CRTCs which are driving
outputs that are no longer leased so that they start working
again.
This required splitting the DIX level lease termination code
into two pieces, one to remove the lease from the system
(RRLeaseTerminated) and a new function that frees the lease
data structure (RRLeaseFree).
v4: Report RR_Rotate_0 rotation for leased crtcs.
v5: Terminate all leases on server reset.
Leases hang around after the associated client exits so that
the client doesn't need to occupy an X server client slot and
consume a file descriptor once it has gotten the output
resources necessary.
Any leases still hanging around when the X server resets or
shuts down need to be cleaned up by calling the kernel to
terminate the lease and freeing any DIX structures.
Note that we cannot simply use the existing
drmmode_terminate_lease function on each lease as that wants
to also reset the video mode, and during server shut down that
modesetting: Validate leases on VT enter
The kernel doesn't allow any master ioctls to run when another
VT is active, including simple things like listing the active
leases. To deal with that, we check the list of leases
whenever the X server VT is activated.
xfree86: hide disabled cursors when resetting after lease termination
The lessee may well have played with cursors and left one
active on our screen. Just tell the kernel to turn it off.
v6: Add meson build infrastructure
[Also bumped libdrm requirement - ajax]
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Tracks changes to the non-desktop property so that when non-zero,
outputs will always appear to be disconnected.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
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>
Monitor outputs are of type RROutput, not RRCrtc.
(Which are both XID, so this makes no difference in practice, other than
being technically correct.)
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
RRChangeOutputProperty and RRConfigureOutputProperty should not modify
their parameters, and callers may want to pass pointers to fixed data,
so declare the value pointers as const in both cases.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When the last crtc (resp. output) is destroyed, the rrScrPriv crtcs
(resp. outputs) fields do not get cleared, which can lead to a situation
where the private's numCrtcs (resp. numOutputs) field is zero, but the
associated memory is still allocated. Just checking if numCrtcs (resp.
numOutputs) is zero is thus not a good criteria to determine whetehr to
use a realloc or a malloc.
Since crtcs (resp. outputs) are NULL-initialized anyway, relying on
numCrtcs (resp. numOutputs) is actually unnecessary, because
reallocation of a NULL ptr is equivalent to a malloc anyway.
Therefore, just use realloc() unconditionally, and ensure that the
fields are properly initialized.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Similarly to bb766ef112, ensure that the
extra padding is set to 0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Running Xephyr under valgrind reveals that we're sending some
uninitialized memory over the wire (particularly, the leftover padding
that comes from rounding extraLen to the next 32-bit multiple).
Solve by calloc()ing the memory instead of malloc()ing (the alternative
would be to memset just the padding, but I'm not sure it's more
convenient.)
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This allows making the master screen's pixmap_dirty_list entries
explicitly reflect that we're now tracking the root window instead of
the screen pixmap, in order to allow Present page flipping on master
outputs while there are active slave outputs.
Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave
HAS_DIRTYTRACKING_ROTATION defined as well to make things slightly
easier for drivers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Currently, RRCrtcPendingTransform returns false unless the
transformation matrix itself is changing. This makes RRCrtcSet skip
doing anything if the only thing that is changing is the transform
filter.
There's already a function for comparing RRTransformPtrs, so use that
instead.
Tested by running
xrandr --output DP-1 --mode 1920x1080 --rate 144 --scale 0.5x0.5 --filter nearest
follwed by
xrandr --output DP-1 --mode 1920x1080 --rate 144 --scale 0.5x0.5 --filter bilinear
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.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>
xrandr --setprovideroutputsource <screen> <gpu screen>
Xorg: ../../../xserver/dix/dispatch.c:4018: AttachOutputGPU:
Assertion `new->isGPU' failed.
GPUScreen is not allowed to be sink output.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The purpose of rrCheckPixmapBounding is to make sure that the
screen_pixmap is *large* enough for the slave-output which crtc is
being configured.
However until now rrCheckPixmapBounding would also shrink the
screen_pixmap in certain scenarios leading to various problems.
For example: Take a laptop with its internalscreen on a slave-output and
currently disabled and an external monitor at 1920x1080+0+0.
Now lets say that we want to drive the external monitor at its native
resolution of 2560x1440 and have the internal screen mirror the top left
part of the external monitor, so we run:
$ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
--mode 2560x1440 --pos 0x0
Here xrandr utility first calls RRSetScreenSize to 2560x1440, then it
calls RRSetCrtc 1920x1080+0+0 on the eDP, since this is a slave output,
rrCheckPixmapBounding gets called and resizes the screen_pixmap to
1920x1080, undoing the RRSetScreenSize. Then RRSetCrtc 2560x1440+0+0
gets called on the HDMI, depending on crtc->transforms this will
either result in a BadValue error from ProcRRSetCrtcConfig; or
it will succeed, but the monitor ends up running at 2560x1440
while showing a 1920x1080 screen_pixmap + black borders on the right
and bottom. Neither of which is what we want.
This commit removes the troublesome shrinking behavior, fixing this.
Note:
1) One could argue that this will leave us with a too large screen_pixmap
in some cases, but rrCheckPixmapBounding only gets called for slave
outputs, so xrandr clients already must manually shrink the screen_pixmap
after disabling crtcs in normal setups.
2) An alternative approach would be to also call rrCheckPixmapBounding
on RRSetCrtc on normal (non-slave) outputs, but that would result in
2 unnecessary resizes of the screen_pixmap in the above example, which
seems undesirable.
Cc: Nikhil Mahale <nmahale@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The purpose of rrCheckPixmapBounding is to make sure that the
screen_pixmap is large enough for the slave-output which crtc is
being configured.
This should include crtc->x and crtc->y, otherwise the crtc might
still end up scanning out an area outside of the screen-pixmap.
For example: Take a laptop with an external monitor on a slave-output at
1920x1080+0+0 and its internal-screen at 3840x2160+1920+0 and in
gnome-settings-daemon move the external monitor to be on the ri ght of
the internal screen rather then on the left. First g-s-d will do a
RRSetScreenSize to 5760*2160 (which is a nop), then it calls RRSetCrtc
to move the slave output to 1920x1080+3840+0, since this is a slave
output, rrCheckPixmapBounding gets called, since the 2 crtcs now overlap
the code before this commit would shrinks the screen_pixmap to 3180*2160.
Then g-s-d calls RRSetCrtc to move the internal screen to 3180*2160+0+0.
And we end up with the slave-output configured to scan-out an area
which completely falls outside of the screen-pixmap (and end up with
a black display on the external monitor).
This commit fixes this by not substracting the x1 and y1 coordinates
of the union-ed region when determining the new screen_pixmap size.
Cc: Nikhil Mahale <nmahale@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Before this commit crtc_bounds() did not take reflection into account,
when using reflection with 0 / 180 degree rotation this was not an
issue because of the default in the switch-case doing the right thing.
But when using 90 / 270 degree rotation we would also end up in the
default which is wrong in this case. This would lead to the cursor
being constrained to a height x height area of the monitor.
This commit masks out the reflection bits for the switch-case,
making crtc_bounds return the correct bounds and fixing the
problematic cursor constraining.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This is a preparation patch for adding prime hw-cursor support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Adds an output parameter to disable PRIME synchronization.
Output parameter is created when the user calls 'xrandr
--setprovideroutputsource <sink> <source>' to prevent polluting output
parameters of non-PRIME configurations.
Defaults to on, so if the user wants PRIME synchronization they don't need
to do anything.
If the user wishes to disable PRIME synchronization when they first set up
PRIME, they can run 'xrandr --output <output> --set "PRIME Synchronization"
0' after running 'xrandr --setprovideroutputsource <sink> <source>', but
before 'xrandr --auto'.
If the user wishes to enable or disable PRIME synchronization after PRIME has
already been set up, they can run 'xrandr --output <output> --set "PRIME
Synchronization" <0 or 1>' at any time, xrandr will trigger a modeset, which
will tear down and setup PRIME in the configuration they requested on CRTCs
associated with that output.
randrstr.h:
Add central definition of the output property name.
rrcrtc.c:
Add function rrGetPixmapSharingSyncProp() to query the status of the
output property.
Add function rrSetPixmapSharingSyncProp() to set the output property.
Add 'sync' parameter to rrSetupPixmapSharing(), which when false will
use single buffering even if the required ABI functions are supported.
Changes rrSetupPixmapSharing() to only report an error if falling back
to single buffering when the user requested synchronization.
Change RRCrtcSet() to use rrPixmapSharingSyncProp() to query the status
of the output property and feed it into rrSetupPixmapSharing() using
the 'sync' parameter.
rrprovider.c:
Add RR(Init/Fini)PrimeSyncProps(), functions to create and destroy the
PRIME synchronization output property.
Add a call to RRInitPrimeSyncProps() in
ProcRRSetProviderOutputSource(), such that the output property is
created when the user requests PRIME.
Add a call to RRFiniPrimeSyncProps() in RRProviderDestroy().
v1: Initial commit
v2: Unchanged
v3: Add /* TODO */ for handling different sources with different outputs
Make rrSetupPixmapSharing() set the output property to 0 if it has to fall
back, to avoid user confusion.
Make rr(Get)PixmapSharingSyncProp() check the current value if there isn't a
pending value
v4: Unchanged
v5: Unchanged
v6: Rebase onto ToT
v7: Unchanged
Signed-off-by: Alex Goins <agoins@nvidia.com>
Changes PRIME to use double buffering and synchronization if all required
driver functions are available.
rrcrtc.c:
Changes rrSetupPixmapSharing() to use double buffering and
synchronization in the case that all required driver functions are
available. Otherwise, falls back to unsynchronized single buffer.
Changes RRCrtcDetachScanoutPixmap() to properly clean up in the case of
double buffering.
Moves StopPixmapTracking() from rrDestroySharedPixmap() to
RRCrtcDetachScanoutPixmap().
Changes RRReplaceScanoutPixmap() to fail if we are using double buffering,
as it would need a second ppix parameter to function with double buffering,
and AFAICT no driver I've implemented double buffered source support in uses
RRReplaceScanoutPixmap().
randrstr.h:
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME
double buffering.
xf86Crtc.h:
Adds current_scanout_back to _xf86Crtc to facilitate detection
of changes to it in xf86RandR12CrtcSet().
xf86RandR12.c:
Changes xf86RandR12CrtcSet() to detect changes in
scanout_pixmap_back.
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME double
buffering.
v1: Initial commit
v2: Rename PresentTrackedFlippingPixmap to PresentSharedPixmap
v3: Refactor to accomodate moving (rr)StartFlippingPixmapTracking and
(rr)(Enable/Disable)SharedPixmapFlipping to rrScrPrivRec from ScreenRec
Add fallback if flipping funcs fail
v4: Detach scanout pixmap when destroying scanout_pixmap_back, to avoid
dangling pointers in some drivers
v5: Disable RRReplaceScanoutPixmap for double-buffered PRIME, it would need an
ABI change with support for 2 pixmaps if it were to be supported, but AFAICT
no driver that actually supports double-buffered PRIME uses it.
Refactor to use rrEnableSharedPixmapFlipping() as a substitute for
rrCrtcSetScanoutPixmap() in the flipping case.
Remove extraneous pSlaveScrPriv from DetachScanoutPixmap()
Remove extraneous protopix and pScrPriv from rrSetupPixmapSharing()
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Adds typedefs for (*RRStartFlippingPixmapTrackingProcPtr),
(*RREnableSharedPixmapFlippingProcPtr),
and (*RRDisableSharedPixmapFlippingProcPtr) in randrstr.h.
Adds typedefs for (*PresentSharedPixmapProcPtr),
(*SharedPixmapNotifyDamageProcPtr),
(*RequestSharedPixmapNotifyDamageProcPtr), and
(*StopFlippingPixmapTrackingProcPtr) in scrnintstr.h.
Adds RR(Enable/Disable)SharedPixmapFlipping, and
RRStartFlippingPixmapTracking to rrScrnPrivRec.
Adds StopFlippingPixmapTracking, PresentSharedPixmap,
SharedPixmapNotifyDamage, and RequestSharedPixmapNotifyDamage to ScreenRec.
rrScrnPrivRec used for functions that use RandR-private data types, and
ScreenRec used for the rest.
RREnableSharedPixmapFlipping will allow the sink driver to setup for
flipping between two shared pixmaps.
RRDisableSharedPixmapFlipping will allow the sink driver to do teardown
associated with flipping between two shared pixmaps.
(RRStart/Stop)FlippingPixmapTracking are merely the double-buffered
equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do
whatever setup and teardown necessary for presenting on the two shared
pixmaps.
PresentSharedPixmap is a function exposed by the source driver for the X
server or sink driver to call to request a present on a given shared
pixmap. This way, presents can be driven by the sink's vblank instead of a
timer or similar mechanism.
SharedPixmapNotifyDamage and RequestSharedPixmapNotifyDamage are OPTIONAL
(even for double-buffered PRIME) functions exposed by the sink driver and
the source driver, respectively. By calling
master->RequestSharedPixmapNotifyDamage(ppix), the sink driver can request
for the source driver to call slave->SharedPixmapNotifyDamage(ppix) in
response to damage on the master screen pixmap tracked by ppix.
v1: Initial commit
v2: Rename PresentTrackedFlippingPixmap to PresentSharedPixmap
Add SharedPixmapNotifyDamage / RequestSharedPixmapNotifyDamage
v3: Add RRCrtcPtr as a parameter to StartFlippingPixmapTracking
Move functions that use RandR-private data types to rrScrnPrivRec.
v4: Unchanged
v5: Add front and back parameters to RREnableSharedPixmapFlippingProcPtr
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
In prime configurations master's last set time may not be latest
and greatest, adjust it with slaves last set time, pick up greatest
one. Otherwise xserver may end with events which has
lastSetTime < lastConfigTime even if that's not
the case and confuse xrandr client.
[hdegoede: rebase on "xrandrprovider: Do not use separate lists for unbound /
source / offload slaves"]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
A single provider can be both a offload and source slave at the same time,
the use of seperate lists breaks in this case e.g. :
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
xrandr --setprovideroutputsource 1 0x7b
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
xrandr --setprovideroffloadsink 1 0x7b
xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Not good. The problem is that the provider with id 0x46 now is on both
the output_slave_list and the offload_slave_list of the master screen.
This commit fixes this by unifying all 3 lists into a single slaves list.
Note that this does change the struct _Screen definition, so this is an ABI
break. I do not expect any of the drivers to actually use the removed / changed
fields so a recompile should suffice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
RRScreenSizeNotify() will update the connection information block, but
if this occurs during initialization before ConnectionInfo is even
initialized, this will lead to a crash.
Simply check for ConnectionInfo prior to update it to avoid the crash.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is an ABI break, in that we now pass NULL to a function that hasn't
accepted it before.
Alex Goins had a different patch for this but it wasn't symmetrical, it
freed something in a very different place than it allocated it, this
attempts to retain symmetry in the releasing of the backing bo.
v2: use a new toplevel API, though it still passes NULL to something
that wasn't expecting it.
v3: pass -1 instead of 0.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Goins <agoins at nvidia.com>
This was added in:
commit 312910b4e3
Author: Chase Douglas <chase.douglas@canonical.com>
Date: Wed Apr 18 11:15:40 2012 -0700
Update currentTime in dispatch loop
Unfortunately this is equivalent to calling GetTimeInMillis() once per
request. In the absolute best case (as on Linux) you're only hitting the
vDSO; on other platforms that's a syscall. Either way it puts a pretty
hard ceiling on request throughput.
Instead, push the call down to the requests that need it; basically,
grab processing and event generation.
Cc: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This lets clients know that the layout of the monitors on the screen
has changed so they can adapt appropriately.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Make sure we account for slave CRTCs when building the monitor list,
since that's what rrxinerama uses to fake Xinerama geometry.
[ajax: Slightly more informative commit message.]
Bugzilla: https://bugs.freedesktop.org/92313
Reviewed-by: Dave Airlie <airlied@redhat.com>
Otherwise, we leave a dangling reference to the destroyed pixmap in the
master screen's pixmap_dirty_list.
Fixes regression from commit cf5d6414 ("randr: Factor out shared pixmap
destruction").
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
protopix is completely redundant with mscreenpix. Get rid of it.
We don't need rrScrPriv, so remove it.
[ajax: also squash an unused variable in RRCrtcDetachScanoutPixmap,
though it'll come back when the rest of this series lands]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
The old version of rrCreateSharedPixmap(), in addition to actually creating
a shared pixmap with scanout, also set up pixmap tracking on the source
driver.
I will be needing to create multiple shared pixmaps for PRIME double
buffering, so factor the part that does shared pixmap creation into its own
function, the new rrCreateSharedPixmap(). Rename the old
rrCreateSharedPixmap() to rrSetupPixmapSharing(), a function that
replicates the old functionality of rrCreateSharedPixmap() using the new
rrCreateSharedPixmap().
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Shared pixmap destruction is done by unrefing the master pixmap twice: once
for the original reference, and once for the reference implicitly added by
PixmapShareToSlave. Then, unrefing the slave pixmap once.
When I add PRIME double buffering and synchronization, I will need to do
this in multiple places. To avoid duplication of code and comments
explaining it everywhere, factor it out into its own function and use that
in place of where it was before.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
We only set changes on the main protocol screen as, for example
in RRSetChanged() and RRTellChanged(), therefore we should follow
the same logic when reporting that an output changed in
RROutputChanged().
This means that RRTellChanged() will then update the relevant
timestamps also when events come from gpu screens.
[ajax: Fix mixed code and decls]
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alberto Milone <alberto.milone@canonical.com>
rrtransform.c:199:23: warning: shifting a negative signed value is undefined [-Wshift-negative-value,Semantic Issue]
rot_cos = F(-1);
^~~~~
rrtransform.c:114:14: note: expanded from macro 'F'
^~~~~~~~~~~~~~
../render/picture.h:200:24: note: expanded from macro 'IntToxFixed'
^~~~~~~~~~~~~~~~~~~~~~
/opt/X11/include/pixman-1/pixman.h:130:56: note: expanded from macro 'pixman_int_to_fixed'
~~~ ^
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
rrtransform.c:124:22: warning: using integer absolute value function 'abs' when
argument is of floating point type [-Wabsolute-value,Semantic Issue]
if ((v = abs(f_transform->m[j][i])) > max)
^
rrtransform.c:124:22: note: use function 'fabs' instead [Semantic Issue]
if ((v = abs(f_transform->m[j][i])) > max)
^~~
fabs
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
xorg/xserver/randr/rrmonitor.c:35:5: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘RRCrtc’ [-Werror=format=]
RRCrtc is XID is CARD32, which inside the server is unsigned long or int
depending on architecture, so a cast is required.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
[ajax: To be clear, we already have code to emit these events, and it
looks like it works, but to get them you'd have had to also ask for one
of the other notify types. This makes it possible to listen for e.g.
ProviderChange alone.]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
As we define sizeFits based on whether a CRTC is active, and skip trying
to redirect the scanout on a disable pipe, we then attempt to undo it
later and fail because crtc->scanout_pixmap != DRI2_Pixmap and
!sizeFits. Paper over this failure by skipping unredirected CRTC when
disabling.
v2: Unwind upon failure
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84653
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reported-by: Christoph Haag <haagch@frickel.club>
Tested-by: Christoph Haag <haagch@frickel.club>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
One of the lacking features with output offloading was
that screen rotation didn't work at all.
This patch makes 0/90/180/270 rotation work with USB output
and GPU outputs.
When it allocates the shared pixmap it allocates it rotated,
and any updates to the shared pixmap are done using a composite
path that does the rotation. The slave GPU then doesn't need
to know about the rotation and just displays the pixmap.
v2:
rewrite the sync dirty helper to use the dst pixmap, and
avoid any strange hobbits and rotations.
This breaks ABI in two places.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This creates an automatic monitor for a tiled monitor at startup.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This replaces the CRTC-based Xinerama implementation with one which
uses Monitors instead, allowing clients to manipulate the Xinerama
configuration through the RandR Monitor list.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Store the user-defined monitors in the RandR screen private.
Generate a list of monitors from both the user-defined ones and from
any outputs not mentioned in one of the user-defined monitors. This list
covers both the outputs in the main screen as well as any slaves.
v1.1: airlied: fix up primary skipping bug,
fix wrong height initialiser
add get_active flag from updated protocol.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
In most of xserver code-base we define new functions at column 0, with
their return type provided on the previous line. Two functions did not
follow this rule so update them, and get them wrapped up to 80 as an
added bonus.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Also make use of total_name_len variable for consistency.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This will allow us to make the code more readable, and the lines will
fit within 80 columns.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
To provide some information about the origin of the message.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
All of these seem like left over from developments stage. Remove them as
they can cause excessive flood in the logs.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Prevent RRXinerama from activating if PseudoramiX is, so we don't get XINERAMA
listed twice in the list of extensions. I think this is otherwise benign, as
the PseudoramiX XINERAMA gets registered first and thus handles all requests.
Perhaps AddExtension() ought to warn us if the extension name is already
registered?
This appears to be a long-standing bug seen in XQuartz, and now in XWin as well.
Future work: Perhaps since RRXinerama isn't actually doing anything useful but
faking it when we have one screen, it seems that the PseudoramiX code could be
also used in that case.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
If the user wants to set one of the slave devices as
the primary output, we shouldn't fail to do so,
we were returning BadMatch which was tripping up
gnome-settings-daemon and bad things ensues.
Fix all the places we use primaryOutput to work
out primaryCrtc and take it into a/c when slave
gpus are in use.
v2: review from Aaron, fix indent, unhide has_primary from
macro. I left the int vs Bool alone to be consistent with
code below, a future patch could fix both.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88614
Signed-off-by: Carlos Sánchez de La Lama <csanchezdll@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
RRPointerToNearestCrtc is suppose to snap to the nearest Crtc,
but best_x and best_y is always positive, hence when calling
SetCursorPosition it will make the cursor even further away.
Correct delta x/y to allow negative values and also use
"width/height -1" in the calculation. Also choose the closest
Crtc by setting the "best" value.
Signed-off-by: David Ung <davidu@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Slaving two outputs on a secondary GPU to a primary GPU testing
picked this up, in that we'd try to resize to the totally the
wrong thing, then as usual segfault in the rotation code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
The protocol handlers all have support for swapping variable data and
replies, but the top-level dispatch plumbing was missing.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Both xRRSetProviderOutputSourceReq and xRRSetProviderOffloadSinkReq are
fixed-size requests, so the length on the wire should match exactly.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The previous code was checking the wrong table for function pointers.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The function RRCrtcSet call checks to see if the config being set is
already configured, but, doesn't check that the selected outputs are
connected to the crtc before skipping. This means that the following
sequence will omit the final CrtcSet call to the driver:
CRTC c1 connect to output o
CRTC c2 connect to output o
CRTC c1 connect to output o
This change adds the check to ensure that each of the calls are made to
the driver.
Signed-off-by: David Sodman <dsodman@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Don't use rrScrPriv for nested screen private fetching.
Eliminate a duplicate fetch of the randr screen private in rrCheckPixmapBounding.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Consider all attached output providers when looking for changed outputs and
crtcs.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Send RRResourceChangeNotify event when provider, output or crtc was created or
destroyed. I.e. when the list of resources returned by RRGetScreenResources and
RRGetProviders changes.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Send RRProviderChangeNotify event when a provider becomes output source or
offload sink.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We don't want to know about changes on the non-protocol screen,
we will fix up setchanged to make sure non-protocol screens update
the protocol screens when they have a change.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When SetChanged is called we now modify the main protocol screen,
not the the gpu screen. Since changed stuff should work at the protocol level.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce a wrapper interface so we can fix things up for multi-gpu
situations later.
This just introduces the API for now.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So in the cold plug server shutdown case, we reap the resources
before we call CloseScreen handlers, so the config->randr_provider
is a dangling pointer when the xf86CrtcCloseScreen handler is called,
however in the hot screen unplug case, we can't rely on automatically
reaped resources, so we need to clean up the provider in the xf86CrtcCloseScreen
case.
This patch provides a cleanup callback from the randr provider removal
into the DDX so it can cleanup properly, this then gets called by the automatic
code for cold plug, or if hot unplug it gets called explicitly.
Fixes a number of random server crashes on shutdown
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58174
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=891140
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
rrcrtc.c: In function 'RRCrtcDetachScanoutPixmap':
rrcrtc.c:366:9: warning: variable 'ret' set but not used
[-Wunused-but-set-variable]
rrcrtc.c: In function 'rrCheckPixmapBounding':
rrcrtc.c:505:13: warning: variable 'ret' set but not used
[-Wunused-but-set-variable]
rrcrtc.c:445:9: warning: unused variable 'i' [-Wunused-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
When an RandR shared pixmap is created in rrCreateSharedPixmap, it has a refcnt
of 1. Then, PixmapShareToSlave bumps the refcnt to 2. However, there's no
corresponding PixmapUnshareFromSlave where the refcnt can be decreased again,
and there's no convenient common place where the refcnt can be decremented when
the slave pixmap is destroyed.
Fix this by just unreffing the pixmap twice in RRCrtcDetachScanoutPixmap.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Enrico Weigelt, metux IT consult
Michael Wyraz
Ilya Pominov
Peter Hutterer
Minh Phan
JiangWu
Olivier Fourdan
Xaver Hugl
Povilas Kanapickas
Mario Kleiner
Łukasz Spintzyk
Michel Dänzer
Jan Beich
Alex Goins
Dave Airlie
Alexander Volkov
Pekka Paalanen
Keith Packard
Lyude Paul
Eric Anholt
Chris Wilson
Thierry Reding
Michel Dänzer
Adam Jackson
Giuseppe Bilotta
Aaron Plattner
Qiang Yu
Michal Srb
Hans de Goede
Nikhil Mahale
Dave Airlie
Jan Burgmeier
Alberto Milone
Jeremy Huddleston
Jon TURNEY
Alan Coopersmith
Emil Velikov
Carlos Sánchez de La Lama
David Ung
Robert Morell
David Sodman