Wayland Weston blank screen with drm-backend

[John Frankish]

Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a 
machine with intel hd4400 graphics when staring with:

WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u) 
weston-launch >weston.log 2>&1

X works fine and, a couple of mesa upgrades ago, Weston worked fine - full 
output log attached, any troubleshooting suggestions would be appreciated.

John

--

[22:03:44.040] weston 3.0.0
   http://wayland.freedesktop.org
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=3.0.0
   Build: unknown (not built from git or tarball)
[22:03:44.040] Command line: /usr/local/bin/weston
[22:03:44.040] OS: Linux, 4.14.10-tinycore64, #2018 SMP Mon Jan 1 16:07:42 UTC 
2018, x86_64
[22:03:44.040] Using config file '/home/tc/.config/weston.ini'
[22:03:44.040] Output repaint window is 7 ms maximum.
[22:03:44.040] Loading module '/usr/local/lib/libweston-3/drm-backend.so'
[22:03:44.044] initializing drm backend
[22:03:44.045] using /dev/dri/card0
[22:03:44.045] Loading module '/usr/local/lib/libweston-3/gl-renderer.so'
...
libEGL debug: did not find optional extension DRI_FlushControl version 1
libEGL debug: No DRI config supports native format XRGB2101010
libEGL debug: No DRI config supports native format ARGB2101010
libEGL debug: the best driver is DRI2
failed to get cairo EGL argb device
EGL does not seem to work, falling back to software rendering and wl_shm.
[2989107.820]  -> wl_shm@9.create_pool(new id wl_shm_pool@15, fd 7, 4096)
failed to get cairo EGL argb device
EGL does not seem to work, falling back to software rendering and wl_shm.
[2989107.894]  -> wl_shm_pool@15.resize(8832)
[2989107.916]  -> wl_shm_pool@15.resize(18624)
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
[2989108.011]  -> wl_shm@9.create_pool(new id wl_shm_pool@15, fd 7, 4096)
[2989108.076]  -> wl_shm_pool@15.resize(8832)
[2989108.097]  -> wl_shm_pool@15.resize(18624)
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
[2989115.122]  -> wl_regis...@2.bind(12, "wl_output", 2, new id [unknown]@18)
[2989115.134]  -> wl_regis...@2.bind(19, "weston_desktop_shell", 1, new id 
[unknown]@19)
[2989115.143]  -> weston_desktop_shell@19.set_panel_position(0)
[2989115.147]  -> wl_compositor@4.create_surface(new id wl_surface@20)
[2989115.257]  -> wl_regis...@2.bind(13, "zwp_input_panel_v1", 1, new id 
[unknown]@18)
[2989115.268]  -> wl_regis...@2.bind(14, "zwp_input_method_v1", 1, new id 
[unknown]@19)
[2989115.276]  -> wl_compositor@4.create_surface(new id wl_surface@20)
[2989115.286]  -> wl_compositor@4.create_region(new id wl_region@21)
libEGL debug: mincore failed: Cannot allocate memory
[2989115.324]  -> wl_surface@20.frame(new id wl_callback@22)



weston.log.tar.gz
Description: weston.log.tar.gz
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] ivi-shell: Damage view below after unmapping

[zou lan]

Hi Emre

I ask why calling it?  which scenario could reproduce the issue you said
"keep visible after set layer/surface invisible "?

Thank you.

Best Regards
Nancy

2018-04-10 22:19 GMT+08:00 Ucan, Emre (ADITG/ESB) :

> Hi,
>
>
>
> Are you asking if it is possible to move weston_view_damage_below() to
> commit_screen_list ? or are you asking why we are calling it ?
>
>
>
> Best regards
>
> *Emre Ucan*
> Engineering Software Base (ADITG/ESB)
>
> Tel. +49 5121 49 6937
>
> *From:* zou lan [mailto:nancy.lan@gmail.com]
> *Sent:* Dienstag, 10. April 2018 08:55
> *To:* Pekka Paalanen
> *Cc:* Ucan, Emre (ADITG/ESB); wayland-devel@lists.freedesktop.org
> *Subject:* Re: [PATCH weston v2] ivi-shell: Damage view below after
> unmapping
>
>
>
> Hi  Emre
>
>
>
> I have a question about this change:
>
>
>
> Is the commit_screen_list function not enough to handle the
> layer/surface's visibility? Why need to handle visibility in
> commit_changes? They are  called ivi_layout_commit_changes together.
>
>
>
> Best Regards
>
> Nancy
>
>
>
> 2017-02-07 21:04 GMT+08:00 Pekka Paalanen :
>
> On Tue, 7 Feb 2017 12:55:59 +
> "Ucan, Emre (ADITG/SW1)"  wrote:
>
> > If ivilayer or ivisurf of ivi_view is made invisible in the
> > commit_changes call, we have to damage the weston_view below this
> > ivi_view. Otherwise content of this ivi_view will stay visible.
> >
> > Signed-off-by: Emre Ucan 
> > ---
> >  ivi-shell/ivi-layout.c |   13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > index 712cc30..64e4ead 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c
> > @@ -681,8 +681,19 @@ commit_changes(struct ivi_layout *layout)
> >* If the view's layer or surface is invisible, we do not
> need
> >* to update its properties.
> >*/
> > - if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility)
> > + if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility) {
> > + /*
> > + * If ivilayer or ivisurf of ivi_view is made
> invisible
> > + * in this commit_changes call, we have to damage
> > + * the weston_view below this ivi_view. Otherwise
> content
> > + * of this ivi_view will stay visible.
> > + */
> > + if ((ivilayer->prop.event_mask |
> ivisurf->prop.event_mask) &&
> > + IVI_NOTIFICATION_VISIBILITY)
> > + weston_view_damage_below(ivi_view->view);
> > +
> >   continue;
> > + }
> >
> >   update_prop(ivi_view);
> >   }
>
> Hi,
>
> looks fine to me, pushed:
>19222b4..7fe0bb2  master -> master
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCHv3] Add name event to xdg-output

[Drew DeVault]

Signed-off-by: Drew DeVault 
Reviewed-by: Simon Ser 
---
This version clarifies the uniqueness constraint, mapping of names to
wl_outputs, and persistence between sessions.

 .../xdg-output/xdg-output-unstable-v1.xml | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
b/unstable/xdg-output/xdg-output-unstable-v1.xml
index 0c0c481..b46c9df 100644
--- a/unstable/xdg-output/xdg-output-unstable-v1.xml
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -77,7 +77,7 @@
 
   
 
-  
+  
 
   An xdg_output describes part of the compositor geometry.
 
@@ -157,5 +157,22 @@
   
 
 
+
+  
+Many compositors will assign names to their outputs, show them to the user,
+allow them to be configured by name, etc. The client may wish to know this
+name as well to offer the user similar behaviors.
+
+The naming convention is compositor defined. Each name is unique among all
+wl_output globals, but if a wl_output global is destroyed the same name may
+be reused later. The names will also remain consistent across sessions with
+the same hardware and software configuration.
+
+The name event is sent after creating an xdg_output (see
+xdg_output_manager.get_xdg_output).
+  
+  
+
+
   
 
-- 
2.17.0

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

Re: [PATCH weston 21/25] protocol: add weston_touch_calibration

[Peter Hutterer]

On Tue, Apr 10, 2018 at 02:01:10PM +0300, Pekka Paalanen wrote:
> On Mon, 9 Apr 2018 12:54:43 +1000
> Peter Hutterer  wrote:
> 
> > On Fri, Mar 23, 2018 at 02:01:01PM +0200, Pekka Paalanen wrote:
> > > From: Pekka Paalanen 
> > > 
> > > This is a Wayland protocol extension to allow the calibration of
> > > touchscreens in Weston.
> > > 
> > > See: https://phabricator.freedesktop.org/T7868
> > > 
> > > Signed-off-by: Pekka Paalanen 
> > > ---
> > >  Makefile.am   |   5 +-
> > >  protocol/weston-touch-calibration.xml | 320 
> > > ++
> > >  2 files changed, 324 insertions(+), 1 deletion(-)
> > >  create mode 100644 protocol/weston-touch-calibration.xml
> 
> > > +  
> > > +
> > > +  This is the global interface for calibrating a touchscreen input
> > > +  coordinate transformation. It is recommended to make this interface
> > > +  privileged.
> > > +
> > > +  This interface can be used by a client to show a calibration 
> > > pattern and
> > > +  receive uncalibrated touch coordinates, facilitating the 
> > > computation of
> > > +  a calibration transformation that will align actual touch positions
> > > +  on screen with their expected coordinates.
> > > +
> > > +  Immediately after being bound by a client, the server sends the
> > > +  touch_device events.  
> > 
> > s/server/compositor/, in a few more places
> 
> I'm a bit mixed there. I tried to be consistent with "server", but one
> "compositor" still remained. There are a couple dozen "server".
> 
> Is your point that all Wayland spec language should be using
> "compositor" to talk about the server-side?

Yeah, sorry, should've made this clear. 30 years of confusion about X'
client and server model suggests using 'compositor' and 'client' is
superior, simply because at least you know one side for sure now :)
 

> > > +
> > > +  
> > > + This gives the calibrator role to the surface and ties it with the
> > > + given touch input device.
> > > +
> > > + The surface must not already have a role, otherwise invalid_surface
> > > + error is raised.
> > > +
> > > + The device string must be one advertised with touch_device event's
> > > + device argument, otherwise invalid_device error is raised.
> > > +
> > > + There must not exist a weston_touch_calibrator protocol object in the
> > > + server already, otherwise already_exists error is raised. This
> > > + limitation is server-wide and not specific to any particular client.  
> > 
> > Personal preference: I find it easier to understand when a sentence is "if
> > blah then error E". As opposed to "if not blah, otherwise E". It also
> > narrows down the error cases a bit better too because you're only describing
> > the error case rather than the not-error case.
> 
> Yup.
> 
> > > +  
> > > +   > > +   summary="the surface to give the role to"/>
> > > +  
> > > +   > > +   summary="a new calibrator object"/>
> > > +
> > > +
> > > +
> > > +  
> > > + This request asks the server to save the calibration data for the
> > > + given touch input device. The server may ignore this request.
> > > +
> > > + The device string must be one advertised with touch_device event's
> > > + device argument, otherwise invalid_device error is raised.
> > > +
> > > + The array must contain exactly six 'float' (the 32-bit floating
> > > + point format used by the C language on the system) numbers. The numbers
> > > + form a libinput style 2-by-3 calibration matrix in row-major order.  
> > 
> > 'libinput-style', i.e. hyphenated. but tbh, no need to mention libinput
> > here, just spell out the matrix:
> > """
> >  For a 3D matrix in the form
> >( a b c )
> >( d e f )
> >( 0 0 1 )
> >  the array must contain the values [a, b, c, d, e, f] with a at index 0.
> > """
> 
> Not only that, but it also needs to define the coordinate spaces where
> it applies, and probably also the ordering with other transformations
> as well. Hence I just punted to "how libinput uses it", because
> everything here is specifically designed for libinput.
> 
> I'm also not sure I can actually lay out a matrix so that it will still
> look ok in generated output and doxygen docs generated from that.

@code and @endcode in doxygen map to  (you can use the html tag
directly too). Or there's @verbatim and @endverbatim.  You can do fancy
things with latex like libinput does, but it makes the source pretty awful
to look at (and introduces extra build dependencies).

> > Much easier than figuring out what "row-major order" means.
> 
> It's a standard term.
> 
> > > +  
> > > +  
> > > +  
> > > +
> > > +
> > > +
> > > +  
> > > + When a client binds to weston_touch_calibration, one touch_device
> > > + event is sent for each touchscreen that is available to be calibrated.
> > > + These events are 

[PATCH] xwayland/selection: do not remove NULL property_source

[Greg V]

