[ANNOUNCE] libinput 1.14.0
libinput 1.14.0 is now available. A flurry of patches over the last RC but most of these were CI related. Two new significant bugfixes: the calibration matrix is now returned correctly even when it is the identity matrix. And the tablet pressure range is scaled correctly into the available physical range. Previously, the bottom 5% where effectively missing and pressure offset on worn-out pens handling took some of the scale away from the top. Below is the text from the 1.14.rc1 announcement which lists the other big features added since the 1.13 release. We have new and improved thumb detection for touchpads, thanks to Matt Mayfield. On Clickpad devices this should make interactions where a thumb is resting on the touchpad or dropped during an interaction more reliable. A summary of the changes can be found here: https://who-t.blogspot.com/2019/07/libinputs-new-thumb-detection-code.html The Dell Canvas Totem is now supported by libinput. It is exposed as a new tool type through the tablet interface along with two new axes. Note that this is only low-level support, the actual integration of the totem needs Wayland protocol changes and significant changes in all applications that want to make use of it. A summary of the changes can be found here. https://who-t.blogspot.com/2019/06/libinput-and-dell-canvas-totem.html Touch-capable tablets now tie both devices together for rotation. If you set the tablet to left-handed, the touchpad will be rotated along with the tablet. Note that this does not affect the left-handed-ness of the touchpad, merely the rotation. Tablet proximity out handling for tablets that are unreliably sending proximity out events is now always timeout-based. It is no longer necessary to add per-device quirks to enable this feature and it is completely transparent on devices that work correctly anyway. The blog post below has a summary: https://who-t.blogspot.com/2019/06/libinput-and-tablet-proximity-handling.html Tablets that send duplicate tools (BTN_TOOL_PEN and BTN_TOOL_ERASER) now ignore the latter. This is an intermediate fix only but at least makes those tablets more usable than they are now. Issue #259 is the tracker for this particular behaviour if you are affected by it. The handling of kernel fuzz has been slightly improved. Where our udev rule fails to reset the fuzz on the kernel device, we disable the hysteresis and rely on the kernel now to handle it. Previously our hysteresis would take effect on top of the kernel's, causing nonresponsive behaviour. Note to distribitors: the python-evdev dependency has been dropped, the tools that used it are now using python-libevdev instead. As usual, the git shortlog is below. Benjamin Tissoires (3): gitlab-ci: allow to run on unprivileged containers gitlab-ci: force using docker format for the generated images tests: increase the timeout for the subprocess to receive the quit signal Brian Ashworth (1): evdev: always store user calibration matrix Peter Hutterer (14): tools: record: fix segfault on exit tools: record: fix two memory leaks meson.build: drop explicit install:true from configure_file gitlab CI: replace the user:password with a netrc file gitlab CI: fetch the WAYLAND_WEB_TOKEN from a file tablet: point the pressure offset log messages to the right URL tablet: add a comment explaining why we adjust the pressure offset downwards Add the ck_double_eq_tol() macros to the backwards compat headers test: fix the pressure offset tests tablet: make the pressure-offset inclusive of the axis minimum tablet: reduce the pressure range by the offset test: don't test at the 100 y range tablet: scale the available pressure range into the pressure thresholds libinput 1.14.0 git tag: 1.14.0 https://www.freedesktop.org/software/libinput/libinput-1.14.0.tar.xz MD5: 1c33d49fc7985926eab877e3de9c17eb libinput-1.14.0.tar.xz SHA1: 3a8f1ea7ba8a23868b2a7d48286924547ba6d108 libinput-1.14.0.tar.xz SHA256: 7cb85c24f8920b81bc5360220107e267ab4e0e718704c7690a8c7b03fa14fc67 libinput-1.14.0.tar.xz SHA512: e501c5b8a58bb287c175692af0e59ff766a8613eb576aaa0700686dfbb6c6ab63b7a5d3f148fce75397c8170bc49871068861d93c352355ab5d0d9e7f1b059ec libinput-1.14.0.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.14.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
Re: has weston a rtsp video src support?
Pekka Paalanen 于2019年8月3日周六 上午12:06写道：
>
> On Wed, 31 Jul 2019 10:20:22 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > as said in the other email, independent clone mode has been resolved
> > by hacking weston damage tracking system.
> > i am looking for a solution to support remote screen mirroring. the
> > current idea is making the pipewire display work as a duplicated
> > display which shows the same content with the physical display.
> > this will probably resolve the screen mirror issue. would you like to
> > think it is the right direction?
>
> Hi,
>
> yes, that can work, and it is nicely orthogonal in implementation to
> the real outputs.
>
> It will have the same problem as the remoting plugin already worked
> around with the concept of DRM virtual outputs. Libweston currently
> supports only one backend at a time, but we would really need to able to
> have multiple input and output backends in use at the same time to
> improve the internal architecture and make remoting independent of the
> actual backends.
Hi Pekka,
it seems the memcpy(spa_buffer->datas[0].data, ptr, size) is a big
problem to limit the usage of pipewire.
i am wondering if there is a zero-copy solution to share the drm_fb to
pipewiresrc then to encoder?
static void
pipewire_output_handle_frame(struct pipewire_output *output, int fd,
int stride, struct drm_fb *drm_buffer)
{
...
if (pw_stream_get_state(output->stream, NULL) !=
PW_STREAM_STATE_STREAMING)
goto out;
buffer = pw_stream_dequeue_buffer(output->stream);
if (!buffer) {
weston_log("Failed to dequeue a pipewire buffer\n");
goto out;
}
spa_buffer = buffer->buffer;
...
ptr = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
memcpy(spa_buffer->datas[0].data, ptr, size);
munmap(ptr, size);
...
pw_stream_queue_buffer(output->stream, buffer);
}
>
> An alternative approach would be to hook up to a real existing output
> and copy frames from it when the remote video pipeline is ready to
> consume them. That could also side-step the issue of the video encoder
> wanting to keep a hold of too many old frames for reference, that would
> otherwise cause gbm_surface to run out of buffers.
>
> The screen-share plugin does the copying already through glReadPixels
> from an existing output. That would be fine for a software video
> encoder, but sub-optimal for a hardware video encoder.
>
> FWIW, I wrote down some ramblings here:
> https://gitlab.freedesktop.org/wayland/weston/issues/268
>
>
> Thanks,
> pq
-barry
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Independent clone mode
Pekka Paalanen 于2019年8月3日周六 上午12:24写道：
>
> On Wed, 31 Jul 2019 09:48:07 +1200
> Barry Song <21cn...@gmail.com> wrote:
>
> > Pekka Paalanen 于2019年7月27日周六 下午8:20写道：
> > >
> > > On Fri, 26 Jul 2019 08:58:42 +1200
> > > Barry Song <21cn...@gmail.com> wrote:
> > >
> > > > Pekka Paalanen 于2019年7月26日周五 上午3:30写道：
> > > > >
> > > > > On Thu, 25 Jul 2019 13:00:55 +1200
> > > > > Barry Song <21cn...@gmail.com> wrote:
> > > > >
> > > > > > Pekka Paalanen 于2019年7月24日周三 下午8:10写道：
> > > > > > >
> > > > > > > On Wed, 24 Jul 2019 13:22:43 +0800
> > > > > > > zou lan wrote:
> > > > > > >
> > > > > > > > Hi pekka
> > > > > > > >
> > > > > > > > I see the clone mode is supported from this commit message.
> > > > > > > > https://patchwork.freedesktop.org/patch/227970/
> > > > > > > >
> > > > > > > > I also see the message "Independent CRTC clone mode cannot be
> > > > > > > > supported
> > > > > > > > until output layout logic is moved from libweston into the
> > > > > > > > frontend and
> > > > > > > > libweston's damage tracking issues stemming from overlapping
> > > > > > > > outputs are
> > > > > > > > solved".
> > > > > > > >
> > > > > > > > I want to ask is independent CRTC clone mode already supported
> > > > > > > > in Weston 6
> > > > > > > > or 7? If not,
> > > > > > > > is there a plan to support it?
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > no, that commit message is still accurate. I don't know of any
> > > > > > > plans to work on independent CRTC clone mode.
> > > > > >
> > > > > > Pekka,
> > > > > > any possible workaround do you know to support independent crtc
> > > > > > clone
> > > > > > within weston? right now it is very important product feature.
> > > > > > for example, force weston to identify only one screen, and sync copy
> > > > > > the screen to 2nd screen and call the drm api of 2nd screen?
> > > > >
> > > > > Hi,
> > > > >
> > > > > you could hack it up to do that, but it would be in no way an
> > > > > upstreamable solution. It would also hurt display timings because
> > > > > every repaint would have to wait for both monitors to refresh. Or,
> > > > > all but one monitor would tear.
> > > > >
> > > > > A simpler hack would be to create overlapping outputs and
> > > > > force them repaint fully on every refresh instead of repainting
> > > > > only the damage. That's not upstreamable either, but the damage
> > > > > could be hacked with probably a one-liner.
> > > >
> > > > Hi Pekka,
> > > > Thanks. even though i have seen many times that damage tracking of
> > > > overlapping outputs is the main cause stopping weston from supporting
> > > > full clone mode, i haven't fully understood what is overlapping
> > > > outputs in weston and found the code related with overlapping output,
> > > > would you like to point out some code path so that i can begin to do
> > > > some work on it? pls forgive me if you think the question is just
> > > > stupid.
> > >
> > > Hi,
> > >
> >
> >
> > i made a very great progress to hack weston to support clone mode in
> > the direction you pointed out.
> >
> > it works very well without any tearing.
>
> Hi,
>
> sorry, I did not mean tearing. I meant areas with outdated content.
>
> I guess the best way to make that clearly visible is to have the
> outputs overlap by 50%, not 100%, and then continuously move a window
> such that it will cross all four areas:
> - output A: exclusive area
> - output A: shared with output B area
> - output B: shared with output A area
> - output B: exclusive area
>
> Then observe inconsistency in the image between the exclusive and the
> shared area on each output separately. If you see the window decimate
> on either output, that's bad.
>
> Mind that the effect is semi-random, because it depends on the timings
> of the outputs and the client and desktop updates.
>
>
> > > what I suggested is not about code for overlapping outputs at all.
> > > I'm simply suggesting to hack e.g. weston_output_repaint() or
> > > something to ignore the accumulated damage and use full damage
> > > instead. I can't tell you exactly what and where without doing it
> > > myself first, which I cannot do at the moment.
> >
> > hacked by:
> >
> > @@ -2406,13 +2406,20 @@ weston_output_repaint(struct weston_output
> > *output, void *repaint_data)
> > }
> > }
> >
> > - compositor_accumulate_damage(ec);
> > + if (!output->external) {
> > + compositor_accumulate_damage(ec);
> >
> > - pixman_region32_init(_damage);
> > - pixman_region32_intersect(_damage,
> > - >primary_plane.damage,
> > >region);
> > - pixman_region32_subtract(_damage,
> > -_damage, >primary_plane.clip);
> > + pixman_region32_init(_damage);
> > + pixman_region32_intersect(_damage,
> > + >primary_plane.damage, >region);
> > + pixman_region32_subtract(_damage,
> > +
