Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Sunday, June 5th, 2022 at 20:16, Zack Rusin wrote: > > At any rate, I consider broken any driver which exposes a cursor plane, > > then doesn't display it exactly at the CRTC_X/CRTC_Y > > But we do… The cursor is at crtc_x, crtc_y. How do you show the cursor on the host side then? Pretty sure you use the host X11/Wayland cursor? In which case nothing guarantees that the host cursor position matches CRTC_X/CRTC_Y.
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Fri, 3 Jun 2022 14:38:54 + Zack Rusin wrote: > > On Jun 3, 2022, at 10:32 AM, Simon Ser wrote: > > > > ⚠ External Email > > > > On Friday, June 3rd, 2022 at 16:27, Zack Rusin wrote: > > > >>> In particular: since the driver will ignore the KMS cursor plane > >>> position set by user-space, I don't think it's okay to just expose > >>> without opt-in from user-space (e.g. with a DRM_CLIENT_CAP). > >>> > >>> cc wayland-devel and Pekka for user-space feedback. > >> > >> I think Thomas expressed our concerns and reasons why those wouldn’t > >> work for us back then. Is there something else you’d like to add? > > > > I disagreed, and I don't understand Thomas' reasoning. > > > > KMS clients will need an update to work correctly. Adding a new prop > > without a cap leaves existing KMS clients broken. Adding a cap allows > > both existing KMS clients and updated KMS clients to work correctly. > > I’m not sure what you mean here. They are broken right now. That’s > what we’re fixing. That’s the reason why the virtualized drivers are > on deny-lists for all atomic kms. So nothing needs to be updated. If Hi Zack, please, stop removing all email quoting level indicators, you have been doing that a lot in your more recent replies. It makes reading the emails really difficult, and I had to stop trying to make sense of the latest emails. It is really unfortunate that display servers have driver deny-lists indeed. All the bug reports they got from being broken should have been denied and forwarded to the respective drivers instead for breaking the KMS UAPI. OTOH, I understand that some userspace projects do not want to stop because of few broken but popular drivers. > you have a kms client that was using virtualized drivers with atomic > kms then mouse clicks never worked correctly. So, yes, clients need > to set cursor hotspot if they want mouse to work correctly with > virtualized drivers. I'm very much agreeing with Simon. He has made similar questions and comments that occurred to me. Reading as much of the discussion between Simon and Zack as I could, it seems every time Simon gets to the point, Zack hops to a completely different use case to make Simon's argument no longer apply. Like, root-window-less per-window remoting through KMS? How is that even possible? > >>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin z...@kde.org wrote: > >>> > - all userspace code needs to hardcore a list of drivers which require > hotspots because there's no way to query from drm "does this driver > require hotspot" > >>> > >>> Can you elaborate? I'm not sure I understand what you mean here. > >> > >> Only some drivers require informations about cursor hotspot, user space > >> currently has no way of figuring out which ones are those, i.e. amdgpu > >> doesn’t care about hotspots, qxl does so when running on qxl without > >> properly set cursor hotspot atomic kms will result in a desktop where > >> mouse clicks have incorrect coordinates. > >> > >> There’s no way to differentiate between drivers that do not care about > >> cursor hotspots and ones that absolutely require it. > > > > Only VM drivers should expose the hotspot properties. Real drivers like > > amdgpu must not expose it. > > Yes, that’s what I said. There’s no way to differentiate between > amdgpu that doesn’t have those properties and virtio_gpu driver from > a kernel before hotspot properties were added. Why would userspace want to tell the difference between a driver that truly does not need those properties, and a driver that did not add those properties *yet*? Thanks, pq pgpPaDwTUVGSH.pgp Description: OpenPGP digital signature
[ANNOUNCE] libei 0.3
libei 0.3 is now available. libei is a library to send Emulated Input (EI) to a matching Emulated Input Server (EIS) which can receive those events with libeis, also part of this project. libei uses GitLab releases, for tarballs please see: https://gitlab.freedesktop.org/libinput/libei/-/releases/0.3 Notable changes since 0.2: - libei now supports the concept of sender/receiver contexts. A libei context in sender mode can send events to the (EIS-created) devices, a libei context in receiver mode can receive events from the (EIS-created) devices. This allows for libei to be used as a transport layer for captured input events (the synergy server use-case). - a libei context can bind/unbind to seat capabilities individually at any time - frame events now carry a timestamp - a helper tool ei-debug-events is now available, this tool can be used in e.g. portal implementation to show the events being sent. This is a development snapshot and neither API nor ABI should be considered stable. Anyone using libei or libeis must keep both in sync, there are no accommodations made for libei/libeis from different versions and the wire protocol may break at any time. Please see the API documentation here: https://libinput.pages.freedesktop.org/libei/ The git shortlog is below: David Redondo (1): Some doc fixes relating to keymaps Jonas Ådahl (7): libei: Clarify whether a context owns a passed fd eis: Clarify mmap restrictions on keymap eis: Fix a couple of coding style issues eis: Add API to add client getting an fd eirpecken: Use the new eis_backend_fd_add_client() eis: Remove eis_backend_fd_add_fd() Only auto-stop emulating if sender Peter Hutterer (64): Fix a typo in the docs Documentation updates meson.build: don't pass werror through to munit gitlab CI: move the pages job configuration to config.yml gitlab CI: add a -Werror job (allowed to fail) gitlab CI: drop the requirement for Signed-off-by Add SPDX identifiers to all source files gitlab CI: fail the CI early if the fork is private util: add a helper for fetching the cmdline. eis: add the functions to fetch a region back from the device test: localize a coordinate set a bit better test: add a helper function to mark test progress test: aded a test for key events util-object: split macro to generate unref into one two test: define peck_unrefp in the header file doc: document the events a little doc: fix the documentation for the eis capabilities doc: updates all over the place eis: don't allow for region changes once the region was added Add concept of active/passive libei contexts tools: add active/passive mode to the demo server and client test: add test cases for eis -> ei events ei: require the client to confirm capabilities rather than drop them eis: remove eis_device_set_name(), use eis_device_configure_name() eis: after the client binds the seat, drop the capabilities meson.build: fix a deprecation warning Fix a comment referring to an old implementation Remove a stray uint32_t from the documentation Correct two comments regarding active vs passive context Add ei_is_active() eis: the EIS context does not have a is_active setting Change to allow dynamic binding of capabilities Differentiate between physical and virtual devices Rename ei active/passive to sender/receiver tools: print the returned negative errno on failure tools: fix a few issues in the demo server tools: add ei-debug-events Whitespace fix Improve the "message type" debug output a bit Better touch debugging messages test: make the dispatch looping easier to understand in the debug logs test: use the helper functions to enable the default behaviors test: handle frame events in passive ei contexts by default ei: frame events must be sent on state emulating, not resumed test: add a few missing frame events Only send touch up events on destroy if the touch is down Enforce a frame after ei_touch_destroy() Filter empty frame events test: ensure we only get frame events after device events Add a bunch of warnings when sending events outside of emulating Warn if the touch isn't down for a touch motion Flush the frame event before a stop_emulating Assert on start_emulating if we're left with a pending frame event Add a filter for empty frames on the receiver side ei: add receiver handling for empty/flushing frame events Remove an outdated comment Print the strerror too if a message fails Add timestamps to frame events util: add the macros to run through a list backwards ei: expose ei_event_get_context() internally Add a pending event queue for incoming device events Retrof