Happened mostly with neovim's xclip usage.
---
This fixes the most frequent source of crashes for me.

 xwayland/selection.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xwayland/selection.c b/xwayland/selection.c
index f145089f..b0bccc0d 100644
--- a/xwayland/selection.c
+++ b/xwayland/selection.c
@@ -370,7 +370,9 @@ weston_wm_read_data_source(int fd, uint32_t mask, void 
*data)
if (len == -1) {
weston_log("read error from data source: %m\n");
weston_wm_send_selection_notify(wm, XCB_ATOM_NONE);
-   wl_event_source_remove(wm->property_source);
+   if (wm->property_source) {
+   wl_event_source_remove(wm->property_source);
+   }
wm->property_source = NULL;
close(fd);
wl_array_release(>source_data);
-- 
2.16.2

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

Re: [PATCHv2] Add name event to xdg-output

[Drew DeVault]

On 2018-04-10  5:09 PM, Pekka Paalanen wrote:
> How do you define "one wl_output"?
> 
> Do you mean it is the wl_output as identified by its global name (int),
> and gets destroyed when the wl_registry sends the remove event?

Yes, I mean one wl_output as in one global on the registry.

> Unplugging a monitor likely causes the corresponding wl_output global
> to be destroyed, right?
> 
> If so, that means a couple of things:
> 
> - If a user unplugs and re-plugs the same monitor to the same connector,
>   you require the xdg-output name to be chosen different as the
>   wl_output is no longer the same.

Not necessarily. Uniqueness is only consistent across all of the
wl_output globals currently in existence. Once one goes away, a new
wl_output can utilize the same name.

> - When ever a compositor starts, all wl_outputs are new, which means
>   all xdg-output names must be new as well. So if an application saves
>   a name in its config, it will never find a match anymore after the
>   compositor gets restarted.

Again, the only uniqueness constraint is across the current list of
living wl_output globals. Nothing prevents the names from being the same
across sessions, in fact it's strongly suggested that they are.

> My recent work on Weston introduces the concept of "heads" which
> essentially refer to connectors and share their names. Weston "outputs"
> are basically rendering engine instances and in clone mode one
> weston_output feeds the image into several heads at the same time. Then
> we have wl_output that represents the monitor, carrying its make and
> model, and being 1:1 to a "head" when the head is active (but not
> necessarily connected to a monitor).
> 
> Given that you say clones will not share the xdg-output name, then in a
> Weston implementation I would use either the connector name or the
> monitor info (EDID) as the base for creating xdg-output names. I still
> don't know which one would be appropriate for the clients, though.

I'd do HDMI-A-1-1, DP-1-2, etc, if subdividing one output into several
logical wl_outputs. The specification is deliberately left vague on how
the compositor comes up with the name. Do it however you feel is useful.

> - If a user unplugs a monitor and replugs it into another connector, do
>   applications expect the xdg-output name for the new situation to be
>   different from the old situation?
>
> - If a user unplugs a monitor and replaces it with a different monitor
>   plugged into the same connector, do applications expect the
>   xdg-output name to be different from before?

Up to your compositor. I'm just going to use the connector but this is
again deliberately vague.

> The reason why I am insisting on this is that you said that
> applications are free to save the name and expect to find it later
> under some circumstances. We need to establish those circumstances, so
> that application writers can know what it actually means to find or not
> find an xdg-output of a certain name they've seen before. If it's all
> undefined, then it would be better to just specify that applications
> should not expect to be able to find xdg-outputs with the same name as
> they have seen some time before.

I don't want to specify the degree to which the compositor embues the
name with meaning, just that it does so somewhat consistently. The
constraint is: at a bare minimum the same configuration of hardware and
software produces the same names across settings.

I do not want to bring into this already nicely generic API any
underlying details of the output's hardware, like an EDID - whether or
not we abstract it into some more generic sounding event name. "Name" is
a nice vague term that compositors can give any meaning they like.

Will it address your concerns if I:

1. Add a statement clarifying that the names are unique across all
   living wl_outputs and may be reused if the corresponding wl_output
   global is removed
2. Add a statement clarifying that persistence of names between sessions
   is only guaranteed for the same hardware & software configuration

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

RE: [PATCH weston v2] ivi-shell: Damage view below after unmapping

[Ucan, Emre (ADITG/ESB)]

Hi,

Are you asking if it is possible to move weston_view_damage_below() to 
commit_screen_list ? or are you asking why we are calling it ?

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937
From: zou lan [mailto:nancy.lan@gmail.com]
Sent: Dienstag, 10. April 2018 08:55
To: Pekka Paalanen
Cc: Ucan, Emre (ADITG/ESB); wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH weston v2] ivi-shell: Damage view below after unmapping

Hi  Emre

I have a question about this change:

Is the commit_screen_list function not enough to handle the layer/surface's 
visibility? Why need to handle visibility in commit_changes? They are  called 
ivi_layout_commit_changes together.

Best Regards
Nancy

2017-02-07 21:04 GMT+08:00 Pekka Paalanen 
>:
On Tue, 7 Feb 2017 12:55:59 +
"Ucan, Emre (ADITG/SW1)" > 
wrote:

> If ivilayer or ivisurf of ivi_view is made invisible in the
> commit_changes call, we have to damage the weston_view below this
> ivi_view. Otherwise content of this ivi_view will stay visible.
>
> Signed-off-by: Emre Ucan >
> ---
>  ivi-shell/ivi-layout.c |   13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index 712cc30..64e4ead 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -681,8 +681,19 @@ commit_changes(struct ivi_layout *layout)
>* If the view's layer or surface is invisible, we do not need
>* to update its properties.
>*/
> - if (!ivilayer->prop.visibility || !ivisurf->prop.visibility)
> + if (!ivilayer->prop.visibility || !ivisurf->prop.visibility) {
> + /*
> + * If ivilayer or ivisurf of ivi_view is made invisible
> + * in this commit_changes call, we have to damage
> + * the weston_view below this ivi_view. Otherwise content
> + * of this ivi_view will stay visible.
> + */
> + if ((ivilayer->prop.event_mask | 
> ivisurf->prop.event_mask) &&
> + IVI_NOTIFICATION_VISIBILITY)
> + weston_view_damage_below(ivi_view->view);
> +
>   continue;
> + }
>
>   update_prop(ivi_view);
>   }
Hi,

looks fine to me, pushed:
   19222b4..7fe0bb2  master -> master


Thanks,
pq

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

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

RE: Same ilm surface on multiple layer support

[Ucan, Emre (ADITG/ESB)]

Hi Vikas,

This patch “5e8d55da698e58”  enabled the feature. It is part of weston 1.12 
release.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Vikas Patil
Sent: Dienstag, 10. April 2018 14:58
To: genivi-ivi-layer-managem...@lists.genivi.org; Mizuno, Wataru (ADITJ/SWG); 
wayland mailing list
Subject: Same ilm surface on multiple layer support

+Subject
Dear All,
We are facing issue when we are trying to add same surface to multiple layers. 
When we try to attach surface to another layer, it is getting detached from the 
earlier layer.
We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend on 
TI's Soc.
Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed in 
newer version and can it be ported to 1.11.0 ? or Is there any other way to 
show same surface on multiple layers?
I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].

"Currently 1 layer can be only on 1 screen, and 1 surface can be only on 1 
layer,
 we are planning to relax this limitation And allow 1 surface to be on many 
layers but we would need to break the ABI and change the
ivi-controller protocol."
[1] 
https://lists.genivi.org/pipermail/genivi-ivi-layer-management/2016-October/005416.html

Thanking you in advance.

Best Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Tue, 10 Apr 2018 08:30:28 -0400
Drew DeVault  wrote:

> On 2018-04-10 12:20 PM, Pekka Paalanen wrote:
> > Oh yes, that's a good point. This is actually a good reason to repeat
> > the question:
> > 
> > Does the name identify the connector or the monitor?  
> 
> I suppose I should repeat the answer, too: one xdg_output maps to one
> wl_output and has a unique name.

How do you define "one wl_output"?

Do you mean it is the wl_output as identified by its global name (int),
and gets destroyed when the wl_registry sends the remove event?

Unplugging a monitor likely causes the corresponding wl_output global
to be destroyed, right?

If so, that means a couple of things:

- If a user unplugs and re-plugs the same monitor to the same connector,
  you require the xdg-output name to be chosen different as the
  wl_output is no longer the same.

- When ever a compositor starts, all wl_outputs are new, which means
  all xdg-output names must be new as well. So if an application saves
  a name in its config, it will never find a match anymore after the
  compositor gets restarted.

Therefore I don't think it makes sense to tie the xdg-output name to
the identity of the wl_output global, and even less to a wl_output
protocol object which is created anew every time someone calls
wl_registry.bind.

You seem to have an intuitive idea of what you mean, but we still need
to get into the spec wording so that other people can understand it the
same way. Right now I'm not quite sure what exactly identifies an
xdg-output for you.

> It doesn't always make sense to think about connectors. DRM might have
> them, but many compositors also have other backends like X11 or Wayland.
> wlroots names those too (X11-1, WL-2, etc), but they aren't connectors
> and don't have a monitor model.

Right. Outputs in compositors are often named by the connector, not by
the monitor.

My recent work on Weston introduces the concept of "heads" which
essentially refer to connectors and share their names. Weston "outputs"
are basically rendering engine instances and in clone mode one
weston_output feeds the image into several heads at the same time. Then
we have wl_output that represents the monitor, carrying its make and
model, and being 1:1 to a "head" when the head is active (but not
necessarily connected to a monitor).

Given that you say clones will not share the xdg-output name, then in a
Weston implementation I would use either the connector name or the
monitor info (EDID) as the base for creating xdg-output names. I still
don't know which one would be appropriate for the clients, though.

> > The very least the current proposal for a "name" should specify whether
> > it refers to the connector or the monitor, because if it is ambiguous,
> > then we need to add two more events that are not ambiguous when the
> > need to make the difference arises.  
> 
> I don't think there's any amgibuity. One xdg_output == one wl_output,
> this much is already clear by the existing semantics of the protocol and
> we needn't go any further than that.

I do think it is ambiguous, because I have several options on what to
tie the name to, and these options will behave differently towards
clients:

- If a user unplugs a monitor and replugs it into another connector, do
  applications expect the xdg-output name for the new situation to be
  different from the old situation?

- If a user unplugs a monitor and replaces it with a different monitor
  plugged into the same connector, do applications expect the
  xdg-output name to be different from before?

Or, there is a third option:

You could require, that the xdg-output name must be the same as long as
the same monitor is being connected to the same connector, and
compositor restarts alone must not come up with a different the name.
IOW, a correct implementation would include both the connector name and
the monitor serial number in the xdg-output name.

None of these match the lifetime of a wl_output global.

Given all the examples above, when do you expect the name to change,
and when must it stay the same when you think about things over time
and over user actions like unplugging or plugging in a monitor, not
just any single time instant?

The reason why I am insisting on this is that you said that
applications are free to save the name and expect to find it later
under some circumstances. We need to establish those circumstances, so
that application writers can know what it actually means to find or not
find an xdg-output of a certain name they've seen before. If it's all
undefined, then it would be better to just specify that applications
should not expect to be able to find xdg-outputs with the same name as
they have seen some time before.


Thanks,
pq


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

Re: EXT: [PATCH weston v6 00/73] Head-based output configuration API a.k.a clone mode infrastructure

[Derek Foreman]

On 2018-04-10 08:12 AM, Pekka Paalanen wrote:
> On Sat, 24 Mar 2018 10:16:12 +
> "Ray, Ian (GE Healthcare)"  wrote:
> 
>>> On 23 Mar 2018, at 19.16, Ray, Ian (GE Healthcare)  wrote:
>>>
>>>   
 On 23 Mar 2018, at 15.12, Ray, Ian (GE Healthcare)  wrote:

   
