[ANNOUNCE] libinput 1.12.0
libinput 1.12 is now available. Since the rc3 a few more notable changes went in: The tablet axis smoothing previously caused some axes to change value even though the "axis has changed" bit wasn't set in the event. This is fixed now. The delta for tablet axis events is now always 0 for tip up/down events. This works around the pointer jumps seen on some devices when the tip is pressed/released. The fuzz handling (i.e. hysteresis auto-detection) was restored after being accidentally removed during the hwdb->quirks rework. All in all, this ended up being the usual 3 month cycle but with well over 340 patchsets. The biggest and most noticable changes are the switch from hwdb entries to a .ini style quirks configuration system, prettier and more user-friendly documentation, and new trackpoint acceleration . A writeup of all other 1.12 features is available here: https://who-t.blogspot.com/2018/09/whats-new-in-libinput-112.html and/or in the previous RC announcements: rc1: https://lists.freedesktop.org/archives/wayland-devel/2018-July/039173.html rc2: https://lists.freedesktop.org/archives/wayland-devel/2018-August/039294.html rc3: https://lists.freedesktop.org/archives/wayland-devel/2018-September/039418.html Many thanks to Atri Bhattacharya, Benjamin Tissoires, Carlos Garnacho, Daniel Stone, Greg V, Hans de Goede, Jeremy, Kim Lindberger, Konstantin Kharlamov, Matt Mayfield, Sergiusz Michalik, jeff for their contributions and of course the tireless army of bug reporters :) Peter Hutterer (8): doc/user: update the trackpoint pointer acceleration graph tools: debug-events - print axes on tablet tip events tablet: always set the changed axis bits if the coordinates differ tablet: on tip down/up, force the delta to zero udev: re-instate the model-quirks callout udev: tighten the conditions when we call the model quirks tools: drop the libinput measure trackpoint-range tool libinput 1.12.0 git tag: 1.12.0 https://www.freedesktop.org/software/libinput/libinput-1.12.0.tar.xz MD5: efbea0deaa7126b6d1f8cbbe16c0470a libinput-1.12.0.tar.xz SHA1: 677dcc4b2dae48936b5ea2b127e243db93fec0ba libinput-1.12.0.tar.xz SHA256: 15ac2b78ec0b502c14400d711dbd6b9164a43a724cedeaf21c7fa29960e701a4 libinput-1.12.0.tar.xz SHA512: 4aee877785f9ac080e4f8ee20f3643bc4f3ddbc568aca6c363a962f8c8f76b8db7dc113c8167092f0277d112346a85b9a7e7c3c3f227ed243aaba32c9092c924 libinput-1.12.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.12.0.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
What has happened to wayland-wall?
I no longer seem to be able to find the wayland-wall repository on GitHub. Just wondering what has happened to it? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: egl image creation in case of atomic
> -Original Message- > From: wayland-devel On Behalf > Of Hosokawa, Kenji (ADITG/ESB) > Sent: Dienstag, 28. August 2018 14:32 > To: wayland-devel@lists.freedesktop.org > Subject: egl image creation in case of atomic > > Hi, > > When eglSwapInterval is 0, clients may send buffers without waiting frame > callbacks. Currently, egl image is created when a buffer is > committed from client. But egl image is only needed, when gl-renderer is used > to render the framebuffer. Creating an egl image in > every commit causes additional CPU load in weston when clients are sending > more buffers than display refresh rate. Furthermore, > creating egl images are not needed at all, when the client buffer can be > imported to a DRM plane. We would like to reduce CPU usage > of weston in that case. > In my investigation, egl image creation can produce higher CPU load in > Weston. I tried to remove egl image creation with this simple > ugly patch for weston. > > diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c > index 2c50d2d..bbb5846 100644 > --- a/libweston/gl-renderer.c > +++ b/libweston/gl-renderer.c > @@ -2260,6 +2260,8 @@ gl_renderer_attach_dmabuf(struct weston_surface > *surface, > buffer->y_inverted = > !(dmabuf->attributes.flags & > ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT); > > + return; > + > for (i = 0; i < gs->num_images; i++) > egl_image_unref(gs->images[i]); > gs->num_images = 0; > > Without the patch (original), total CPU usage of weston was 25%. With the > patch, it was decreased to 10%. > I used weston v4.0.92, weston-simple-egl with -o and -b options, rcar h3 > target. It was measured with top command simply. > > My question is that can egl image creation be postponed until repaint output > (gl_renderer_repaint_output)? Hi, Do you have any ideas for my question? If it makes sense in principle, I will jump into the detail to achieve it. If there are some problems which I don't know, I hope you'll let me know. Best regards Kenji Hosokawa Engineering Software Base (ADITG/ESB) > Best regards > > Kenji Hosokawa > Engineering Software Base (ADITG/ESB) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: arch linux: weston 5.0.0 not working with nouveau
On Mon, 10 Sep 2018 11:16:03 +0200 Dirk Eibach wrote: > I did a git bisect and found the commit "244244d1 (refs/bisect/bad) > compositor-drm: Use GBM modifier API" introduced the problem. Hi, ok. I wonder if there is something wrong with Mesa/GBM/Nouveau, since it is generic code in Weston and works for other drivers. It could also be something the Nouveau DRM driver in the kernel. It's possible no-one else has tried using the new GBM API with Nouveau before. The idea in short is, Weston queries the KMS device what pixel formats + modifiers it can use, Weston picks the pixel format, and asks GBM to choose the modifier to go with it from the set KMS-supported modifiers. If the KMS device doesn't support querying the formats and modifiers, then Weston is meant to fall back to the old path with implicit modifiers, which presumably should make Nouveau happy. Of course, it would be better if Nouveau worked correctly with the new stuff. Thanks, pq > Am Mo., 10. Sep. 2018 um 10:12 Uhr schrieb Dirk Eibach > : > > > > Perhaps I should add, that with rolling back to weston 4.0.0. > > everything works fine. So nouveau support must have been broken > > somewhere inbetween. pgpIzeN4sV234.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: arch linux: weston 5.0.0 not working with nouveau
On Mon, 10 Sep 2018 10:12:18 +0200 Dirk Eibach wrote: > Perhaps I should add, that with rolling back to weston 4.0.0. > everything works fine. So nouveau support must have been broken > somewhere inbetween. Hi, right, so it's a regression. Weston does not have code specific to Nouveau, but it did go through extensive changes to the DRM-backend between 4.0.0 and 5.0.0. The error itself is the most surprising to me: EGL says it's using Nouveau, yet "failed to create kms fb: Invalid argument". It is as if Mesa/Nouveau allocates buffers that the kernel DRM/Nouveau driver cannot use. One would have to look more closely on what happens there, is Weston fumbling some buffer attributes, or is it a bug in Nouveau that just got exposed by using EGL/GBM/DRM little differently. The only tangible suggestion I can make is to bisect Weston and see which commit breaks things for you. Thanks, pq pgp6rUoVwyEBV.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: arch linux: weston 5.0.0 not working with nouveau
I did a git bisect and found the commit "244244d1 (refs/bisect/bad) compositor-drm: Use GBM modifier API" introduced the problem. Am Mo., 10. Sep. 2018 um 10:12 Uhr schrieb Dirk Eibach : > > Perhaps I should add, that with rolling back to weston 4.0.0. > everything works fine. So nouveau support must have been broken > somewhere inbetween. > Am Mo., 10. Sep. 2018 um 08:59 Uhr schrieb Dirk Eibach > : > > > > > Looks like some drm issue. Just wondering if you can use KMS APIs > > > directly without seeing this issue? So for example, will kmscube draw > > > something on the screen (https://github.com/robclark/kmscube)? BTW, > > > noticed that you are using /dev/dri/card1 in your logs. What's at card0? > > > Note that this kmscube will only open a handle to card0 so you may want > > > to change that and test. > > > > Removed the second graphics adapter. kmscube works fine. > > > > Cheers > > Dirk ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC,wayland-protocols] Add alpha-compositing protocol
On Fri, Sep 07, 2018 at 04:02:24PM +0200, Gary Bisson wrote: > Hi Alexandros, All, > > On Tue, Aug 08, 2017 at 05:24:58PM +0300, Alexandros Frantzis wrote: > > This protocol specifies a set of interfaces used to control the alpha > > compositing and blending of surface contents. > > > > It's based on the Chromium Wayland protocol of the same name ([1]), > > with a few changes made to the blending_equation enumeration. > > > > A proof-of-concept implementation for Weston can be found at: > > > > https://git.collabora.com/cgit/user/alf/weston.git/log/?h=alpha-compositing-v1 > > > > [1] > > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > > Was there any feedback on this RFC? On top of Chromium, it seems that > NXP is now also using it for its i.MX processors [2]. So it would > definitely be great to have this protocol upstream. > > Note that NXP apparently modified this version of the patch a bit. > > Regards, > Gary > > [2] > https://source.codeaurora.org/external/imx/wayland-protocols-imx/commit/?id=799164a4 Hi Gary, thanks for bringing the i.MX version to my/our attention. I haven't received any feedback about this proposal so far, but I am happy to revive the upstreaming effort as soon as I do. To this end, I have also added Haihua Hu (from NXP) to the CC list for this thread. Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: arch linux: weston 5.0.0 not working with nouveau
Perhaps I should add, that with rolling back to weston 4.0.0. everything works fine. So nouveau support must have been broken somewhere inbetween. Am Mo., 10. Sep. 2018 um 08:59 Uhr schrieb Dirk Eibach : > > > Looks like some drm issue. Just wondering if you can use KMS APIs directly > > without seeing this issue? So for example, will kmscube draw something on > > the screen (https://github.com/robclark/kmscube)? BTW, noticed that you are > > using /dev/dri/card1 in your logs. What's at card0? Note that this kmscube > > will only open a handle to card0 so you may want to change that and test. > > Removed the second graphics adapter. kmscube works fine. > > Cheers > Dirk ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: arch linux: weston 5.0.0 not working with nouveau
> Looks like some drm issue. Just wondering if you can use KMS APIs directly > without seeing this issue? So for example, will kmscube draw something on the > screen (https://github.com/robclark/kmscube)? BTW, noticed that you are using > /dev/dri/card1 in your logs. What's at card0? Note that this kmscube will > only open a handle to card0 so you may want to change that and test. Removed the second graphics adapter. kmscube works fine. Cheers Dirk ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
