• Do we need three-and-a-half nigh-identical X =?utf-8?Q?compositor?= =?u

    From =?utf-8?B?0L3QsNCx?=@21:1/5 to All on Fri Dec 13 15:10:02 2024
    Hi!

    We seem to be shipping 3.5 standalone compositors
    (maintainers in CC):
    1. xcompmgr ‒ the upstream's effectively finished
    (we have 1.1.8, the two releases since changed nothing of substance)
    last maintainer upload 2019-07
    popcon inst=852 vote=171
    2. compton ‒ fork of fork of xcompmgr, upstream also finished
    orphaned since 2024-05
    popcon inst=1121 vote=306
    3. picom ‒ fork of compton, actually mostly alive?
    not in testing
    (FTBFS on char=uchar and missing 8-byte atomics,
    this is at least partly fixed in 12.4)
    clearly missing maintenance resources downstream
    (would definitely benefit from being team-maintained)
    popcon inst=2221 vote=879
    3.5. unagi ‒ dead outright (popped up on BOTD)
    last updated 2013
    popcon inst=43 vote=7

    unagi needs to be cut obviously
    (preferably with a failover to a modern compositor,
    but that's unlikely considering its config is unlike anything else).

    As for the other three... do we need them all?
    It's certainly overly confusing.

    xcompmgr users could be mostly-seamlessly upgraded to compton
    (AFAICT by comparing the manuals:
    xcompmgr has -s/-n (compton is always in -n mode and no flags)
    xcompmgr has -a (this is kinda like -s i think?)
    and all these do is enable "server-side compositing".
    given how the manual describes this,
    the usefulness of this seems marginal at first glance,
    so the likelihood of anyone using it likewise)
    by providing xcompmgr as exec(compton) minus -s, -n, -a;
    the interface appears otherwise equivalent.

    The compton -> picom upgrade is harder: compton has
    -m, --menu-opacity
    -C, --no-dock-shadow
    -z, --clear-shadow
    -G, --no-dnd-shadow
    -S Enable synchronous X operation (for debugging).
    --vsync VSYNC_METHOD
    --sw-opti
    turned into --vsync, --no-vsync
    --refresh-rate REFRESH_RATE
    (looks replaced with like --no-frame-pacing?)
    --alpha-step VALUE
    --dbe
    --paint-on-overlay
    --respect-prop-shadow
    --xinerama-shadow-crop
    --glx-copy-from-front
    --glx-use-copysubbuffermesa
    --glx-swap-method undefined/exchange/copy/3/4/5/6/buffer-age
    --glx-use-gpushader4
    --xrender-sync
    which picom is missing. So, idk. picom'd want to be stabler than it is anyway (be in testing consistently enough to end up in trixie at least, probably).

    Thoughts? Snark? Have I missed another standalone compositor?

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmdcPioACgkQvP0LAY0m WPFSqA//bWdg8n+bHKiasO/8AQ2LQjm3SDC4I2kL6/5okGjI5LRUkW1mBFdbr+4U zPerB+c1F5YwbNAiJxZDx+B2df1ax3gd32Z6bpKqU5gU/VJmVgjfwcssdEXOXW2R 7NM+A+0lyQEB9tfDs1EPS/IRZu7MwOwPEwCQEUvCnQc+/xrtvjfn48oMTHjukxLl g8PjZC/qvQfGV0CDffVfD6VpwY8ZYeFxaoJKKAOCuxmkO7IvbGjJ/zhLMrTOz6LM e8Q4erJsNXmfrHhZkFjEetzZA3tp5eQ40aDbxPJ4ZV4E8lRi4TnshmJW2wfDAfzD GJ0FxD1fpxJ0SE5/vl5xbyc2MXlszPc5lLbF35lnds2swgbl3NolVd0zjx5At8py iF2aH/38FwNidZMqQGN4uf7u1t0uzujuFG5ETErsvTU5Y2ixyB/i/AsXl2DvKcQS NOXbfHKTZ76yLa0Pr1u8AxeuzOVOAPGfMr2lJCUKG0HUfFuKw3L+4E0B+4jKsk7z 3w4/70Utc95fVuDCpS4pyj38Ja5B35RdW1ZaGZMPuJK0cm4rEUYBDBvg1BUNntFd 4ZE5T14DwOwePPmbAOkU5zAfaOv1sDqGPX125APuvydRzvXHIoxLLyHFRJ6g1ykT lBqAIAAOX9heIX1ygA9oPnPHYQffeZL497nqOljxKSmOFgC20R0=
    =9RYq
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)