> On 16 Feb 2018, at 16.56, Pekka Paalanen  wrote:
>
> From: Pekka Paalanen 
>
> Hi all,
>
> here is the v6 of the shared-CRTC clone mode series. Since v5, quite
> many patches have been extracted from this series, sent out and merged
> upstream. However, now the series is bigger than ever, because here I am
> posting the complete series, including the full DRM-backend migration
> and DRM shared-CRTC clone mode implementation, thanks to having the
> basic atomic modesetting landed upstream.
>
> The previous submission is here:
> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036236.html
>
> Design discussion etc. (sequence diagrams!) can be found here:
> https://phabricator.freedesktop.org/T7727
> https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>
> The series is available as a branch at:
> https://gitlab.collabora.com/pq/weston/commits/clonemode-6
>
> Highlights since v5:
> - DRM-backend migration
> - shared-CRTC clone mode implemented in DRM backend
> - applied review comments from v5
> - don't create a weston_output just to turn it off (DRM)
> - cms-colord will print a warning when used with clone mode
> - cms-colord vs. clone mode mentioned in weston-drm.man
>
> Unfortunately the testing results are not 100%, you can find my testing
> procedure below the diffstat.
>
> The patch series is structured as follows:
>
> - Patches 1-17 introduce most of the new head-based API, and build the
> scaffolding that allows migrating the frontends and the backends one
> by one.
>   

 Patches 01-17 : Reviewed-by Ian Ray 

   
> - Patches 18-24 migrate the frontends one by one. Patch 19 introduces
> the simple output configurator which is first used for all backends,
> including the DRM-backend.
>
> - Patches 25-30 clean up libweston after the frontend migration.  
>>>
>>> Patches 18-30 : Reviewed-by Ian Ray 
>>>
>>>   
>
> - Patches 31-38 migrate all the backends to the head-based API. At this
> point the DRM-backend migration is basically a fake, though.
>
> - Patch 39 removes weston_output::head with the last bits of the
> scaffolding.  
>>
>> Patches 31-39 : Reviewed-by Ian Ray 
>>
>> (May I say that I am really enjoying the review so far.  The commits
>> are well structured and the commit messages are highly informative.)
> 
> Thank you very much for the reviews, Ian!
> 
> I have addressed your nitpicks and added your R-bs to the first 39
> patches you went through. These can be found in the branch:
> 
> https://gitlab.collabora.com/pq/weston/commits/clonemode-7-part1
> 
> I should probably test that a bit more before pushing.
> 
> Now I'd just need an Acked-by or two from our oldtimers to land that
> batch. After that there would be 34 patches left to review in this
> series.

Well, the whole series can certainly be
Acked-by: Derek Foreman 

though I might not find time to review it in the near future.

Thanks,
Derek

> 
> Thanks,
> pq
> 
>
> - Patches 40-44 enhances libweston core to better support the
> DRM-backend's clone mode configuration and improve logging.
>
> - Patches 45-55 implement the head-based API for real in the
> DRM-backend, culminating in patch 55 which creates heads for all
> connectors.
>
> - Patch 56 removes unused_connectors array which has been replace with
> the head list.
>
> - Patches 57-70 finally implement everything needed for shared-CRTC
> clone mode in the DRM-backend.
>
> - Patches 71-73 add a new output configrator logic in the frontend to
> handle clone mode, supporting a new weston.ini key "same-as".
>
>
> Do you think we should call the weston.ini key "clone-of" instead, to
> leave "same-as" reserved for clone mode where only the desktop area is
> the same but the monitors would have different video modes, scaling,
> etc.?
>
> There are several imaginable uses for "same-as" variants:
> - get me shared-CRTC clone mode or fail
> - get me clone mode, preferring shared-CRTC but automatic fallback to
> independent CRTCs
> - get me clone mode, but I want one monitor with HiDPI and one with
> LoDPI

___
wayland-devel mailing list

Re: EXT: [PATCH weston v6 00/73] Head-based output configuration API a.k.a clone mode infrastructure

[Pekka Paalanen]

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

> > On 23 Mar 2018, at 19.16, Ray, Ian (GE Healthcare)  wrote:
> > 
> >   
> >> On 23 Mar 2018, at 15.12, Ray, Ian (GE Healthcare)  wrote:
> >> 
> >>   
> >>> On 16 Feb 2018, at 16.56, Pekka Paalanen  wrote:
> >>> 
> >>> From: Pekka Paalanen 
> >>> 
> >>> Hi all,
> >>> 
> >>> here is the v6 of the shared-CRTC clone mode series. Since v5, quite
> >>> many patches have been extracted from this series, sent out and merged
> >>> upstream. However, now the series is bigger than ever, because here I am
> >>> posting the complete series, including the full DRM-backend migration
> >>> and DRM shared-CRTC clone mode implementation, thanks to having the
> >>> basic atomic modesetting landed upstream.
> >>> 
> >>> The previous submission is here:
> >>> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036236.html
> >>> 
> >>> Design discussion etc. (sequence diagrams!) can be found here:
> >>> https://phabricator.freedesktop.org/T7727
> >>> https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
> >>> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
> >>> 
> >>> The series is available as a branch at:
> >>> https://gitlab.collabora.com/pq/weston/commits/clonemode-6
> >>> 
> >>> Highlights since v5:
> >>> - DRM-backend migration
> >>> - shared-CRTC clone mode implemented in DRM backend
> >>> - applied review comments from v5
> >>> - don't create a weston_output just to turn it off (DRM)
> >>> - cms-colord will print a warning when used with clone mode
> >>> - cms-colord vs. clone mode mentioned in weston-drm.man
> >>> 
> >>> Unfortunately the testing results are not 100%, you can find my testing
> >>> procedure below the diffstat.
> >>> 
> >>> The patch series is structured as follows:
> >>> 
> >>> - Patches 1-17 introduce most of the new head-based API, and build the
> >>> scaffolding that allows migrating the frontends and the backends one
> >>> by one.
> >>>   
> >> 
> >> Patches 01-17 : Reviewed-by Ian Ray 
> >> 
> >>   
> >>> - Patches 18-24 migrate the frontends one by one. Patch 19 introduces
> >>> the simple output configurator which is first used for all backends,
> >>> including the DRM-backend.
> >>> 
> >>> - Patches 25-30 clean up libweston after the frontend migration.  
> > 
> > Patches 18-30 : Reviewed-by Ian Ray 
> > 
> >   
> >>> 
> >>> - Patches 31-38 migrate all the backends to the head-based API. At this
> >>> point the DRM-backend migration is basically a fake, though.
> >>> 
> >>> - Patch 39 removes weston_output::head with the last bits of the
> >>> scaffolding.  
> 
> Patches 31-39 : Reviewed-by Ian Ray 
> 
> (May I say that I am really enjoying the review so far.  The commits
> are well structured and the commit messages are highly informative.)

Thank you very much for the reviews, Ian!

I have addressed your nitpicks and added your R-bs to the first 39
patches you went through. These can be found in the branch:

https://gitlab.collabora.com/pq/weston/commits/clonemode-7-part1

I should probably test that a bit more before pushing.

Now I'd just need an Acked-by or two from our oldtimers to land that
batch. After that there would be 34 patches left to review in this
series.


Thanks,
pq

> >>> 
> >>> - Patches 40-44 enhances libweston core to better support the
> >>> DRM-backend's clone mode configuration and improve logging.
> >>> 
> >>> - Patches 45-55 implement the head-based API for real in the
> >>> DRM-backend, culminating in patch 55 which creates heads for all
> >>> connectors.
> >>> 
> >>> - Patch 56 removes unused_connectors array which has been replace with
> >>> the head list.
> >>> 
> >>> - Patches 57-70 finally implement everything needed for shared-CRTC
> >>> clone mode in the DRM-backend.
> >>> 
> >>> - Patches 71-73 add a new output configrator logic in the frontend to
> >>> handle clone mode, supporting a new weston.ini key "same-as".
> >>> 
> >>> 
> >>> Do you think we should call the weston.ini key "clone-of" instead, to
> >>> leave "same-as" reserved for clone mode where only the desktop area is
> >>> the same but the monitors would have different video modes, scaling,
> >>> etc.?
> >>> 
> >>> There are several imaginable uses for "same-as" variants:
> >>> - get me shared-CRTC clone mode or fail
> >>> - get me clone mode, preferring shared-CRTC but automatic fallback to
> >>> independent CRTCs
> >>> - get me clone mode, but I want one monitor with HiDPI and one with
> >>> LoDPI


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

[PATCH] xdg-shell: add enums for tiled window state to toplevel configure

[Mike Blumenkrantz]

this adds implementation from a related discussion long ago in which
it was decided that it would be useful for clients to know if/where their
windows were tiled so that various behaviors and visuals could be modified
to improve UX

a window which is e.g., tiled on the right side of the screen would set the
right|top|bottom tiled states in configure

Signed-off-by: Mike Blumenkrantz 

Changes since v1: added since=2 to enum members
---
 stable/xdg-shell/xdg-shell.xml | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..629b983 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -29,7 +29,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   The xdg_wm_base interface is exposed as a global object enabling clients
   to turn their wl_surfaces into windows in a desktop environment. It
@@ -115,7 +115,7 @@
 
   
 
-  
+  
 
   The xdg_positioner provides a collection of rules for the placement of a
   child surface relative to a parent surface. Rules can be defined to 
ensure
@@ -359,7 +359,7 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@
 
   
 
-  
+  
 
   This interface defines an xdg_surface role which allows a surface to,
   among other things, set window-like properties such as maximize,
@@ -750,6 +750,30 @@
  keyboard or pointer focus.

   
+  
+   
+ The window is currently in a tiled layout and the left edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the right edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the top edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the bottom edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
 
 
 
@@ -989,7 +1013,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.14.3

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

Same ilm surface on multiple layer support

[Vikas Patil]

 +Subject

Dear All,

We are facing issue when we are trying to add same surface to multiple
layers. When we try to attach surface to another layer, it is getting
detached from the earlier layer.

We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
in newer version and can it be ported to 1.11.0 ? or Is there any other way
to show same surface on multiple layers?

I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].

*"Currently 1 layer can be only on 1 screen, and 1 surface can be only *
*on 1 layer, we are planning to relax this limitation And allow 1 **surface *
*to be on many layers but we would need to break the ABI and change
the  **ivi-controller protocol."*

[1] https://lists.genivi.org/pipermail/genivi-ivi-layer-
management/2016-October/005416.html

Thanking you in advance.

Best Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Drew DeVault]

On 2018-04-10 12:20 PM, Pekka Paalanen wrote:
> Oh yes, that's a good point. This is actually a good reason to repeat
> the question:
> 
> Does the name identify the connector or the monitor?

I suppose I should repeat the answer, too: one xdg_output maps to one
wl_output and has a unique name.

It doesn't always make sense to think about connectors. DRM might have
them, but many compositors also have other backends like X11 or Wayland.
wlroots names those too (X11-1, WL-2, etc), but they aren't connectors
and don't have a monitor model.

> The very least the current proposal for a "name" should specify whether
> it refers to the connector or the monitor, because if it is ambiguous,
> then we need to add two more events that are not ambiguous when the
> need to make the difference arises.

I don't think there's any amgibuity. One xdg_output == one wl_output,
this much is already clear by the existing semantics of the protocol and
we needn't go any further than that.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

ikshwaku.ec2...@gmail.com

[Vikas Patil]

Dear All,

We are facing issue when we are trying to add same surface to multiple
layers. When we try to attach surface to another layer, it is getting
detached from the earlier layer.

We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
in newer version and can it be ported to 1.11.0 ? or Is there any other way
to show same surface on multiple layers?

I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].

