[PATCH weston-ivi-shell v3 02/10] ivi application protocol:
Nobuhiko Tanibata
nobuhiko_tanibata at xddp.denso.co.jp
Sun Mar 16 21:48:45 PDT 2014
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??
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