crashmedia/wayland-protocols
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/wayland/wayland-protocols.git synced 2026-07-21 15:07:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
Page: meetings
Pages
home meetings
17 meetings
Carlos Garnacho edited this page 2024-07-02 21:23:28 +00:00
Table of Contents

This page tracks meetings held with wayland-protocols members. Meeting notes are collected here.

[[TOC]]

2024-07-02 - Text input 3.2 (2)

  • Attendees: Vlad Zahorodnii, Victoria Brekenfeld, Peng Wu, Orko Garai, Mike FABIAN, Kramer Ge, David Redendo, David Edmundson, Alexey Ushakov, Carlos Garnacho, Jonas Ådahl, Nikita Provotorov, moon

  • Commit on click (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/71)

    • Behavior necessary for Hangul
    • seems doable on the compositor side, should not be necessary to add protocol plumbing?

  • Key event routing (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/233)

    • https://w3c.github.io/uievents/tools/key-event-viewer.html
    • Carlos: After review of W3C specs, it seems better not to deviate in excess from it, a serial-based approach as discussed previous meeting may work.
    • Orko: Chromium does want key events before IM. Should not be a blocker to get started on a v3 implementation.
    • Action: Implement new MR with protocol change (Carlos)

  • Pre-edit text hints (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/234)

    • Mike: Traditionally, IMs have had the ability to set preedit color values (fg/bg) in RGB values. There are too many, too different usecases for preedit style, examples:
      • indicating navigation across multi-word preedit for word-by-word edition
      • indicating autocompleted part inline, vs. already typed
      • indicating impossible/mistaken words
      • Different IMs may have different usecases, there's a number of them
    • Consensus seems to be that it's better to avoid color information
    • Mike: Feedback from Matthias Clasen is to make a semantic list, however it proves hard to come up with a comprehensive list.
    • Mike: Looking at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/234, it seems to provide enough variety for input methods not to run short.
    • Carlos: Will look into Mutter/GTK implementations. The biggest sore point is going to be integration with the current preedit styling APIs in input methods.
    • David: Would like a name for "pre-completion" something to say "sticks out less than current text"

  • Reset API (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/34)

    • Orko: Chromium wants this for when you click in the same field in a different place.
    • Peng: Can be solved with disable request and enable request sequence. But if we want to go down this path, we would need to document it. A reset is functionally equivalent.
    • Agreement: It's better to have less stuff, lets leave as is and document it.
    • Action: (Peng) Create an MR documenting it.

  • Input panel show/hide

    • Currently implicit. Having a explicit action makes sense
    • lets go for 3.2
    • Action: (Carlos) make a MR

  • Preedit-shown hint (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/66).

    • David: Sounds useful, but perhaps avoidable if nobody is doing anything with it in practice
    • Carlos: it's pretty much unused from the GNOME side
    • Action (David Edmundson): "A pre-edit shown hint" email someone at SDL to see if we can make it do something useful.

  • Next meeting? Might be better to see some action first.

2024-05-13 - Text input 3.2

Merge request: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/282

  • Attendees: Jonas Ådahl, Carlos Garnacho, Austin Shafer, David Edmundson, David Redondo, Orko Garai, Vlad Zahorodnii, Xuetian Weng

  • Text input actions (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/73)

    • Sending actions like backspace, instead of via wl_keyboard. Carlos says the original MR had a bit more in the past, but is now a good initial set of actions to get the ball rolling on actions.
    • Xuetian: Might think delete_surrounding is similar to delete, but from input method point of view it's different; needs distinguish "backspace" from deleting entered text, as it makes no sense in e.g. a terminal emulator. In fctx, in chinese, when you type "," during typing numbers regular comma, while otherwise it's full width. Backspace / delete_surrounding needs to handle doing the right thing here.
    • Carlos: Similar issue in emoji.
      • Question: what is "submit"? It's a generalized action for e.g. "search" in search field, "send" text messaging field, used to "submit" whatever is entered to somewhere.
      • Question: Perhaps skip 'none' action? It has no use. And then start the first actual action with value 1.
      • Action: Qt implementation. (David E.)
      • Action: Move proposal forward, check with Tadeo, or take over. (Carlos)
      • Action: Updating Input Method to forward actions (David E.?)

  • Key repeat & input routing (https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/46)

    • Server side key repetition might solve problems related to key repeat.
    • Xuetian: Semi related to key repeat; Chromium appears to claim that to implement w3c support, keys needs to always pass via the web engine (and web page(?)) meaning input_method.grab_keyboard() not doable. Why is this related to key repeat? If we change the flow of keys, key repeat as it works today, can be fixed by routing keys via the text-input. Could be solved similarly to the "replay" question, but for key-by-key, by re-routing events from input-method to the input method via serials.
    • Keys sent via wl_keyboard and then to the input method could also solve e.g. holding backspace (key repeat), and first erasing pre-edit text, then automagically continue erasing already committed text.
    • Problems with re-routing key events via wl_keyboard instead of text-input are inconsistent modifier and xkb state, or modifier state that might not reflect reality, e.g. input method needs shift to still be pressed, but in reality it has been released. It could also be useful to actually know what is being replayed by the input method.
    • Routing input events via text input can still avoid arbitrary input injection by clients by using serials. Client side repeat can be handled by allowing repeating a serial. Xkb has state to know whether keys can be repeated or not, and should ignore when it that is the case.
    • There are use cases for arbitrary injection (e.g. client side OSK), but lets handle that separately. Could perhaps even be client side completely.
    • Different client side OSK being less problematic, is e.g. calculator with a number entry. It should have text-entry, but it should allow not showing compositor side OSK or input panel, and UI keys wouldn't go via the input method.
      • Action: Look up what W3C says about this, to know if our hands are tied or not. (Carlos, Xuetian can also check with Chrome people)

  • Surrounding text

    • Xuetian: If there are two widgets, one supporting supporting_text, another don't. How should it work one moves between them?
    • One might say just do disable/enable, but clients doesn't appear to do that when switching focus between text entries. Would prefer some hint from text-input whether it is currently supported by the context.
    • Carlos: Perhaps useful for terminals, but for different text entries, there should be disable/commit/.../enable between these still, which would make the information about surrounding text support being available.
      • Action: Make sure Qt does disable/enable when switching focus (Xuetian, with the help of David E)

  • Preedit-commit mode (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/71, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/240)

    • Xuetian: What if a text entry is destroyed before being able to commit text, where does the text go? The suggestions is committing a pre-edit string on widget focus change on the client-side.
    • Jonas: Isn't it a client side issue?
    • Carlos: All other times a pre_edit string is committed from a compositor action.
    • David E: The situation where a client randomly deletes a widget without user intervention doesn't seem like a common problem.
    • Xuetian: There is also the problem with client side commit if pre-edit often is different from committed text. In text-input-v1 there was a "commit string" that was sent together with the pre-edit that would allow clients to commit on focus out without having to coordinate with the compositor.
    • Jonas: To make this possible, we'd probably need to carry "session handle" for text-input's to associate commit_string with "I committed by myself" hints from the client.
    • David E.: Maybe we should postpone dealing with client commits to 3.3, to not stall 3.2 too much.

  • Forward language from IM -> client (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/241)

    • Non controversial
      • Question: What about RTL and input method GUI (E.g. chinese when the surrounding language and future language hint is arabic)? Don't change the UI, but change text. But really, should probably involve someone who know and use RTL.
      • Action: Add !241 to MR (Carlos)

  • Other hints in the MR seem uncontroversial (no emoji, on_screen_input_provided, preedit_shown, also input rectangle synchronization)

    • Action: Schedule follow-up meeting for remaining controversial topics (Carlos)

2024-04-08 - Group transactions

Merge request in question: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26

  • Attendes: Jonas Ådahl, any1, Carlos Garnacho, David Edmundson, David Redondo, Michel Dänzer, Sebastian Wick, Simon, Victoria Brekenfeld, Vlad Zahorodnii, Xaver Hugl

  • A few administrative things to complete, e.g. moving to staging, addressing a few review issues

  • Main thing that needs consensus is to agree on semantics for handling synchronous subsurfaces

    • Ignoring synchronous subsurface has issues as it can lead to out of order content updates

    • Sending errors if mixing is problematic if different components of the same clients that doesn't know about each other use both transactions and sync subsurfaces

    • Deprecating sync subsurfaces would be nice but has its downsides. e.g. libdecor uses sync subsurfaces quite nicely to group decoration updates on the main surface

      • sounds possible to handle in some different manner, but needs some thinking
      • doesn't allow removal of related functionality for compositors who want backward compatibility

    • Rough consensus (?) is to bite the bullet and spell out how group transactions and sync subsurface trees interact, and leave deprecation to Wayland 2.0.

  • How to mix usage of transactions between drivers, toolkits, and apps

    • Should probably not allow usage in drivers
    • Toolkits should make their own decision, and potentially allow applications to integrate

  • Way forward:

    • Continue on Michel's suggestion and define interactions
    • Possibly change the wording to describe phases of applying a transaction commit. Jonas to make a suggestion.

So far the test case that exists is the original gtk4 implementation. Test case mostly used is testpopover.c in tests/. More test cases would be nice.

Other use cases for group transaction is session management (restore multiple toplevels together) and potentially also relative positioning (placing multiple windows knowing each of their sizes).

Side note:

  • Simon will merge the alpha modifier protocol.

2023-11-01 - Color Management

Attendees: Victoria B., Carlos G., Xaver H., Mario K, Pekka P., Jehan P., Aleix P., Simon S., Sebastian W.

Calibration and profiling

  • GIMP (and others) want an advanced color calibration workflow.
  • Compositors currently have different ways to calibrate and characterize on different monitors. There's no reliable and cross-compositor way
  • We want a Wayland extension for calibration+characterization. Things to observe:
    • disabling red shift / effects and other color adjustments
    • ensuring the profiling window is not occluded
    • disabling screensaver
    • ...
  • https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/27
  • Requirements are clear, mostly needs work.
  • Need to implement color management in compositors first, because profiling interacts with it.

Using the protocol:

  • Design goals
  • All 3 options are wanted:
    • Color unaware surfaces get default sRGB image description
    • Clients may choose a image description for surfaces, the compositor will adjust for the output.
    • Using the output image description, compositors might "pass through" and avoid color conversions.
  • Which image description to attach
    • A surface knows which outputs it's on, needs to pick best representation for one.
    • The preferred image description is available as a fallback
  • We need to define the meaning and use of the surface preferred image description.

Special pixel formats

  • Usecase: Medical devices with proprietary pixel formats combining multiple pixels (8bit) into a single high bit depth pixel.
  • Xorg used to allow hacking support for it in the client, because client pixels were pushed to display bit-identical.
  • Suggested plan:
    • Support 16-bit unsigned integer per channel RGB pixel formats, to be used by Wayland clients. Alternatively, expose the below special pixel format to Wayland clients.
    • New RGB pixel format (or modifier) in KMS to describe the special false-color layout that makes those special displays possible to drive with existing KMS hardware.
    • Wayland compositors need to support the special pixel format towards KMS.
    • KMS translates the special pixel format with image width W to the commonly supported pixel format with image width 2*W for driving display controller hardware and the cable (DVI/HDMI/DP).
    • Caveat: requires support in each compositor, but also each compositor needs certification anyway in order to guarantee precise color reproduction.

Enum naming CICP

Merging/upstreaming color-management

  • Maybe too early, unless it's stated clear/loud enough that it is unstable.
  • All work is still in a branch anyways.

2023-08-22 - direct input access protocol