*"Currently 1 layer can be only on 1 screen, and 1 surface can be only *
*on 1 layer, we are planning to relax this limitation And allow 1 **surface *
*to be on many layers but we would need to break the ABI and change
the  **ivi-controller protocol."*

[1]
https://lists.genivi.org/pipermail/genivi-ivi-layer-management/2016-October/005416.html

Thanking you in advance.

Best Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 21/25] protocol: add weston_touch_calibration

[Pekka Paalanen]

On Mon, 9 Apr 2018 12:54:43 +1000
Peter Hutterer  wrote:

> On Fri, Mar 23, 2018 at 02:01:01PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > This is a Wayland protocol extension to allow the calibration of
> > touchscreens in Weston.
> > 
> > See: https://phabricator.freedesktop.org/T7868
> > 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  Makefile.am   |   5 +-
> >  protocol/weston-touch-calibration.xml | 320 
> > ++
> >  2 files changed, 324 insertions(+), 1 deletion(-)
> >  create mode 100644 protocol/weston-touch-calibration.xml

> > +  
> > +
> > +  This is the global interface for calibrating a touchscreen input
> > +  coordinate transformation. It is recommended to make this interface
> > +  privileged.
> > +
> > +  This interface can be used by a client to show a calibration pattern 
> > and
> > +  receive uncalibrated touch coordinates, facilitating the computation 
> > of
> > +  a calibration transformation that will align actual touch positions
> > +  on screen with their expected coordinates.
> > +
> > +  Immediately after being bound by a client, the server sends the
> > +  touch_device events.  
> 
> s/server/compositor/, in a few more places

I'm a bit mixed there. I tried to be consistent with "server", but one
"compositor" still remained. There are a couple dozen "server".

Is your point that all Wayland spec language should be using
"compositor" to talk about the server-side?


> > +
> > +  
> > +   This gives the calibrator role to the surface and ties it with the
> > +   given touch input device.
> > +
> > +   The surface must not already have a role, otherwise invalid_surface
> > +   error is raised.
> > +
> > +   The device string must be one advertised with touch_device event's
> > +   device argument, otherwise invalid_device error is raised.
> > +
> > +   There must not exist a weston_touch_calibrator protocol object in the
> > +   server already, otherwise already_exists error is raised. This
> > +   limitation is server-wide and not specific to any particular client.  
> 
> Personal preference: I find it easier to understand when a sentence is "if
> blah then error E". As opposed to "if not blah, otherwise E". It also
> narrows down the error cases a bit better too because you're only describing
> the error case rather than the not-error case.

Yup.

> > +  
> > +   > +   summary="the surface to give the role to"/>
> > +  
> > +   > +   summary="a new calibrator object"/>
> > +
> > +
> > +
> > +  
> > +   This request asks the server to save the calibration data for the
> > +   given touch input device. The server may ignore this request.
> > +
> > +   The device string must be one advertised with touch_device event's
> > +   device argument, otherwise invalid_device error is raised.
> > +
> > +   The array must contain exactly six 'float' (the 32-bit floating
> > +   point format used by the C language on the system) numbers. The numbers
> > +   form a libinput style 2-by-3 calibration matrix in row-major order.  
> 
> 'libinput-style', i.e. hyphenated. but tbh, no need to mention libinput
> here, just spell out the matrix:
> """
>  For a 3D matrix in the form
>( a b c )
>( d e f )
>( 0 0 1 )
>  the array must contain the values [a, b, c, d, e, f] with a at index 0.
> """

Not only that, but it also needs to define the coordinate spaces where
it applies, and probably also the ordering with other transformations
as well. Hence I just punted to "how libinput uses it", because
everything here is specifically designed for libinput.

I'm also not sure I can actually lay out a matrix so that it will still
look ok in generated output and doxygen docs generated from that.

> Much easier than figuring out what "row-major order" means.

It's a standard term.

> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   When a client binds to weston_touch_calibration, one touch_device
> > +   event is sent for each touchscreen that is available to be calibrated.
> > +   These events are not sent later even if new touch devices appear.  
> 
> Unclear what "later" means, use "Touch devices added after the initial burst
> of events will not generate a touch_device event".

More like:

Touch devices added in the server will not generate touch_device events
for existing weston_touch_calibration objects.

Or simply:

This is the only time when touch_device events are sent.

> Though arguably - why not? Because it makes things easier to implement?

Yes. There is no event to remove a touch device, and there is no need
for a client to maintain an accurate list of touch devices.

Since there is no event to remove a touch device, there also is no
protocol race between server removing and the client using one.

Re: [PATCH weston 16/25] libweston: introduce notify_touch_cal() and doc

[Pekka Paalanen]

On Mon, 9 Apr 2018 12:12:49 +1000
Peter Hutterer  wrote:

> On Fri, Mar 23, 2018 at 02:00:56PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > notify_touch_cal() is an extended form of notify_touch(), adding
> > normalized touch coordinates which are necessary for calibrating a
> > touchscreen.
> > 
> > It would be possible to invert the transformation and convert from
> > global coordinates to normalized device coordinates in input.c without
> > adding this API, but this way it is more robust against code changes.
> > 
> > Recovering normalized device coordinates is necessary because libinput
> > calibration matrix must be given in normalized units, and it would be
> > difficult to compute otherwise. Libinput API does not offer normalized
> > coordinates directly either, but those can be fetched by pretending the
> > output resolution is 1x1.
> > 
> > Anticipating touch calibration mode, the old notify_touch() is renamed
> > into a private process_touch_normal(), and the new notify_touch_cal()
> > delegates to it.
> > 
> > Co-developed by Louis-Francis and Pekka.
> > 
> > Cc: Louis-Francis Ratté-Boulianne 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  libweston/compositor.h  | 21 +++-
> >  libweston/input.c   | 60 
> > -
> >  libweston/libinput-device.c | 11 -
> >  3 files changed, 79 insertions(+), 13 deletions(-)
> > 

> > -/**
> > - * notify_touch - emulates button touches and notifies surfaces 
> > accordingly.
> > - *
> > - * It assumes always the correct cycle sequence until it gets here: 
> > touch_down
> > - * → touch_update → ... → touch_update → touch_end. The driver is 
> > responsible
> > - * for sending along such order.
> > - *
> > - */
> > -WL_EXPORT void
> > -notify_touch(struct weston_touch_device *device, const struct timespec 
> > *time,
> > -int touch_id, double double_x, double double_y, int touch_type)
> > +static void
> > +process_touch_normal(struct weston_touch_device *device,
> > +const struct timespec *time, int touch_id,
> > +double double_x, double double_y, int touch_type)  
> 
> IMO just process_touch() is better, otherwise it's more confusing ("wait?
> why is this normal? and what's not normal? or is this an abbreviation of
> normalized?")

Ok.

> >  {
> > struct weston_touch *touch = device->aggregate;
> > struct weston_touch_grab *grab = device->aggregate->grab;
> > @@ -2423,6 +2416,51 @@ notify_touch(struct weston_touch_device *device, 
> > const struct timespec *time,
> > }
> >  }
> >  
> > +/** Feed in touch down, motion, and up events, calibratable device.
> > + *
> > + * It assumes always the correct cycle sequence until it gets here: 
> > touch_down
> > + * → touch_update → ... → touch_update → touch_end. The driver is 
> > responsible
> > + * for sending along such order.
> > + *
> > + * \param device The physical device that generated the event.
> > + * \param time The event timestamp.
> > + * \param touch_id ID for the touch point of this event (multi-touch).
> > + * \param double_x X coordinate in compositor global space.
> > + * \param double_y Y coordinate in compositor global space.
> > + * \param norm_x Normalized device X coordinate in calibration space.
> > + * \param norm_y Normalized device Y coordinate in calibration space.
> > + * \param touch_type Either WL_TOUCH_DOWN, WL_TOUCH_UP, or WL_TOUCH_MOTION.
> > + *
> > + * Coordinates double_x and double_y are used for normal operation.
> > + *
> > + * Coordinates norm_x and norm_y are only used for touch device 
> > calibration.
> > + * If and only if the weston_touch_device does not support calibrating,
> > + * norm_x and norm_y must be WESTON_INVALID_TOUCH_COORDINATE.
> > + *
> > + * The calibration space is the normalized coordinate space
> > + * [0.0, 1.0]×[0.0, 1.0] of the weston_touch_device. This is assumed to
> > + * map to the similar normalized coordinate space of the associated
> > + * weston_output.
> > + */
> > +WL_EXPORT void
> > +notify_touch_cal(struct weston_touch_device *device,  
> 
> this should be notify_touch_normalized() because that's what the extra
> values are. That calibration affects those is just an implementation detail.
> 
> Also, at this point I can only say creating structs for each coordinate type
> in libinput has helped greatly in understanding what exactly you're dealing
> with at any point in time. see libinput-private.h:
> 
> /* A coordinate pair in device coordinates */
> struct device_coords {
> int x, y;
> };
> 
> /* A dpi-normalized coordinate pair */
> struct normalized_coords {
> double x, y;
> };
> 
> /* A pair of coordinates normalized to a [0,1] or [-1, 1] range */
> struct normalized_range_coords {
> double x, y;
> };
> 
> 
> etc. These are passed through the various functions, so 

Re: [PATCH weston 12/25] input: introduce weston_touch_device

[Pekka Paalanen]

On Mon, 9 Apr 2018 11:55:51 +1000
Peter Hutterer  wrote:

> On Fri, Mar 23, 2018 at 02:00:52PM +0200, Pekka Paalanen wrote:
> > From: Louis-Francis Ratté-Boulianne 
> > 
> > Introduce weston_touch_device for libweston core to track individual
> > touchscreen input devices. A weston_seat/weston_touch may be an
> > aggregation of several physical touchscreen input devices. Separating
> > the physical devices will be required for implementing touchscreen
> > calibration. One can only calibrate one device at a time, and we want to
> > make sure to handle the right one.
> > 
> > Both backends that support touch devices are updated to create
> > weston_touch_devices. Wayland-backend provides touch devices that cannot
> > be calibrated, because we have no access to raw touch coordinates from
> > the device - calibration is the responsibility of the parent display
> > server. Libinput backend provides touch devices that can be calibrated,
> > hence implementing the set and get calibration hooks.
> > 
> > Backends need to maintain an output pointer in any case, so we have a
> > get_output() hook instead of having to maintain an identical field in
> > weston_touch_device. The same justification applies to
> > get_calibration_head_name.
> > 
> > Also update the test plugin to manage weston_touch_device objects.
> > 
> > Co-developed by Louis-Francis and Pekka.  
> 
> just a little nit: you're going to make the world an every so slightly
> angrier place by choosing "calb" instead of "calib" or "cal" as shortcut for
> "calibration" :)
> 
> I predict that almost everyone working on that code will mistype that the
> first few times around.

Right, I can try to think of another name for the calibration matrix
local variable.


Thanks,
pq


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

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Mon, 09 Apr 2018 16:00:35 +0200
Philipp Kerling  wrote:

> Hey,
> 
> I'll just reiterate one point from the prior discussion.
> 
> > On Mon, 9 Apr 2018 08:13:15 -0400
> > Drew DeVault  wrote:
> >   
> > > Good feedback.
> > > 
> > > On 2018-04-09 11:09 AM, Pekka Paalanen wrote:  
> > > > Does this name correspond to the physical connector or to the
> > > > specific
> > > > monitor connected? Or some abstract "output" concept, see the
> > > > next
> > > > paragraph about clone mode.
> > > 
> > > Doesn't matter, whatever the compositor wants. Should be unique to
> > > each
> > > wl_output.  
> > 
> > If it is unique to each wl_output, then it is referring to either a
> > connector or a monitor, ok.
> >   
> > > > [...] Would xdg_outputs for the cloned wl_outputs report
> > > > identical
> > > > names to signify they in fact always show the exact same image?
> > > 
> > > No.  
> > 
> > This is consistent with the above, good.
> >   
> > > > Is this name intended to be stable and persistent, so that
> > > > applications
> > > > can expect to save it in a config and find the same one later,
> > > > after a
> > > > machine reboot, at least if the configuration of that output has
> > > > not
> > > > changed and the compositor is still the same version?
> > > 
> > > Yes.  
> > 
> > But if it is undefined whether the name refers to a connector or a
> > monitor, would that not cause problems for apps to decide how to use
> > it?
> > 
> > If a user unplugs one monitor and then plugs in a different monitor
> > to
> > the same connector, should the name change or stay the same?
> > 
> > If the name is defined to stay the same, the app can look at
> > wl_output
> > make/model to see if the monitor is different.  

