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.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This field isn't used by any drivers, and also better belongs into
the corresponding extension instead of OS adaption layer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
Several SProc's have become no-ops, just calling the actual Proc's,
so we can get rid of them entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
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>
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>
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