issues:

  • backward compatilility
  • input device file descriptor is lost when client looses focus
  • applications might use buttons under the user's nose (steam big picture mode)
  • emulating gamepads

nested compositors (like gamescope) could create a fake controller and remap the controller offered to the client

VR issue: how do VR runtimes get a hold of the controllers

  • portal?
  • runtime should lease the device to grab them

2023-08-16 - toplevel_drag

  • KDE really wants it for some of their apps

  • last open thread resolved

  • does gtk have something that would use this? -> Not yet, would probably need new API as well as a need from designers that it's something useful for GTK

  • firefox seems interested -> david R will look into if it could be integrated

  • needs clarification regarding pointer_focus

    • assuming the wl_data_device.start_drag focus change clarification is accepted, it's enough to rely on it. although unlikely, if not, then it needs to be made behave like xdg_toplevel.move.
    • clarify that the attached window is not a target for itself
      • action item: David R

  • action item: merge kwin as-is under alternative prefix (david R), get more testing in master

  • current DND (start_drag) is a bit underspecified, apparently kwin and mutter does things differently

    • kwin keeps the pointer focus
    • mutter sends a wl_pointer.leave
    • weston sends a wl_pointer.leave

  • consensus is that wl_data_device.start_drag should result in wl_pointer.leave on the source and a wl_data_device.enter on the target (which initially likely is the source)

    • action item: write a patch (Carlos)
    • action item: change kwin (Vlad)

  • clarify the unmap and remap, it needs reattaching (david R).

  • specify that on unmap the toplevel is detached from the drag (david R)

  • Should it be possible to cancel the operation with an attached window (i.e. delete the source) while it happens

    • a) If yes it's more like a dnd
    • b) if no it's more like a move
    • c) it could be made so that deleting the source makes it 100% a toplevel drag
    • d) like a, while making it undefined (compositor policy) what to do with the attached window (move back, continue drag, leave it where it is)

  • Some preference towards d), meaning a DND with an attached toplevel behaves like xdg_toplevel.move to the user, but protocol wise a bit more like a DND.

  • how to treat it (move back (cancel), leave in place, should perhaps be compositor policy

  • One potential problem is treating it like "cancel" and moving it back to the original position is the order of destruction on client termination can cause wierd animation issues when things gets unmapped (e.g. cancel first, destroy toplevel later)

  • action item David R => option d)

2023-08-08 - Xdg session manager

General discussion:

Decision was to make the meeting link public, so anyone can listen in would they so want to, anonymous or not.

Topic for the meeting was xdg-session-manager (!18)

Use cases:

  • save on logout and reboot
    • requires more interaction with a 3rd party service, (but lets focus on the window manager part today )
  • "gimp style" multiple tiny windows. xdg-toplevel-drag solves part, but you still need something on restore
  • "save window" of some windows (user settings)
  • shutdown? Inhibition and cancelling if unsaved changes

There's a guadec talk about session management with gnome's experimentation. Still in experiment phase. https://events.gnome.org/event/101/contributions/453/ https://www.youtube.com/watch?v=hv-bkYpHSbQ

xdg-session-manager could address the use cases of "restore session after reboot", and "gimp style" applications.

"window-id" approach can address compositors letting users configuring spcefic windows in a better way, a bit like wmctl but without having to match window title etc. e.g. "always launch APP A window W at x,y with size w x h.

Apps currently try to restore themselves using their own knowledge, and that's a problem.

The difference between window Id and sesison restore. If you have 5 terminal windows, all have the same window_id, each needs it's own unique ID for session purposes.

Can the "window-id" really not be used for gimp style restoring? It can be compositor policy to handle restoring, and will not need "classified" as restore vs new instance

  • less clear expectations from applications with xdg-session-manager, window-id is fully compositor policy - but compositor can also ignore xdg-session-manager if it wants
  • can't restore different "workspaces" with window-id
  • how to tell apart apps wanting to restore position and ones who dont?

