[ANNOUNCE] libinput 1.17.901
libinput 1.18 RC1 is now available. No big new features, just general fixes and polishing everywhere. This is mostly just flushing the main branch out. I don't expect the need for a second RC. Some of the user-visibile changes are: - Gestures' unaccelerated motion now matches the accelerated motion (without accel, obviously). A bug caused these to be in different scales which didn't work overly well for obvious reasons. - Better gesture detection should reduce the amount of pinch gestures detected as two-finger scrolling. - Pressing the wheel button down now suppresses accidental scroll wheel events. - Reworked clickpad detection means we should be more robust for devices with broken firmware. As usual, please see the git shortlog for details. Alexander Mikhaylenko (1): gestures: Filter unaccelerated deltas for gestures Ben Weston (1): quirk: fix sensitivity for Dell Latitude 7490 pointing-stick Chris Dickson (1): quirks: mark the 0x252 razer keyboard as internal Greg V (4): quirks: recognize SPI bus quirks: add quirks for Apple SPI input devices quirks: implement DMI support on FreeBSD quirks: add wildcard to HID-over-I2C names (for FreeBSD) Hans Gaiser (1): Add quirk for Lenovo Legion 5 Pro. Jonas Ådahl (1): tablet-pad-leds: Open led file with O_NONBLOCK | O_CLOEXEC JoseExposito (9): fallback: replace fallback_dispatch->wheel with an anonymous struct fallback: disable mouse scroll wheel while middle button is pressed tools/code-formatting: Add EditorConfig file touchpad/clickfinger: limit middle click to 3 fingers libinput: change gesture notify cancel parameter from int to bool gestures: rename int filter_motion to bool ignore_motion gestures: move the code to get raw pointer motion to its own function gestures: move up some functions to use them later gestures: move the logic to detect gestures to its own function José Expósito (1): test: cleanup: remove fallthrough followed by break Konstantin Kharlamov (2): util-list.h: simplify code by removing an excess initialization treewide: get rid of `tmp` argument in list_for_each_safe Nicolas Fella (1): doc/user: Add instructions for using with CMake Pedro Ribeiro (1): Add Lenovo Legion 5 keyboard to 50-system-lenovo.quirks Peter Hutterer (55): completion: add missing libinput analyze subtools to the zsh completions tools/per-slot-delta: print the button state too while analyzing tools/per-slot-delta: handle KeyboardInterrupts nicely util: document our list interface tools/debug-gui: start the unaccelerated motion deltas in the screen center tools/debug-gui: move the pointer position into a struct point tools/debug-gui: move the abs pointer position into a struct point tools/debug-gui: draw a sprite for the unaccelerated pointer as well test: fix two inadvertent pointer jumps in a test test: add a comment to the thumb speed test touchpad: always push a touch's current point to the motion history test: localize a few variables test: update a few tests for more modern helpers filter: correct comments about the threshold's unit doc/user: explain why we are doing motion normalization test: fix debugging messages for gesture begin event test: simplify the helper for moving three touches at the same time test: push/pop event frames around three-touch movements tests: add a gesture test to ensure our unaccel deltas are in a sane range tools/record: factor out the output file collection tools/record: de-duplicate an error message tools/record: localize a variable tools/record: free the namelist when we're done tools/record: deduplicate the device opening logic tools/record: switch the output file from an fd to a FILE* tools/record: mark the iprintf function as printf tools/record: get rid of indent push/pop, replace with fixed indents tools/record: append the devices in-order tools/record: remember the first device in the context tools/record: rename the output file handling tools/record: rework the event printing tools/record: line up the "neutral state" message evdev: don't check the event time if it's higher than the dispatch time evdev: don't truncate event time to 32 bits quirks: add palm size quirk for the Gigabyte Aero 15 touchpad: factor out clickpad assignment to a helper touchpad: use some helper variables to make the code easier to read touchpad: a touchpad with only one button is a clickpad touchpad: if we have a right button, let's assume it's not a clickpad gitlab CI: switch to Ubuntu 21.04 doc/user: fix a link to the system hwdb file Change various references to the master branch to main tools/record: fix a strlen assumption
Re: Wayland and window position/size
Hi, Carsten, On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler wrote: > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot said: > > > Hi, list, > > Couple of questions about Wayland, since more and more distros switching ;-) > > > > If I understand correctly window positioning/sizing is based on the > > compositor/window content. > > > > 1. Is there a way to select where each individual program will start? > > The compositor decides this. It may place it randomly, somewhere intelligently > with minimum overlap, relative to some parent surface/window or perhaps it > might store the position it saw that named window at last and restore it to > that position. The compositor may expose such settings to the user, or maybe > not. It's between the compositor and the user and the idea is that it will be > consistent with all windows. OK, so there is no "per-program" settings anywhere. Understood. > > > 1a. If not - will there be one? > > 2. I am working on the program that should start up with the empty > > window - only the toolbar > > and the very basic menu. > > Then when the user chooses some action from the toolbar some child > > windows appear. > > I think such program will always start up with very minimal size, > > basically the size of the toolbar > > under Wayland. Am I wrong? > > That is up to your program. It could create a very wide and narrow window with > just menu bar and toolbar. That's perfectly possible - the buffer you provide > will determine this. Generally for most applications the toolkit you use will > handle all of this for you, unless you are making your own toolkit or you are > nutty enough to avoid a toolkit entirely and try and write everything "bare > metal" in which case essentially your app includes a toolkit and thus the work > that toolkits normally do becomes your work. Well, I'm using wxWidgets (cross-platform library) with GTK underneath. But that should be irrelevant to the problem. My understanding is that the size of the TLW is determined by the content of it I can't just call window->SetSize( 100, 100 ); and the window will obey my command and will be created with the size 100x100. Or can I? > > > 3. How can one write a cross-platform application that should behave > > the same on the different > > platforms when the developer doesn't have control over window position/size. > > Don't try and position a window. I write applications and I simply don't go > positioning the window in my own code. I leave it to the system to decide. It > just so happens my apps work on multiple platforms too because the toolkit > handles that. I expect the system to provide some sensible window positioning > of its own. I know full well that this falls apart quickly unless you spend a > lot of effort doing things like adapting the position you want to the current > resolution, and avoiding putting your window under other obstacles like > panels/taskbars and other elements. I just let the WM/compositor handle that. > If a user has a tiling WM/compositor or a WM capable of tiling modes then > trying to position your window instantly falls apart and assuming/expecting > this works is a recipe for pain. I understand. As I said I believe that the window sizing is based on the window content. So all I am doing is calling: window->Maximize(); which actually works on all 3 major platforms (Windows, *nix+X, OSX). However, my understanding is that it will not work under Wayland. Am I being wrong? For both points? > > > 4. How can a developer write a program that should connect to the database? > > That has nothing to do with Wayland or display systems in general - that's > your > job. What kind of database, where it is, how it's dealt with is up to you. A > separate problem entirely. Actually it does. Most DBMSes provide dialogs for requesting user ID and password. Whether it is ODBC or a native library call. Now those dialogs are usually centered on screen (at least on Windows w/ODBC). And I think the same can be said about OSX. Now the user would be very confused when such dialog will appear in the corner of the screen. Wouldn't you? > > > 5. I know there was a plan to respect a save/restore window > > positioning/size. Is it implemented? > > This is up to compositors to do. Your job is to provide a name for your > window(s) in Wayland so a compositor can implement this sanely. Name of the window or a name of the application? Can you collaborate a little? > > > 6. How complete is Wayland API currently in terms of window > > positioning/sizing? > > Positioning - Don't position and Wayland discourages it by not having such an > API. Sizing - do whatever you like. It just discourages it, so it is not completely impossible, correct? Thank you. > > > Thank you. > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > -- > - Codito,
[ANNOUNCE] libinput 1.17.3
libinput 1.17.3 is now available. The device specific quirks listed below add the necesssary keyboard integration quirk to get palm rejection to work correctly. Hans Gaiser (1): Add quirk for Lenovo Legion 5 Pro. Peter Hutterer (2): gitlab CI: bump from Fedora 32 to 34 libinput 1.17.3 dan g (1): quirks: add palm rejection support for all Razer Blade models git tag: 1.17.3 https://www.freedesktop.org/software/libinput/libinput-1.17.3.tar.xz SHA256: 0d010e0bf601b5d3a06b3c4d77d67751cf554f3e6448e57aa046ea9ee8f818ac libinput-1.17.3.tar.xz SHA512: 3d1ab4362ede886996795d700a938d20e04cd922e8f9598fe9346f9f93e149119526fb324a096787b4b8a47bf3e5613130bcd874f10df86761031710d2acc792 libinput-1.17.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.17.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and window position/size
On Tue, 25 May 2021 16:24:30 -0500 Igor Korot said: > Hi, list, > Couple of questions about Wayland, since more and more distros switching ;-) > > If I understand correctly window positioning/sizing is based on the > compositor/window content. > > 1. Is there a way to select where each individual program will start? The compositor decides this. It may place it randomly, somewhere intelligently with minimum overlap, relative to some parent surface/window or perhaps it might store the position it saw that named window at last and restore it to that position. The compositor may expose such settings to the user, or maybe not. It's between the compositor and the user and the idea is that it will be consistent with all windows. > 1a. If not - will there be one? > 2. I am working on the program that should start up with the empty > window - only the toolbar > and the very basic menu. > Then when the user chooses some action from the toolbar some child > windows appear. > I think such program will always start up with very minimal size, > basically the size of the toolbar > under Wayland. Am I wrong? That is up to your program. It could create a very wide and narrow window with just menu bar and toolbar. That's perfectly possible - the buffer you provide will determine this. Generally for most applications the toolkit you use will handle all of this for you, unless you are making your own toolkit or you are nutty enough to avoid a toolkit entirely and try and write everything "bare metal" in which case essentially your app includes a toolkit and thus the work that toolkits normally do becomes your work. > 3. How can one write a cross-platform application that should behave > the same on the different > platforms when the developer doesn't have control over window position/size. Don't try and position a window. I write applications and I simply don't go positioning the window in my own code. I leave it to the system to decide. It just so happens my apps work on multiple platforms too because the toolkit handles that. I expect the system to provide some sensible window positioning of its own. I know full well that this falls apart quickly unless you spend a lot of effort doing things like adapting the position you want to the current resolution, and avoiding putting your window under other obstacles like panels/taskbars and other elements. I just let the WM/compositor handle that. If a user has a tiling WM/compositor or a WM capable of tiling modes then trying to position your window instantly falls apart and assuming/expecting this works is a recipe for pain. > 4. How can a developer write a program that should connect to the database? That has nothing to do with Wayland or display systems in general - that's your job. What kind of database, where it is, how it's dealt with is up to you. A separate problem entirely. > 5. I know there was a plan to respect a save/restore window > positioning/size. Is it implemented? This is up to compositors to do. Your job is to provide a name for your window(s) in Wayland so a compositor can implement this sanely. > 6. How complete is Wayland API currently in terms of window > positioning/sizing? Positioning - Don't position and Wayland discourages it by not having such an API. Sizing - do whatever you like. > Thank you. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland and window position/size
Hi, list, Couple of questions about Wayland, since more and more distros switching ;-) If I understand correctly window positioning/sizing is based on the compositor/window content. 1. Is there a way to select where each individual program will start? 1a. If not - will there be one? 2. I am working on the program that should start up with the empty window - only the toolbar and the very basic menu. Then when the user chooses some action from the toolbar some child windows appear. I think such program will always start up with very minimal size, basically the size of the toolbar under Wayland. Am I wrong? 3. How can one write a cross-platform application that should behave the same on the different platforms when the developer doesn't have control over window position/size. 4. How can a developer write a program that should connect to the database? 5. I know there was a plan to respect a save/restore window positioning/size. Is it implemented? 6. How complete is Wayland API currently in terms of window positioning/sizing? Thank you. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/7] dma-buf: Add an API for exporting sync files (v11)
Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch Cc: Christian König Cc: Michel Dänzer Cc: Dave Airlie Cc: Bas Nieuwenhuizen Cc: Daniel Stone Cc: mesa-...@lists.freedesktop.org Cc: wayland-devel@lists.freedesktop.org Test-with: 20210524205225.872316-1-ja...@jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (6): dma-buf: Rename dma_resv helpers from _rcu to _unlocked (v2) dma-buf: Add dma_resv_get_singleton_unlocked (v5) dma-buf: Document DMA_BUF_IOCTL_SYNC dma-buf: Add an API for exporting sync files (v11) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 + drivers/dma-buf/dma-buf.c | 107 +- drivers/dma-buf/dma-fence-array.c | 27 drivers/dma-buf/dma-resv.c| 139 -- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +- drivers/gpu/drm/drm_gem.c | 10 +- drivers/gpu/drm/drm_gem_atomic_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/dma_resv_utils.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_busy.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 10 +- drivers/gpu/drm/i915/i915_request.c | 6 +- drivers/gpu/drm/i915/i915_sw_fence.c | 4 +- drivers/gpu/drm/msm/msm_gem.c | 3 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
