Skip to content
GitLab
Switch branch/tag
  1. 20 Apr, 2022 3 commits
    • Olivier Fourdan's avatar
      xwayland/output: Set the "RANDR Emulation" property · 7b7170ec
      Olivier Fourdan authored 
      

Xwayland does not change the actual XRANDR setup for real, it just
emulates the resolution changes using viewports in Wayland.

With a single output, if an X11 applications tries to change the CRTC
back to the native mode, RRCrtcSet() will simply ignore the request as
no actual change is induced by this.

Set the property "RANDR Emulation" on all Xwayland outputs to make sure
the optimizations in RRCrtcSet() get skipped and Xwayland can receive
and act upon the client request.

Also make sure we do not allow that property to be changed by X11
clients.

v2: Prevent X11 clients from changing the property value
    (Pekka Paalanen <pekka.paalanen@collabora.com>)
Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
Closes: #1305
      7b7170ec
    • Olivier Fourdan's avatar
      randr: Add "RANDR Emulation" property · 0904421f
      Olivier Fourdan authored 
      

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's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      0904421f
    • Olivier Fourdan's avatar
      randr: No need to check RRGetOutputProperty() twice · 97260384
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed 
      

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's avatarOlivier Fourdan <ofourdan@redhat.com>
Fixes: df8e8693

 - randr: Add ability to turn PRIME sync off
Reviewed-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
Tested-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      97260384
  3. 19 Apr, 2022 1 commit
  5. 05 Apr, 2022 1 commit
  7. 02 Apr, 2022 9 commits
  9. 31 Mar, 2022 3 commits
  11. 17 Mar, 2022 1 commit
    • Michel Dänzer's avatar
      xwayland: Always hook up frame_callback_list in xwl_present_queue_vblank · 9e5a3796
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed 
      Even if there's no pending frame callback yet.

Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.

Doing this requires some adjustments elsewhere:

1. xwl_present_reset_timer needs to check for a pending frame callback
   as well.
2. xwl_window_create_frame_callback needs to call
   xwl_present_reset_timer for all child windows hooked up to
   frame_callback_list, to make sure the timer length takes the pending
   frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
   before calling xwl_window_create_frame_callback, for 2. to work.

Closes: xorg/xserver#1309
Fixes: 9b31358c

 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      9e5a3796
  13. 15 Mar, 2022 2 commits
    • Michel Dänzer's avatar
      xwayland: Clear timer_armed in xwl_present_unrealize_window · 102764b6
      Michel Dänzer authored and Olivier Fourdan's avatar Olivier Fourdan committed 
      Without this, xwl_present_reset_timer would call
xwl_present_timer_callback if the timer was originally armed over a
second ago. xwl_present_timer_callback would call xwl_present_msc_bump,
which could end up hooking up the window to
xwl_window->frame_callback_list again. This would lead to use-after-free
in xwl_present_cleanup:

  Invalid write of size 8
    at 0x42B65C: __xorg_list_del (list.h:183)
    by 0x42B693: xorg_list_del (list.h:204)
    by 0x42C041: xwl_present_cleanup (xwayland-present.c:354)
    by 0x423669: xwl_destroy_window (xwayland-window.c:770)
    by 0x4FDDC5: compDestroyWindow (compwindow.c:620)
    by 0x5233FB: damageDestroyWindow (damage.c:1590)
    by 0x501C5F: DbeDestroyWindow (dbe.c:1326)
    by 0x4EF35B: FreeWindowResources (window.c:1018)
    by 0x4EF687: DeleteWindow (window.c:1086)
    by 0x4E24B3: doFreeResource (resource.c:885)
    by 0x4E2ED7: FreeClientResources (resource.c:1151)
    by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
  Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
    at 0x48470E4: free (vg_replace_malloc.c:872)
    by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
    by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
    by 0x4F3F5C: UnrealizeTree (window.c:2805)
    by 0x4F424B: UnmapWindow (window.c:2863)
    by 0x4EF58C: DeleteWindow (window.c:1075)
    by 0x4E24B3: doFreeResource (resource.c:885)
    by 0x4E2ED7: FreeClientResources (resource.c:1151)
    by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
    by 0x5E27EE: ClientReady (connection.c:599)
    by 0x5E6CB7: ospoll_wait (ospoll.c:657)
    by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
  Block was alloc'd at
    at 0x4849464: calloc (vg_replace_malloc.c:1328)
    by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
    by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
    by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
    by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
    by 0x4EDB3F: TraverseTree (window.c:441)
    by 0x4FC851: compSetPixmap (compwindow.c:151)
    by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
    by 0x4FC938: compCheckRedirect (compwindow.c:174)
    by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
    by 0x4F36EC: RealizeTree (window.c:2606)
    by 0x4F39F5: MapWindow (window.c:2683)

Fixes: 288ec0e0

 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      102764b6
    • Olivier Fourdan's avatar
      xwayland/present: Fix use-after-free in xwl_unrealize_window() · 42113ab2
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed 
      

When a window is unrealized, Xwayland would destroy the Wayland surface
prior to unrealizing the present window.

xwl_present_flip() will then do a wl_surface_commit() of that surface,
hence causing a use-after-free:

 Invalid read of size 8
    at 0x49F7FD4: wl_proxy_marshal_array_flags (wayland-client.c:852)
    by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
    by 0x42B877: wl_surface_commit (wayland-client-protocol.h:3914)
    by 0x42CAA7: xwl_present_flip (xwayland-present.c:717)
    by 0x42CD0E: xwl_present_execute (xwayland-present.c:783)
    by 0x42C26D: xwl_present_msc_bump (xwayland-present.c:416)
    by 0x42C2D1: xwl_present_timer_callback (xwayland-present.c:433)
    by 0x42BAC4: xwl_present_reset_timer (xwayland-present.c:149)
    by 0x42D1F8: xwl_present_unrealize_window (xwayland-present.c:945)
    by 0x4230E2: xwl_unrealize_window (xwayland-window.c:616)
    by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
    by 0x4F3F5C: UnrealizeTree (window.c:2805)
  Address 0x1390b8d8 is 24 bytes inside a block of size 80 free'd
    at 0x48470E4: free (vg_replace_malloc.c:872)
    by 0x49F8029: wl_proxy_destroy_caller_locks (wayland-client.c:523)
    by 0x49F8029: wl_proxy_marshal_array_flags (wayland-client.c:861)
    by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
    by 0x421984: wl_surface_destroy (wayland-client-protocol.h:3672)
    by 0x423052: xwl_unrealize_window (xwayland-window.c:599)
    by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
    by 0x4F3F5C: UnrealizeTree (window.c:2805)
    by 0x4F424B: UnmapWindow (window.c:2863)
    by 0x4EF58C: DeleteWindow (window.c:1075)
    by 0x4E24B3: doFreeResource (resource.c:885)
    by 0x4E2ED7: FreeClientResources (resource.c:1151)
    by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
  Block was alloc'd at
    at 0x4849464: calloc (vg_replace_malloc.c:1328)
    by 0x49F7F29: zalloc (wayland-private.h:233)
    by 0x49F7F29: proxy_create (wayland-client.c:422)
    by 0x49F7F29: create_outgoing_proxy (wayland-client.c:664)
    by 0x49F7F29: wl_proxy_marshal_array_flags (wayland-client.c:831)
    by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
    by 0x4218CA: wl_compositor_create_surface (wayland-client-protocol.h:1291)
    by 0x422A0D: ensure_surface_for_window (xwayland-window.c:445)
    by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
    by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
    by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
    by 0x4EDB3F: TraverseTree (window.c:441)
    by 0x4FC851: compSetPixmap (compwindow.c:151)
    by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
    by 0x4FC938: compCheckRedirect (compwindow.c:174)

To avoid that, call xwl_present_unrealize_window() before destroying the
Wayland surface.
Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      42113ab2
  15. 08 Mar, 2022 1 commit
    • Olivier Fourdan's avatar
      Xwayland: Do not map the COW by default when rootless · 47d33174
      Olivier Fourdan authored 
      The composite overlay window (COW) can be queried from any X11 client,
not just the X11 compositing manager.

If a client tries to get the composite overlay window, the Xserver will
map the window and block all pointer events (the window being mapped and
on top of the stack).

To avoid that issue, unset the "mapped" state of the composite overlay
window once realized when Xwayland is running rootless.