> No, this does not work. Having multiple instances of the same make and
> model is common in desktop multi-monitor setups. The app has no option
> to recognize specific ones as long as there is no serial number or
> other additional identifier involved that is not currently part of the
> wl_output and xdg_output info.

Oh yes, that's a good point. This is actually a good reason to repeat
the question:

Does the name identify the connector or the monitor?

I feel that we should have both a connector name and a monitor name
separately and explicitly defined, so that applications that care about
the identity can pick which one they want to match to.

I would hesitate to simply add a "monitor serial" event because I don't
think it's always available and there might be other ways to identify a
unit if it even is a physical monitor to begin with. Hence I'd go with
"monitor name" which could simply be the serial plus maybe make+model
when those are available and something else at other times. Then there
is the special case of what to do when you just cannot identify the
unit uniquely at all.

The very least the current proposal for a "name" should specify whether
it refers to the connector or the monitor, because if it is ambiguous,
then we need to add two more events that are not ambiguous when the
need to make the difference arises.


Thanks,
pq


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

[PATCH weston v3 06/15] ivi-layout: introduced surface create and configure

[Michael Teyfel]

Introduced surface create and configure function for xdg-apps.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-layout-shell.h |  8 +
 ivi-shell/ivi-layout.c   | 74 ++--
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/ivi-shell/ivi-layout-shell.h b/ivi-shell/ivi-layout-shell.h
index 68ca68b..c86cbb1 100644
--- a/ivi-shell/ivi-layout-shell.h
+++ b/ivi-shell/ivi-layout-shell.h
@@ -40,6 +40,14 @@ struct weston_surface;
 struct ivi_layout_surface;
 
 void
