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
  2. 19 Apr, 2022 1 commit
  3. 05 Apr, 2022 1 commit
  4. 02 Apr, 2022 9 commits
  5. 31 Mar, 2022 3 commits
  6. 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
  7. 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
  8. 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
  9. 16 Feb, 2022 1 commit
  10. 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
  11. 11 Feb, 2022 1 commit
  12. 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
  13. 06 Feb, 2022 3 commits
  14. 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
  15. 29 Jan, 2022 1 commit
  16. 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
  17. 19 Jan, 2022 1 commit
  18. 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
  19. 14 Jan, 2022 1 commit
  20. 24 Dec, 2021 1 commit
  21. 20 Dec, 2021 2 commits