Note: All Xservers are actually affected by this issue, but with most
regular X servers, the compositing manager will take care of dealing
with the composite overlay window, and an X11 client using
GetOverlayWindow() won't break pointer events for all X11 clients.
Wayland compositors however usually run Xwayland rootless and have no
use for the COW.

v2: Avoid registering damage for the COW (Michel)
v3: Remove the "mapped" test to avoid calling register_damage() if the
    COW is not mapped (Michel)

Closes: xorg/xserver#1314

Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      47d33174
  17. 16 Feb, 2022 1 commit
  19. 12 Feb, 2022 1 commit
    • Povilas Kanapickas's avatar
      dix: Don't send touch end to clients that do async grab without touches · 43e934a1
      Povilas Kanapickas authored 
      GTK3 menu widget creates a selection for touch and other events and
after receiving touch events creates an async grab that excludes touch
events. Unfortunately it relies on X server not sending the touch end
event in order to function properly. Sending touch end event will cause
it to think that the initiating touch ended and when it actually ends,
the ButtonRelease event will make it think that the menu should be
closed. As a result, the menu will be open only for the duration of the
touch making it useless.

This commit reverts f682e056.

Fixes: xorg/xserver#1255

Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
      43e934a1
  21. 11 Feb, 2022 1 commit
  23. 09 Feb, 2022 2 commits
    • Povilas Kanapickas's avatar
      dix: Fix use after free in input device shutdown · 1801fe0a
      Povilas Kanapickas authored 
      This fixes access to freed heap memory via dev->master. E.g. when
running BarrierNotify.ReceivesNotifyEvents/7 test from
xorg-integration-tests:

==24736==ERROR: AddressSanitizer: heap-use-after-free on address
0x619000065020 at pc 0x55c450e2b9cf bp 0x7fffc532fd20 sp 0x7fffc532fd10
READ of size 4 at 0x619000065020 thread T0
    #0 0x55c450e2b9ce in GetMaster ../../../dix/devices.c:2722
    #1 0x55c450e9d035 in IsFloating ../../../dix/events.c:346
    #2 0x55c4513209c6 in GetDeviceUse ../../../Xi/xiquerydevice.c:525
../../../Xi/xichangehierarchy.c:95
    #4 0x55c450e3455c in RemoveDevice ../../../dix/devices.c:1204
../../../hw/xfree86/common/xf86Xinput.c:1142
    #6 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
    #7 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
    #8 0x55c450e837ef in dix_main ../../../dix/main.c:302
    #9 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)
    #11 0x55c450d0113d in _start (/usr/lib/xorg/Xorg+0x117713d)

0x619000065020 is located 160 bytes inside of 912-byte region
[0x619000064f80,0x619000065310)
freed by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
    #1 0x55c450e19f1c in CloseDevice ../../../dix/devices.c:1014
    #2 0x55c450e343a4 in RemoveDevice ../../../dix/devices.c:1186
../../../hw/xfree86/common/xf86Xinput.c:1142
    #4 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
    #5 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
    #6 0x55c450e837ef in dix_main ../../../dix/main.c:302
    #7 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)

previously allocated by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
    #1 0x55c450e1c57b in AddInputDevice ../../../dix/devices.c:259
    #2 0x55c450e34840 in AllocDevicePair ../../../dix/devices.c:2755
    #3 0x55c45130318f in add_master ../../../Xi/xichangehierarchy.c:152
../../../Xi/xichangehierarchy.c:465
    #5 0x55c4512cb9f5 in ProcIDispatch ../../../Xi/extinit.c:390
    #6 0x55c450e6a92b in Dispatch ../../../dix/dispatch.c:551
    #7 0x55c450e834b7 in dix_main ../../../dix/main.c:272
    #8

 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)

The problem is caused by dev->master being not reset when disabling the
device, which then causes dangling pointer when the master device itself
is being deleted when exiting whole server.

Note that RecalculateMasterButtons() requires dev->master to be still
valid, so we can reset it only at the end of function.
Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
      1801fe0a
    • Povilas Kanapickas's avatar
      dix: Correctly save replayed event into GrabInfoRec · 6ef5c057
      Povilas Kanapickas authored 
      When processing events we operate on InternalEvent pointers. They may
actually refer to a an instance of DeviceEvent, GestureEvent or any
other event that comprises the InternalEvent union. This works well in
practice because we always look into event type before doing anything,
except in the case of copying the event.

