- Oct 04, 2017
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Later events are sometimes added in front of the queue (e.g. if page flipping fails) so we need to check the whole queue on event. Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit c2f2b25a)
-
This provides an API wrapper around the kernel interface for queueing a vblank event, simplifying all of the callers. v2: Fix missing '|' in computing vbl.request.type v3: Remove spurious bit of next patch (thanks, Michel Dänzer) Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 677c32bc)
-
Generating strings for XKB data used a single shared static buffer, which offered several opportunities for errors. Use a ring of resizable buffers instead, to avoid problems when strings end up longer than anticipated. Reviewed-by: Michal Srb <msrb@suse.com> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Julien Cristau <jcristau@debian.org> (cherry picked from commit 94f11ca5)
-
XkbStringText escapes non-printable characters using octal numbers. Such escape sequence would be at most 5 characters long ("\0123"), so it reserves 5 bytes in the buffer. Due to char->unsigned int conversion, it would print much longer string for negative numbers. Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Julien Cristau <jcristau@debian.org> (cherry picked from commit eaf1f72e)
-
Otherwise it can belong to a non-existing client and abort X server with FatalError "client not in use", or overwrite existing segment of another existing client. Signed-off-by: Julien Cristau <jcristau@debian.org> (cherry picked from commit b95f25af)
-
Adam Jackson authored
gcc/glibc think the snprintf in dmxExecOS() might truncate. Yes, it might, and we also don't care. Just delete all this. Signed-off-by: Adam Jackson <ajax@redhat.com> Acked-by: Keith Packard <keithp@keithp.com> (cherry picked from commit d6db6681)
-
Adam Jackson authored
Modern glibc is very insistent that you care about whether write() succeeds: ../hw/dmx/input/usb-keyboard.c: In function ‘kbdUSBCtrl’: ../hw/dmx/input/usb-keyboard.c:292:9: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] write(priv->fd, &event, sizeof(event)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 17ad6e5d)
-
[ajax: Fixed test/Makefile.am as well] Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit fbdd73fa)
-
UDL (usb) devices are blacklisted because of they weird behaviour when it comes to vblank events. As EVDI uses very similar model of handling vblanks it should be treated similarly. When doing a page flip, EVDI does not wait for real vblank, but simulates it by adding constant delay. It also does not support DRM_IOCTL_WAIT_VBLANK. In contrast to UDL, EVDI uses platform devices, thus instead of 'usb' in path they all have 'platform'. It is possible to blacklist by 'platform', so without explicitly saying 'evdi', but it might be misleading when it comes to real reason for it. Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.com> (cherry picked from commit fbd80b2c)
-
Outputs may have NULL mode_output (connector) pointers if the connector disappears while the server is running. Skip these when resetting outputs with BAD link status. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 37f4e765)
-
Despite all the careful planning of the kernel, a link may become insufficient to handle the currently-set mode. At this point, the kernel should mark this particular configuration as being broken and potentially prune the mode before setting the offending connector's link-status to BAD and send the userspace a hotplug event. This may happen right after a modeset or later on. Upon receiving a hot-plug event, we iterate through the connectors to re-apply the currently-set mode on all the connectors that have a link-status property set to BAD. The kernel may be able to get the link to work by dropping to using a lower link bpp (with the same display bpp). However, the modeset may fail if the kernel has pruned the mode, so to make users aware of this problem a warning is outputed in the logs to warn about having a potentially-black display. This patch does not modify the current behaviour of always propagating the events to the randr clients. This allows desktop environments to re-probe the connectors and select a new resolution based on the new (currated) mode list if a mode disapeared. This behaviour is expected in order to pass the Display Port compliance tests. Signed-off-by: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit bcee1b76)
-
- Sep 25, 2017
-
-
./hw/xfree86/common/xf86pciBus.c: In function ‘xf86MatchDriverFromFiles’: ../hw/xfree86/common/xf86pciBus.c:1330:52: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=] snprintf(path_name, sizeof(path_name), "%s/%s", ^~~~~~~ ../hw/xfree86/common/xf86pciBus.c:1330:13: note: ‘snprintf’ output between 2 dirent->d_name is 256, so sprintf("%s/%s") into a 256 buffer gives us: and 257 bytes into a destination of size 256 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 96af794d)
-
signal-logging.c:182:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses] Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ea82ecec)
-
[Added HAVE_SYS_SYSMACROS_H guard - ajax] Signed-off-by: Nick Sarnie <commendsarnex@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 84e3b96b)
-
Adam Jackson authored
glibc would like to stop declaring major()/minor() macros in <sys/types.h> because that header gets included absolutely everywhere and unix device major/minor is perhaps usually not what's expected. Fair enough. If one includes <sys/sysmacros.h> as well then glibc knows we meant it and doesn't warn, so do that if it exists. Signed-off-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit d732c365)
-
Adam Jackson authored
The meson build gives me: ../os/utils.c: In function ‘LockServer’: ../os/utils.c:310:40: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=] snprintf(pid_str, sizeof(pid_str), "%10ld\n", (long) getpid()); ^~~~~~~~~ ../os/utils.c:310:5: note: ‘snprintf’ output between 12 and 13 bytes into a destination of size 12 snprintf(pid_str, sizeof(pid_str), "%10ld\n", (long) getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Which seems to be due to the %d part meaning that a negative number's - sign would be one wider than we're expecting. Fine, just coerce it to unsigned. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit aabf65d2)
-
glamor_compute_transform_clipped_regions() uses a temporary box32 internally which is copied back to a box16 to init the regions16, thus causing a potential overflow. If an overflow occurs, the given region is invalid and the pixmap init region will fail. Simply check that the coordinates won't overflow when copying back to the box16, avoiding a crash later down the line in glamor. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Tested-by: Fabrice Bellet <fabrice@bellet.info> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 9869dcb3)
-
COMPOSITE_REGION() can pass NULL as a source picture, make sure we handle that nicely in both glamor_composite_clipped_region() and glamor_composite_choose_shader(). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit bd353e9b)
-
Xwayland would crash in some circumstances while trying to issue a pointer locking when the cursor is hidden when there is no seat focus window set. The crash signature looks like: #0 zwp_pointer_constraints_v1_lock_pointer () #1 xwl_pointer_warp_emulator_lock () at xwayland-input.c:2584 #2 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2756 #3 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2765 #4 xwl_seat_cursor_visibility_changed () at xwayland-input.c:2768 #5 xwl_set_cursor () at xwayland-cursor.c:245 #6 miPointerUpdateSprite () at mipointer.c:468 #7 miPointerDisplayCursor () at mipointer.c:206 #8 CursorDisplayCursor () at cursor.c:150 #9 AnimCurDisplayCursor () at animcur.c:220 #10 ChangeToCursor () at events.c:936 #11 ActivatePointerGrab () at events.c:1542 #12 GrabDevice () at events.c:5120 #13 ProcGrabPointer () at events.c:4908 #14 Dispatch () at dispatch.c:478 #15 dix_main () at main.c:276 xwl_pointer_warp_emulator_lock() tries to use the surface from the xwl_seat->focus_window leading to a NULL pointer dereference when that value is NULL. Check that xwl_seat->focus_window is not NULL earlier in the stack in xwl_seat_maybe_lock_on_hidden_cursor() and return early if not the case to avoid the crash. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=102474 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit cdd0352b)
-
Otherwise a client can send any value of num_barriers and cause reading or swapping of values on heap behind the receive buffer. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 211e05ac)
-
Copied from Mesa with no modifications. Gives us Coffee Lake and Cannon Lake PCI IDs. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit abb031e7)
-
Adam Jackson authored
... where it is named src/egl/wayland/wayland-drm/wayland-drm.xml and has its requests sorted by protocol version number, avoiding a warning from wayland-scanner. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit 04511a04)
-
The memcmp didn't catch when e.g. only the filter changed. Tested by alternately running xrandr --output DVI-I-0 --scale-from 3840x2160 --filter bilinear xrandr --output DVI-I-0 --scale-from 3840x2160 --filter nearest Reviewed-by: Aaron Plattner <aplattner@nvidia.com> (cherry picked from commit 4212c884)
-
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> (cherry picked from commit 091af80b)
-
The SProcXSendExtensionEvent must not attempt to swap GenericEvent because it is assuming that the event has fixed size and gives the swapping function xEvent-sized buffer. A GenericEvent would be later rejected by ProcXSendExtensionEvent anyway. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ba336b24)
-
The requirement is that events have type in range EXTENSION_EVENT_BASE..lastEvent, but it was tested only for first event of all. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 8caed4df)
-
The SendEvent request holds xEvent which is exactly 32 bytes long, no more, no less. Both ProcSendEvent and SProcSendEvent verify that the received data exactly match the request size. However nothing stops the client from passing in event with xEvent::type = GenericEvent and any value of xGenericEvent::length. In the case of ProcSendEvent, the event will be eventually passed to WriteEventsToClient which will see that it is Generic event and copy the arbitrary length from the receive buffer (and possibly past it) and send it to the other client. This allows clients to copy unitialized heap memory out of X server or to crash it. In case of SProcSendEvent, it will attempt to swap the incoming event by calling a swapping function from the EventSwapVector array. The swapped event is written to target buffer, which in this case is local xEvent variable. The xEvent variable is 32 bytes long, but the swapping functions for GenericEvents expect that the target buffer has size matching the size of the source GenericEvent. This allows clients to cause stack buffer overflows. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 215f8949)
-
Make sure that the xEvent eventT is initialized with zeros, the same way as in SProcSendEvent. Some event swapping functions do not overwrite all 32 bytes of xEvent structure, for example XSecurityAuthorizationRevoked. Two cooperating clients, one swapped and the other not, can send XSecurityAuthorizationRevoked event to each other to retrieve old stack data from X server. This can be potentialy misused to go around ASLR or stack-protector. Signed-off-by: Michal Srb <msrb@suse.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 05442de9)
-
The previous values happened to work in basic cases, but not in general if the destination is a subwindow or has a border. Fixes crash with xli, which moves a large subwindow inside a smaller parent window for scrolling. No regressions with xterm, x11perf -copyplane or the xscreensaver phosphor hack. Bug: https://bugs.debian.org/857983 Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit ffda82ed)
-
Adam Jackson authored
The client could have said anything here, and if what they said doesn't actually name an atom NameForAtom() will return NULL, and strcmp() will be unhappy about that. Signed-off-by: Adam Jackson <ajax@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 d4995a39)
-
Just like we do with XWarpPointer's. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 95febc42)
-
In the typical pattern in games of "hide cursor, grab with a confineTo, warp constantly the pointer to the middle of the window" the last warping step is actually rather optional. Some games may choose to just set up a grab with confineTo argument, and trust that they'll get correct relative X/Y axis values despite the hidden cursor hitting the confinement window edge. To cater for these cases, lock the pointer whenever there is a pointer confinement and the cursor is hidden. This ensures the pointer position is in sync with the compositor's when it's next shown again, and more importantly resorts to the relative pointer for event delivery. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ca17f3e9)
-
This fixes grabs on InputOnly windows whose parent is the root window failing with GrabNotViewable. This is due to window->borderSize/windowSize being computed as clipped by its parent, resulting in a null region. Setting up the right size on the root window makes the InputOnly size correct too, so the GrabNotViewable paths aren't hit anymore. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 513e3bd3)
-
Of sorts, actually make it confine to the pointer focus, as the InputOnly window is entirely invisible to xwayland accounting, we don't have a xwl_window for it. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit fafdb0cc)
-
Of sorts, as we can't honor pointer warping across the whole root window coordinates, peek the pointer focus in these cases. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit c217fcb4)
-
Fixes subtle breakage which could sometimes trigger after a server reset with multiple screens using glamor: Screen A enters glamor_close_screen last and calls various cleanup functions, which at some point call glamor_make_current to make sure screen A's GL context is current. This sets lastGLContext to screen A's &glamor_priv->ctx. Finally, glamor_close_screen calls glamor_release_screen_priv, which calls free(glamor_priv). Later, screen B enters glamor_init, which allocates a new glamor_priv. With bad luck, this can return the same pointer which was previously used for screen A's glamor_priv. So when screen B's glamor_init calls glamor_make_current, lastGLContext == &glamor_priv->ctx, so MakeCurrent isn't called for screen B's GL context, and the following OpenGL API calls triggered by glamor_init mess up screen A's GL context. The observed end result of this was a crash in glamor_get_vbo_space because glamor_priv->vbo didn't match the GL context, though there might be other possible outcomes. Assigning the actual GL context pointer to lastGLContext prevents this by preventing the false negative test in glamor_make_current. Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 7c88977d)
-
When running an Xwayland server from the command line, we end up resetting the server every time all of the clients connected to the server leave. This would be fine, except that xwayland makes the mistake of unconditionally calling LoadExtensionList(). This causes us to setup the glxExtension twice in a row which means that when we lose our last client on the second server generation, we end up trying to call the glx destructors twice in a row resulting in a segfault: (EE) (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x70845bf] (EE) 2: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32897d) [0x1196e5bd] (EE) 3: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x328a45) [0x1196e745] (EE) 4: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32665f) [0x11969f7f] (EE) 5: Xwayland (__glXDRIscreenDestroy+0x30) [0x54686e] (EE) 6: Xwayland (glxCloseScreen+0x3f) [0x5473db] (EE) 7: Xwayland (glxCloseScreen+0x53) [0x5473ef] (EE) 8: Xwayland (dix_main+0x7b6) [0x44c8c9] (EE) 9: Xwayland (main+0x28) [0x61c503] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x72b1401] (EE) 11: Xwayland (_start+0x2a) [0x4208fa] (EE) 12: ? (?+0x2a) [0x2a] (EE) (EE) Segmentation fault at address 0x18 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Easy reproduction recipe: - Start an Xwayland session with the default settings - Open a window - Close that window - Open another window - Close that window - Total annihilation occurs Signed-off-by: Lyude <lyude@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 4f29366f)
-
Commit aa6717ce switched xf86WaitForInput from using select(2) to using poll(2). Before this change, the timeout was interpreted as being in microseconds; afterwards it is fed directly to xorg_poll which interprets it as being in milliseconds. This results in the function potentially blocking 1000x longer than intended. This commit scales down the timeout argument before passing it to xorg_poll, being careful to ensure the result is not rounded down due to integer division. 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> (cherry picked from commit 2fbf62b2)
-
Delay removing the client from these two queues until all potential I/O has completed in case we mark the client as ready for reading or with pending output during the close operation. Bugzilla: https://bugs.freedesktop.org/100957 Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Nick Sarnie <commendsarnex@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit d9e23ea4)
-