aboutsummaryrefslogtreecommitdiff
path: root/include/xwayland
AgeCommit message (Collapse)Author
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-02-05xwayland/xwm: make atom_map constManuel Stoeckl
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-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-27xwayland: drop unused enum net_wm_state_actionSimon Ser
2021-01-25xwayland/selection: rename Wayland-facing data and helpersTudor Brindus
Previously, wlr_xwm_selection_transfer.source_fd meant: - the source of data in a Wayland -> X11 copy (good) - the destination of data in a X11 -> Wayland copy (confusing) This made reading through xwayland/selection/incoming.c difficult: in many places, "source" actually means "destination".
2020-07-30xwayland: do not allow apps to change focus after wlroots requestIlia Bozhinov
2020-07-27xwm: Set _NET_WM_STATE_FOCUSED property for the focused surfaceScott Moreau
Certain clients require this property to be set for expected behavior. Most notably, steam client CSD maximize button no longer worked after unmaximizing once, unless the state was changed by another method. The state is unset whenever another surface gains focus.
2020-07-21xwm: add support for xwayland minimizeTobias Langendorf
2020-07-03xwm: end transfers when the requestor is destroyedJohn Chadwick
This improves the failure cases when incremental transfers fail to complete successfully for one reason or another.
2020-05-19xwayland: split serverSimon Ser
Split the server part of wlr_xwayland into wlr_xwayland_server. This allows compositors to implement their own XWM when wlroots' isn't a good fit.
2020-03-06xwayland: remove underscore prefix from atom namesSimon Ser
Previously, some atoms had a leading underscore, others didn't. Be more consistent and never use a leading underscore (symbols with a leading underscore followed by an upper-case letter are reserved).
2020-03-06xwayland: remove duplicate _NET_WM_NAME entrySimon Ser
2020-03-06xwayland: use explicit indexes when initializing atom_mapSimon Ser
It's very easy to break the mapping between the atom_name enum and the atom_map array. Use explicit indexes to prevent issues.
2019-02-15xwm: Add _NET_CLIENT_LIST supportUli Schlachter
Fixes: https://github.com/swaywm/wlroots/issues/1469 Signed-off-by: Uli Schlachter <psychon@znc.in>
2019-01-24data-device, primary-selection: add request_set_selectionemersion
This makes compositors able to block and/or customize set_selection requests coming from clients. For instance, it's possible for a compositor to disable rich selection content (by removing all MIME types except text/plain). This commit implements the design proposed in [1]. Two new events are added to wlr_seat: request_set_selection and request_set_primary_selection. Compositors need to listen to these events and either destroy the source or effectively set the selection. Fixes https://github.com/swaywm/wlroots/issues/1138 [1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
2018-11-29primary-selection: introduce wlr_primary_selection_sourceemersion
This is a common interface that can be used for all primary selection protocols, as discussed in [1]. A new function wlr_seat_set_primary_selection is added to set the primary selection for all protocols. The seat now owns again the source, and resets the selection to NULL when destroyed. [1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
2018-11-23Rename wlr_primary_selection to wlr_gtk_primary_selectionemersion
2018-11-12Use #if instead of #ifdef for wlroots config dataemersion
This prevents some annoying issues when e.g. not including wlr/config.h or making a typo in the guard name.
2018-10-27xwayland: fix typo to enable transparencyemersion
We spent literally hours trying to debug this. Turns out it's a typo. Kill me.
2018-09-03xwayland: Introduce set_role eventRyan Dwyer
2018-09-02xwayland: Add WM_STATE modal propertyRyan Dwyer
Adds a modal property to indicate whether the surface wants to be a modal.
2018-04-26xwayland: fix some Chromium comboboxesemersion
Some comboboxes (e.g. in chrome://flags) are advertized as… Notifications of course! Yeah, notifications, the thing that tells you you have mail, your battery is low, or the dog has eaten your carpet. This isn't the first time we notice Chromium's X11 backend is pretty shit. Anyway, added notifications and splash screens to the list of unmanaged windows. Also removed utility windows because those should be managed, but maybe I'm wrong and I'll revert this.
2018-04-25Make sure we don't use others' prefixesemersion
2018-04-08Add wlr_xwayland_surface_pingemersion
2018-04-08xwayland: add _NET_WM_WINDOW_TYPE_MENU supportemersion
2018-04-03xwayland: refactor selection codeemersion
2018-04-03xwayland: only send one target at a timeemersion
2018-04-02xwayland: support multiple wayland → xwayland selection transfersemersion
This fixes drag'n'drop support for Chromium.
2018-03-29xwayland: use a separate window for drag'n'dropemersion
2018-03-29xwayland: allow drag data source transfer after drag endsemersion
2018-03-28xwayland: improve error handlingemersion
2018-03-28xwayland: send DND_DROPemersion
2018-03-28xwayland: send DND_POSITIONemersion
2018-03-28xwayland: send DND_ENTERemersion
2018-03-27xwayland: create DND window, add DND atom helpersemersion
2018-03-27Fix x11 backendDominique Martinet
Need to include wlr/config.h before using the various WLR_HAS_xxx defines
2018-03-04xwm.h: fix guard ifdef and remove wlr_ prefix from xwm_atoms_containsDominique Martinet
2018-03-03xcb errors: init errors context at startDominique Martinet
`xcb_errors_context_new` is more than just a malloc, it does a few xcb requests so we benefit from not generating a new context everytime
2018-03-03move xwm.h out of include/wlrDominique Martinet
xwm.h was meant to be private, so move it to include/xwayland/xwm.h We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move to xwm, it is not safe to use the WLR_HAS_* in the public headers. I checked a few of our current users and none rely on xwm.h being public as expected (rootston, sway, hsroots)
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-01 21:37:31 +0000