Commit graph

79 commits

Author SHA1 Message Date
GoodbyeNJN
2f57480d21 fix: correct popup detection logic to handle optional has_skip_taskbar value 2026-01-29 14:12:22 -05:00
GoodbyeNJN
0e93461aa6 feat: add support for combo window type in XState 2026-01-29 14:12:22 -05:00
GoranKovac
3af3e3ab78
Remove skip_taskbar check (#355)
Current wine versions (with yabridge) do not provide SKIP_TASKBAR atom
so current implementation does not work at all for yabridge.
Reason SKIP_TASKBAR check was introduced because there was a edge case
with PixelComposer which spawned as popup instead of top level window.

That app spawns now normally as toplevel with both old and current wine
versions so removing the SKIP_TASKBAR check makes yabridge popups work
for any wine version.

Note:
After extensive testing wine-staging and non staging verisons they
report atoms very differenly:
wine-staging 9.21 reports all atoms in NET_WM_STATE while non stage and
anything above that report only single atom there or non at all
2026-01-24 13:26:52 -05:00
Shawn Wallace
64c70be855 cargo fmt 2026-01-18 14:46:11 -05:00
Shawn Wallace
1979beaa39 Update to Rust 2024
Bumps MSRV to 1.85.
2026-01-18 14:46:11 -05:00
GoranKovac
645ca1125b
Detect WM_HINTS popup (yabridge popups fix) (#328)
* Detect WM_HINTS popup (yabridge popups fix)

Many windows popups have:

WM_HINTS(WM_HINTS) Client accepts input or input focus: False

Which is a good indicator window SHOULD be a popup.

This is true for example on yabridge plugins and some other apps.
However toplevel windows have this property True. In order to
differentiate them we check if there are no decorations on the window
(client) and this property is False.
Its applied ONLY to _NET_WM_WINDOW_TYPE_NORMAL windows since its most
generic one that comes up.

This was tested across many apps: Reaper, Ardour, Godot, MaterialMaker,
PixelOver, PixelComposer, Steam, Steam games (both windowed and
fullscreen), Fusion 9, Unity and others I have.

There are no regression seen in any of tested apps and fixes yabridge
popups.
Additionally check if MOTIF has functions that should not be in popup
Combine wmhint popup check with skip_taskbar.
wmhint is only considered to be a popup if application has skip_taskbar
atom.
Fixed edgecases so far:
BattleNet spawning as popupp
PixelComposer spawning as popup
2026-01-18 11:31:17 -05:00
Ivan Molodetskikh
72245e108f Advertise _NET_WM_MOVERESIZE
Makes GTK 4 use compositor-side move and resize.
2026-01-10 23:48:35 -05:00
En-En
bc47ef5950 deps: bump xcb to 1.7.0
Notably, `xcb` 1.7.0 made `XidNew::new` no longer unsafe, so remove all
of the unsafe blocks wrapping `XidNew::new` calls. Most of these were
for creating fake windows in the unit tests, but a few were in `xstate`.
2026-01-08 23:29:13 -05:00
GoranKovac
bf738fffbb
Detecting if UTILITY is popup (#323)
Ardour uses UTILITY atom all over the place for toplevel windows:
Plugins, Dialogs etc
However it does not provide any MOTIF_HINTS at all.

WeChat however uses them for popups and also provides MOTIF_HINTS with
flags 0x2 indicating that only decorations are active. MaterialMaker
also follows what WeChat is doing for right click menus.

This fix assigns UTILITY as popup ONLY if MOTIF_HINTS are provided and
functions are not active.

Couple of apps like Godot mark their windows
(_NET_WM_WINDOW_TYPE_UTILITY) with override_redirect which makes them
popup by default. Potentionally is_popup can be overriden in case MOTIF
functions exists with so no_function_motif would be false.

This fix prefers override_redirect in case that scenario comes up.

Closes #294
2025-12-21 19:30:50 -05:00
GoranKovac
6abdbc81a2 Update WM_STATE on window map/unmap
Some wine apps expect WM_STATE to be updated when mapping/unmapping
windows. Unless handled properly wine app would timeout while waiting
for update state

Fixes #302
2025-12-08 08:52:05 -05:00
Shawn Wallace
e719ce746a xstate: mark _NET_WM_WINDOW_TYPE_UTILITY windows as popups
Fixes #277
2025-11-30 22:36:20 -05:00
En-En
273ce6aa5d docs: better explain write_to reasoning 2025-11-09 22:55:32 -05:00
En-En
45f2305f61 refactor: change select to poll in write_pipe
Not sure why I could not get `poll` to work in the first place.
2025-11-09 22:55:32 -05:00
En-En
0162ac31ff fix: rewrite write_all for O_NONBLOCK pipe support
`wl_clip_persist` hands satellite a `WritePipe` with the `O_NONBLOCK`
flag, which prevented more than 64 KiB (the Linux pipe capacity since
2.6.11) of selection data to be transferred. Since my research concluded
having `O_NONBLOCK` on Wayland's pipe transfer ends was probably valid,
I implemented basic handling for such a scenario.

I previously considered just using `fcntl` to remove the `O_NONBLOCK`
flag, but decided that was way too hacky, as it would not resolve the
underlying problem (which could easily be triggered by the receiving
program resetting `O_NONBLOCK` during the `write_all`.
2025-11-09 22:55:32 -05:00
En-En
59dc560182 fix: queue new selections instead of juggling them
The previous method of converting X selections had some flaws, including
one where XWayland would fail to send the necessary PropertyNotify
events if multiple INCR requests were sent to the same selection at
once. By using `write_to` to create a FIFO queue and `next_conversion`
to advance the queue, we can guarantee only one request is being
converted at a time, working around this issue.
2025-11-09 22:55:32 -05:00
En-En
114d48e2e1 fix: uniquely define property separate from target
Both PRIMARY and CLIPBOARD were using the same target atoms for their
property. When both are simultaneously requested (the behavior of
`wl-clip-persist --clipboard both`), the first would delete the property
the second was prepared to write data to, resulting in getting the
GetProperty reply containing the failure data.

This commit distinguishes `target` as the atom of a mime type contained
within `TARGETS`, and `property` as the atom which contains both data of
`target` and which selection requested it.
2025-11-09 22:55:32 -05:00
En-En
e991cb39c2 fix: do not change owner on SelectionClear
The SelectionClear event was previously calling `handle_new_owner`,
which relies on `SelectionClear` being sent only after a
`SetSelectionOwner` event. Even so, the
`XFixes::SelectionEvent::SetSelectionOwner` event already handles this
(and more obviously so). The result was that whenever Wayland owned the
X selection and X took it back, `handle_new_owner` would be called
twice, as would all of the machinery involved in acquiring a selection.

This behavior manifests as a bug if Wayland quickly reclaims ownership
of the selection, which can cause the selection event to be cancelled
before getting the SelectionNotify response is received, resulting in an
empty Wayland selection.
2025-11-09 22:55:32 -05:00
En-En
34bf07db05 fix: give clipboard/primary TARGETS unique atoms
The clipboard and primary selections previously used the same atom to
store TARGETS when queried for them by `handle_target_list`. When a
program requests both selections simultaneously, problems such as one
selection using the target list of the other, then deleting it and
requiring the second target to get the selection targets again could
occur. This was observed when using `wl-clip-persist` and could result
in selection desyncs.

This change gives a unique atom to each primary and clipboard selection
targets so they no longer compete over the same property. It also adds
updates to the `copy_from_x11` intergration to test for this issue.
2025-11-09 22:55:32 -05:00
En-En
e8079bc072 feat: popup POPUP & DROPDOWN _NET_WM_WINDOW_TYPE
Thanks for @SamSaffron for the implementation. I added the relevant
check to the `popup_heuristics` integration.
2025-11-05 21:47:10 -05:00
En-En
53b6072bd9 refactor: improve logs, unify integration log fmt
The catch-all case of `handle_client_message` now logs the atom's name
instead of its opaque atom id.

`get_atom_name` now warns there was an error and returns a filler name.
Since most the use of `get_atom_name` is in logging, this makes those
logs easier to read.

The integration tests now use `formatted_timed_builder` logger
constructor, which should unify the look of logs between the integration
tests and the main binary.
2025-11-04 19:20:24 -05:00
En-En
e9ef847544 refactor(xstate): handle client_message in own fn
The `ClientMessage` case in `handle_events` was moved to its own
function (it is over 90 LoC).
2025-11-04 19:20:24 -05:00
En-En
2b754c3bec refactor(xstate): rustfmt, clean up some matches
LuckShiba's commit was not formatted with `rustfmt`, so I took the
opportunity to do some additional refactors.

Some bulky match constructions in xstate/selection were made more
compact as well.
2025-11-04 19:20:24 -05:00
LuckShiba
53d14ead2a fix: remove unnecessary unwrap in xstate::selection 2025-11-04 19:20:24 -05:00
En-En
04816e2a36 fix: factor out some unwraps in xstate::selection
Brought to my attention by #252, several `unwrap`s exist on code whose
failure does not justify the termination of the program, so I took some
time to replace them with proper error handling.

The request for TARGETS in `handle_selection_request` used `unwrap`.
Since the code for a failure of responsing to `SelectionRequest` exists,
it simply uses that.

`handle_target_list` now early returns if receiving the
`GetProperty` request fails.

`handle_new_owner` does not update the timestamp for the last selection
on failure.

`set_owner` now returns a `bool` to indicate whether the
`SetSelectionOwner` and `GetSelectionOwner` requests succeeded and
whether they transferred ownership successfully or not. The call spots
have also been modified to not change the `selection_state` if this call
fails.
2025-10-24 18:40:12 -04:00
En-En
d621a0b37a fix: X-owned primary blocks clipboard INCR
Due to an oversight, if `XState` had both a valid primary selection
and a valid clipboard selection, `handle_selection_property_change`
would early return after `check_for_incr` determines the primary selection
existed but was not the recipient of the `PropertyNotifyEvent`, preventing
INCR events from ever reaching the clipboard. An addtion to the
`incr_copy_from_x11` integration test validates this fix.

Also fixed was a missing check in `WaylandSelection`'s `check_for_incr`
to confirm the property requesting more data is indeed the property the
selection is responsible for. I could not figure out how to write an
integration for this mistake, but it is obvious enough in hindsight.
2025-10-24 18:40:12 -04:00
En-En
cdf405fac5 refactor: swap WaylandIncrInfo from range to start
Since the range end was always encoded in the data length, calculating
the end of the selection is a bit cleaner and removes a potentially
confusing slice operation on a slice.
2025-10-24 18:40:12 -04:00
En-En
cc011f3251 refactor: fix handle_selection_request 8/7 args
Resolve Clippy's `too_many_arguments` lint on
`handle_selection_request` by removing the `success` and `refuse`
parameters and returning a bool indicating which needs to be run.

Use the helper functions defined last commit to simplify
`incr_copy_from_x11`

Reduce the `match` statement checking if the target is the TARGET
atom to an if statement. Although using `match` statements as
`if`/`else if`/`else` chains occur elsewhere, this one is both only 2
cases, and already of particular relevance to the current work.

Refactor `paste_impl` to be much easier to read. I did this code algebra
way back while investigating #142, but since I never figured that out,
the change has just been sitting in my stash.

refactor: simplify paste_data logic, some unnests
2025-10-24 18:40:12 -04:00
En-En
1ec45141e6 feat: send huge Wayland-to-X selections via INCR
Since the connection handshake establishes the most data a request can
send, if the data length exceeds that limit, we can follow ICCCM 2.7.2
sending the INCR property and continuing to send data via PropertyNotify
events.

To test the changes, we create `XState::set_max_req_bytes` to forcefully
trigger the INCR mechanism in integration test runs with a constant,
substantially less amount of data.
2025-10-24 18:40:12 -04:00
Shawn Wallace
970728d0d9 Support client initiated window resizing
Closes #185
2025-09-06 13:29:18 -04:00
Shawn Wallace
0b94ae1eb8 Support client initiated window move (_NET_WM_MOVERESIZE)
Part of #185
2025-09-06 13:29:14 -04:00
Shawn Wallace
2c30ea7863 xstate: always stack newly mapped windows below
I can't figure out a way to actually test this, but this seems to work in manual testing.
Fixes #146
2025-09-02 23:08:00 -04:00
En-En
d759c64681 dep: bump xcb to 1.6.0
switch from the deprecated API we found unsoundness in to the one introduced in 1.6.0
2025-08-23 11:39:05 -04:00
Shawn Wallace
5a184d4359 Support primary selection
This was more tedious than expected.
Fixes #103
2025-08-14 20:59:01 -04:00
Shawn Wallace
13469566b0 Fix Rust 1.89 mismatched_lifetime_syntaxes lint
https://blog.rust-lang.org/2025/08/07/Rust-1.89.0/#mismatched-lifetime-syntaxes-lint
2025-08-14 01:29:17 -04:00
En-En
be9d573fd6 server: make state's client and connection mandatory
The goal of the previous commits being to remove these unwraps. The `unwrap_or_skip_bad_window` changes needed to make a singular debug conditional
2025-08-06 22:32:00 -04:00
En-En
4280639df8 server: give uninitialized and initialized xstate with unique types 2025-08-06 22:32:00 -04:00
Shawn Wallace
e4bb8c3f9d cargo clippy everywhere 2025-07-12 12:32:20 -04:00
Shawn Wallace
557ebeb616 xstate/settings: Clamp scale to >=1
Avoids crashing, and GTK apps also seem to generally dislike
when the reported DPI is less than the default.

Fixes #181
2025-06-29 16:24:45 -04:00
skyrelia
ef24bce5d9 Recognize drag and drop window type
Fixes #166
2025-06-29 16:15:20 -04:00
Shawn Wallace
b98fa84524 Use fractional scaling when setting scale through xsettings
Fixes #168
2025-06-19 17:02:42 -04:00
Ivan Molodetskikh
ac391db415 xstate: Set WM_S0 atom at startup
Xwayland waits for this before starting to listen on the -listenfd descriptors
if either -wm or -initfd is set.

- https://gitlab.freedesktop.org/xorg/xserver/-/blob/xwayland-24.1.6/hw/xwayland/xwayland.c?ref_type=tags#L463-472
- https://gitlab.freedesktop.org/xorg/xserver/-/blob/xwayland-24.1.6/hw/xwayland/xwayland.c?ref_type=tags#L300-317
2025-06-07 12:59:01 -04:00
Shawn Wallace
d7bc38e6e7 xstate: mark _NET_WM_WINDOW_TYPE_MENU/TOOLTIP as popups
Fixes #161
2025-05-27 20:01:12 -04:00
Shawn Wallace
572fa4a2bf Add Xsettings support, for setting scaling related settings
This allows for most GTK and Qt apps to be scaled properly.
In the case of mixed DPI, it will default to using the smallest monitor scale.
2025-05-23 23:25:33 -04:00
Shawn Wallace
ec9ff64c1e Mark WM_TRANSIENT_FOR windows as toplevel parents 2025-05-13 00:46:02 -04:00
Shawn Wallace
4671f27282 Use _MOTIF_WM_HINTS to determine if window should be popup
Surely this won't go horribly wrong...
Fixes #155
2025-05-12 23:25:17 -04:00
Shawn Wallace
51300780f8 Allow toplevels to reconfigure themselves 2025-05-11 11:46:29 -04:00
Shawn Wallace
378421d356 xstate: add _NET_WM_STATE{_FULLSCREEN} to _NET_SUPPORTED
Fixes #157
2025-05-11 11:30:54 -04:00
Shawn Wallace
56a681bfec Mark windows with _NET_WM_STATE_SKIP_TASKBAR as popups
Also includes some light refactoring of the popup flow in general
and trimming down some unused code.

I suspect this may cause some windows to unexpectedly become popups when they
otherwise shouldn't, but that's a bridge we'll cross when we get there.

Fixes #110 and #112.
2025-04-27 01:10:55 -04:00
Shawn Wallace
8188df0e70 Force buffers to be unscaled
Satellite will now force Xwayland to always render with the native
display resolution, and just scale surface sizes accordingly. As a result,
applications won't really respect DPI, but this can be adjusted through
the same means as with normal X11.

Part of #28.
2025-04-09 00:32:20 -04:00
bbb651
0559ace758 Support xdg decorations 2025-03-29 23:09:32 -04:00