*dst_event = *src_event would copy whole InternalEvent event and would
cause out of bounds read in case the pointed to event was not
InternalEvent but e.g. DeviceEvent.

This regression has been introduced in
23a8b62d.

Fixes #1261

Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
      6ef5c057
  25. 06 Feb, 2022 3 commits
  27. 03 Feb, 2022 3 commits
    • nerdopolis's avatar
      xephyr: Don't check for SeatId anymore · 4c03b67d
      nerdopolis authored and n3rdopolis's avatar n3rdopolis committed 
      After a change for the xserver to automatically determine the seat
based on the XDG_SEAT variable, xephyr stopped working. This was
because of an old feature where xephyr used to handle evdev
directly. This was dropped some time ago, and now this check is
not needed
      4c03b67d
    • Samuel Thibault's avatar
      xkb: fix XkbSetMap when changing a keysym without changing a keytype · 0217cc6e
      Samuel Thibault authored and Povilas Kanapickas's avatar Povilas Kanapickas committed 
      As the comment says:

"symsPerKey/mapWidths must be filled regardless of client-side flags"

so we always have to call CheckKeyTypes which will notably fill mapWidths
and nTypes. That is needed for CheckKeySyms to work since it checks the
width. Without it, any request with XkbKeySymsMask but not
XkbKeyTypesMask will fail because of the missing width information, for
instance this:

  XkbDescPtr xkb;
  if (!(xkb = XkbGetMap (dpy, XkbKeyTypesMask|XkbKeySymsMask, XkbUseCoreKbd))) {
    fprintf (stderr, "ERROR getting map\n");
    exit(1);
  }
  XFlush (dpy);
  XSync (dpy, False);

  XkbMapChangesRec changes = { .changed = 0 };
  int oneGroupType[XkbNumKbdGroups] = { XkbOneLevelIndex };

  if (XkbChangeTypesOfKey(xkb, keycode, 1, XkbGroup1Mask, oneGroupType, &changes)) {
    fprintf(stderr, "ERROR changing type of key\n");
    exit(1);
  }
  XkbKeySymEntry(xkb,keycode,0,0) = keysym;

  if (!XkbChangeMap(dpy,xkb,&changes)) {
    fprintf(stderr, "ERROR changing map\n");
    exit(1);
  }

  XkbFreeKeyboard (xkb, 0, TRUE);
  XFlush (dpy);
  XSync (dpy, False);

This had being going under the radar since about ever until commit
de940e06

 ("xkb: fix key type index check
in _XkbSetMapChecks") fixed checking the values of kt_index, which was
previously erroneously ignoring errors and ignoring all other checks, just
because nTypes was not set, precisely because CheckKeyTypes was not called.

Note: yes, CheckKeyTypes is meant to be callable without XkbKeyTypesMask, it
does properly check for that and just fills nTypes and mapWidths in that
case.
Signed-off-by: Samuel Thibault's avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      0217cc6e
    • tholin .'s avatar
      dix: Hold input lock for AttachDevice() · dc7cb454
      tholin . authored and Povilas Kanapickas's avatar Povilas Kanapickas committed 
      Fix the following race:

Possible data race during read of size 8 at 0xA112510 by thread #6
Locks held: 1, at address 0x366B40
   at 0x14C8B9: GetMaster (devices.c:2691)
   by 0x15CFC5: IsFloating (events.c:346)
   by 0x2B9554: miPointerGetScreen (mipointer.c:527)
   by 0x1A5136: xf86PostButtonEventM (xf86Xinput.c:1379)
   by 0x1A52BD: xf86PostButtonEvent (xf86Xinput.c:1345)
   by 0x485F45B: EvdevProcessEvent (in /usr/lib64/xorg/modules/input/evdev_drv.so)
   by 0x485FDAC: EvdevReadInput (in /usr/lib64/xorg/modules/input/evdev_drv.so)
   by 0x195427: xf86ReadInput (xf86Events.c:247)
   by 0x2CC113: InputReady (inputthread.c:180)
   by 0x2CE4EA: ospoll_wait (ospoll.c:657)
   by 0x2CC077: InputThreadDoWork (inputthread.c:369)
   by 0x484A336: mythread_wrapper (hg_intercepts.c:406)

This conflicts with a previous write of size 8 by thread #1
Locks held: none
   at 0x14D2C6: AttachDevice (devices.c:2609)
   by 0x15CF85: ReattachToOldMaster (events.c:1457)
   by 0x1647DD: DeactivateKeyboardGrab (events.c:1700)
   by 0x25D7F1: ProcXIUngrabDevice (xigrabdev.c:169)
   by 0x2552AD: ProcIDispatch (extinit.c:398)
   by 0x155291: Dispatch (dispatch.c:479)
   by 0x158CBA: dix_main (main.c:276)
   by 0x143A3D: main (stubmain.c:34)
 Address 0xa112510 is 336 bytes inside a block of size 904 alloc'd
   at 0x4846571: calloc (vg_replace_malloc.c:1328)
   by 0x14A0B3: AddInputDevice (devices.c:260)
   by 0x1A31A0: xf86ActivateDevice (xf86Xinput.c:365)
   by 0x1A4549: xf86NewInputDevice (xf86Xinput.c:948)
   by 0x1A4B44: NewInputDeviceRequest (xf86Xinput.c:1090)
   by 0x1B81FE: device_added (udev.c:282)
   by 0x1B8516: config_udev_init (udev.c:439)
   by 0x1B7091: config_init (config.c:50)
   by 0x197970: InitInput (xf86Init.c:814)
   by 0x158C6B: dix_main (main.c:250)
   by 0x143A3D: main (stubmain.c:34)
 Block was alloc'd by thread #1

The steps to trigger the race are:
1. Main thread does cleanup at mipointer.c:360 setting the slave device's
   miPointerPtr to null.
2. Input thread use MIPOINTER in mipointer.c and get the slave's
   miPointerPtr = null.
3. Main thread updates dev->master at devices.c:2609.
4. MIPOINTER would now return the master's miPointerPtr but the input
   thread already got the slave's miPointerPtr in step 2 and segfaults by
   null ptr deref.

Closes: #1260

Signed-off-by: tholin .'s avatarThomas Lindroth <thomas.lindroth@gmail.com>
      dc7cb454
  29. 29 Jan, 2022 1 commit
  31. 25 Jan, 2022 1 commit
    • Olivier Fourdan's avatar
      render: Fix build with gcc 12 · c6b0dcb8
      Olivier Fourdan authored 
      The xserver fails to compile with the latest gcc 12:

 render/picture.c: In function ‘CreateSolidPicture’:
 render/picture.c:874:26: error: array subscript ‘union _SourcePict[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
  874 |     pPicture->pSourcePict->type = SourcePictTypeSolidFill;
      |                          ^~
 render/picture.c:868:45: note: object of size 16 allocated by ‘malloc’
  868 |     pPicture->pSourcePict = (SourcePictPtr) malloc(sizeof(PictSolidFill));
      |                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 render/picture.c: In function ‘CreateLinearGradientPicture’:
 render/picture.c:906:26: error: array subscript ‘union _SourcePict[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Werror=array-bounds]
  906 |     pPicture->pSourcePict->linear.type = SourcePictTypeLinear;
      |                          ^~
 render/picture.c:899:45: note: object of size 3...
      c6b0dcb8
  33. 19 Jan, 2022 1 commit
  35. 18 Jan, 2022 1 commit
    • Olivier Fourdan's avatar
      xwayland: Raise the FD limit to the max · d1f26c3e
      Olivier Fourdan authored 
      

Xwayland may open a fair amount of file descriptors for passing Wayland
buffers, even more so when using the `wl_shm` either for the pointer
cursors or for when GLAMOR is not usable.

As a result, Xwayland may hit the (soft) limit of file descriptors
leading to a Wayland protocol error and the termination of Xwayland.

To mitigate that risk, raise the limit to the maximum (hard) limit of
file descriptors (unless of course the limit was set explicitly from the
command line with "-lf").

Note that for completeness, the Wayland compositor may have to do the
same, otherwise the limit might get reached on the compositor side as
well.
Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
Suggested-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
Closes: #1283
      d1f26c3e
  37. 14 Jan, 2022 1 commit
  39. 24 Dec, 2021 1 commit
  41. 20 Dec, 2021 2 commits