In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE
(which it does if no config file or directory is present), the
autoconfig flag is set, causing xf86AutoConfig to be called
later on.
xf86AutoConfig calls xf86OutputClassDriverList via the
call tree:
xf86AutoConfig =>
listPossibleVideoDrivers =>
xf86PlatformMatchDriver =>
xf86OutputClassDriverList
and xf86OutputClassDriverList attempts to traverse a linked list
that is a member of the XF86ConfigRec struct pointed to by the
global xf86configptr, which is NULL at this point because the
XF86ConfigRec struct is only allocated (by xf86readConfigFile)
AFTER the config file and directory have been successfully
opened; the CONFIG_NOFILE return from xf86HandleConfigFile
occurs BEFORE the call to xf86readConfigFile which allocates
the XF86ConfigRec struct.
Rx: In read.c (for symmetry with xf86freeConfig, which already
appears in this file), add a new function xf86allocateConfig
which tests the value of xf86configptr and, if it's NULL,
allocates the XF86ConfigRec struct and deposits the pointer
in xf86configptr. In xf86Parser.h, add a prototype for the
new xf86allocateConfig function.
Back in read.c, #include "xf86Config.h". In xf86readConfigFile,
change the open-code call to calloc to a call to the new
xf86allocateConfig function.
In xf86AutoConfig.c, add a call to the new xf86allocateConfig function
to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct
is allocated.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ben Crocker <bcrocker@redhat.com>
If we did not find any non GPU Screens, try again ignoring the notion
of any video devices being the primary device. This fixes Xorg exiting
with a "no screens found" error when using virtio-vga in a
virtual-machine and when using a device driven by simpledrm.
This is a somewhat ugly solution, but it is the best I can come up with
without major surgery to the bus and probe code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is primarily a preparation patch for fixing the xserver exiting with
a "no screens found" error even though there are supported video cards,
due to the server not recognizing any card as the primary card.
This also fixes the (mostly theoretical) case of a platformBus capable
driver adding a device as GPUscreen before a driver which only supports
the old PCI probe method gets a chance to claim it as a normal screen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If foundScreen is TRUE, then all the code below the removed if
will not execute until we reach the return foundScreen; at the
end, so this entire if block is redundant.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Sometimes, Xwayland will try to use a cursor that has just been freed,
leading to a crash when trying to access that cursor data either in
miPointerUpdateSprite() or AnimCurTimerNotify().
CheckMotion() updates the pointer's cursor based on which xwindow
XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
to fake a crossing to the root window when the pointer has left the
Wayland surface but is still within the xwindow.
But after an xwindow is unrealized, the last xwindow used to match the
xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
not return the same xwindow.
To avoid this issue, update the last_xwindow based on enter and leave
notifications instead of xwl_xy_to_window(), and check if the xwindow
found by the regular miXYToWindow() is a child of the known last
xwindow, so that multiple consecutive calls to xwl_xy_to_window()
return the same xwindow, being either the one found by miXYToWindow()
or the root window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Vít Ondruch <vondruch@redhat.com>
Tested-by: Satish Balay <balay@fastmail.fm>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The definition by the manual is:
calloc(size_t nmemb, size_t size)
Swap the arguments of calloc() calls to be the right way around.
Presumably this makes no functional difference, but better follow the
spec.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not needed anymore now that mipointer exposes an API for that,
miPointerInvalidateSprite()
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>
posix_fallocate() does an explicit rollback if it gets EINTR, and
this is a problem on slow systems because when the allocation size
is sufficiently large posix_fallocate() will always be interrupted
by the smart scheduler's SIGALRM.
Changes since v1 - big comment in the code to explain what is going on
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ian Ray <ian.ray@ge.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
If we're never painting anything in the window, we probably don't need
to map it.
v2: Drop ephyr_glamor_gles2 from hostx.c
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option
"SWCursor" is specified, sPriv == NULL. In this case we should assume that HW
cursors are not supported.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().
The (simplified) backtrace goes as follow:
(gdb) bt
#0 GetTouchEvents() at getevents.c:1892
#1 QueueTouchEvents() at getevents.c:1866
#2 xwl_touch_send_event() at xwayland-input.c:652
#5 wl_closure_invoke() from libwayland-client.so.0
#6 dispatch_event() from libwayland-client.so.0
#7 wl_display_dispatch_queue_pending() from libwayland-client.so.0
#8 xwl_read_events() at xwayland.c:483
#9 ospoll_wait() at ospoll.c:412
#10 WaitForSomething() at WaitFor.c:222
#11 Dispatch() at dispatch.c:412
#12 dix_main() at main.c:287
#13 __libc_start_main() at libc-start.c:289
#14 _start ()
The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.
Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.
Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer enter event coordinates are surface relative and we need them to
be screen relative for pScreen->SetCursorPosition().
https://bugzilla.gnome.org/show_bug.cgi?id=758283
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit c7e8d4a6ee had already unifdef
MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
9257b1252d didn't notice that.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Prior to this commit the Xorg.wrap code to detect if root rights are
necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and*
reporting more then 0 output connectors.
DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate
between old drm only cards (which need ums and thus root) and kms capable
cards.
Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs,
resulting in Xorg needlessly running as root. This commits removes the
res.count_connectors > 0 check, fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a missing ifdef needed for --disable-glamor.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Special case for the systemd-logind case in xfree86: when we're vt-switched
away and a device is plugged in, we get a paused fd from logind. Since we
can't probe the device or do anything with it, we store that device in the
xfree86 and handle it later when we vt-switch back. The device is not added to
inputInfo.devices until that time.
When the device is removed while still vt-switched away, the the config system
never notifies the DDX. It only runs through inputInfo.devices and our device
was never added to that.
When a device is plugged in, removed, and plugged in again while vt-switched
away, we have two entries in the xfree86-specific list that refer to the same
device node, both pending for addition later. On VT switch back, the first one
(the already removed one) will be added successfully, the second one (the
still plugged-in one) fails. Since the fd is correct, the device works until
it is removed again. The removed devices' config_info (i.e. the syspath)
doesn't match the actual device we addded tough (the input number increases
with each plug), it doesn't get removed, the fd remains open and we lose track
of the fd count. Plugging the device in again leads to a dead device.
Fix this by adding a call to notify the DDX to purge any remainders of devices
with the given config_info, that's the only identifiable bit we have at this
point.
https://bugs.freedesktop.org/show_bug.cgi?id=97928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes but it makes it easier to remove elements from the
middle of the list (future patch).
We don't have an init call into this file, so the list is manually
initialized.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
They're identically laid-out structs but let's use the right type to search
for our desired value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prevents the HW cursor from intermittently jumping around when the
cursor image is changed while the cursor is being moved. This is hardly
noticeable in normal operation but can be quite confusing when stepping
through these codepaths in a debugger.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes incorrect HW cursor position on PRIME slave screens.
Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to
xf86Set/MoveCursor, since the hotspot position is a property of the
cursor, not the screen.
v2:
* Squash patches 1 & 2 of the v1 series, since it's basically the same
problem
* Use the master screen's xf86CursorScreenRec::HotX/Y instead of
CursorRec::bits->x/yhot, since CursorRec::bits can be NULL (Hans de
Goede)
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
eglGetDisplay forces the implementation to guess which kind of display
it's been handed. glvnd does something different from Mesa, and in
general it's impossible for the library to get this right. Add a new
inline that gets the logic right, and works around a quirk in epoxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
As of last commit all the places in our configure.ac require version
2.3.1 (released back in 2007) or later. With the latter introducing the
1.3.0 version, as returned by drmGetLibVersion.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Presently the option guards both direct and accelerated indirect GLX. As
such when one toggles it off they end up without any acceleration.
Remove the option all together until we have the time to split/rework
things.
Cc: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The option is misleading and using it leads to disabling both direct and
accelerated indirect GLX. In such cases the xserver GLX attempts to
match DRISW (IGLX) configs with the DRI2/3 ones (direct GLX) leading to
all sorts of fun experience.
Remove the option until we get a clear split and control over direct vs
indirect GLX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Translate grabbing a pointer device with confineTo set to a window into
confining the Wayland pointer using the pointer constraints protocol.
This makes clients that depend on the pointer not going outside of the
window region, such as certain games and virtual machines viewers, to
function more properly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If there was an relative pointer motion within the same frame as an
absolute pointer motion, provide both the absolute coordinate and the
unaccelerated delta when setting the valuator mask.
If a frame contained only a relative motion, queue an absolute motion
with an unchanged position, but still pass the unaccelerated motion
event.
If the wl_seat advertised by the compositor is not new enough, assume
each relative and absolute pointer motion arrives within their own
separate frames.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Wait until wl_pointer.frame with dispatching the pointer motion event,
if wl_pointer.frame is supported by the compositor. This will later be
used to combine unaccelerated motion deltas with the absolute motion
delta.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Generating relative and absolute movement events from the same input
device is problematic, because an absolute pointer device doesn't
expect to see any relative motion events. To be able to generate
relative pointer motion events including unaccelerated deltas, create a
secondary pointer device 'xwayland-relative-pointer', and use that for
emitting relative motion events.
Signed-off-by: Krzysztof Sobiecki <sobkas@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Put device class initialization in init_[device_class](xwl_seat) and
releasing in release_[device class](xwl_seat). The purpose is to make
it easier to add more type of initialization here later, without making
the function too large.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Will be used for getting unaccelerated motion events and later for
relative motions used by a pointer warp emulator.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The way we map the touch absolute device to screen coordinates can't
work across wl_output mode and geometry events. Instead, set up
a fixed coordinate space, and transform touch events according to
the screen coordinate space as they happen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
The checks in xwayland's XYToWindow handler pretty much assumes that the
sprite is managed by the wl_pointer, which is not entirely right, given
1) The Virtual Core Pointer may be controlled from other interfaces, and
2) there may be other SpriteRecs than the VCP's.
This makes XYToWindow calls return a sprite trace with just the root
window if any of those two assumptions are broken, eg. on touch events.
So turn the check upside down, first assume that the default XYToWindow
proc behavior is right, and later cut down the spriteTrace if the
current device happens to be the pointer and is out of focus. We work
our way to the device's lastSlave here so as not to break assumption #1
above.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This change effectively reverts commit 074cf58. We were falling back from
drmModeSetCursor2() to drmModeSetCursor() whenever the first failed. This
fall-back only makes sense on pre-mid-2013 kernels which implemented the
cursor_set hook but not cursor_set2, and in this case the call to
drmModeSetCursor2() will always return -EINVAL. Specifically, a return
value of -ENXIO usually means that neither are supported.
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
[hdegoede@redhat.com: initialize ret to -EINVAL]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We get multiple udev events for actions like docking a laptop into its
station or plugging a monitor to the station. By consuming as much
events as we can, we reduce the number of output re-evalutions.
I.e. having a Lenovo X250 in a ThinkPad Ultra Dock and plugging a
monitor to the station generates 5 udev events. Or having 2 monitors
attached to the station and docking the laptop generates 7 events.
It depends on the timing how many events can consumed at once.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
[hdegoede@redhat.com: Keep goto out so that we always call RRGetInfo()]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This fix is for the following xorg.conf can work:
Section "ServerFlags"
Option "AutoAddGPU" "off"
EndSection
Section "Device"
Identifier "Amd"
Driver "ati"
BusID "PCI:1:0:0"
EndSection
Section "Device"
Identifier "Intel"
Driver "modesetting"
BusID "pci:0:2:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Intel"
GPUDevice "Amd"
EndSection
Without AutoAddGPU off, modesetting DDX will also be loaded
for GPUDevice.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The new platform bus code and the old PCI bus code overlap. Platform bus
can handle any type of device, including PCI devices, whereas the PCI code
can only handle PCI devices. Some drivers only support the old style
PCI-probe methods, but the primary device detection code is server based,
not driver based; so we might end up with a primary device which only has
a PCI bus-capable driver, but was detected as primary by the platform
code, or the other way around.
(The above paragraph was shamelessly stolen from Hans de Goede, and
customized.)
The latter case applies to QEMU's virtio-gpu-pci device: it is detected as
a BUS_PCI primary device, but we actually probe it first (with the
modesetting driver) through xf86platformProbeDev(). The
xf86IsPrimaryPlatform() function doesn't recognize the device as primary
(it bails out as soon as it sees BUS_PCI); instead, we add the device as a
secondary graphics card under "autoAddGPU". In turn, the success of this
automatic probing-as-GPU prevents xf86CallDriverProbe() from proceeding to
the PCI probing.
The result is that the server exits with no primary devices detected.
Commit cf66471353 ("xfree86: use udev to provide device enumeration for
kms devices (v10)") added "cross-bus" matching to xf86IsPrimaryPci(). Port
that now to xf86IsPrimaryPlatform(), so that we can probe virtio-gpu-pci
as a primary card in platform bus code.
Cc: Adam Jackson <ajax@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675
Signed-off-by: Kyle Guinn <elyk03@gmail.com>
[hdegoede@redhat.com: Simplify by adding 2 if conds together with &&]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
A couple of memory leaks fixes and avoiding bit shifting on an
unitialized value.
[hdegoede@redhat.com: Split out some non free fixes in separate patches]
[hdegoede@redhat.com: Don't touch ancient (and weird) os/rpcauth.c code]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Adam Jackson
Ben Crocker
Hans de Goede
Olivier Fourdan
Rui Matos
Pekka Paalanen
Timo Aaltonen
Ian Ray
Keith Packard
Alex Goins
Jon Turney
Nikhil Mahale
Michel Dänzer
Mihail Konev
Peter Hutterer
Emil Velikov
Jonas Ådahl
Krzysztof Sobiecki
Carlos Garnacho
Michael Thayer
Daniel Martin
Qiang Yu
Laszlo Ersek
Kyle Guinn
David CARLIER