window-id needs buy in from toolkits and applications, toolkits currently lack API for applications to use to classify their windows

General consensus, window-id has a use for "scripting" separate from session stuff.

Xdg-session manager open threads:

  • there's a race on start
  • if a duplicate is used, just fail to restore
  • clients should try to avoid this, but we need to have some prep compositor side
  • if a compositor forgets, we would fail to restore anyway If the client provides an ID and gets denied, then client should use the new ID moving forwards

Other notes were saved on relevant wayland-protocols MR

Potential next meeting topic: toplevel DND. Potential meeting in around two weeks is a follow up to the text input discussions from before.

2023-07-12 - Layer Shell

Discussion about ext-layer-shell.

Difference between wlr/ext:

  • Cleanup, more errors
  • Layer is part of the state
  • app_id instead of namespace
  • No negative margins (replaced by viewporter)
  • Opposite edges are an error now

Issues:

  • exclusive zone has magic values
  • is keyboard interactivity exclusive useful?
    • wlr-input-inhibitor? deprecated nowadays
    • Remove from layer-shell, do in separate protocol somehow
    • Prevent focus stealing from password fields, so maybe send semantic information like that via protocol? would be useful for e.g. web browsers too. policy over mechanism
  • Place surface relative to output (e.g. two thirds from the top) not really possible, if output isn't known (set to null to choose active output)
    • configure_bounds would come too late for set_margin
  • Namespace use-cases
    • KWin: used for different focus/activation behaviour for dock, panel, etc
    • Cosmic: used to not capture certain surfaces via screencopy (mostly when capturing a workspace)
    • Whitelisting app-ids sounds horrible (clients might fake app-id)
    • Semantic enum?
    • Enum for focus / activation behavior?
  • What if the client buffer doesn't match the configure event?
    • fixed aspect ratio, or increment? round up or down?
    • clients can't do anything super malicious that they can't do anyway
    • there are feedback loops IRL
    • maybe clients must obey the configured size? like xdg-shell maximized
  • keyboard exclusivity: who gets initial focus, who gets focus when last toplevel is closed
  • window geometry
    • snapping, with a rectangular dock: window geometry matches snap zone
    • with a iconic dock: window geometry doesn't match, so is window geometry what we really want?
    • maybe a new flag to say whether toplevels can go behind or not?
    • set_size replaced by set_window_geometry?

Action Items:

  • @davidedmundson: List KDE use-cases for namespace client and server
  • @Drakulix: List Cosmic use-cases and skim wlroots/sway wiki for clients
  • Hiding windows from screencopy: @Drakulix will do it in a private procotol for their case
  • @emersion: think about infinite feedback loops a bit more
  • Auto-hide docks:
    • kwin does logic in the compositor and autohides that side
    • for clients to do it themselves layers need to know their position
    • could be done client side, with two layer surfaces with same anchors, one acting as a trigger
    • vlad to send victoria the kwin protocol
    • unity had even more complex paths where some bits could be visible, without the whole dock being visible
    • prototype as separate, could add events/requests later to layer-shell

2023-07-05 - Text Input/InputMethods

Current state of IME-protocols is confusing at best.

  • text-input handles receiving text as a client
    • v2 is not in wayland-protocols
    • v3 generally supported, except for Qt
  • input-method handles IME clients
    • Not supported on gnome (yet?), uses ibus instead
    • v1-v2 in use, but v2 not in wayland-protocols

text-input

=> Lets try do this via incremental changes to v3 instead of a v4

input-method

  • IME's need to re-inject events via e.g. virtual-keyboard..
  • ...

Action Items

  • @davidedmundson: "v3 seems very workable, Qt should implement it"
  • Pull requests for adding onto v3 instead for the wanted features
  • Check with ibus people for further requirements?
  • @carlosg: Search for draft protocol change to add serial to focus-request (type-to-search bug)

2023-06-28 - Prefixes and governance