Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • W wayland-protocols
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 78
    • Issues 78
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 55
    • Merge requests 55
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • wayland-protocols
  • Issues
  • #25

Closed
Open
Created Jul 24, 2020 by Dorota Czaplejewicz (Purism)@dcz_purism

Timestamps for synthetic input events

Proposed protocols like virtual-pointer or virtual-keyboard are being designed to let compositor generate synthetic input events. Both of them give the compositor timestamps, in order to synchronize the desired generated input events with input events from other sources.

This works well when the clients work as transformers: a keyboard event goes in, a pointer event goes out. Both use the same time stamp, synchronization is achieved.

However, they don't work so well when they need to convert an event without a timestamp into an input event. The trigger could come from a source like DBus: a request to hide the keyboard should result in the unpressing of keys. The events could be related to the system clock, but a timestamped source from a random clock would still not match the timestamps the compositor uses, which are "arbitrary base".

The solution that I have in mind is to give the client a way to find out the clock for input events. For example, a request in the form:

request: clock_manager.get_current_input_time(seat)
event: clock_manager.current_input_time(seat, int ms_time_since_epoch)

That would have to be part of every protocol that ever needs to generate input events (like text-input could in the future), so there was the idea that it could maybe become part of input-timestamps instead.

Does this proposal make sense?

Assignee
Assign to
Time tracking