aboutsummaryrefslogtreecommitdiff
path: root/xwayland
AgeCommit message (Collapse)Author
2022-04-17Revert "Copy xcb_icccm structs into wlroots"John Lindgren
The original commit introduced a bug by transposing the order of some of the fields in xcb_size_hints_t. Since XCB ICCCM support is required now, we can just eliminate the duplicate structs. With minor changes: - Remove #ifdef HAS_XCB_ICCCM guards - Fix #includes - Fix references to local size_hints struct This reverts commit 12b9b1a4bdf00742cc510c2329c7a66c649b3ab0.
2022-03-02Xwayland: use -displayfd instead of USR1Dominique Martinet
Using Xwayland -displayfd means we don't need to worry about handling SIGUSR1 to second guess when Xwayland is ready and write to the pipe: just let it do that write when it would be sending SIGUSR1 otherwise. Closes: #3356
2022-03-02Xwayland: rename notify pipe 'p' to notify_fdDominique Martinet
2022-01-13surface: improve role precommit hookKirill Primak
Now the role precommit hook is called before the commit, not on wl_surface.commit request, and takes a state which is to be applied.
2022-01-13surface: deprecate wlr_surface.hKirill Primak
2021-11-02xwayland: add support for -noTouchPointerEmulationSimon Ser
This allows compositors to handle touch pointer emulation manually, instead of having Xwayland do it [1]. [1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/691
2021-09-11xwayland: Allow to retrieve startup-id via _NET_STARTUP_INFOGuido Günther
A launchee notifies with a "remove"¹ message when done starting up. Catch these and forward to the compositor. This allows the compositor to end the startup sequence that might have been started by another protocol like xdg-activation. We don't handle other messages since we expect the launcher to use a wayland protocol like xdg-activation. While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids this signals the end of the startup sequence. 1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
2021-09-06surface: drop wlr_surface_state.buffer_resourceSimon Ser
Instead, use wlr_surface_state.buffer only.
2021-08-28xwm: do not restack surfaces on activationTudor Brindus
Currently, upon activating a surface, wlroots restacks it on top of all others. This may not necessarily be correct from the calling compositor's point of view, where having focus may not imply being top-of-stack (e.g., focusing a window under an always-on-top window). In Sway's case, this means that focused tiling windows will always be on top of floating windows, at least in the order communicated to X11 apps. This breaks drag-and-drop from a focused tiling X11 window to a floating X11 window which partially obscures the former. This is a breaking change; to retain the previous behavior, users that were calling wlr_xwayland_surface_activate(xsurface, true); should now be calling wlr_xwayland_surface_activate(xsurface, true); wlr_xwayland_surface_restack(xsurface, NULL, XCB_STACK_MODE_ABOVE);
2021-08-20xwayland: Allow to retrieve _NET_STARTUP_IDGuido Günther
This is use for startup notifications per startup-notifiation spec https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
2021-08-17xwayland: do not free cursor in handle_server_ready()Michele Sorcinelli
If XWayland terminates for any reason, xwm_set_cursor() has to to be called again, so the cursor has to stick around.
2021-07-27xwayland: embed wlr_xwayland_server_options in server structSimon Ser
As more options are added, more fields will be duplicated. Let's just embed the struct in wlr_xwayland_server so that we don't need to keep both in sync.
2021-07-27xwayland: simplify argv filling logicSimon Ser
Remove fill_arg and replace it with stack-allocations and simple array-filling.
2021-06-25xwayland: improve startup log messageSimon Ser
Logging the raw Xwayland command-line was incomplete, uninformative and confusing for end-users. Instead, print a proper message in English.
2021-05-31xwm: prevent X11 clients from blowing our stack by opening too many windowsTudor Brindus
Allocate window arrays for list property updates on the heap instead.
2021-05-31xwm: implement _NET_CLIENT_LIST_STACKINGTudor Brindus
This property is present on all modern X11 instances. The nonpresence of it requires applications to fall back to XQueryTree-based logic to determine stacking logic (e.g., to determine what surface should get Xdnd events). These code paths are effectively untested nowadays, so this makes it more likely for wlroots to "break" applications. For instance, the XQueryTree fallback path has been broken in Chromium for the last 10 years. It's easy enough to maintain this property, so let's just do it. Fixes #2889.
2021-05-31xwm: use correct list link when iterating over `unpaired_surfaces`Tudor Brindus
2021-05-12xwayland: actually use Xwayland from pkg-configThomas Weißschuh
eec2e1d3b16ba40c85483badcc7809277274ce5d introduced logic to use the Xwayland binary discovered via pkg-config. While the newly introduced checks correctly used the binary from pkg-config, the actual execution still used the previous PATH-search logic.
2021-04-23xwayland: remove _NET_WM_PID handlerAleksei Bavshin
We already get the PID from XRes and _NET_WM_PID code can overwrite it with incorrect data.
2021-04-23xwayland: query window PIDs via XResQueryClientIdsAleksei Bavshin
`_NET_WM_PID` is unreliable: it is optional and even if set it may contain PIDs from sandbox namespaces or remote systems. Prefer XRes v1.2 QueryClientIds method which returns PIDs as seen by the Xwayland server.
2021-04-16xwayland/sockets: ensure proper permissionsRyan Farley
Create a private UNIX socket directory (755), or use an existing one but ensure proper permissions are set to prevent meddling from other users.
2021-04-09Remove WLR_HAS_XCB_ERRORSSimon Ser
wlroots' dependency on this library doesn't change the features exposed to compositors. It's purely a wlroots implementation detail. Thus downstream compositors shouldn't really care about it. Introduce an "internal_features" dictionary to store the status of such internal dependencies.
2021-04-08gtk-primary-selection: drop supportIsaac Freund
The standard primary-selection protocol is now widely supported.
2021-03-29xwayland: use ICCCM state defines from xcb-icccmSimon Ser
2021-03-29xwayland: require xcb-icccmSimon Ser
This dependency is already required by many other widely used X11 programs, such as i3, Qt, and other XWMs. So it should be available on most systems. X11 support can be pretty broken without xcb-icccm, with focus issues for instance. Let's just remove this --please-break-my-desktop footgun option.
2021-03-29xwayland: assume no WM_HINTS means window wants inputSimon Ser
Some X11 clients (e.g. Chromium, sxiv) don't set WM_HINTS. The spec says: > Window managers are free to assume convenient values for all fields of the > WM_HINTS property if a window is mapped without one. Our wlr_xwayland_icccm_input_model function assumes missing WM_HINTS means the window doesn't want input, but this is incorrect. Assume the window wants input unless it explicitly opts-out by setting WM_HINTS. Closes: https://github.com/swaywm/sway/issues/6107
2021-03-03xwayland: use -listenfd if availableSimon Ser
Xwayland's -listen option was deprecated in [1] in favor of -listenfd. [1]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/593
2021-03-03xwayland: check executable exists on initSimon Ser
Instead of walking PATH like a previous proposal [1], this one checks that the Xwayland path specified in the pkg-config file exists. I think this is a reasonable compromise: - Users that don't have Xwayland installed system-wide won't get a bogus DISPLAY env variable set up. - Users that have WLR_XWAYLAND set won't be affected by this check. - Users that have Xwayland installed system-wide and a different Xwayland in their PATH still get their custom Xwayland. - Users that don't have Xwayland installed system-wide but have it somewhere else in PATH are left out. But this is pretty niche, and they can just set WLR_XWAYLAND. [1]: https://github.com/swaywm/wlroots/pull/2314
2021-03-03xwayland: add dependency on xwaylandSimon Ser
Check that the pkg-config file is available. This will be required in the future to check whether xwayland supports features such as -listenfd, -initfd or -verbose. If there's no pkg-config file, check that the Xwayland executable is available. This effectively makes our relationship with xwayland closer to what a dynamic library is: checked at build-time, but can be overridden at run-time.
2021-02-15build: use dictionnary for features instead of configuration_dataSimon Ser
This allows us to easily iterate on all features and only deal with bools.
2021-02-15xwayland/selection: flush connection after changing xwm selection ownerTudor Brindus
This was the actual underlying cause of #2192; we were not getting the XFIXES_SELECTION_NOTIFY event in time.
2021-02-15xwayland/selection: log when proxy window loses ownershipTudor Brindus
2021-02-15xwayland/selection: ignore requests for anything but the newest dataTudor Brindus
Our internal state machine gets screwed up if selection events are not monotonically increasing in time, and we can enter a self-copy loop from the proxy window that exhausts all pipes. Snippet of logs when this occurs: 00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=4194626) 00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=2097153) 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:378] XCB_SELECTION_REQUEST (time=58979563 owner=2097153, requestor=2097153 selection=277, target=279, property=278) 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:397] ignoring old request from timestamp 58979563; expecting > 58979563 00:00:46.238 [wlr] [xwayland/selection/outgoing.c:29] SendEvent destination=2097153 SelectionNotify(31) time=58979563 requestor=2097153 selection=277 target=279 property=0 00:00:46.238 [wlr] [xwayland/selection/incoming.c:453] XCB_SELECTION_NOTIFY (selection=277, property=0, target=279) Note that 2097153 is `selection->window`, and 4194626 is Emacs. The race occurs if the selection owner changes back to our proxy window between when we get `XCB_XFIXES_SELECTION_NOTIFY` for Emacs and when we call `xcb_convert_selection` in `incoming.c:source_send` -- the ConvertSelection request can end up hitting our proxy window, but the timestamp will be rejected. Fixes #2192.
2021-02-05xwayland: free render picture backing cursorIlia Mirkin
Otherwise it gets leaked never to be recovered.
2021-02-05xwayland/xwm: make atom_map constManuel Stoeckl
2021-02-04xwayland/selection: allow simultaneous Wayland-to-X11 transfersTudor Brindus
There seems to be no reason why we can't service multiple Wayland-to-X11 transfers concurrently, so long as they are to different windows (or possibly, same windows but different target properties?) This commit removes the queuing logic, but retains the request de-duplication from #2428.
2021-02-04xwayland/selection: use one target window per selectionTudor Brindus
Previously, the clipboard and primary selections shared the same window. This was racey, and could have led to pasting failures. On xfixes selection owner change notification, the logic for requesting the supported mimetypes of the new owner's selection looks like: xcb_convert_selection( xwm->xcb_conn, selection->window, selection->atom, xwm->atoms[TARGETS], xwm->atoms[WL_SELECTION], selection->timestamp ); This means ask the selection owner to write its TARGETS for the `selection->atom` selection (one of PRIMARY, CLIPBOARD, DND_SELECTION) to `selection->window`'s WL_SELECTION atom. However, `selection->window` is shared for both PRIMARY and CLIPBOARD selections, and WL_SELECTION is used as the target atom in both cases. So, there's a race when both selections change at the same time. The CLIPBOARD selection might support mimetypes {A, B, C}, and the PRIMARY only {A, B}. If the ConvertSelection requests/responses "cross on the wire", so to speak, wlroots can end up believing that the PRIMARY selection also supports C. A Wayland client may then ask for the PRIMARY selection in C format, which will fail with "convert selection failed". This commit fixes this by using a separate window for PRIMARY and CLIPBOARD target requests, so that WL_SELECTION can be used as the target atom in both cases.
2021-02-04xwayland/selection: use one X11 window per incoming transferTudor Brindus
This commit introduces logic for using a new X11 window for each incoming transfer, rather than having a global window for each selection source. This eliminates a whole class of bugs involving multiple concurrent incoming transfers. For now, we retain the outgoing transfer queue, and the selection source-specific windows to support it. Source-specific windows are no longer used in the incoming path, and will be removed in a future PR. Refs #1497.
2021-01-31xwayland/selection: make xwm_selection_init take a wlr_xwm_selection *Tudor Brindus
This makes it consistent with xwm_selection_finish.
2021-01-31xwayland/selection: introduce `xwm_selection_transfer_init`Tudor Brindus
Currently, all this does is initialize `wl_client_fd` to -1, so that comparisons with 0 are meaningful.
2021-01-31xwayland/selection: make xwm_selection_finish take a wlr_xwm_selection *Tudor Brindus
Previously it took a wlr_xwm *, which was a bit surprising in that it freed members of wlr_xwm *, not just its respective selections.
2021-01-31xwayland/selection: destroy all selections on Xwayland restartTudor Brindus
Previously, Xwayland could restart, and we'd get events for transfers pointing to the previous (now freed) xwm instance. This led to use-after-free segfaults. Closes #2565.
2021-01-31xwayland/selection: don't leak Wayland fd if ConvertSelection failsTudor Brindus
If our ConvertSelection failed, we would previously leak the pending Wayland client fd. Refs swaywm/sway#5946.
2021-01-31xwayland/selection: don't request another selection while one is pendingTudor Brindus
This will hopefully be fixed in the future by having separate windows for each X11-to-Wayland transfer, but until then, let's avoid a compositor crash.
2021-01-29xwayland/selection: end incr transfer on empty prop, not next selectionTudor Brindus
Previously, `transfer->incr` was being cleared on the next selection. However, if the next selection was *also* incremental, it's possible that `xwm_handle_selection_property_notify` would route us to `xwm_get_incr_chunk` instead of `xwm_selection_get_data`.
2021-01-29xwayland/selection: refactor remaining incremental transfer codeTudor Brindus
2021-01-29xwayland/selection: extract out property requestsTudor Brindus
Apart from reducing duplication, this has the positive side-effect of allowing all deallocs to use `xwm_selection_transfer_destroy_property_reply`, as opposed to the latter and a mix of ad-hoc `free`s.
2021-01-29xwayland/selection: simplify incremental transfer control flowTudor Brindus
Previously, if the Wayland client died before an incremental transfer was complete, the logs would be spammed by "write error to target fd" as wlroots entered some control flow wherein it'd continually try scheduling further writes to the already-dead pipe. This commit contains no behavioral changes, but introduces explicit handling for draining the X11 selection in case of Wayland client death.
2021-01-29xwayland/selection: explicitly bail if first write to Wayland fd failsTudor Brindus
If `xwm_data_source_write` failed, it's failed permanently. In fact, a failing `xwm_data_source_write` sets `transfer->property_reply` to null as part of its error handling. Instead of relying on an indirect check (whether `transfer->property_reply` is still non-null), explicitly use the return value from `xwm_data_source_write`.
2021-01-29xwayland/selection: make `xwm_data_source_write` return 0 on failureTudor Brindus
The `fd` is marked `O_NONBLOCK`, so `write` will never spuriously return `EINTR`. Therefore, `write` failing is permanent, and we can return 0 to make the return value meaningful.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 07:38:11 +0000