Re: [PATCH weston 00/25] A new touchscreen calibrator

[Jason Gerecke]

On Mon, Mar 26, 2018 at 2:36 AM, Pekka Paalanen  wrote:
> On Fri, 23 Mar 2018 09:33:10 -0700
> Jason Gerecke  wrote:
>
>> Nice! Do you think its reasonable to extend the allowed use of this
>> protocol to other kinds of direct-input devices? I don't see anything
>> which would prevent this protocol from working equally well to
>> calibrate the pen input for a tablet PC or Cintiq for example. The
>> compositor would need to obviously have pen support and notify the
>> client of the device in a "touch_device" event, but otherwise it looks
>> like the client doesn't really have to care about the underlying
>> device -- the protocol provides its own definition of down/up/motion
>> events. Just the documentation would need to be tweaked.
>
> Hi Jason,
>
> I suppose, but I am not at all familiar with such devices, so I cannot
> make the call. I have never even used one.
>
> If the design is a good match for other devices, I would be happy to
> accept spec changes and renaming interfaces to be more generic, but
> only if someone is working on an implementation somewhere as well.
>
> Currently the protocol is being proposed to be Weston private. We might
> land it as is, and then talk about how it should be generalized and
> which package should install it for public use. We can have
> libweston-dev install the XML file, or it could be proposed to be
> included in wayland-protocols if it satisfies the general inclusion
> requirements there. Or somewhere else.
>
>
> Thanks,
> pq
>

Good to know. It certainly seems like a good match at least for this
second class of devices, so I would be very interested in seeing the
wording made a bit more generic.

Weston's tablet support is still in the works (I believe Lyude was
last working on it?) so there's not an urgent need to make these
changes, but it would be good to think about them if/when the protocol
goes public. I imagine GNOME would be remotely interested in this
protocol... Their current tablet calibration tool has to deal with
exactly the same issues that this protocol very nicely addresses (e.g.
un-transforming coordinates, screen mapping, grabbing input).

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours

>
>> On Fri, Mar 23, 2018 at 5:00 AM, Pekka Paalanen  wrote:
>> > From: Pekka Paalanen 
>> >
>> > Hi all,
>> >
>> > the existing touchscreen calibrator in Weston has several problems. This
>> > proposal intends to solve them all by introducing a new protocol
>> > extension for touchscreen calibration and a new calibrator tool.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3] xwm: Fix memory leak

[Pekka Paalanen]

On Fri, 23 Mar 2018 15:07:07 -0500
Derek Foreman  wrote:

> On 2018-03-23 02:41 PM, Scott Moreau wrote:
> > A memory leak introduced by 6b58ea8c led to me finding a bigger leak,
> > which is xwm was calling frame_create() without calling frame_destroy().
> > This meant that the associated icon_surface was not being destroyed,
> > leaving the destroy handler for it broken. Here we fix this by calling
> > frame_destroy() when the window is destroyed and free the reply in
> > the icon_surface destroy handler.  
> 
> Reviewed-by: Derek Foreman 
> 
> Though, I guess this should probably be split into two, in case the icon
> stuff needs to be pulled before the RC.
> 
> I can do that when I land it though.
> 
> Will wait on this a little longer to see if anyone else wants to review.
>  Looks trivially correct to me, but xwm has tricked me before.

Hi,

it looks reasonable to me too, so
Acked-by: Pekka Paalanen 
split or unsplit.

> > ---
> > 
> > Changed in v2:
> > 
> > - Setup destroy handler to free reply when surface is destroyed
> > - Call frame_destroy() for window->frame
> > 
> > Changed in v3:
> > 
> > - Fix whitespace
> > - Drop unnecessary cast in handle_icon_surface_destroy()
> > 
> >  xwayland/window-manager.c | 21 +++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)

Thanks,
pq


pgpKLZPNNr9U8.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] libweston/compositor-drm: Reset repaint scheduled status when setting DPMS level to off

[Marius-cristian Vlad]

