[PATCH weston-ivi-shell v3 02/10] ivi application protocol:
Nobuhiko Tanibata
nobuhiko_tanibata at xddp.denso.co.jp
Mon Mar 17 02:11:44 PDT 2014
2014-03-17 16:15 に Pekka Paalanen さんは書きました:
> On Mon, 17 Mar 2014 13:48:45 +0900
> Nobuhiko Tanibata <nobuhiko_tanibata at xddp.denso.co.jp> wrote:
>
>> 2014-03-17 10:24 に Nobuhiko Tanibata さんは書きました:
>> > 2014-03-15 15:58 に Nobuhiko Tanibata さんは書きました:
>> >> 2014-03-14 23:16 に Pekka Paalanen さんは書きました:
>> >>> On Wed, 12 Mar 2014 23:59:33 +0900
>> >>> Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp> wrote:
>> >>>
>> >>>> Add interface ivi_application, which creates ivi_surface objects
>> >>>> tied
>> >>>> to a given wl_surface with a given id. The given id can be used in a
>> >>>> shell to identify which application is assigned to a wl_surface and
>> >>>> layout the surface wherever the shell wants. ivi_surface objects can
>> >>>> be used to receive status of wl_surface in the scenegraph of the
>> >>>> compositor.
>> >>>>
>> >>>> Signed-off-by: Nobuhiko Tanibata
>> >>>> <NOBUHIKO_TANIBATA at xddp.denso.co.jp>
>> >>>> ---
>> >>>>
>> >>>> Changes for v2:
>> >>>> - Rename "error" to "warning" because meaning of "error" in
>> >>>> wayland is fatal.
>> >>>>
>> >>>> Changes for v3:
>> >>>> - Move "warning" from ivi_application to ivi_surface.
>> >>>> - Squash Makefile.
>> >>>> - Add description to ivi_surface:destroy.
>> >>>> - Update description of ivi_application:surface_create.
>> >>>>
>> >>>> protocol/Makefile.am | 3 +-
>> >>>> protocol/ivi-application.xml | 96
>> >>>> ++++++++++++++++++++++++++++++++++++++++++++
>> >>>> 2 files changed, 98 insertions(+), 1 deletion(-)
>> >>>> create mode 100644 protocol/ivi-application.xml
>> >>>>
>> >>>> diff --git a/protocol/Makefile.am b/protocol/Makefile.am
>> >>>> index 5e331a7..9913f16 100644
>> >>>> --- a/protocol/Makefile.am
>> >>>> +++ b/protocol/Makefile.am
>> >>>> @@ -8,7 +8,8 @@ protocol_sources = \
>> >>>> text-cursor-position.xml \
>> >>>> wayland-test.xml \
>> >>>> xdg-shell.xml \
>> >>>> - scaler.xml
>> >>>> + scaler.xml \
>> >>>> + ivi-application.xml
>> >>>>
>> >>>> if HAVE_XMLLINT
>> >>>> .PHONY: validate
>> >>>> diff --git a/protocol/ivi-application.xml
>> >>>> b/protocol/ivi-application.xml
>> >>>> new file mode 100644
>> >>>> index 0000000..8f5c23d
>> >>>> --- /dev/null
>> >>>> +++ b/protocol/ivi-application.xml
>> >>>> @@ -0,0 +1,96 @@
>> >>>> +<?xml version="1.0" encoding="UTF-8"?>
>> >>>> +<protocol name="ivi_application">
>> >>>> +
>> >>>> + <copyright>
>> >>>> + Copyright (C) 2013 DENSO CORPORATION
>> >>>> + Copyright (c) 2013 BMW Car IT GmbH
>> >>>> +
>> >>>> + Permission is hereby granted, free of charge, to any person
>> >>>> obtaining a copy
>> >>>> + of this software and associated documentation files (the
>> >>>> "Software"), to deal
>> >>>> + in the Software without restriction, including without
>> >>>> limitation the rights
>> >>>> + to use, copy, modify, merge, publish, distribute, sublicense,
>> >>>> and/or sell
>> >>>> + copies of the Software, and to permit persons to whom the
>> >>>> Software is
>> >>>> + furnished to do so, subject to the following conditions:
>> >>>> +
>> >>>> + The above copyright notice and this permission notice shall be
>> >>>> included in
>> >>>> + all copies or substantial portions of the Software.
>> >>>> +
>> >>>> + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> >>>> EXPRESS OR
>> >>>> + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> >>>> MERCHANTABILITY,
>> >>>> + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>> >>>> EVENT SHALL THE
>> >>>> + AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>> >>>> OR OTHER
>> >>>> + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> >>>> ARISING FROM,
>> >>>> + OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> >>>> DEALINGS IN
>> >>>> + THE SOFTWARE.
>> >>>> + </copyright>
>> >>>> +
>> >>>> + <interface name="ivi_surface" version="1">
>> >>>> + <description summary="application interface to surface in
>> >>>> ivi compositor"/>
>> >>>> +
>> >>>> + <request name="destroy" type="destructor">
>> >>>> + <description summary="destroy ivi_surface">
>> >>>> + This removes link from surface_id to wl_surface.
>> >>>> However it doesn't
>> >>>> + remove internal properties, e.g. position,
>> >>>> visibility, and so on, which
>> >>>> + is set to the surface_id. This means when some
>> >>>> issues happen on clients
>> >>>> + and a ivi_surface is destroyed, it can use previous
>> >>>> properties immediately
>> >>>> + without setting it again if it restarts and
>> >>>> attaches new wl_surface to
>> >>>> + the same surface_id.
>> >>>
>> >>> This keeping of properties... why even mention it here? They are
>> >>> nothing this client can affect, are they?
>> >>>
>> >>> Otherwise I would ask, how would the client know if the properties
>> >>> are
>> >>> already set, or if it needs to set them again, or if the client
>> >>> actually needs to know some of them to function correctly.
>> >>>
>> >>> Not a big deal.
>> >>
>> >> Hi pq,
>> >>
>> >> Yes, it doesn't affect client behavior so I will remove description
>> >> after "However...".
>> >> The decision shall be done in server side. So as you say, it should
>> >> not be mentioned here.
>> >>
>> >>>
>> >>>> + </description>
>> >>>> + </request>
>> >>>> +
>> >>>> + <event name="visibility">
>> >>>> + <description summary="visibility of surface in ivi
>> >>>> compositor has changed">
>> >>>> + The new visibility state is provided in argument
>> >>>> visibility.
>> >>>> + If visibility is 0, the surface has become
>> >>>> invisible.
>> >>>> + If visibility is not 0, the surface has become
>> >>>> visible.
>> >>>> + </description>
>> >>>> + <arg name="visibility" type="int"/>
>> >>>> + </event>
>> >>>> +
>> >>>> + <enum name="warning_code">
>> >>>> + <description summary="possible warning codes returned
>> >>>> by ivi compositor">
>> >>>> + These warning codes define all possible warning
>> >>>> codes returned by ivi compositor
>> >>>> + on server-side warnings.
>> >>>> + invalid_wl_surface: invalid wl_surface is set. This
>> >>>> happen if wl_surface is destroy before this.
>> >>>
>> >>> I guess you mean, that invalid_wl_surface is emitted, if the
>> >>> wl_surface
>> >>> is destroyed before the ivi_surface, right?
>> >>
>> >> Yes, you are right.
>> >>>
>> >>> Usually we deal with these things by saying the ivi_surface would
>> >>> just
>> >>> become inert, but I assume you really want the notification here.
>> >>>
>> >>> Is invalid_wl_surface also for the case when the wl_surface already
>> >>> has
>> >>> an ivi_surface associated?
>> >>
>> >> In the above case, a code "surface_id_in_use" is used. But, I shall
>> >> add "wl_surface_in_use" to the warnings.
>> >>
>> >>>
>> >>>> + surface_id_in_use: surface_id is already assigned
>> >>>> by another application.
>> >>>> + </description>
>> >>>> + <entry name="invalid_wl_surface" value="1"
>> >>>> summary="wl_surface is invalid"/>
>> >>>> + <entry name="surface_id_in_use" value="2"
>> >>>> summary="surface_id is in use and can not be shared"/>
>> >>>> + </enum>
>> >>>> +
>> >>>> + <event name="warning">
>> >>>> + <description summary="server-side warning detected">
>> >>>> + The ivi compositor encountered warning while
>> >>>> processing a request by this
>> >>>> + application. The warning is defined by argument
>> >>>> warning_code and optional
>> >>>> + warning_text. If the warning is detected, client
>> >>>> shall destroy the ivi_surface
>> >>>> + object.
>> >>>
>> >>> You still need to specify how the server handles this ivi_surface
>> >>> object after sending the warning, but before it is destroyed. Does
>> >>> the
>> >>> server ignore all requests referring to this ivi_surface, or the ID?
>> >>> Is
>> >>> the ID immediately free again, or does the ivi_surface need to be
>> >>> destroyed before the ID becomes available again?
>> >>
>> >> Yes, the server ignore all requests.
>> >> In case of "surface_id_in_use", ivi_surface, e.g. "A" doesn't have to
>> >> be destroyed to use surface_id. the surface_id is tied only to the
>> >> other ivi_surface, e.g. "B" already. If the other ivi_surface "B" is
>> >> destroyed, client can use surface_id without destruction of
>> >> ivi_surface "A" because "A" doesn't have any link to the surface_ID.
>> >>
>> >> I will add more description of correct behavior here.
>> >>
>> >>>
>> >>>> + </description>
>> >>>> + <arg name="warning_code" type="int"/>
>> >>>> + <arg name="warning_text" type="string"
>> >>>> allow-null="true"/>
>> >>>> + </event>
>> >>>> +
>> >>>> + </interface>
>> >>>> +
>> >>>> + <interface name="ivi_application" version="1">
>> >>>> + <description summary="interface for ivi applications to use
>> >>>> ivi compositor features"/>
>> >>>> +
>> >>>> + <request name="surface_create">
>> >>>> + <description summary="create ivi_surface with numeric
>> >>>> ID in ivi compositor">
>> >>>> + surface_create will create a interface:ivi_surface
>> >>>> with numeric ID; surface_id in
>> >>>> + ivi compositor. These surface_ids are defined as
>> >>>> unique in the system to identify
>> >>>> + it inside of ivi compositor. The ivi compositor
>> >>>> implements business logic how to
>> >>>> + set properties of the surface with surface_id
>> >>>> according to status of the system.
>> >>>> + E.g. a unique ID for Car Navigation application is
>> >>>> used for implementing special
>> >>>> + logic of the application about where it shall be
>> >>>> located. Created ivi_surface
>> >>>> + notifies warnings when following situation happens,
>> >>>> + - Invalid wl_surface is set. This happen if
>> >>>> wl_surface is destroy before this.
>> >>>> + - surface_id is already assigned by another
>> >>>> application.
>> >>>> + </description>
>> >>>> + <arg name="id_surface" type="uint"/>
>> >>>> + <arg name="surface" type="object"
>> >>>> interface="wl_surface"/>
>> >>>> + <arg name="id" type="new_id" interface="ivi_surface"/>
>> >>>
>> >>> Does this give the surface a role? E.g. what should happen if a
>> >>> client
>> >>> registers the same wl_surface as both an ivi_surface and a pointer
>> >>> image (wl_pointer.set_cursor).
>> >>>
>> >>> If your weston implementation sets weston_surface::configure, it is a
>> >>> strong indication that this gives a role, which excludes all other
>> >>> roles. IOW, this request should fail, if weston_surface::configure is
>> >>> already set, so you need a warning code for it.
>> >>>
>> >>> You should probably look at all interfaces, where a wl_surface can be
>> >>> an argument for a request, and check if those interfaces can exist in
>> >>> an IVI environment, and if they can, how they interoperate with a
>> >>> wl_surface that has a ivi_surface.
>> >>
>> >> Good comments. I will check them and come back immediately.
>> >> Hi pq,
>> >
>> > I am investigating the above point in wayland.xml.
>> >
>> > -wl_data_device::start_drag
>> > This may be applied for ivi system as well. I think this is also
>> > used with wl_pointer.set_cursor.
>> > Please give me your suggestion how to use the above two interfaces for
>> > one wl_surface.
>> > I think it is avoided by calling them sequentially from client. E.g.
>> > after one configure of set_sursor is done and then another configure
>> > of start_drag shall be called.
>> > I think similarly configure of ivi_application is one called, it can
>> > be set to another callback from by another request. Shall I write them
>> > in protocol as manner?
>>
>> Hi pq,
>>
>> I mis-understand this case. My clarification is that if client want to
>> use a wl_surface for wl_subsurface and wl_data_device::start_drag??
>
> It cannot.
>
> Sub-surface, drag icon, pointer cursor, and a shell surface are all
> surface roles and so they are exclusive; A surface can only be at
> most one of those at a time, and quite often also for the whole
> wl_surface lifetime as it does not make much sense to change the role
> of
> a surface after the initial assignment.
>
> A role gives wl_surface a meaning. Without a role, the compositor will
> have no idea how to present the wl_surface, and hence wl_surfaces
> without a role will never be visible.
>
>
> Thanks,
> pq
Hi pq,
I see. In case of ivi, ivi_application shall be exclusive from others.
In wayland client manner, client manages which role wl_surface shall do,
I understand.
Sub-surface: it can have a wl_surface of ivi_surface as a parent. So
client can use it exclusively.
Pointer cursor: it is for cursor. It can use it exclusively.
wl_shell: this is desktop style. It can use it exclusively.
drag icon: wl_surface is registered for icon surface around cursor
during drag. It can be used exclusively.
So I think above request can be used for ivi-application request.
However, I have to take care wl_surface which is set to set_cursor and
icon of start_drag shall be visible in ivi-shell. However for the time
being, it is not critical for ivi use case.
Thank you very much. This comment was good to start investigation.
BR,
Nobuhiko
>
>> >
>> > -wl_shell::get_shell_surface
>> > -wl_shell_surface::set_transient
>> > -wl_shell_surface::set_popup
>> > wl_shell is for desktop style shell so above three request is not
>> > used with ivi_application.xml.
>> >
>> > -wl_pointer::set_cursor
>> > This may be applied for ivi system as well.
>> >
>> > -wl_subcompositor::get_subsurface
>> > -wl_subsurface::place_above
>> > -wl_subsurface::place_below
>> > wl_surface shall be set to child surface of a wl_surface which is
>> > set to ivi_surface. If client set a wl_surface which is already set to
>> > wl_subsurface, it should fail. I will take core of it.
>> >
>> > BTW, thank you for many comment, this is very useful for me.
>> >
>> > Thanks,
>> > Nobuhiko
>> >
>> >> Thanks,
>> >> Nobuhiko
>> >>>
>> >>>> + </request>
>> >>>> +
>> >>>> + </interface>
>> >>>> +
>> >>>> +</protocol>
>> >>>
>> >>> This is a very simple interface, but there are many details to
>> >>> get right anyway. You are doing good progress. :-)
>> >>>
>> >>>
>> >>> Thanks,
>> >>> pq
More information about the wayland-devel
mailing list