wayland-protocols issueshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues2021-10-31T11:14:25Zhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/69Protocol Extension for VRR in Fullscreen Use (FreeSync, Variable Refresh Rate)2021-10-31T11:14:25ZphaitonicanProtocol Extension for VRR in Fullscreen Use (FreeSync, Variable Refresh Rate)Here is a good discussion about the topic I found: https://github.com/swaywm/wlroots/issues/1406
What are the requests, events etc VRR needs for the protocol extension?
ThanksHere is a good discussion about the topic I found: https://github.com/swaywm/wlroots/issues/1406
What are the requests, events etc VRR needs for the protocol extension?
Thankshttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34UI/text scaling information for toolkits2022-04-12T13:40:47ZMikhail GusarovUI/text scaling information for toolkitsUI toolkits do not have a way to query environment for the preferred text and UI size, aside from a blunt integer "scale factor" in `wl_output`.
This makes it hard to achieve aesthetically pleasing desktop look and leads to horrible hac...UI toolkits do not have a way to query environment for the preferred text and UI size, aside from a blunt integer "scale factor" in `wl_output`.
This makes it hard to achieve aesthetically pleasing desktop look and leads to horrible hacks like fractional scaling that ruin any chance for crisp text rendering.
This issue does not have answers (yet), but is intended to works as a Schelling point for scaling discussions:
```
<pq> dottedmag, so if you can't find an open issue or MR in wayland-protocols repo for it,
it might be a good idea to open one, so things stop relying on hearsay and vague memories of irc discussions.
```https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158Add protocol for pointer (mouse cursor) warping2024-03-24T16:35:04ZJon EvansAdd protocol for pointer (mouse cursor) warpingThis is a feature request for a protocol that allows applications to ask the compositor to warp the mouse cursor to a new location.
I understand that the pointer-constraints-v1 protocol provides some facility for warping through the pos...This is a feature request for a protocol that allows applications to ask the compositor to warp the mouse cursor to a new location.
I understand that the pointer-constraints-v1 protocol provides some facility for warping through the position hint, however this doesn't seem like the right solution for me because the warping is a side-effect of cursor locking (which is not what I'm trying to do) and is optional and so may not even happen.
I understand that there is some sentiment that allowing an application to move the cursor anywhere on the screen may create poor user experience or even security risks, so I want to clarify that I only need cursor warping within a focused application window.
The use cases I have, from [KiCad](https://kicad.org):
1. KiCad implements infinite mouse-drag pan, meaning that when a drag action hits the edge of the rectangular drawing canvas, the cursor is warped to the opposite edge. This allows quick navigation of large drawings, especially with input devices such as trackballs/trackpoint. This particular use case appears to be identical to [one brought up in this forum thread ](https://discourse.gnome.org/t/pointer-warping-on-wayland/9197)by another EDA tool author.
2. KiCad implements an (optional) special zoom behavior that some users find very helpful and productive. When this behavior is enabled, any zoom event (typically from a mouse wheel or keyboard shortcut) will result in the current cursor location being warped to the center of the drawing canvas (as well as repositioning the drawing canvas center). More details can be see in [this KiCad issue](https://gitlab.com/kicad/code/kicad/-/issues/9785).
3. KiCad keeps track of a "drawing cursor" separate from the system cursor, that represents the insertion point of new graphic shapes on the editing canvas. This cursor is snapped to a grid but tracks the system cursor when the drawing canvas has focus. When the user performs certain editing operations, a child window (pop-up dialog) may open that the user can interact with. In some cases, KiCad will warp the system cursor back to the last drawing cursor position when such a dialog is closed, so that even if the user interacted with the dialog using the mouse, the editing operation will take place at the last drawing cursor location rather than jumping to a new position (e.g. whatever position is under the dialog's OK button)
KiCad uses wxWidgets as an abstraction layer for cross-platform UI. So, my proposed solution is to have some wayland protocol that can provide similar results to the `gdk_device_warp` call that wxWidgets uses today on X11/Xwayland, but perhaps with more restrictions (e.g. only allowing warping if the application window has focus, only allowing warping to coordinates that are within the focused window, etc) if desired by the wayland team in order to prevent "bad behavior".https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/44Support for Picture-in-Picture windows2023-01-06T12:03:23ZVlad ZahorodniiSupport for Picture-in-Picture windowsPicture-in-Picture is a feature that allows watching videos in a floating window. On desktop, web browsers such as Firefox provide support for this feature.
A picture-in-picture window is almost the same as a normal window except a few ...Picture-in-Picture is a feature that allows watching videos in a floating window. On desktop, web browsers such as Firefox provide support for this feature.
A picture-in-picture window is almost the same as a normal window except a few minor bits:
* It is placed above other windows. On X11, it is achieved by setting the _NET_WM_STATE_ABOVE state
* It is not listed in the task manager. On X11, it is achieved by setting the _NET_WM_STATE_SKIP_TASKBAR state
Currently, it's unclear how picture-in-picture mode can be properly implemented on Wayland as there is no way to instruct the compositor that a window should not be listed in the task manager and be placed above other windows.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/153Primary or audience display2024-02-22T19:51:32ZColin KinlochPrimary or audience displayWhen presenting LibreOffice Impress creates two full screen surfaces:
* One showing the slides to the audience
* One for the presenters controls and notes.
I feel this use case could be improved by either having a protocol for identify ...When presenting LibreOffice Impress creates two full screen surfaces:
* One showing the slides to the audience
* One for the presenters controls and notes.
I feel this use case could be improved by either having a protocol for identify a primary display or some way to tag a surface with the intended audience.
Links:
* [related W3C presentation API](https://www.w3.org/TR/presentation-api/)
* Gnome desktop analysis: [gnome-shell#5252](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5252)
* previous discussion: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/102https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/70Support HDR2021-10-31T11:16:05ZromulasrySupport HDRAll the lower left level "stuff" support it already, right? Or is there more that must be done before wayland can support it? HDR would be nice to have though...All the lower left level "stuff" support it already, right? Or is there more that must be done before wayland can support it? HDR would be nice to have though...https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39Input Method Hub2024-03-10T11:53:17ZRoman GilgInput Method Hub# Introduction
The purpose of this ticket is to serve as an **entry page** for input method support in Wayland.
It shall give newcomers a first understanding of what input methods are and
how they are implemented in Wayland.
The ticket ...# Introduction
The purpose of this ticket is to serve as an **entry page** for input method support in Wayland.
It shall give newcomers a first understanding of what input methods are and
how they are implemented in Wayland.
The ticket shall also act as a hub
to **organize ongoing efforts** for improving input method support
in the Wayland Protocols project
and point to as well as guide the individual downstream projects basing their implementations on us.
## Table of Contents
- [Introduction](#introduction)
* [Table of Contents](#table-of-contents)
* [Motivation](#motivation)
* [Challenges](#challenges)
- [Current State](#current-state)
* [Overview](#overview)
* [Upstream Protocols](#upstream-protocols)
+ [text-input-unstable-v3](#text-input-unstable-v3)
+ [input-method-unstable-v1](#input-method-unstable-v1)
* [Downstream Protocols](#downstream-protocols)
+ [input-method-unstable-v2](#input-method-unstable-v2)
+ [virtual-keyboard-unstable-v1](#virtual-keyboard-unstable-v1)
+ [qt-text-input-method-unstable-v1](#qt-text-input-method-unstable-v1)
* [Implementation Matrix](#implementation-matrix)
* [Stalled Upstream Protocol Work](#stalled-upstream-protocol-work)
+ [text-input-unstable-v3](#text-input-unstable-v3-1)
+ [virtual-keyboard-unstable-v1](#virtual-keyboard-unstable-v1-1)
- [Next Steps](#next-steps)
* [Requirements](#requirements)
* [Protocol Consolidation](#protocol-consolidation)
+ [Analysis](#analysis)
+ [Plan](#plan)
* [Project Management](#project-management)
+ [Upstream](#upstream)
+ [Implementations](#implementations)
## Motivation
Keyboards were one of the first,
and are still one of the most important devices for entering data into a computer.
In Wayland we have the *wl_keyboard* interface
to directly handle the most common form of keyboards:
the well known physical hardware device
with more or less 100 individual buttons.
Here each button is identified by a separate code.
Usually the buttons represent the letters of the alphabet,
a few special characters
and some additional function keys.
<div align="center">
<img src="https://images-na.ssl-images-amazon.com/images/I/71JfIlmk7uL._AC_SL1500_.jpg" height="300">
*A standard keyboard, here with RGB for increased typing speed.*
</div>
Basically these individual codes are then just forwarded via wl_keyboard to a Wayland client.
Regularly though this basic form of data input is **not enough** and we rely on more sophisticated means.
Reasons for that can be:
* User writes in a language that has **more individual letters**
than can reasonably be put on a physical keyboard,
for example several Asian languages
(often coined *CJK* as of *Chinese, Japanese, Korean*).
* User does not use a physical keyboard
but uses other means of inputting text,
for example a **virtual keyboard** on a touch screen.
* Additional metadata about text should be communicated,
for example to provide suggestions for **word completion** while
the user types in individual letters.
<div align="center">
<img src="https://upload.wikimedia.org/wikipedia/commons/d/d9/Interface_of_Weasel_Input_Method.png">
*CJK input method presenting word selection options.*
</div>
Software components that
– independent of the connected physical hardware –
provide such functionality, are called **input methods**.
## Challenges
At the moment Wayland Protocols provides several protocols
at different versions
to enable input methods support on Wayland.
While these protocols already allow
to get CJK input and virtual keyboards working to a certain degree,
the situation is far from optimal:
* The two relevant protocols in Wayland Protocols are at different versions.
* Some downstream projects use these protocols, but already more advanced versions.
* Some projects use completely different protocols.
* There is a number of technical issues with the currently provided protocols
and merge requests to solve some of them are already stalled for a long time.
# Current State
## Overview
An overview of how input method support is engineered in principle on Wayland
can be found in [this blog post][im-blog].
One can think of it like a pipeline with both ends being connected to different clients
and each end being defined by a separate protocol.
On one end a special client acts as an input method (for example IBus) which sends text
and on the other end a client with a focused text input field receives the text.
<div align="center">
<img src="https://dcz_self.gitlab.io/posts/input_method/focused.svg" height="400">
*Diagram sourced from [above article][im-blog] visualizing the pipeline model.*
</div>
[im-blog]: https://dcz_self.gitlab.io/posts/input_method/
That is not a one-way street though.
The client receiving text needs to often provide metadata to the input method client
so that the input method can function correctly.
## Upstream Protocols
In the following Wayland protocol extensions are listed
that are relevant for input methods support and are still actively used by some clients.
### text-input-unstable-v3
#### Documents
* [Protocol](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/text-input/text-input-unstable-v3.xml)
* [Early research ticket](https://github.com/swaywm/wlroots/issues/717)
#### Details
Defines the receiving side of the pipeline.
Influenced by the
[gtk-text-input](https://gitlab.gnome.org/GNOME/mutter/-/blob/master/src/wayland/protocol/gtk-text-input.xml) protocol, which is now deprecated.
In comparison to previous text-input versions
[v1](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/text-input/text-input-unstable-v1.xml)
and [v2](https://github.com/KDE/kwayland/blob/fc4f20934009497a5d740411e1f4c6d0a73057f4/src/client/protocols/text-input-unstable-v2.xml)
the third version has been slimmed down and uses atomic operations.
*Notable requests:*
* `set_surrounding_text`: Provides metadata about the text, for example for auto completion of words.
* `set_content_type`: Provides metadata about the text field, for example so a phone keypad instead of a full keyboard is shown on a touchscreen.
### input-method-unstable-v1
#### Documents
* [Protocol](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/input-method/input-method-unstable-v1.xml)
#### Details
Defines the dispatching side of the pipeline.
Primarily provides methods to interact with the receiving end on the other side of the pipeline,
but also requests to define an "input panel" surface.
*Notable requests:*
* `preedit_string`: Sends a pre-edit string via pipeline.
* `commit_string`: Sends final text via pipeline.
* `keysym`: Forwards a key event. Seems to collide with `key` and `modifiers` requests.
* `grab_keyboard`: Grabs input from a wl_keyboard. Complemented by the `key` and `modifiers` requests.
* `set_toplevel`: Sets a referenced surface as the input panel at indicated position on a certain output.
## Downstream Protocols
### input-method-unstable-v2
#### Documents
* [Protocol](https://github.com/swaywm/wlroots/blob/master/protocol/input-method-unstable-v2.xml)
#### Details
*TODO*
### virtual-keyboard-unstable-v1
#### Documents
* [Protocol](https://github.com/swaywm/wlroots/blob/master/protocol/virtual-keyboard-unstable-v1.xml)
* [Primary PR](https://github.com/swaywm/wlroots/pull/999)
#### Details
*TODO*
### qt-text-input-method-unstable-v1
#### Documents
* [Protocol][qt-v1]
#### Details
*TODO*
## Implementation Matrix
The following table lists clients and compositors with the protocols they support at which version.
Please post a comment if you can provide information which is missing (including links) or wrong.
I will then update the table.
| | text-input | input-method | virtual-keyboard | qt-text-input-method |
|----------------------------|----------------------------------------------|----------------------------------------|-------------------------|----------------------|
| [fcitx5][fcitx5] | - | [v1][fcitx5-im-v1], [v2][fcitx5-im-v2] | - | - |
| [GTK][gtk] | [v3][gtk-ti-v3] | - | - | - |
| [IBus][ibus] | - | [v1][ibus-im-v1] | - | - |
| [Maliit][maliit] | - | [v1][maliit-im-v1] | - | - |
| [squeekboard][squeekboard] | - | [v2][squeekboard-im-v2] | [v1][squeekboard-vk-v1] | - |
| [Qt][qt] | [v2][qt-ti-v2], [v4-MR][qt-ti-v4-mr] | - | - | [v1][qt-v1] |
| | | | | |
| [KWin][kwin] | [v2][kwin-ti-v2], [v3][kwin-ti-v3] | [v1][kwin-im-v1] | - | - |
| [KWinFT][kwinft] | [v2][kwinft-ti-v2], [v3][kwinft-ti-v3] | [v2][kwinft-im-v2] | [v1][kwinft-vk-v1] | - |
| [Mir][mir] | - | - | - | - |
| [Mutter][mutter] | [v3][mutter-ti-v3] | - | - | - |
| [Phoc][phoc] | [v3][phoc-ti-v3] | [v2][phoc-im-v2] | [v1][phoc-vk-v1] | - |
| [Smithay][smithay] | [v3][smithay-ti-v3] | [v2][smithay-im-v2] | [v1][smithay-vk-v1] | - |
| [Weston][weston] | [v1][weston-ti-v1], [v3-MR][weston-ti-v3-mr] | [v1][weston-im-v1] | - | - |
| [wlroots][wlroots] | [v3][wlroots-ti-v3] | [v2][wlroots-im-v2] | [v1][wlroots-vk-v1] | - |
[fcitx5]: https://github.com/fcitx/fcitx5
[fcitx5-im-v1]: https://github.com/fcitx/fcitx5/blob/e1ddc10fc0d5f3a3ab23891f9cad9b41f7dbc0b4/src/frontend/waylandim/waylandimserver.h#L20
[fcitx5-im-v2]: https://github.com/fcitx/fcitx5/commit/b8c4e7423b38aec2bdeb0802413a491f999bf687
[gtk]: https://gitlab.gnome.org/GNOME/gtk
[gtk-ti-v3]: https://gitlab.gnome.org/GNOME/gtk/-/blob/fe45f283afc7ab70df2d97e25555885ff771e200/gtk/gtkimcontextwayland.c#L30
[ibus]: https://github.com/ibus/ibus/wiki
[ibus-im-v1]: https://github.com/ibus/ibus/blob/master/client/wayland/main.c
[kwin]: https://invent.kde.org/plasma/kwin
[kwin-im-v1]: https://invent.kde.org/plasma/kwayland-server/-/blob/master/src/server/inputmethod_v1_interface.h
[kwin-ti-v2]: https://invent.kde.org/plasma/kwayland-server/-/blob/master/src/server/textinput_v2_interface.h
[kwin-ti-v3]: https://invent.kde.org/plasma/kwayland-server/-/blob/master/src/server/textinput_v3_interface.h
[kwinft]: https://gitlab.com/kwinft/kwinft
[kwinft-im-v2]: https://gitlab.com/kwinft/wrapland/-/blob/master/server/input_method_v2.h
[kwinft-ti-v2]: https://gitlab.com/kwinft/wrapland/-/blob/master/server/text_input_v2.h
[kwinft-ti-v3]: https://gitlab.com/kwinft/wrapland/-/blob/master/server/text_input_v3.h
[kwinft-vk-v1]: https://gitlab.com/kwinft/wrapland/-/blob/master/server/virtual_keyboard_v1.h
[maliit]: https://maliit.github.io/
[maliit-im-v1]: https://github.com/maliit/framework/blob/a9ab494883108669ff38a48b2ef086ec247e4c22/connection/waylandinputmethodconnection.cpp#L152
[mir]: https://github.com/MirServer/mir
[mutter]: https://gitlab.gnome.org/GNOME/mutter
[mutter-ti-v3]: https://gitlab.gnome.org/GNOME/mutter/-/commit/85e5b160ee7dbeec474c3f6877ddbd5310f0fbe8
[phoc]: https://source.puri.sm/Librem5/phoc/
[phoc-im-v2]: https://source.puri.sm/Librem5/phoc/-/blob/5940f584ba16ca8aececf8c8953ac13c817eee9b/src/text_input.c#L265
[phoc-ti-v3]: https://source.puri.sm/Librem5/phoc/-/blob/5940f584ba16ca8aececf8c8953ac13c817eee9b/src/text_input.c
[phoc-vk-v1]: https://source.puri.sm/Librem5/phoc/-/blob/master/src/virtual.c
[smithay]: https://github.com/Smithay/smithay
[smithay-ti-v3]: https://github.com/Smithay/smithay/tree/master/src/wayland/text_input
[smithay-im-v2]: https://github.com/Smithay/smithay/tree/master/src/wayland/input_method
[smithay-vk-v1]: https://github.com/Smithay/smithay/tree/master/src/wayland/virtual_keyboard
[squeekboard]: https://source.puri.sm/Librem5/squeekboard
[squeekboard-im-v2]: https://source.puri.sm/Librem5/squeekboard/-/blob/3cdced0c0cc588d56f2b7dfaf850bb54f0c55138/src/imservice.rs
[squeekboard-vk-v1]: https://source.puri.sm/Librem5/squeekboard/-/blob/3cdced0c0cc588d56f2b7dfaf850bb54f0c55138/src/vkeyboard.rs
[qt]: https://www.qt.io/contribute-to-qt
[qt-ti-v2]: https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandinputcontext_p.h#n77
[qt-ti-v4-mr]: https://codereview.qt-project.org/c/qt/qtwayland/+/355841
[qt-v1]: https://code.qt.io/cgit/qt/qtwayland.git/tree/src/extensions/qt-text-input-method-unstable-v1.xml
[weston]: https://gitlab.freedesktop.org/wayland/weston
[weston-im-v1]: https://gitlab.freedesktop.org/wayland/weston/-/blob/f6ff85b1b7accae97e486b07cea9bc6fa177582e/compositor/text-backend.c#L39
[weston-ti-v1]: https://gitlab.freedesktop.org/wayland/weston/-/blob/f6ff85b1b7accae97e486b07cea9bc6fa177582e/compositor/text-backend.c#L38
[weston-ti-v3-mr]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/150
[wlroots]: https://github.com/swaywm/wlroots
[wlroots-im-v2]: https://github.com/swaywm/wlroots/blob/master/protocol/input-method-unstable-v2.xml#L196
[wlroots-ti-v3]: https://github.com/swaywm/wlroots/blob/master/types/wlr_text_input_v3.c
[wlroots-vk-v1]: https://github.com/swaywm/wlroots/blob/master/protocol/virtual-keyboard-unstable-v1.xml
## Stalled Upstream Protocol Work
### text-input-unstable-v3
* !10: Adds hint that no input panel should be shown by the input methods client. Stalled because no implementations exist making real use of it.
* !16: Mark invalid state changes with serial 0 so a client can filter them. Stalled because of integer overflow ambiguity.
* !19: Specify text deletion in the absence of set_surrounding_text support. Stalled as no reviewer showed up yet.
* !34: Adds reset request, a "leaner" alternative to disable/enable. Stalled because benefit not clear and technical alternative was proposed.
### virtual-keyboard-unstable-v1
* !11: Adds the protocol. Stalled because of use case is not clear and technically a virtual seat might be preferred.
# Next Steps
The goal is to consolidate our different protocols and their versions
as well as fix remaining issues with them.
## Requirements
*The following is a rather unrevised list to give some clues:*
* For receiving clients single protocol to implement.
* Allow changing of the preferred input method client at runtime.
* Besides text provide means to send actions like "copy" with <kbd>Ctrl</kbd> + <kbd>C</kbd>.
* ...
*Specific requirements are aggregated in the following subtasks:*
* #40: Requirements specifically from the viewpoint of the input method dispatching side.
* #43: Synchronize cursor rectangle with wl_surface.
## Protocol Consolidation
### Analysis
**Q:** Is it enough to have a single protocol for the sending side amending/replacing input-method-unstable-v2
and one for the receiving side amending/replacing text-input-unstable-v3? See #41 for a discussion on the general nature of these protocols.\
**A:** ...
**Q:** Should we emulate physical keyboard keys for actions like "copy" or provide them via a separate interface? See #12 for details.\
**A:** ...
### Plan
*TODO:* Outline solution.
## Project Management
### Upstream
* Advance according to the plan above.
* This ticket is the main hub which will link to forked off subtasks.
* Work-in-progress branch is [wip/text-input-next](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commits/wip/text-input-next/).
### Implementations
*TODO:* Declare projects participating, link their respective overview tasks and name a person of contact for each.Roman GilgRoman Gilghttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/87Display notch support2023-10-14T14:32:41ZAnjandev MomiDisplay notch supportWith many phones having notch support and laptops eventually gaining notches, it might be worthwhile to have a standardized approach to handling notches. What is the best approach to address this?
Related: https://lore.kernel.org/dri-d...With many phones having notch support and laptops eventually gaining notches, it might be worthwhile to have a standardized approach to handling notches. What is the best approach to address this?
Related: https://lore.kernel.org/dri-devel/f8747f99-0695-5be0-841f-4f72ba5d5da3@connolly.tech/
The easiest fix would be to add a bezel (black bar) to the top of the phone. However, this doesn't cover cases when the screen is curved on the corners.
Cc: @emersionhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/116Transparent fullscreen surfaces2024-03-23T22:30:09ZXaver HuglTransparent fullscreen surfaces`xdg_toplevel.set_fullscreen` says that
```
If the fullscreened surface is not opaque, the compositor must make
sure that other screen content not part of the same surface tree (made
up of subsurfaces, popups or similarly coupled surface...`xdg_toplevel.set_fullscreen` says that
```
If the fullscreened surface is not opaque, the compositor must make
sure that other screen content not part of the same surface tree (made
up of subsurfaces, popups or similarly coupled surfaces) are not
visible below the fullscreened surface
```
While that is useful for some applications, for use cases like transparent+blurred fullscreen application launchers or terminal emulators, it takes away functionality that users expect. KWin currently doesn't enforce opaqueness in part to not break that expectation, but that of course has the potential to break clients relying on that functionality.
The most straight-forward way to handle this would probably be to add a `set_transparent_fullscreen` request (plus the corresponding capability and state) that allows for (partially) transparent surfaces.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/46Input method and key repetition2023-01-23T04:29:11ZWeng XuetianInput method and key repetitionThe state of art is that the key repetition is implemented in wayland client.
This introduced a new issue regarding key repetition and input method.
The current zwp_input_method_v3, the input method would
1. Create keyboard grab
2. Al...The state of art is that the key repetition is implemented in wayland client.
This introduced a new issue regarding key repetition and input method.
The current zwp_input_method_v3, the input method would
1. Create keyboard grab
2. All key event goes to input method instead of client, thus client can not do client side key repetition.
3. Input method need to handle the key repetition on its own, and forward back the "repeated" key back via zwp_virtual_keyboard_v1.
4. If client has no clear distinguish between the synthetic key and real physical key, it may trigger client side key repetition.
Here's a pull request that makes me think there's some fundamental issue within the current approach. https://github.com/fcitx/fcitx5/pull/274
As for some background, there is a feature in fcitx that detect the repeated key and do something different.
Normal use case:
1. User presses key A
2. Input method receives A, handles it.
3. Input method triggers its own key repetition code and handle following repeated key "A".
Some problematic use case 1:
1. User presses key A
2. Input method receives A, but it does not want to handle the first "A", use zwp_virtual_keyboard_v1 to forward it back to compositor.
3a. Input method triggers its own key repetition code and handle following repeated key "A".
3b. Client receive key from step 2 and triggers key repetition.
Some problematic use case 2:
1. User presses key A
2. Input method receives A, and handles it.
3. Input method triggers its own key repetition code and handle 2nd, 3rd repeated key "A". But the following repeated "A" in input method logic (based on engine) need to be ignored, so it forward synthetic repeated key created on input method side. The "repetition trigger duration" is already handled once on input method side.
4. client received synthetic key A and trigger key repetition from the very beginning, which goes through the key repetition start up time again.
The source of this problem is that there are multiple sources of key repetition and they just can't agree with each other. In X11, key repetition always comes from server so there's no problem. If we want to keep key repetition handling on wayland client, the input method then cannot use the "keyboard grab" approach, otherwise there will be always who should generate key repetition problem.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/184Auto-fill API2024-03-25T19:58:12ZXaver HuglAuto-fill APICurrently there's no good way for password managers to have working autofill on Wayland. Afaiu on X11 that works something like this:
- the user pressed a global shortcut or opens the password manager manually
- the password manager look...Currently there's no good way for password managers to have working autofill on Wayland. Afaiu on X11 that works something like this:
- the user pressed a global shortcut or opens the password manager manually
- the password manager looks at the currently focused window, its application name and window title (if it wasn't opened manually)
- the password manager offers a list of passwords to choose from
- once a password is selected, the password manager uses X11 to type in a password, potentially with tab and enter to jump between input fields
I think we can make that work in Wayland without too many issues, and we can make it work better than on X11. My idea is relatively similar to how input methods work:
- two protocols, one for password managers, one for applications
- for the password manager side:
- the compositor ensures that only trusted clients bind to this interface. The password manager could maybe be started by the compositor, like at least KWin does with input methods
- the compositor can ask the password manager to fill in some password - on global shortcut, or application request. It gives additional information like application name and window title, so that the password manager can show a curated list of logins to select from
- the password manager can create a surface with some special interface for positioning it close to the input field - like `zwp_input_panel_surface_v1` but in not terrible, and with the possibility for keyboard input (for searching through logins, or inputting a new one)
- the password manager can send the login name (account, email, whatever) + password (or pin, or whatever) to the compositor, which will input it into the correct window through whatever means is appropriate. The compositor ensures that input never goes to the wrong window, even if focus is changed before the input happens
- for the client side:
- the client can advertise a login field to be selected, with additional information like
- the position and size of the input field
- the website or service the login is for
- what kind of login data needs to be filled in (username, email, password, credit card information, addresses)
- what login data is already filled in
- the compositor can give the client a list of key:value pairs to fill in
- if the client doesn't support the interface (or even if it does and just doesn't trigger it in some situation), the user can still manually press a keyboard shortcut to trigger the password manager's prompt. Input would happen through `wl_keyboard` or `text-input-v1/2/3` in that case
Open questions:
- does this have to be in Wayland, or should it be a portal? I think it does belong here; doing this requires privileged information about windows, input into them, placement of overlay surfaces relative to app's windows / content in them, and the compositor is heavily involved in all of those
- do we need to support multiple password managers being active at once?
- what about passkeys? I don't know a lot about them tbh, they might require additional information exchange?
Some input from password manager developers would be nice; I can't comment on the keepassxc issue about this, but @vimpostor seems to be involved with it?https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/89wayland-protocols needs replacement for XDS dnd file saving protocol2023-02-14T12:39:29ZNelson Benítez Leónwayland-protocols needs replacement for XDS dnd file saving protocolWe need a wayland equivalent protocol to replace XDS (https://freedesktop.org/wiki/Specifications/XDS/)
XDS support is currently broken between File roller and Nautilus under Wayland ([see issue](https://gitlab.gnome.org/GNOME/file-roll...We need a wayland equivalent protocol to replace XDS (https://freedesktop.org/wiki/Specifications/XDS/)
XDS support is currently broken between File roller and Nautilus under Wayland ([see issue](https://gitlab.gnome.org/GNOME/file-roller/-/issues/4)).
Having a Direct Save Dnd protocol is useful for more applications apart from file-roller, GIMP also had support for this, which let you drag the image from inside GIMP over a Nautilus directory and be saved there (this is now broken on wayland). Thanks to XDS you could also drag a file from inside file-roller and drop it over Gedit and be opened for editing ([relevant commit](https://gitlab.gnome.org/GNOME/gedit/-/commit/c1c3b568ec6294f49d1ce7e90ae64109c4dc3a93)).
About the protocol:\
Basically, we just need the drag target to be able to communicate a path (or list of paths) to the drag source, the drag source will then transfer the files and communicate when it's finished to the drag target (as the target app may want to open the files after that).
Can this be done as an extension over the current wayland dnd protocol? or maybe needs a separate wayland protocol?https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/72Add support for positioning clients in outputs2023-12-08T21:21:44ZPetr MánekAdd support for positioning clients in outputsSome clients offer the capability to position themselves at absolute X/Y locations in an output, or relative to output's bounds. From the user perspective, this is usually accomplished with a `--geometry` shell option or a similar config...Some clients offer the capability to position themselves at absolute X/Y locations in an output, or relative to output's bounds. From the user perspective, this is usually accomplished with a `--geometry` shell option or a similar configuration parameter (see [example here][xterm]). While X11 [supports this behavior][confwin], to my knowledge similar implementation does _not_ exist in xdg-shell or any other Wayland protocols.
I am attaching a reference to [mpv issue][mpv], which lead to the creation of this proposal.
[xterm]: https://unix.stackexchange.com/a/269335
[confwin]: https://www.x.org/releases/X11R7.5/doc/man/man3/XMoveWindow.3.html
[mpv]: https://github.com/mpv-player/mpv/issues/8692https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/38Add a way to express an 'suspended' state2021-06-18T18:00:13ZRobert MaderAdd a way to express an 'suspended' stateApplications may have ways to reduce resource consumption when not actively in use - for example when hidden behind other windows etc. One example here are browsers that throttle JS timers in such cases.
In the moment it is somewhat pos...Applications may have ways to reduce resource consumption when not actively in use - for example when hidden behind other windows etc. One example here are browsers that throttle JS timers in such cases.
In the moment it is somewhat possible to do this by adding some heuristic around frame callbacks, however it might make sense to have an explicit hint, controlled by the compositor. For example for app overviews, where apps may not be woken up.
Some points from IRC:
- may or may not be defined as "visible"
- may or may not be defined as "watch your resources, noone cares about you right now"
- could be added to xdg-shell
- could be helpful on Xwayland/WMs as well to emulate similar X11 optimizations (`XVisibilityEvent`, map/unmap, `NET_WM_STATE_HIDDEN`)https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/32Create a website with some document engine2023-03-06T15:37:33ZPekka Paalanenppaalanen@gmail.comCreate a website with some document engineWe are starting to use more and more RestructuredText documents for protocol extensions, and the README etc. are in ReST already as well. GitLab showing ReST files as rendered documents has worked ok'ish so far, but now that I want to us...We are starting to use more and more RestructuredText documents for protocol extensions, and the README etc. are in ReST already as well. GitLab showing ReST files as rendered documents has worked ok'ish so far, but now that I want to use math with the CM&HDR documentation, it's no longer sufficient. [GitLab does not render math elements.](https://gitlab.com/gitlab-org/gitlab/-/issues/222805)
The reason I originally suggested using ReST is that Weston is using ReST for its documentation already and it uses Sphinx as the engine. Weston also includes documentation from code comments with varying degrees of success. You can check [the Weston documentation web site](https://wayland.pages.freedesktop.org/weston/). You can also see [Weston's CI directives](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/.gitlab-ci.yml) for generating the website automatically. Unfortunately [Sphinx does not integrate well with Meson](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/doc/sphinx/meson.build), but it's the best we could find for Weston [when we looked](https://gitlab.freedesktop.org/wayland/weston/-/issues/216). There are several issues with it still: wayland/weston#308, wayland/weston#315, wayland/weston#316, wayland/weston#365.
What is not covered by the Weston Sphinx setup is generating documentation from protocol XML, which would be really nice for both wayland-protocols and wayland. Wayland currently uses [an unholy construction](https://gitlab.freedesktop.org/wayland/wayland/-/tree/master/doc) of Doxygen, DocBook and [hand-crafted XSLT (!)](https://gitlab.freedesktop.org/wayland/wayland/-/tree/master/doc/publican) to create the Wayland book, which is [not automatically published](https://gitlab.freedesktop.org/wayland/wayland/-/issues/48). Unlike Wayland, wayland-protocols probably doesn't need to generate documentation from code comments.
Additionally, wayland-protocols wants to generate [the adoption website (Section 3)](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/GOVERNANCE.md) from some sort of database'ish.
We have some precedent with Sphinx, so I would suggest attempting with it first. My immediate need is to just get HTML generated from all the ReST files with proper handling of mathematical formulas, but how to generate documentation from Wayland XML is also important in the long run.
Once wayland-protocols has perfected the documentation generation from Wayland XML files, then maybe Wayland itself can start using that and generating documentation from code comments and [move the Wayland book into Gitlab pages](https://gitlab.freedesktop.org/wayland/wayland/-/issues/48#note_453031) instead of needing to copy it into [wayland-web repository](https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org).https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/23xdg-decoration: differentiate between shadows and actual visible decoration2023-07-21T10:20:34ZChristian Rauchrauch.christian@gmx.dexdg-decoration: differentiate between shadows and actual visible decorationThe definition of `xdg-decoration` only knows two modes where all decoration surfaces are either drawn by the client or the server. Decorations usually consist of the visible surfaces inside the window geometry, such as the title bar and...The definition of `xdg-decoration` only knows two modes where all decoration surfaces are either drawn by the client or the server. Decorations usually consist of the visible surfaces inside the window geometry, such as the title bar and buttons, and the "invisible" shadows outside of the window geometry, where "window geometry" refers to the region defined by `xdg_surface.set_window_geometry`.
Since `xdg-decoration` does not distinguish between these two sets, it is not possible to toggle either of those independently. This has the downside that a client with server-side decorations cannot disable decorations without also disabling shadows. A use case for this is an undecorated client that would like to use shadows to visually separate it from other visible clients. A concrete usage of this is `glfwWindowHint(GLFW_DECORATED, GLFW_FALSE)` in GLFW, which on X11 will only hide the title bar but keep shadows.
On top of this, it would be useful if clients with client-side decorations could request server-side shadows from the compositor. This would align the visual shadow style of different toolkits and clients that do not make use of third-party toolkits, such as GLFW and SDL.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/7xdg-output doesn't belong in the xdg namespace2023-12-16T13:31:56ZSimon Sercontact@emersion.frxdg-output doesn't belong in the xdg namespacexdg-output doesn't fit well in the description of the xdg namespace.
In general, regular clients shouldn't care about geometry metadata they can get from xdg-output. There are special cases like Xwayland, which needs this information. T...xdg-output doesn't fit well in the description of the xdg namespace.
In general, regular clients shouldn't care about geometry metadata they can get from xdg-output. There are special cases like Xwayland, which needs this information. There's an opportunity to stop exposing this protocol from regular clients to prevent them from e.g. configuring the size of their surface depending on the xdg-output geometry.
Another part of xdg-output are the more recent name/description events. Arguably these could (should?) be part of the core protocol, because compositors not arranging clients in a 2D coordinate space (e.g. VR compositors) may still want to advertise a name/description (without advertising a geometry).
Apart from these two issues, I guess the real issue is that xdg-output has nothing to do with window management.
```
2019-02-19 19:27:32 jadahl honenstly I think the original "xdg_output" should have been xwayland_output and distributed by Xwayland. then we could hav created a wp_output for name, description etc
```
* * *
We can't really do anything about xdg-output-unstable-v1, but maybe we should consider fixing this for v2.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/185cursor shape issues2024-03-27T22:14:38ZMatthias Clasencursor shape issuesThe cursor shape protocol is following the css ui spec for the allowed cursor values.
Unfortunately, the css ui spec is a bit insufficient when it comes to cursor values.
There are at least two problems that should be addressed before ...The cursor shape protocol is following the css ui spec for the allowed cursor values.
Unfortunately, the css ui spec is a bit insufficient when it comes to cursor values.
There are at least two problems that should be addressed before hardcoding these cursor values into a Wayland protocol.
- The 'move' cursor is meant to represent that the move action is selected during a dnd operation (that is why it is in the "Drag and Drop" section of the css spec), but since there is no cursor for moving things in the "Resizing and scrolling" section, everybody is misusing 'move' for moving windows, and similar operations that are not related to dnd actions. Suggestion: Add a 'nesw_move' value that can be used instead of 'move' for these cases.
- The Wayland protocol supports 'ask' as a dnd action, and cursor themes commonly include a dnd-ask cursor. But the css spec omitted this drag action from their cursor enumeration. It should be added, to fully support Wayland dnd in the cursor shape protocol.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/132fractional-scale-v1: should advise on rounding calculation2024-02-05T16:25:28ZM. Stoecklfractional-scale-v1: should advise on rounding calculationThe [`fractional-scale-v1`](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/cf838fd316f74b0a79ca6cbe1a5cf2548c8265c2/staging/fractional-scale/fractional-scale-v1.xml) protocol describes how, given a fractional scale value...The [`fractional-scale-v1`](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/cf838fd316f74b0a79ca6cbe1a5cf2548c8265c2/staging/fractional-scale/fractional-scale-v1.xml) protocol describes how, given a fractional scale value, clients should compute the a buffer size to use in conjunction with wp_viewport. Quoting:
> The buffer size is calculated by multiplying the surface size by the scale.
> [...]
> if a surface has a surface-local size of 100 px by 50 px and wishes to
> submit buffers with a scale of 1.5, then a buffer of 150px by 75 px should
> be used and the wp_viewport destination rectangle should be 100 px by 50 px.
>
> For toplevel surfaces, the size is rounded halfway away from zero. The
> rounding algorithm for subsurface position and size is not defined.
Say a client wants to submit a wl_surface which is W by H logical pixels in size, following the advice of the above protocol; and the scale factor provided by wp_fractional_scale_v1::preferred_scale is the fraction S / 120. Then the width of the wl_buffer that the client should submit is (expressed using pseudocode):
```
round(W * (S / 120))
```
The rounding rule is that if W*(S/120) has fractional part less than 1/2, the number is rounded down; and if it has fractional part >= 1/2, the number is rounded up. To compute this by hand, one would use rational numbers; for example, if W=300, S=11, then 300 * (11/120) = 3300/120 = 55/2 = 27 ½ , which rounds to 28.)
Unfortunately, the C programming language has only two easily accessible types of numbers: bounded range integers and IEEE754 binary floating point. One can compute the above formula using just integers (`(W*S + 60)/120`), but more general calculations are tricky to do right. Computations with floating point look closer to the mathematical formulas. For example, directly translating the above pseudocode formula to C can be done like this:
```
int W = 300;
int S = 11;
double scale = S / 120.;
int v = llround(W * scale);
```
However, because binary floating point can only approximate multiples of 1/120, this code gives the wrong output; `scale` evaluates to `0.09166666666666666 = 0x1.7777777777777p-4`, and `W * scale` evaluates to `27.499999999999996 = 0x1.b7fffffffffffp+4`, which has fractional part less than 1/2; so `llround` produces 27, which is incorrect.
Depending on whether computations are done in float, double, or a mixture of the two; and on the order of operations, direct translations into C may (or may not) give incorrect results for a small fraction of possible inputs. See https://github.com/swaywm/swaybg/pull/56#discussion_r1114733556 for some more analysis. (Note: If one must use floating point, one way to calculate the buffer dimensions correctly is to bias the value before rounding, like `llround( W * (S / 120.) + 1/240.)`, and use double precision everywhere.).
Considering the above, I think that *The text of the `fractional-scale-v1` protocol should be edited to help implementers avoid this type of error.*
A prior thread on this topic is at https://github.com/swaywm/swaybg/pull/56#discussion_r1112237340.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/131keyboard-shortcuts-inhibit: add key filter2023-05-14T05:57:46ZSimon Sercontact@emersion.frkeyboard-shortcuts-inhibit: add key filterThe KeyboardLock W3C API has a concept of [reserved key codes](https://wicg.github.io/keyboard-lock/#keyboard-reserved-key-codes). When inhibiting keyboard shortcuts, the caller can specify a list of keycodes they're interested in. Keybo...The KeyboardLock W3C API has a concept of [reserved key codes](https://wicg.github.io/keyboard-lock/#keyboard-reserved-key-codes). When inhibiting keyboard shortcuts, the caller can specify a list of keycodes they're interested in. Keyboard shortcuts including these keycodes are inhibited, the rest continues to work as usual.
To support this, we'd need to expand the keyboard-shortcuts-inhibit protocol to send the keys.
See: https://bugs.chromium.org/p/chromium/issues/detail?id=1408927#c3