On Fri, 2018-03-23 at 21:30 +0300, Greg V wrote:
> > On 7 March 2018 at 17:36, Marius Vlad  > nxp.com 
> >  > Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fwayland-
> > devel&data=02%7C01%7Cmarius-
> > cristian.vlad%40nxp.com%7Cf1acbc5280754c8936a908d590ec293a%7C686ea1
> > d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636574266340740999&sdata=Q60NW
> > AAtygRpT0s55ToG%2Fkz5DloXqOM5Bhy5xIEO6PM%3D&reserved=0>> wrote:
> > /
> > > /Otherwise when setting dpms level DPMS_ON, 
> > > weston_output_schedule_repaint() //will bail out early and never
> > > get a chance to wake up the output. Arguably this could also
> > > be done in drm_set_dpms() when setting 
> > > dpms_off_pending //but I figure it better to do it when
> > > deferred./
> > 
> > /
> > Thanks, that's a good catch, but I do wonder how it wasn't getting
> > tripped up before. In previous releases, we'd call drm_set_dpms()
> > from
> > anywhere, which would block on the update completing and then set
> > the
> > DPMS level. I wonder if it's because we would receive a flip-done
> > event anyway and call weston_output_finish_frame() after the DPMS
> > had
> > completed, which would drive us into repaint-idle.
> 
> Hi! I think I might have tripped that up before.
> 
> Or a different DPMS bug?
> Does "wake up the output" here mean DPMS wake, or starting drawing to
> that output again?
Hi,

When the monitor wakes up it will eventually start drawing. From your
description seems to be a different issue. This (patch) relates to
Daniels' basic atomic modesetting patches that have landed in a few
weeks ago, and to me it seems you are (still) using the legacy KMS page
flip ioctl.


> One of my monitors, which is quite slow to wake up (AOC U2879VF)
> pretty often becomes frozen after waking up from DPMS.
> While on the other monitor (an old NEC MultiSync) this problem never
> happened.
> So like I could move the mouse and see the picture change on that
> monitor, but the first one was still displaying the frozen picture
> from before going to sleep.
> 
> The log lines were:
> 
> > [00:42:10.740] queueing pageflip failed: m [00:42:10.740] Couldn't
> > apply 
> 
> state for output DP-2|

Yes, failing to queue page flips will lead a frozen image on the
screen. 

> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EXT: [PATCH weston v6 37/73] compositor-wayland: migrate to head-based output API

[Pekka Paalanen]

On Sat, 24 Mar 2018 10:13:48 +
"Ray, Ian (GE Healthcare)"  wrote:

> > On 16 Feb 2018, at 16.57, Pekka Paalanen  wrote:
> > 
> > From: Pekka Paalanen 
> > 
> > Follow the standard pattern used in the headless and x11 backend
> > migration, but also cater for the two other backend modes: --sprawl or
> > fullscreen-shell, and --fullscreen.
> > 
> > Stops relying on the implicit weston_output::head.
> > 
> > Unlike other backends, this uses the attach_head hook to do the
> > required head setup that is not possible to do without an output, but
> > must be done before weston_output_enable(). This also requires the
> > detach_head hook for the one case where the user attaches a --fullscreen
> > head and then detaches it without enabling the output.
> > 
> > It is a little awkward to fully initialize heads as late as attach, but
> > aside from the --sprawl/fullscreen-shell case, there is not really a way
> > to know the head properties without creating the parent wl_surface and
> > configuring it.
> > 
> > Heads/outputs created for parent outputs now have distinct names instead
> > of all being called "wlparent".
> > 
> > Signed-off-by: Pekka Paalanen 
> > ---
> > libweston/compositor-wayland.c | 239 
> > ++---
> > 1 file changed, 178 insertions(+), 61 deletions(-)
> > 
> > diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
> > index cf4a5f3f..455d94a0 100644
> > --- a/libweston/compositor-wayland.c
> > +++ b/libweston/compositor-wayland.c
> > @@ -137,7 +137,7 @@ struct wayland_output {
> > 
> > struct wayland_parent_output {
> > struct wayland_backend *backend;/**< convenience */
> > -   struct wayland_output *output;
> > +   struct wayland_head *head;
> > struct wl_list link;
> > 
> > struct wl_output *global;
> > @@ -161,6 +161,11 @@ struct wayland_parent_output {
> > struct weston_mode *current_mode;
> > };
> > 
> > +struct wayland_head {
> > +   struct weston_head base;
> > +   struct wayland_parent_output *parent_output;
> > +};

> > +static int
> > +wayland_output_attach_head(struct weston_output *output_base,
> > +  struct weston_head *head_base)
> > +{
> > +   struct wayland_backend *b = to_wayland_backend(output_base->compositor);
> > +   struct wayland_output *output = to_wayland_output(output_base);
> > +   struct wayland_head *head = to_wayland_head(head_base);
> > +
> > +   if (!wl_list_empty(&output->base.head_list))
> > +   return -1;
> > +
> > +   if (head->parent_output) {
> > +   if (wayland_output_setup_for_parent_output(output,
> > +  head->parent_output) 
> > < 0)
> > +   return -1;
> > +   } else if (b->fullscreen) {
> > +   if (wayland_output_setup_fullscreen(output, head) < 0)
> > +   return -1;
> > +   } else {
> > +   /* A floating window, nothing to do. */
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static void
> > +wayland_output_detach_head(struct weston_output *output_base,
> > +  struct weston_head *head)  
> 
> Nit: head unused.  (GCC_CFLAGS contains `-Wno-unused-parameter' so
> presumably I should not report similar occurrences?)

Hi Ian,

yes, it's not a mistake. There are lots of code in Weston in general
where functions that need to follow API do not actually use all their
arguments.

In this specific case, wayland-backend can only ever have a single head
per output, so if any head is removed, it was sure to be the only head
on the output which is then left with none. I'm not sure I could put
even an assert here to assure the head argument is correct even if
unnecessary.

> > +{
> > +   struct wayland_output *output = to_wayland_output(output_base);
> > +
> > +   /* Rely on the disable hook if the output was enabled. We do not
> > +* support cloned heads, so detaching is guaranteed to disable the
> > +* output.
> > +*/
> > +   if (output->base.enabled)
> > +   return;
> > +
> > +   /* undo setup fullscreen */
> > +   if (output->parent.surface)
> > +   wayland_backend_destroy_output_surface(output);
> > +}


Thanks,
pq


pgpCvwhGjpTrP.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 00/25] A new touchscreen calibrator

[Pekka Paalanen]

On Fri, 23 Mar 2018 09:33:10 -0700
Jason Gerecke  wrote:

> Nice! Do you think its reasonable to extend the allowed use of this
> protocol to other kinds of direct-input devices? I don't see anything
> which would prevent this protocol from working equally well to
> calibrate the pen input for a tablet PC or Cintiq for example. The
> compositor would need to obviously have pen support and notify the
> client of the device in a "touch_device" event, but otherwise it looks
> like the client doesn't really have to care about the underlying
> device -- the protocol provides its own definition of down/up/motion
> events. Just the documentation would need to be tweaked.

Hi Jason,

I suppose, but I am not at all familiar with such devices, so I cannot
make the call. I have never even used one.

If the design is a good match for other devices, I would be happy to
accept spec changes and renaming interfaces to be more generic, but
only if someone is working on an implementation somewhere as well.

Currently the protocol is being proposed to be Weston private. We might
land it as is, and then talk about how it should be generalized and
which package should install it for public use. We can have
libweston-dev install the XML file, or it could be proposed to be
included in wayland-protocols if it satisfies the general inclusion
requirements there. Or somewhere else.


Thanks,
pq


> On Fri, Mar 23, 2018 at 5:00 AM, Pekka Paalanen  wrote:
> > From: Pekka Paalanen 
> >
> > Hi all,
> >
> > the existing touchscreen calibrator in Weston has several problems. This
> > proposal intends to solve them all by introducing a new protocol
> > extension for touchscreen calibration and a new calibrator tool.


pgpTeDp8gznMr.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel