- 18 Aug, 2020 1 commit
-
-
You will not find GL_ARB_* extensions in a GLES context by definition, the droid you're looking for is named GL_KHR_debug. Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
- 04 Aug, 2020 1 commit
-
-
Olivier Fourdan authored
Xwayland is just a Wayland client, no X11 screensaver should be expected to work reliably on Xwayland when running rootless because Xwayland cannot grab the input devices so it has no way to actually lock the screen managed by the Wayland compositor. Turn off the screensaver on Xwayland when running rootless by setting the screensaver timeout and interval and their default values to zero and disable the MIT-SCREEN-SAVER extension. Closes: xorg/xserver#1051 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- 31 Jul, 2020 2 commits
-
-
Avoid leaking un-initalized memory to clients by zeroing the whole pixmap on initial allocation. This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu> Reviewed-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
-
Replicate 7d2543a3 but for all types of X servers
-
- 30 Jul, 2020 1 commit
-
-
Instead of optionally return early when an event is aborted and potentially clean it up in there we can only optionally inform Present if not aborted and afterwards clean it up if required. Saves some lines of code and conditional branches. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
- 29 Jul, 2020 2 commits
-
-
Jon Turney authored
-
Jon Turney authored
Update commit ea47af87 renaming master_pixmap to primary_pixmap in struct PixmapRec.
-
- 28 Jul, 2020 1 commit
-
-
Huacai Chen authored
On a DT-base PCI platform, the sysfs path of vga device is like this: /sys/devices/platform/bus@10000000/1a000000.pci/pci0000:00/0000:00:11.0/0000:04:00.0. Then the ID_PATH from udev is platform-1a000000.pci-pci-0000:04:00.0 and the BusID will be pci-0000:04:00.0, which causes Xorg start fail. This is because config_udev_odev_setup_attribs() use strstr() to search the first "pci-" in ID_PATH. To fix this, we implement a strrstr() function and use it to search the last "pci-" in ID_PATH, which can get a correct BusID. Signed-off-by:
Huacai Chen <chenhc@lemote.com>
-
- 24 Jul, 2020 1 commit
-
-
Roman Gilg authored
For Pixmap flips to have well defined outcomes the window must be contained by the valid region if such region was specified. The valid region is inserted as an argument to the check in window mode. Setting this argument is missing in screen mode as well but we ignore it for now and only add it to window mode. It seems there are none or only very few clients actually making use of valid regions at the moment. For simplicity we therefore just check if a valid region was set by the client and in this case do never flip, independently of the window being contained by the region or not. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
- 22 Jul, 2020 5 commits
-
-
Roman Gilg authored
The function is never called from present_screen.c in contrast to the behavior in screen mode. In present_wnmd.c we can simply remove the function which does an unnecessary check of the property before setting it and directly set the property at the two locations the function was called previously. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
Roman Gilg authored
With the newly introduced separate API method for idling a presented Pixmap in window mode we can simplify the logic by allowing calls to it at any point in time. This is done by setting the flip_idler flag if the Pixmap was idled before being presented. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
Roman Gilg authored
Notifying Present about events' states was done prior with the single function present_wnmd_event_notify just like in screen mode. But it is more intelligible if at least in window mode we make use of three different functions with names that directly indicate what their purpose is: * present_wnmd_event_notify only for queued events feedback. * present_wnmd_flip_notify for when a presentation occured (flip). * present_wnmd_idle_notify for when the Pixmap of the event can be reused. This is an API-breaking change in regards to window mode. DDX written against the previous version won't work anymore. It is assumed that there only exists the XWayland DDX at the moment using the window mode such that this is not an issue for the overall ecosystem. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
Roman Gilg authored
Rename the lists release_queue to release_list and event_list to wait_list. The prior names release_queue and event_list were ambiguous: in both are event- like vblanks which can be removed from the lists in random order. In the release_queue can be flips that are already released but still wait for the sync or frame callback but normally the release comes later. In the event_list are queued events waiting for a later msc. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
Roman Gilg authored
In xwl_present_window an xwl_screen entry was declared but never actually used. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
- 21 Jul, 2020 4 commits
-
-
Alex Goins authored
Commit 1e3f9ea1 removed some NULL checks from xf86RandR12.c, on the premise that they can't be reached unless RandR has already been initialized. For threesuch calls, that's not true: xf86Crtc.c::xf86CrtcScreenInit(): if (c == config->num_crtc) { xf86RandR12SetRotations(screen, RR_Rotate_0 | RR_Rotate_90 | RR_Rotate_180 | RR_Rotate_270 | RR_Reflect_X | RR_Reflect_Y); xf86RandR12SetTransformSupport(screen, TRUE); } else { xf86RandR12SetRotations(screen, RR_Rotate_0); xf86RandR12SetTransformSupport(screen, FALSE); } xf86Crtc.c::xf86CrtcCloseScreen(): xf86RandR12CloseScreen(screen); This change adds checks back to xf86RandR12Set{Rotations,TransformSupport}() and xf86RandR12CloseScreen(), checking that xf86RandR12KeyRec has been registered. Without this, X will hit an assert that causes it to abort. Signed-off-by:
Alex Goins <agoins@nvidia.com>
-
Alex Goins authored
RRHasScanoutPixmap() is called from xf86CheckHWCursor(), regardless of whether or not RandR has been initialized. As mentioned in commit 4226c6d0, 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 4226c6d0 , fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv. Signed-off-by:
Alex Goins <agoins@nvidia.com>
-
Alex Goins authored
RRProviderAutoConfigGpuScreen() is called from outside RandR, so there is no guarantee that RandR has been initialized when it is called. As mentioned in commit 4226c6d0, 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 4226c6d0 , fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv. Signed-off-by:
Alex Goins <agoins@nvidia.com>
-
This can happen e.g. with weston's headless backend. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
-
- 20 Jul, 2020 2 commits
-
-
-
This (so-far) Linux-only API lets users create file descriptors purely in memory, without any backing file on the filesystem and the race condition which could ensue when unlink()ing it. It also allows seals to be placed on the file, ensuring to every other process that we won’t be allowed to shrink the contents, potentially causing a SIGBUS when they try reading it. This patch is best viewed with the -w option of git log -p. This is a port of this commit from Weston: wayland/weston@deae98ef Fixes #848. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
-
- 16 Jul, 2020 1 commit
-
-
Lyude Paul authored
When a slave device causes the master virtual pointer device to change device types, the device's private data pointer (device->public.devicePrivate) is also changed to match the type of the slave device. This can be a problem though, as tablet pad devices will set the device's private data pointer to their own xwl_tablet_pad struct. This can cause us to dereference the pointer as the wrong type, and result in a segfault: Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault. wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 792 va_start(ap, opcode); (gdb) bt 0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0, hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized out>) at /usr/include/wayland-client-protocol.h:4610 2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at xwayland-cursor.c:137 3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>, screen=<optimized out>, cursor=<optimized out>, x=<optimized out>, y=<optimized out>) at xwayland-cursor.c:249 4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:468 5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410 6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740, pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206 7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at mipointer.c:194 8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168 9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197 10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30, cursor=0x5610b4b35740) at events.c:938 11 0x00005610b28ec99f in WindowHasNewCursor (pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362 12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0, vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc, client=client@entry=0x5610b4b2c900) at window.c:1561 13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900) at dispatch.c:746 14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497 15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68, envp=<optimized out>) at main.c:276 16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>, argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at ../csu/libc-start.c:308 17 0x00005610b27ae96e in _start () at cursor.c:1064 Simple reproducer in gnome-shell: open up an Xwayland window, press some tablet buttons, lock and unlock the screen. Repeat if it doesn't crash the first time. So, let's fix this by registering our own device-specific private key for storing a backpointer to xwl_tablet_pad, so that all input devices have their private data pointers set to their respective xwl_seat. Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
- 14 Jul, 2020 1 commit
-
-
In 9141196d positional coordinates were added to the damage call of pixmap flips. The damage box coordinates are in screen space though and we need to convert them first to surface-relative ones by substracting the origin of the window. Signed-off-by:
Roman Gilg <subdiff@gmail.com>
-
- 12 Jul, 2020 1 commit
-
-
Michel Dänzer authored
This gives out of tree drivers a fighting chance to build against both sides of xorg/xserver!468 . Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
- 09 Jul, 2020 2 commits
-
-
Dave Airlie authored
This is an API and ABI break Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Dave Airlie authored
Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- 08 Jul, 2020 1 commit
-
-
Xwayland is usually spawned by the Wayland compositor which sets the command line options. If a command line option is not supported, Xwayland will fail to start. That somehow makes the Xwayland command line option sort of ABI, the Wayland compositor need to know if a particular option is supported by Xwayland at build time. Also, currently, Xwayland is being installed along with the rest of the common executable programs that users may run, which is sub-optimal because, well, Xwayland is not a common executable program, it's meant to be a proxy between the Wayland compositor and the legacy X11 clients which wouldn't be able to run on Wayland otherwise. Xwayland would be better installed in `libexec` but that directory is (purposedly) not in the user `PATH` and therefore the Wayland compositor may not be able to find Xwayland in that case. To solve both problems (which options are supported by Xwayland and where to look for it), add a `pkg-config` file specifically for Xwayland which gives the full path to Xwayland (`xwayland`) and which options it supports (using `pkg-config` variables). The `pkg-config` file also provides the `Version` so the build scripts can check for a particular version if necessary. Obviously, Wayland compositors are not required to use the `pkg-config` file and can continue to use whatever mechanism they deem preferable. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
- 07 Jul, 2020 4 commits
-
-
It was already declared in xwayland-screen.h, and only takes a screen parameter, no window ones. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Seems clearer. While we're at it, also drop the unused pixmap parameter. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
-
No need for the separate boolean. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
-
This couldn't have worked correctly for non-0 x1/y1. Noticed by inspection. Reviewed-by:
Simon Ser <contact@emersion.fr>
-
- 05 Jul, 2020 2 commits
-
-
Alan Coopersmith authored
Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
-
Alan Coopersmith authored
Most (but not all) of these were found by using codespell --builtin clear,rare,usage,informal,code,names but not everything reported by that was fixed. Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
-
- 03 Jul, 2020 2 commits
-
-
The way Xwayland works (like all Wayland clients), it first queries the Wayland registry, set up all relevant protocols and then initializes its own structures. That means Xwayland will get the Wayland outputs from the Wayland compositor, compute the physical size of the combined outputs and set the corresponding Xwayland screen properties accordingly. Then it creates the X11 screen using fbScreenInit() but does so by using a default DPI value of 96. That value is used to set the physical size of the X11 screen, hence overriding the value computed from the actual physical size provided by the Wayland compositor. As a result, the DPI computed by tools such as xdpyinfo will always be 96 regardless of the actual screen size and resolution. However, if the Wayland outputs get reconfigured, or new outputs added, or existing outputs removed, Xwayland will recompute and update the physical size of the screen, leading to an unexpected change of DPI. To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can be set using the standard command lime option "-dpi") and compute a physical screen size to match that DPI setting. Note that only affects legacy core protocols, X11 clients can still get the actual physical output size as reported by the Wayland compositor using the RandR protocol, which also allows for the size to be 0 if the size is unknown or meaningless. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Closes: xorg/xserver#731
-
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it returns TRUE. Without this, we're sending uninitialised values to clients. Fixes: #1040
-
- 02 Jul, 2020 1 commit
-
-
When running with a weston session without a pointer device (thus with the wl_seat not having a pointer) xwayland pointer warping and pointer confining should simply be ignored to avoid crashes. Signed-off-by:
Sjoerd Simons <sjoerd@collabora.com>
-
- 27 Jun, 2020 1 commit
-
-
Since the introduction of "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize" the fb_id isn't initialited at drmmode_xf86crtc_resize. Rotate operation of XRandR uses rotate_bo. So in this case the fb_id associated to the front_bo is not initialized at drmmode_set_mode_major. So fd_id remains 0. As every call to drmmode_xf86crtc_resize allocates a new front_bo we should destroy unconditionally the old_front_bo if operation success. So we free the allocated GBM handles. This avoids crashing xserver with a OOM in the RPI4 1Gb at 4k resolution after 3 series xrandr rotations from normal to left and vice versa reported at https://github.com/raspberrypi/firmware/issues/1345 Signed-off-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by:
Keith Packard <keithp@keithp.com> Closes: xorg/xserver#1024 Fixes: 87745321 "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize"
-
- 25 Jun, 2020 4 commits
-
-
These events aren't reachable after xwl_present_cleanup, so they're leaked if we don't free them first. This requires storing the pixmap pointer in struct xwl_present_window. Luckily, the buffer pointer isn't used for anything, so just replace that. v2: * Bump pixmap reference count in xwl_present_flip and drop it in xwl_present_free_event, fixes use-after-free in the latter due to the pixmap already being destroyed. Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
Minor cleanup, and will make the next change simpler. No functional change intended. Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
When present_wnmd_clear_window_flip is done, present_destroy_window frees struct present_window_priv, and the events in the flip queue become unreachable. So if we don't free them first, they're leaked. Also drop the call to present_wnmd_set_abort_flip, which just sets a flag in struct present_window_priv and thus can't have any observable effect after present_destroy_window. Closes: xorg/xserver#1042 Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
The comment was incorrect: Any reference held by the window (see present_wnmd_execute) is in addition to the one in struct present_vblank (see present_vblank_create). So if we don't drop the latter, the pixmap will be leaked. Reviewed-by:
Dave Airlie <airlied@redhat.com>
-