If a device does not have any valuators, it makes no sense to set the
device transformation. Return a BadMatch error to let the caller know
that they're trying something stupid.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 9ff89a2e46)
The refactoring in commit efc1035ca9
removed the actual update of currentTime.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit fa62ca68ef)
This is necessary to avoid a NULL pointer deference when the pixmap is
used later.
[ajax: massaged commit message, fixed it to compile]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89748
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Brent Collins <bcollins@trustedcs.com>
(cherry picked from commit 7470578520)
We pass the pPixmap->drawable.id to the ShmDetachSegment function after
the pPixmap is freed. Fortunately, we don't use the value inside
ShmDetachSegment and can simply pass zero instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
(cherry picked from commit bcec9f867d)
Make sure X_BIG_ENDIAN/X_LITTLE_ENDIAN are defined before actually using
them.
Otherwise, image byte order could be wrong on big endian hardware even
though endianess detection is correct.
Reported-by: Tim Waugh <twaugh@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 1af15aaf27)
If no compat_output is defined, we inadvertently (attempt to) return
whatever data is at index -1. Instead, return NULL since that's what
callers are expecting.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
(cherry picked from commit 28159eff6b)
Fix missing newlines from error string and fix grammar.
Signed-off-by: Robert Ancell <robert.ancell@canonical.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit cad831f398)
Include the wrapped windows.h via X11/Xwindows.h before xcb_keysyms.h to avoid
type clashes caused by the unwrapped windows.h that includes.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit 2b114d6a51)
Link xwinclip with -lpthread to fix build for MinGW
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit 5bf3e5c832)
Xtrans.h must be included on WIN32 to prototype _XSERVTransWSAStartup()
xserver/os/xdmcp.c: In function ‘get_addr_by_name’:
xserver/os/xdmcp.c:1483:5: error: implicit declaration of function ‘_XSERVTransWSAStartup’ [-Werror=implicit-function-declaration]
Signed-off-by: Colin Harrison <colin.harrison@virgin.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
(cherry picked from commit 8363ef2764)
Needed when using a compiler that defaults to 64-bit output when
configure is checking for $host_cpu.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Thomas Klausner <wiz@NetBSD.org>
(cherry picked from commit d4e85afac6)
At the moment, the X server uses a non-default timeout for D-Bus
messages to systemd-logind. The only timeouts normally used with
D-Bus are:
1) Infinite
2) Default
Anything else is just as arbitrary as Default, and so rarely makes
sense to use instead of Default.
Put another way, there's little reason to be fault tolerant against
a local root running daemon (logind), that in some configurations, the
X server already depends on for proper functionality.
This commit changes systemd-logind to just use the default timeouts.
Downstream-bug: https://bugzilla.redhat.com/show_bug.cgi?id=1209347
Signed-off-by: Ray Strode <rstrode@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit b1029716e4)
It's possible to receive a message reply in the message filter if a
previous message call timed out locally before the reply arrived.
The message_filter function only handles signals, at the moment, and
does not properly handle message replies.
This commit changes the message_filter function to filter out all
non-signal messages, including spurious message replies.
Downstream-bug: https://bugzilla.redhat.com/show_bug.cgi?id=1209347
Signed-off-by: Ray Strode <rstrode@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 792e925167)
The mi filled arc code estimates that a filled arc will produce no
more spans than the arc is tall. This is true for most arcs except
for pie-slice arcs strictly between 180 and 360 degrees where the missing
portion of the arc faces up or down such that we get two spans on some
scanlines.
For those, we need to reserve room for another height/2 spans. This
patch just does it for all partial pie-sliced arcs to make the test
easier to understand; it's just over-allocating a bit of memory, so
that's safe.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 41932dfbc8)
Non serverfd input devices will never get a systemd-logind dbus resume signal,
causing them to never get re-enabled.
This commit changes xf86VTEnter() to enable them immediately, fixing this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89756
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 21e7d2bb5c)
xf86platformProbeDev creates GPU screens for any platform devices that were not
matched by a GDev in the loop above, but only if there was at least one device.
This means that it's impossible to configure a device as a GPU screen if there
is only one platform device that matches that driver.
Instead, create a GPU screen (if possible) for any platform device that was not
claimed by the GDev loop.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e36236eade)
If a PCI entity is found, xf86_check_platform_slot performs a device ID check
against the xf86_platform_device passed in. However, it just returns
immediately without checking the rest of the entities first. This leads to this
situation happening:
1. The nvidia driver creates an entity 0 with bus.type == BUS_PCI
2. The intel driver creates entity 1 for its platform device, opening
/dev/dri/card0
3. xf86platformProbeDev calls probeSingleDevice on the Intel platform device,
which calls doPlatformProbe, which calls xf86_check_platform_slot.
4. xf86_check_platform_slot compares the Intel platform device against the
NVIDIA PCI entity. Since they don't have the same device ID, it returns
TRUE.
5. doPlatformProbe calls xf86ClaimPlatformSlot, which creates a duplicate entity
for the Intel one.
Fix this by only returning FALSE if the PCI ID matches, and continuing the loop
otherwise. In the scenario above, this allows it to continue on to find the
Intel platform device that matches the second entity.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4ecda36259)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 8102927282)
When using glamor (either in Xephyr or Xwayland) on hardware with too
low instructions limit, glamor fallbacks to sw due to large shaders.
This makes glamor unbearably slow on such hardware.
Check reported value for GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB
and fail in glamor_init() if the limit is lower than 128.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 4218a1e066)
Remove the calls to GL_TEXTURE_MAX_LEVEL. Setting the filtering is
a sufficient hint to the driver about texture mipmap allocation.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 0e1372e1bd)
The latter might not be available on GLES2.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit c1f35c3d86)
According to Eric Anholt the check for glGetError is not needed here.
Because a opengl error might be set before this function is called
keeping the check could result in glamor_build_program returning
failure when building the shader succeeded.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit b66501b4fd)
Check for GL_EXT_unpack_subimage and GL_NV_pack_subimage to
check if GL_(UN)PACK_ROW_LENGTH is available. Set the offsets
manually to prevent calls to GL_(UN)PACK_SKIP_*.
v2: Check support for GL_NV_pack_subimage as suggested by Matt Turner.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 7c6f483670)
So that Xwayland gets re-linked each time glamor is modified.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 4f534c26c6)
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>
(cherry picked from commit 93ef0e580e)
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>
(cherry picked from commit a08ee77398)
Improve the parsing of the <proto> XML element
Include all text from the param element, in the order it appears in the xml
document, as part of the formal parameter declaration
This is needed to correctly handle the XML description added in svn r27498 of
glPathGlyphIndexRangeNV()'s baseAndCount parameter of type GLuint[2]
This fixes the way the parameter declaration is generated so it is in the
correct form 'GLuint baseAndCount_[2]' and not 'GLuint baseAndCount[2]_'
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit d02f9611c8)
Factor out duplicated code used in parsing of the <proto> XML element in the
code generator
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit 5071cb7e0a)
XdmcpFatal uses the format specifier %*.*s, which vpnprintf() doesn't
understand, which causes a backtrace and prevents the reason for the XDMCP
failure being logged.
See also:
https://bugs.freedesktop.org/show_bug.cgi?id=66862https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758574
"%*.*s" is also currently used in a few other places, so teach vpnprintf() how
to handle it
$ fgrep -r "%*.*s" *
hw/dmx/config/scanner.l: fprintf(stderr, "parse error on line %d at token \"%*.*s\"\n",
hw/dmx/dmxlog.c: ErrorF("(%s) dmx[i%d/%*.*s]: ", type,
hw/dmx/input/dmxinputinit.c: dmxLogCont(dmxInfo, "\t[i%d/%*.*s",
os/access.c: ErrorF("Xserver: siAddrMatch(): type = %s, value = %*.*s -- %s\n",
os/access.c: ("Xserver: siCheckAddr(): type = %s, value = %*.*s, len = %d -- %s\n",
os/xdmcp.c: FatalError("XDMCP fatal error: %s %*.*s\n", type,
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit d3080d421b)
In X server 1.17, the default configuration is now -nolisten tcp. In this
configuration, XDMCP options don't work usefully, as the X server is not
listening on the port for the display that it tells the display manager to
connect to.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit 491cf02e19)
ephyr_glamor_connect() returns NULL if we failed, but applying
xcb_connection_has_error() to NULL is not permitted.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
(cherry picked from commit f42520c5f1)
pci_device_map_legacy returns 0 on success.
Signed-off-by: Jürg Billeter <j@bitron.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0a78b599b3)
Since _XSERVTransClose frees the connection pointer passed to it,
remove that pointer from the array, so we don't try to double free it
if we come back into CloseWellKnownConnections again.
Should fix https://bugzilla.yoctoproject.org/show_bug.cgi?id=6665 in which
the shutdown section of the main() loop called CloseWellKnownConnections()
and then moved on to ddxGiveUp(), which failed to release the VT and thus
called AbortServer(), which called CloseWellKnownConnections() again.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 7ea64fb437)
Add _X_EXPORT to GetMaster function. It is required by tigervnc's VNC module.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5c4202ea85)
This was reported on irc on Fedora when rawhide went to 1.17.1.
regression occured in: 2566835b43
os: Eliminate uninitialized value warnings from access.c
siAddrMatch doesn't need addr to be a useful value, it checks
some things like localuser without having an address at all.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9d9bd38fe1)
Gcc5 adds additional lines stating line numbers before and
after __attribute__() which need to be skipped.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Tested-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 21b896939c)
Ensure that the given strings length in an XkbSetGeometry request remain
within the limits of the size of the request.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 20079c36cf)
The XkbSetGeometry request embeds data which needs to be swapped when the
server and the client have different endianess.
_XkbSetGeometry() invokes functions that swap these data directly in the
input buffer.
However, ProcXkbSetGeometry() may call _XkbSetGeometry() more than once
(if there is more than one keyboard), thus causing on swapped clients the
same data to be swapped twice in memory, further causing a server crash
because the strings lengths on the second time are way off bounds.
To allow _XkbSetGeometry() to run reliably more than once with swapped
clients, do not swap the data in the buffer, use variables instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 81c90dc8f0)
Jonathan Dieter posted a few patches to do this inside the Xorg
server but it makes no sense to do it there, just have the code
we use to probe the device list at startup check seat assignments
using the same code we check at hotplug time.
Bugilla: https://bugzilla.redhat.com/show_bug.cgi?id=1183654
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Jonathan Dieter <jdieter@lesbg.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
Currently when the ddx does not set any driver name we set DRI2 driver but
not the VDPAU driver name. The result is that VDPAU drivers will not get found
by libvdpau when the modesetting driver is being used.
Just assume that the VDPAU driver matches the DRI2 driver name, this is true
for nouveau, r300, r600 and radeonsi i.e all VDPAU drivers currently supported
by mesa.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
All of our checks for what crtc we are on take rotation into account so we
select the correct crtc. The only problem is that we weren't returning it
we were rotated. This caused X to think DRI3 apps were not on any crtc and
limit them to 1 FPS.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This replaces the stubs for shadow buffer creation/allocation with actual
functions and adds a shadow_destroy function. With this, we actually get
shadow buffers and RandR now works properly. Most of this is copied from
the xf86-video-intel driver and modified for modesetting.
v2 Jason Ekstrand <jason.ekstrand@intel.com>:
- Fix build with --disable-glamor
- Set the pixel data pointer in the pixmap header for dumb shadow bo's
- Call drmmode_create_bo with the right bpp
v2 Jason Ekstrand <jason.ekstrand@intel.com>:
- Make shadow buffers per-crtc and leave shadow_enable alone
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