+ivi_layout_desktop_surface_configure(struct ivi_layout_surface *ivisurf,
+int32_t width, int32_t height);
+
+struct ivi_layout_surface*
+ivi_layout_desktop_surface_create(struct weston_surface *wl_surface,
+ uint32_t id_surface);
+
+void
 ivi_layout_surface_configure(struct ivi_layout_surface *ivisurf,
 int32_t width, int32_t height);
 
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 0ca2d72..d8fb42e 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1903,20 +1903,8 @@ ivi_layout_surface_dump(struct weston_surface *surface,
  * methods of interaction between ivi-shell with ivi-layout
  */
 
-void
-ivi_layout_surface_configure(struct ivi_layout_surface *ivisurf,
-int32_t width, int32_t height)
-{
-   struct ivi_layout *layout = get_instance();
-
-   /* emit callback which is set by ivi-layout api user */
-   wl_signal_emit(>surface_notification.configure_changed,
-  ivisurf);
-}
-
-struct ivi_layout_surface*
-ivi_layout_surface_create(struct weston_surface *wl_surface,
- uint32_t id_surface)
+static struct ivi_layout_surface*
+surface_create(struct weston_surface *wl_surface, uint32_t id_surface)
 {
struct ivi_layout *layout = get_instance();
struct ivi_layout_surface *ivisurf = NULL;
@@ -1926,14 +1914,6 @@ ivi_layout_surface_create(struct weston_surface 
*wl_surface,
return NULL;
}
 
-   ivisurf = get_surface(>surface_list, id_surface);
-   if (ivisurf != NULL) {
-   if (ivisurf->surface != NULL) {
-   weston_log("id_surface(%d) is already created\n", 
id_surface);
-   return NULL;
-   }
-   }
-
ivisurf = calloc(1, sizeof *ivisurf);
if (ivisurf == NULL) {
weston_log("fails to allocate memory\n");
@@ -1957,7 +1937,55 @@ ivi_layout_surface_create(struct weston_surface 
*wl_surface,
 
wl_list_insert(>surface_list, >link);
 
-   wl_signal_emit(>surface_notification.created, ivisurf);
+   return ivisurf;
+}
+
+void
+ivi_layout_desktop_surface_configure(struct ivi_layout_surface *ivisurf,
+int32_t width, int32_t height)
+{
+   struct ivi_layout *layout = get_instance();
+
+   /* emit callback which is set by ivi-layout api user */
+   wl_signal_emit(>surface_notification.configure_desktop_changed,
+  ivisurf);
+}
+
+struct ivi_layout_surface*
+ivi_layout_desktop_surface_create(struct weston_surface *wl_surface,
+ uint32_t id_surface)
+{
+   return surface_create(wl_surface, id_surface);
+}
+
+void
+ivi_layout_surface_configure(struct ivi_layout_surface *ivisurf,
+int32_t width, int32_t height)
+{
+   struct ivi_layout *layout = get_instance();
+
+   /* emit callback which is set by ivi-layout api user */
+   wl_signal_emit(>surface_notification.configure_changed,
+  ivisurf);
+}
+
+struct ivi_layout_surface*
+ivi_layout_surface_create(struct weston_surface *wl_surface,
+ uint32_t id_surface)
+{
+   struct ivi_layout *layout = get_instance();
+   struct ivi_layout_surface *ivisurf = NULL;
+
+   ivisurf = get_surface(>surface_list, id_surface);
+   if (ivisurf) {
+   weston_log("id_surface(%d) is already created\n", id_surface);
+   return NULL;
+   }
+
+   ivisurf = surface_create(wl_surface, id_surface);
+
+   if (ivisurf)
+   wl_signal_emit(>surface_notification.created, ivisurf);
 
return ivisurf;
 }
-- 
2.7.4

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

[PATCH weston v3 07/15] ivi-shell: linked libweston-desktop and added structs

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 Makefile.am| 1 +
 ivi-shell/ivi-layout-private.h | 2 ++
 ivi-shell/ivi-shell.c  | 4 +++-
 ivi-shell/ivi-shell.h  | 2 ++
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cb..75bd02c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1003,6 +1003,7 @@ ivi_shell_la_LDFLAGS = -module -avoid-version
 ivi_shell_la_LIBADD =  \
libshared.la\
libweston-@LIBWESTON_MAJOR@.la  \
+   libweston-desktop-@LIBWESTON_MAJOR@.la  \
$(COMPOSITOR_LIBS)
 ivi_shell_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
 ivi_shell_la_SOURCES = \
diff --git a/ivi-shell/ivi-layout-private.h b/ivi-shell/ivi-layout-private.h
index fe5be01..c054130 100644
--- a/ivi-shell/ivi-layout-private.h
+++ b/ivi-shell/ivi-layout-private.h
@@ -30,6 +30,7 @@
 
 #include "compositor.h"
 #include "ivi-layout-export.h"
+#include "libweston-desktop/libweston-desktop.h"
 
 struct ivi_layout_view {
struct wl_list link;/* ivi_layout::view_list */
@@ -52,6 +53,7 @@ struct ivi_layout_surface {
 
struct ivi_layout *layout;
struct weston_surface *surface;
+   struct weston_desktop_surface *weston_desktop_surface;
 
struct ivi_layout_surface_properties prop;
 
diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index f34a927..173bc91 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -44,7 +44,7 @@
 
 #include "ivi-shell.h"
 #include "ivi-application-server-protocol.h"
-#include "ivi-layout-export.h"
+#include "ivi-layout-private.h"
 #include "ivi-layout-shell.h"
 #include "shared/helpers.h"
 #include "compositor/weston.h"
@@ -265,6 +265,8 @@ application_surface_create(struct wl_client *client,
return;
}
 
+   layout_surface->weston_desktop_surface = NULL;
+
ivisurf = zalloc(sizeof *ivisurf);
if (ivisurf == NULL) {
wl_resource_post_no_memory(resource);
diff --git a/ivi-shell/ivi-shell.h b/ivi-shell/ivi-shell.h
index e35f75f..be43085 100644
--- a/ivi-shell/ivi-shell.h
+++ b/ivi-shell/ivi-shell.h
@@ -30,6 +30,7 @@
 #include 
 
 #include "compositor.h"
+#include "libweston-desktop/libweston-desktop.h"
 
 struct ivi_shell
 {
@@ -37,6 +38,7 @@ struct ivi_shell
 
struct weston_compositor *compositor;
 
+   struct weston_desktop *desktop;
struct wl_list ivi_surface_list; /* struct ivi_shell_surface::link */
 
struct text_backend *text_backend;
-- 
2.7.4

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

[PATCH weston v3 05/15] ivi-layout: introduced configure_desktop_changed

[Michael Teyfel]

Introduced signal configure_desktop_changed with interface. This signal
should be sent, when a desktop-surface is configured.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-layout-export.h  | 10 ++
 ivi-shell/ivi-layout-private.h |  1 +
 ivi-shell/ivi-layout.c | 17 +
 3 files changed, 28 insertions(+)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index a3ec645..c65eb30 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -191,6 +191,16 @@ struct ivi_layout_interface {
int32_t (*add_listener_configure_surface)(struct wl_listener *listener);
 
/**
+* \brief add a listener for notification when desktop_surface is 
configured
+*
+* When an desktop_surface is configured, a signal is emitted
+* to the listening controller plugins.
+* The pointer of the configured desktop_surface is sent as the void 
*data argument
+* to the wl_listener::notify callback function of the listener.
+*/
+   int32_t (*add_listener_configure_desktop_surface)(struct wl_listener 
*listener);
+
+   /**
 * \brief Get all ivi_surfaces which are currently registered and 
managed
 * by the services
 *
diff --git a/ivi-shell/ivi-layout-private.h b/ivi-shell/ivi-layout-private.h
index 2b8bd47..fe5be01 100644
--- a/ivi-shell/ivi-layout-private.h
+++ b/ivi-shell/ivi-layout-private.h
@@ -104,6 +104,7 @@ struct ivi_layout {
struct wl_signal created;
struct wl_signal removed;
struct wl_signal configure_changed;
+   struct wl_signal configure_desktop_changed;
} surface_notification;
 
struct weston_layer layout_layer;
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index d40a260..0ca2d72 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -967,6 +967,21 @@ ivi_layout_add_listener_configure_surface(struct 
wl_listener *listener)
return IVI_SUCCEEDED;
 }
 
+static int32_t
+ivi_layout_add_listener_configure_desktop_surface(struct wl_listener *listener)
+{
+   struct ivi_layout *layout = get_instance();
+
+   if (!listener) {
+   weston_log("ivi_layout_add_listener_configure_desktop_surface: 
invalid argument\n");
+   return IVI_FAILED;
+   }
+
+   wl_signal_add(>surface_notification.configure_desktop_changed, 
listener);
+
+   return IVI_SUCCEEDED;
+}
+
 uint32_t
 ivi_layout_get_id_of_surface(struct ivi_layout_surface *ivisurf)
 {
@@ -1967,6 +1982,7 @@ ivi_layout_init_with_compositor(struct weston_compositor 
*ec)
wl_signal_init(>surface_notification.created);
wl_signal_init(>surface_notification.removed);
wl_signal_init(>surface_notification.configure_changed);
+   wl_signal_init(>surface_notification.configure_desktop_changed);
 
/* Add layout_layer at the last of weston_compositor.layer_list */
weston_layer_init(>layout_layer, ec);
@@ -1995,6 +2011,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.add_listener_create_surface= 
ivi_layout_add_listener_create_surface,
.add_listener_remove_surface= 
ivi_layout_add_listener_remove_surface,
.add_listener_configure_surface = 
ivi_layout_add_listener_configure_surface,
+   .add_listener_configure_desktop_surface = 
ivi_layout_add_listener_configure_desktop_surface,
.get_surface= shell_get_ivi_layout_surface,
.get_surfaces   = ivi_layout_get_surfaces,
.get_id_of_surface  = ivi_layout_get_id_of_surface,
-- 
2.7.4

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

[PATCH weston v3 15/15] window client: remove ivi-application support

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 Makefile.am  |  2 --
 clients/window.c | 44 +---
 2 files changed, 1 insertion(+), 45 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 099b3c3..87a380c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -657,8 +657,6 @@ nodist_libtoytoolkit_la_SOURCES =   \
protocol/viewporter-client-protocol.h   \
protocol/xdg-shell-unstable-v6-protocol.c   \
protocol/xdg-shell-unstable-v6-client-protocol.h\
-   protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h  \
protocol/pointer-constraints-unstable-v1-protocol.c \
protocol/pointer-constraints-unstable-v1-client-protocol.h  \
protocol/relative-pointer-unstable-v1-protocol.c\
diff --git a/clients/window.c b/clients/window.c
index bcf2b01..e842e79 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -82,10 +82,6 @@ typedef void *EGLContext;
 
 #include "window.h"
 
-#include 
-#include "ivi-application-client-protocol.h"
-#define IVI_SURFACE_ID 9000
-
 #define ZWP_RELATIVE_POINTER_MANAGER_V1_VERSION 1
 #define ZWP_POINTER_CONSTRAINTS_V1_VERSION 1
 
@@ -107,7 +103,6 @@ struct display {
struct wl_data_device_manager *data_device_manager;
struct text_cursor_position *text_cursor_position;
struct zxdg_shell_v6 *xdg_shell;
-   struct ivi_application *ivi_application; /* ivi style shell */
struct zwp_relative_pointer_manager_v1 *relative_pointer_manager;
struct zwp_pointer_constraints_v1 *pointer_constraints;
EGLDisplay dpy;
@@ -269,8 +264,6 @@ struct window {
struct window *parent;
struct window *last_parent;
 
-   struct ivi_surface *ivi_surface;
-
struct window_frame *frame;
 
/* struct surface::link, contains also main_surface */
@@ -1439,19 +1432,6 @@ window_get_display(struct window *window)
 }
 
 static void
-handle_ivi_surface_configure(void *data, struct ivi_surface *ivi_surface,
- int32_t width, int32_t height)
-{
-   struct window *window = data;
-
-   window_schedule_resize(window, width, height);
-}
-
-static const struct ivi_surface_listener ivi_surface_listener = {
-handle_ivi_surface_configure,
-};
-
-static void
 surface_create_surface(struct surface *surface, uint32_t flags)
 {
struct display *display = surface->window->display;
@@ -1601,9 +1581,6 @@ window_destroy(struct window *window)
if (window->xdg_surface)
zxdg_surface_v6_destroy(window->xdg_surface);
 
-   if (window->ivi_surface)
-   ivi_surface_destroy(window->ivi_surface);
-
surface_destroy(window->main_surface);
 
wl_list_remove(>link);
@@ -5149,7 +5126,7 @@ window_create_internal(struct display *display, int 
custom)
surface = surface_create(window);
window->main_surface = surface;
 
-   assert(custom || display->xdg_shell || display->ivi_application);
+   assert(custom || display->xdg_shell);
 
window->custom = custom;
window->preferred_format = WINDOW_PREFERRED_FORMAT_NONE;
@@ -5169,7 +5146,6 @@ struct window *
 window_create(struct display *display)
 {
struct window *window;
-   uint32_t id_ivisurf;
 
window = window_create_internal(display, 0);
 
@@ -5192,16 +5168,6 @@ window_create(struct display *display)
window_inhibit_redraw(window);
 
wl_surface_commit(window->main_surface->surface);
-   } else if (display->ivi_application) {
-   /* auto generation of ivi_id based on process id + basement of 
id */
-   id_ivisurf = IVI_SURFACE_ID + (uint32_t)getpid();
-   window->ivi_surface =
-   ivi_application_surface_create(display->ivi_application,
-  id_ivisurf, 
window->main_surface->surface);
-   fail_on_null(window->ivi_surface, 0, __FILE__, __LINE__);
-
-   ivi_surface_add_listener(window->ivi_surface,
-_surface_listener, window);
}
 
return window;
@@ -5956,11 +5922,6 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
wl_registry_bind(registry, id,
 _subcompositor_interface, 1);
}
-   else if (strcmp(interface, "ivi_application") == 0) {
-   d->ivi_application =
-   wl_registry_bind(registry, id,
-_application_interface, 1);
-   }
 
if (d->global_handler)
d->global_handler(d, id, interface, version, d->user_data);
@@ -6259,9 +6220,6 @@ display_destroy(struct display *display)
if (display->xdg_shell)
 

[PATCH weston v3 14/15] simple-shm: remove ivi-application support

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 Makefile.am  |  4 +---
 clients/simple-shm.c | 40 
 2 files changed, 1 insertion(+), 43 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2279d6a..099b3c3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -565,9 +565,7 @@ nodist_weston_simple_shm_SOURCES =  \
protocol/xdg-shell-unstable-v6-protocol.c   \
protocol/xdg-shell-unstable-v6-client-protocol.h\
protocol/fullscreen-shell-unstable-v1-protocol.c\
-   protocol/fullscreen-shell-unstable-v1-client-protocol.h \
-   protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/fullscreen-shell-unstable-v1-client-protocol.h
 weston_simple_shm_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
 weston_simple_shm_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la
 
diff --git a/clients/simple-shm.c b/clients/simple-shm.c
index 9fa2e21..fc2ef00 100644
--- a/clients/simple-shm.c
+++ b/clients/simple-shm.c
@@ -40,10 +40,6 @@
 #include "xdg-shell-unstable-v6-client-protocol.h"
 #include "fullscreen-shell-unstable-v1-client-protocol.h"
 
-#include 
-#include "ivi-application-client-protocol.h"
-#define IVI_SURFACE_ID 9000
-
 struct display {
struct wl_display *display;
struct wl_registry *registry;
@@ -52,7 +48,6 @@ struct display {
struct zwp_fullscreen_shell_v1 *fshell;
struct wl_shm *shm;
bool has_xrgb;
-   struct ivi_application *ivi_application;
 };
 
 struct buffer {
@@ -67,7 +62,6 @@ struct window {
struct wl_surface *surface;
struct zxdg_surface_v6 *xdg_surface;
struct zxdg_toplevel_v6 *xdg_toplevel;
-   struct ivi_surface *ivi_surface;
struct buffer buffers[2];
struct buffer *prev_buffer;
struct wl_callback *callback;
@@ -165,17 +159,6 @@ static const struct zxdg_toplevel_v6_listener 
xdg_toplevel_listener = {
handle_xdg_toplevel_close,
 };
 
-static void
-handle_ivi_surface_configure(void *data, struct ivi_surface *ivi_surface,
-int32_t width, int32_t height)
-{
-   /* Simple-shm is resizable */
-}
-
-static const struct ivi_surface_listener ivi_surface_listener = {
-   handle_ivi_surface_configure,
-};
-
 static struct window *
 create_window(struct display *display, int width, int height)
 {
@@ -213,19 +196,6 @@ create_window(struct display *display, int width, int 
height)
window->surface,

ZWP_FULLSCREEN_SHELL_V1_PRESENT_METHOD_DEFAULT,
NULL);
-   } else if (display->ivi_application ) {
-   uint32_t id_ivisurf = IVI_SURFACE_ID + (uint32_t)getpid();
-   window->ivi_surface =
-   ivi_application_surface_create(display->ivi_application,
-  id_ivisurf, 
window->surface);
-   if (window->ivi_surface == NULL) {
-   fprintf(stderr, "Failed to create 
ivi_client_surface\n");
-   abort();
-   }
-
-   ivi_surface_add_listener(window->ivi_surface,
-_surface_listener, window);
-
} else {
assert(0);
}
@@ -407,11 +377,6 @@ registry_handle_global(void *data, struct wl_registry 
*registry,
  id, _shm_interface, 1);
wl_shm_add_listener(d->shm, _listener, d);
}
-   else if (strcmp(interface, "ivi_application") == 0) {
-   d->ivi_application =
-   wl_registry_bind(registry, id,
-_application_interface, 1);
-   }
 }
 
 static void
@@ -555,11 +520,6 @@ main(int argc, char **argv)
 
fprintf(stderr, "simple-shm exiting\n");
 
-   if (window->display->ivi_application) {
-   ivi_surface_destroy(window->ivi_surface);
-   ivi_application_destroy(window->display->ivi_application);
-   }
-
destroy_window(window);
destroy_display(display);
 
-- 
2.7.4

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

[PATCH weston v3 13/15] simple-egl: remove ivi-application support

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 Makefile.am  |  4 +--
 clients/simple-egl.c | 86 
 2 files changed, 13 insertions(+), 77 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 75bd02c..2279d6a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -607,9 +607,7 @@ demo_clients += weston-simple-egl
 weston_simple_egl_SOURCES = clients/simple-egl.c
 nodist_weston_simple_egl_SOURCES = \
protocol/xdg-shell-unstable-v6-protocol.c   \
-   protocol/xdg-shell-unstable-v6-client-protocol.h\
-   protocol/ivi-application-protocol.c \
-   protocol/ivi-application-client-protocol.h
+   protocol/xdg-shell-unstable-v6-client-protocol.h
 weston_simple_egl_CFLAGS = $(AM_CFLAGS) $(SIMPLE_EGL_CLIENT_CFLAGS)
 weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
 endif
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index a1e57ae..936e015 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -45,8 +45,6 @@
 #include "xdg-shell-unstable-v6-client-protocol.h"
 #include 
 #include 
-#include "ivi-application-client-protocol.h"
-#define IVI_SURFACE_ID 9000
 
 #include "shared/helpers.h"
 #include "shared/platform.h"
@@ -74,7 +72,6 @@ struct display {
EGLConfig conf;
} egl;
struct window *window;
-   struct ivi_application *ivi_application;
 
PFNEGLSWAPBUFFERSWITHDAMAGEEXTPROC swap_buffers_with_damage;
 };
@@ -97,7 +94,6 @@ struct window {
struct wl_surface *surface;
struct zxdg_surface_v6 *xdg_surface;
struct zxdg_toplevel_v6 *xdg_toplevel;
-   struct ivi_surface *ivi_surface;
EGLSurface egl_surface;
struct wl_callback *callback;
int fullscreen, maximized, opaque, buffer_size, frame_sync, delay;
@@ -359,27 +355,22 @@ static const struct zxdg_toplevel_v6_listener 
xdg_toplevel_listener = {
 };
 
 static void
-handle_ivi_surface_configure(void *data, struct ivi_surface *ivi_surface,
- int32_t width, int32_t height)
+create_surface(struct window *window)
 {
-   struct window *window = data;
-
-   wl_egl_window_resize(window->native, width, height, 0, 0);
-
-   window->geometry.width = width;
-   window->geometry.height = height;
+   struct display *display = window->display;
+   EGLBoolean ret;
 
-   if (!window->fullscreen)
-   window->window_size = window->geometry;
-}
+   window->surface = wl_compositor_create_surface(display->compositor);
 
-static const struct ivi_surface_listener ivi_surface_listener = {
-   handle_ivi_surface_configure,
-};
+   window->native =
+   wl_egl_window_create(window->surface,
+window->geometry.width,
+window->geometry.height);
+   window->egl_surface =
+   weston_platform_create_egl_surface(display->egl.dpy,
+  display->egl.conf,
+  window->native, NULL);
 
-static void
-create_xdg_surface(struct window *window, struct display *display)
-{
window->xdg_surface = zxdg_shell_v6_get_xdg_surface(display->shell,
window->surface);
zxdg_surface_v6_add_listener(window->xdg_surface,
@@ -394,50 +385,6 @@ create_xdg_surface(struct window *window, struct display 
*display)
 
window->wait_for_configure = true;
wl_surface_commit(window->surface);
-}
-
-static void
-create_ivi_surface(struct window *window, struct display *display)
-{
-   uint32_t id_ivisurf = IVI_SURFACE_ID + (uint32_t)getpid();
-   window->ivi_surface =
-   ivi_application_surface_create(display->ivi_application,
-  id_ivisurf, window->surface);
-
-   if (window->ivi_surface == NULL) {
-   fprintf(stderr, "Failed to create ivi_client_surface\n");
-   abort();
-   }
-
-   ivi_surface_add_listener(window->ivi_surface,
-_surface_listener, window);
-}
-
-static void
-create_surface(struct window *window)
-{
-   struct display *display = window->display;
-   EGLBoolean ret;
-
-   window->surface = wl_compositor_create_surface(display->compositor);
-
-   window->native =
-   wl_egl_window_create(window->surface,
-window->geometry.width,
-window->geometry.height);
-   window->egl_surface =
-   weston_platform_create_egl_surface(display->egl.dpy,
-  display->egl.conf,
-  window->native, NULL);
-
-
-   if (display->shell) {
-   create_xdg_surface(window, display);
-   } 

[PATCH weston v3 03/15] ivi-shell: introduction of IVI_INVALID_ID

[Michael Teyfel]

Introduction of IVI_INVALID_ID for xdg-shell applications.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-layout-export.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 016d8b5..02bfb2c 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -56,6 +56,7 @@ extern "C" {
 #endif /* __cplusplus */
 
 #include 
+#include 
 
 #include "stdbool.h"
 #include "compositor.h"
@@ -63,6 +64,7 @@ extern "C" {
 
 #define IVI_SUCCEEDED (0)
 #define IVI_FAILED (-1)
+#define IVI_INVALID_ID UINT_MAX
 
 struct ivi_layout_layer;
 struct ivi_layout_screen;
-- 
2.7.4

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

[PATCH weston v3 01/15] ivi-shell: rework goto labels to avoid memory leaks

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-shell.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index 51e13a0..6497376 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -469,7 +469,6 @@ wet_shell_init(struct weston_compositor *compositor,
   int *argc, char *argv[])
 {
struct ivi_shell *shell;
-   int retval = -1;
 
shell = zalloc(sizeof *shell);
if (shell == NULL)
@@ -481,22 +480,27 @@ wet_shell_init(struct weston_compositor *compositor,
wl_signal_add(>destroy_signal, >destroy_listener);
 
if (input_panel_setup(shell) < 0)
-   goto out;
+   goto err_shell;
 
shell->text_backend = text_backend_init(compositor);
if (!shell->text_backend)
-   goto out;
+   goto err_shell;
 
if (wl_global_create(compositor->wl_display,
 _application_interface, 1,
 shell, bind_ivi_application) == NULL)
-   goto out;
+   goto err_text_backend;
 
ivi_layout_init_with_compositor(compositor);
shell_add_bindings(compositor, shell);
 
-   retval = 0;
+   return IVI_SUCCEEDED;
 
-out:
-   return retval;
+err_text_backend:
+   text_backend_destroy(shell->text_backend);
+
+err_shell:
+   free(shell);
+
+   return IVI_FAILED;
 }
-- 
2.7.4

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

[PATCH weston v3 04/15] layout-interface: added interface to change surface id

[Michael Teyfel]

This interface enables an id-agent to change the surface ids of an
ivi-layout-surface once.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-layout-export.h |  6 ++
 ivi-shell/ivi-layout.c| 39 +++
 2 files changed, 45 insertions(+)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 02bfb2c..a3ec645 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -315,6 +315,12 @@ struct ivi_layout_interface {
uint32_t duration);
 
/**
+* \brief set id of ivi_layout_surface
+*/
+   int32_t (*surface_set_id)(struct ivi_layout_surface *ivisurf,
+ uint32_t id_surface);
+
+   /**
 * layer controller interface
 */
 
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index d9a0c2d..d40a260 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1809,6 +1809,44 @@ ivi_layout_surface_set_transition_duration(struct 
ivi_layout_surface *ivisurf,
return 0;
 }
 
+/*
+ * This interface enables e.g. an id agent to set the id of an ivi-layout
+ * surface, that has been created by a desktop application. This can only be
+ * done once as long as the initial surface id equals IVI_INVALID_ID. 
Afterwards
+ * two events are emitted, namely surface_created and surface_configured.
+ */
+static int32_t
+ivi_layout_surface_set_id(struct ivi_layout_surface *ivisurf,
+ uint32_t id_surface)
+{
+   struct ivi_layout *layout = get_instance();
+   struct ivi_layout_surface *search_ivisurf = NULL;
+
+   if (!ivisurf) {
+   weston_log("%s: invalid argument\n", __func__);
+   return IVI_FAILED;
+   }
+
+   if (ivisurf->id_surface != IVI_INVALID_ID) {
+   weston_log("surface id can only be set once\n");
+   return IVI_FAILED;
+   }
+
+   search_ivisurf = get_surface(>surface_list, id_surface);
+   if (search_ivisurf) {
+   weston_log("id_surface(%d) is already created\n", id_surface);
+   return IVI_FAILED;
+   }
+
+   ivisurf->id_surface = id_surface;
+
+   wl_signal_emit(>surface_notification.created, ivisurf);
+   wl_signal_emit(>surface_notification.configure_changed,
+  ivisurf);
+
+   return IVI_SUCCEEDED;
+}
+
 static int32_t
 ivi_layout_surface_set_transition(struct ivi_layout_surface *ivisurf,
  enum ivi_layout_transition_type type,
@@ -1971,6 +2009,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.surface_get_weston_surface = 
ivi_layout_surface_get_weston_surface,
.surface_set_transition = 
ivi_layout_surface_set_transition,
.surface_set_transition_duration= 
ivi_layout_surface_set_transition_duration,
+   .surface_set_id = ivi_layout_surface_set_id,
 
/**
 * layer controller interfaces
-- 
2.7.4

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

[PATCH weston v3 00/15] Desktop Protocol Support for IVI-Shell (Weston 4.0)

[Michael Teyfel]

Hi all,

Since some time I’m working on ivi-shell to add xdg-protocol support by means 
of libweston-desktop. Due to my changes both xdg-protocol applications and 
ivi-shell / ivi-application-protocol applications are supported within 
ivi-shell now. The known functionality is preserved and just extended by a 
further protocol. The advantage is that client applications do not need to be 
edited to generate an id and are also not limited to use the custom 
ivi-application protocol anymore, since the ids are handled by an id agent 
inside of weston now.

As a preparation for the changes the goto labels in ivi-shell have been 
reworked to avoid memory leaks. In ivi-layout I added an interface 
(ivi_layout_surface_set_id) to set the surface-id of an ivi-layout-surface. It 
can be done once after being created by an xdg-protocol application to assign a 
numeric id by means of an id agent for example. Additionally I introduced a new 
event to notify about a desktop surface being configured 
(desktop_surface_configured). An id agent can register to this event and react 
to this accordingly by assigning an id by means of ivi_layout_surface_set_id. 
As a result I also changed the test client applications in the Weston 
repository and removed the ivi-application protocol support since that has only 
been used, if xdg protocol is not supported. Finally hmi-controller has been 
edited to accept desktop surfaces.

There are some things that can be done in the future:  At first it would be 
diligent, if hmi-controller would also use xdg protocol for the GUI itself. 
Then also the surface_configure event could be removed from hmi-controller. 
Secondly the weston unit tests should also test the interface changes for 
surface_set_id and also should stop using the ivi-application protocol.

Thanks for reading and questions are very welcome.


[changes version 2]
Adjustments have been done according to Quentin Glidic's remarks.
* weston_desktop_surface_create_view is used to create a view for toplevel 
desktop surfaces
* weston_desktop_surface_unlink_view is used to destroy a view for toplevel 
desktop surfaces
* weston_desktop_surface_set_user_data and 
weston_desktop_surface_get_user_data() are used instead of loops

Thanks for your review.

Reviewed-by: Emre Ucan 
[/changes version 2]

[changes version 3]
The patches have been rebased and adjusted to Weston 4.0.

Reviewed-by: Emre Ucan  
[/changes version 3]



Michael Teyfel (15):
  ivi-shell: rework goto labels to avoid memory leaks
  ivi-shell: removed assert
  ivi-shell: introduction of IVI_INVALID_ID
  layout-interface: added interface to change surface id
  ivi-layout: introduced configure_desktop_changed
  ivi-layout: introduced surface create and configure
  ivi-shell: linked libweston-desktop and added structs
  ivi-layout: use libweston-desktop api for views
  ivi-shell: added libweston-desktop-api implementation
  ivi-shell: remove surface_destroy_listener
  ivi-shell: create weston_desktop in wet_shell_init
  hmi-controller: register for desktop_surface_configured
  simple-egl: remove ivi-application support
  simple-shm: remove ivi-application support
  window client: remove ivi-application support

 Makefile.am|  11 +--
 clients/simple-egl.c   |  86 +++---
 clients/simple-shm.c   |  40 -
 clients/window.c   |  44 +-
 ivi-shell/hmi-controller.c |  70 ---
 ivi-shell/ivi-layout-export.h  |  18 
 ivi-shell/ivi-layout-private.h |   3 +
 ivi-shell/ivi-layout-shell.h   |   8 ++
 ivi-shell/ivi-layout.c | 155 +++--
 ivi-shell/ivi-shell.c  | 193 ++---
 ivi-shell/ivi-shell.h  |   2 +
 11 files changed, 395 insertions(+), 235 deletions(-)

-- 
2.7.4

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

[PATCH weston v3 02/15] ivi-shell: removed assert

[Michael Teyfel]

Removed assert, that checks if ivi-surface is not available, since this
can now happen with xdg-shell support.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-shell.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index 6497376..f34a927 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -108,7 +108,6 @@ shell_surface_send_configure(struct weston_surface *surface,
struct ivi_shell_surface *shsurf;
 
shsurf = get_ivi_shell_surface(surface);
-   assert(shsurf);
if (!shsurf)
return;
 
-- 
2.7.4

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

[PATCH weston v3 12/15] hmi-controller: register for desktop_surface_configured

[Michael Teyfel]

Since ivi-shell now supports xdg-protocol, the surface_created listener
can be removed and the desktop_surface_configured listener is needed.
ivi-layout: libweston-desktop api is used to send configure event to
application.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/hmi-controller.c | 70 ++
 ivi-shell/ivi-layout.c | 12 ++--
 2 files changed, 49 insertions(+), 33 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 0e44df8..36bffe2 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -129,9 +129,9 @@ struct hmi_controller {
struct weston_compositor   *compositor;
struct wl_listener  destroy_listener;
 
-   struct wl_listener  surface_created;
struct wl_listener  surface_removed;
struct wl_listener  surface_configured;
+   struct wl_listener  desktop_surface_configured;
 
struct wl_client   *user_interface;
struct ui_setting   ui_setting;
@@ -577,28 +577,6 @@ create_layer(struct weston_output *output,
  * Internal set notification
  */
 static void
-set_notification_create_surface(struct wl_listener *listener, void *data)
-{
-   struct hmi_controller *hmi_ctrl =
-   wl_container_of(listener, hmi_ctrl,
-   surface_created);
-   struct ivi_layout_surface *ivisurf = data;
-   struct hmi_controller_layer *layer_link =
-   
wl_container_of(hmi_ctrl->application_layer_list.prev,
-   layer_link,
-   link);
-   struct ivi_layout_layer *application_layer = layer_link->ivilayer;
-   int32_t ret = 0;
-
-   /* skip ui widgets */
-   if (is_surf_in_ui_widget(hmi_ctrl, ivisurf))
-   return;
-
-   ret = hmi_ctrl->interface->layer_add_surface(application_layer, 
ivisurf);
-   assert(!ret);
-}
-
-static void
 set_notification_remove_surface(struct wl_listener *listener, void *data)
 {
struct hmi_controller *hmi_ctrl =
@@ -665,6 +643,42 @@ set_notification_configure_surface(struct wl_listener 
*listener, void *data)
switch_mode(hmi_ctrl, hmi_ctrl->layout_mode);
 }
 
+static void
+set_notification_configure_desktop_surface(struct wl_listener *listener, void 
*data)
+{
+   struct hmi_controller *hmi_ctrl =
+   wl_container_of(listener, hmi_ctrl,
+   desktop_surface_configured);
+   struct ivi_layout_surface *ivisurf = data;
+   struct hmi_controller_layer *layer_link =
+   
wl_container_of(hmi_ctrl->application_layer_list.prev,
+   layer_link,
+   link);
+   struct ivi_layout_layer *application_layer = layer_link->ivilayer;
+   struct weston_surface *surface;
+   int32_t ret = 0;
+
+   /* skip ui widgets */
+   if (is_surf_in_ui_widget(hmi_ctrl, ivisurf))
+   return;
+
+   ret = hmi_ctrl->interface->layer_add_surface(application_layer, 
ivisurf);
+   assert(!ret);
+
+   /*
+* if application changes size of wl_buffer. The source rectangle shall 
be
+* fit to the size.
+*/
+   surface = hmi_ctrl->interface->surface_get_weston_surface(ivisurf);
+   if (surface) {
+   hmi_ctrl->interface->surface_set_source_rectangle(ivisurf, 0,
+   0, surface->width, surface->height);
+   }
+
+   hmi_ctrl->interface->commit_changes();
+   switch_mode(hmi_ctrl, hmi_ctrl->layout_mode);
+}
+
 /**
  * A hmi_controller used 4 ivi_layers to manage ivi_surfaces. The IDs of
  * corresponding ivi_layer are defined in weston.ini. Default scene graph
@@ -858,6 +872,9 @@ hmi_controller_create(struct weston_compositor *ec)
hmi_ctrl->surface_configured.notify = 
set_notification_configure_surface;

hmi_ctrl->interface->add_listener_configure_surface(_ctrl->surface_configured);
 
+   hmi_ctrl->desktop_surface_configured.notify = 
set_notification_configure_desktop_surface;
+   
hmi_ctrl->interface->add_listener_configure_desktop_surface(_ctrl->desktop_surface_configured);
+
hmi_ctrl->destroy_listener.notify = hmi_controller_destroy;
wl_signal_add(_ctrl->compositor->destroy_signal,
  _ctrl->destroy_listener);
@@ -1278,13 +1295,6 @@ ivi_hmi_controller_UI_ready(struct wl_client *client,
hmi_ctrl->interface->commit_changes();
 
ivi_hmi_controller_add_launchers(hmi_ctrl, 256);
-
-   /* Add surface_created listener after the initialization of launchers.
-* Otherwise, surfaces of the 

[PATCH weston v3 10/15] ivi-shell: remove surface_destroy_listener

[Michael Teyfel]

Since the surface_destroy_listener is only registered for ivi-shell
applications, it should only be removed for ivi-shell applications.

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-shell.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index 5c011d9..160c41c 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -156,6 +156,10 @@ layout_surface_cleanup(struct ivi_shell_surface *ivisurf)
 {
assert(ivisurf->layout_surface != NULL);
 
+   /* destroy weston_surface destroy signal. */
+   if (!ivisurf->layout_surface->weston_desktop_surface)
+   wl_list_remove(>surface_destroy_listener.link);
+
ivi_layout_surface_destroy(ivisurf->layout_surface);
ivisurf->layout_surface = NULL;
 
@@ -163,9 +167,6 @@ layout_surface_cleanup(struct ivi_shell_surface *ivisurf)
ivisurf->surface->committed_private = NULL;
weston_surface_set_label_func(ivisurf->surface, NULL);
ivisurf->surface = NULL;
-
-   // destroy weston_surface destroy signal.
-   wl_list_remove(>surface_destroy_listener.link);
 }
 
 /*
-- 
2.7.4

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

[PATCH weston v3 09/15] ivi-shell: added libweston-desktop-api implementation

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-shell.c | 156 ++
 1 file changed, 156 insertions(+)

diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index 173bc91..5c011d9 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -463,6 +463,162 @@ shell_add_bindings(struct weston_compositor *compositor,
 }
 
 /*
+ * libweston-desktop
+ */
+
+static void
+desktop_surface_ping_timeout(struct weston_desktop_client *client,
+void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_ping_timeout is not 
supported\n");
+}
+
+static void
+desktop_surface_pong(struct weston_desktop_client *client,
+void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_pong is not supported\n");
+}
+
+static void
+desktop_surface_added(struct weston_desktop_surface *surface,
+ void *user_data)
+{
+   struct ivi_shell *shell = (struct ivi_shell *) user_data;
+   struct ivi_layout_surface *layout_surface;
+   struct ivi_shell_surface *ivisurf;
+   struct weston_surface *weston_surf =
+   weston_desktop_surface_get_surface(surface);
+
+   layout_surface = ivi_layout_desktop_surface_create(weston_surf,
+  IVI_INVALID_ID);
+   if (!layout_surface) {
+   return;
+   }
+
+   layout_surface->weston_desktop_surface = surface;
+
+   ivisurf = zalloc(sizeof *ivisurf);
+   if (!ivisurf) {
+   return;
+   }
+
+   ivisurf->shell = shell;
+   ivisurf->id_surface = IVI_INVALID_ID;
+
+   ivisurf->width = 0;
+   ivisurf->height = 0;
+   ivisurf->layout_surface = layout_surface;
+   ivisurf->surface = weston_surf;
+
+   weston_desktop_surface_set_user_data(surface, ivisurf);
+}
+
+static void
+desktop_surface_removed(struct weston_desktop_surface *surface,
+   void *user_data)
+{
+   struct ivi_shell_surface *ivisurf = (struct ivi_shell_surface *)
+   weston_desktop_surface_get_user_data(surface);
+
+   assert(ivisurf != NULL);
+
+   if (ivisurf->layout_surface)
+   layout_surface_cleanup(ivisurf);
+}
+
+static void
+desktop_surface_committed(struct weston_desktop_surface *surface,
+ int32_t sx, int32_t sy, void *user_data)
+{
+   struct ivi_shell_surface *ivisurf = (struct ivi_shell_surface *)
+   weston_desktop_surface_get_user_data(surface);
+   struct weston_surface *weston_surf =
+   weston_desktop_surface_get_surface(surface);
+
+   if(!ivisurf)
+   return;
+
+   if (weston_surf->width == 0 || weston_surf->height == 0)
+   return;
+
+   if (ivisurf->width != weston_surf->width ||
+   ivisurf->height != weston_surf->height) {
+   ivisurf->width  = weston_surf->width;
+   ivisurf->height = weston_surf->height;
+
+   ivi_layout_desktop_surface_configure(ivisurf->layout_surface,
+weston_surf->width,
+weston_surf->height);
+   }
+}
+
+static void
+desktop_surface_move(struct weston_desktop_surface *surface,
+struct weston_seat *seat, uint32_t serial, void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_move is not supported\n");
+}
+
+static void
+desktop_surface_resize(struct weston_desktop_surface *surface,
+  struct weston_seat *seat, uint32_t serial,
+  enum weston_desktop_surface_edge edges, void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_resize is not supported\n");
+}
+
+static void
+desktop_surface_fullscreen_requested(struct weston_desktop_surface *surface,
+bool fullscreen,
+struct weston_output *output,
+void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_fullscreen_requested is not 
supported\n");
+}
+
+static void
+desktop_surface_maximized_requested(struct weston_desktop_surface *surface,
+   bool maximized, void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_maximized_requested is not 
supported\n");
+}
+
+static void
+desktop_surface_minimized_requested(struct weston_desktop_surface *surface,
+   void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_minimized_requested is not 
supported\n");
+}
+
+static void
+desktop_surface_set_xwayland_position(struct weston_desktop_surface *surface,
+ int32_t x, int32_t y, void *user_data)
+{
+   weston_log("ivi-shell: desktop_surface_set_xwayland_position is not 
supported\n");
+}
+
+static const 

[PATCH weston v3 08/15] ivi-layout: use libweston-desktop api for views

[Michael Teyfel]

Signed-off-by: Michael Teyfel 
---
 ivi-shell/ivi-layout.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index d8fb42e..b06bf30 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -153,7 +153,10 @@ ivi_view_destroy(struct ivi_layout_view *ivi_view)
wl_list_remove(_view->pending_link);
wl_list_remove(_view->order_link);
 
-   weston_view_destroy(ivi_view->view);
+   if (weston_surface_is_desktop_surface(ivi_view->ivisurf->surface))
+   weston_desktop_surface_unlink_view(ivi_view->view);
+   else
+   weston_view_destroy(ivi_view->view);
 
free(ivi_view);
 }
@@ -170,7 +173,13 @@ ivi_view_create(struct ivi_layout_layer *ivilayer,
return NULL;
}
 
-   ivi_view->view = weston_view_create(ivisurf->surface);
+   if (weston_surface_is_desktop_surface(ivisurf->surface)) {
+   ivi_view->view = weston_desktop_surface_create_view(
+   ivisurf->weston_desktop_surface);
+   } else {
+   ivi_view->view = weston_view_create(ivisurf->surface);
+   }
+
if (ivi_view->view == NULL) {
weston_log("fails to allocate memory\n");
free(ivi_view);
-- 
2.7.4

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

Re: [PATCH weston v2] ivi-shell: Damage view below after unmapping

[zou lan]

Hi  Emre

I have a question about this change:

Is the commit_screen_list function not enough to handle the layer/surface's
visibility? Why need to handle visibility in commit_changes? They are
called ivi_layout_commit_changes together.

Best Regards
Nancy

2017-02-07 21:04 GMT+08:00 Pekka Paalanen :

> On Tue, 7 Feb 2017 12:55:59 +
> "Ucan, Emre (ADITG/SW1)"  wrote:
>
> > If ivilayer or ivisurf of ivi_view is made invisible in the
> > commit_changes call, we have to damage the weston_view below this
> > ivi_view. Otherwise content of this ivi_view will stay visible.
> >
> > Signed-off-by: Emre Ucan 
> > ---
> >  ivi-shell/ivi-layout.c |   13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > index 712cc30..64e4ead 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c
> > @@ -681,8 +681,19 @@ commit_changes(struct ivi_layout *layout)
> >* If the view's layer or surface is invisible, we do not
> need
> >* to update its properties.
> >*/
> > - if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility)
> > + if (!ivilayer->prop.visibility ||
> !ivisurf->prop.visibility) {
> > + /*
> > + * If ivilayer or ivisurf of ivi_view is made
> invisible
> > + * in this commit_changes call, we have to damage
> > + * the weston_view below this ivi_view. Otherwise
> content
> > + * of this ivi_view will stay visible.
> > + */
> > + if ((ivilayer->prop.event_mask |
> ivisurf->prop.event_mask) &&
> > + IVI_NOTIFICATION_VISIBILITY)
> > + weston_view_damage_below(ivi_view->view);
> > +
> >   continue;
> > + }
> >
> >   update_prop(ivi_view);
> >   }
>
> Hi,
>
> looks fine to me, pushed:
>19222b4..7fe0bb2  master -> master
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel