wayland implementation conformance

[Kristian Høgsberg]

On Wed, Jan 26, 2011 at 12:15 PM, Marcus Lorentzon
<marcus.xm.lorentzon at stericsson.com> wrote:
> On 01/26/2011 03:57 PM, Kristian Høgsberg wrote:
>>
>> On Wed, Jan 26, 2011 at 8:22 AM, Tiago Vignatti
>> <tiago.vignatti at nokia.com>  wrote:
>>
>>>
>>> Hi,
>>>
>>> I hijacked this comment which Kristian made in the other email thread; my
>>> comments are inline.
>>>
>>> On 01/24/2011 09:30 PM, ext Kristian Høgsberg wrote:
>>>
>>>>
>>>> Once of the things that X got right was the extension model.  Wayland
>>>> takes it one step further by making everything an extension: the only
>>>> thing that's fixed in the Wayland protocol is an interface for
>>>> discovering other interfaces.  If it turns out that we need to update
>>>> the input model, we have versioning built in for incremental updates,
>>>> and we can add an entire new model if we need to start from scratch.
>>>>
>>>
>>> So what defines exactly a Wayland implementation which is conformant with
>>> the protocol then?
>>>
>>> Let's say I don't care about drm_interface and my implementation works
>>> okay
>>> without it. Does my software is called Wayland then? Nevertheless, in
>>> this
>>> case, I won't be able to connect the same clients from such
>>> implementation
>>> on some other Wayland server that relies on DRM. So if we target
>>> interoperability between clients and server, then I guess we will want to
>>> define hardly a few interfaces.
>>>
>>
>> That's a good question.  My intention is to have wayland.xml be the
>> official interfaces, but you're right that the drm interface is
>> specific to the Linux drm driver model and maybe that should be split
>> out into its own file.  Additionally, it would make sense to abstract
>> out the wl_buffer creation into a library that server and client can
>> link to so that not every toolkit and application that use the wayland
>> protocol directly will have to know about every driver specific
>> interface for creating and sharing buffers.
>>
>
> What about adding "profiles" or interface groups in the protocol xml. Client
> could query compositor of a list of profiles supported. And profiles could
> be hierarchical like:
>
> base (very basic profile allowing simple surfaces and input)
> desktop/netbook : base (base + d&d, mouse pointer, multi touch etc)
> kde/gnome : desktop (desktop + shell interfaces)
> pad/phone : base (base + multi touch, overlays, orientation, ...)
> meego : phone (phone + meego shell services)
> ...
>
> A sample ubuntu profile list could be "base 2.3;desktop 1.2;pad 1.3;gnome
> 1.1;ubuntu 2.0"
>
> That would make it easier for apps to target specific platforms, create
> better fallbacks and improve device/platform portability/interop.

I think of it more as GL extensions or X extensions.  You have to find
out whats available at run time and enable, disable or limit
functionality according to the interfaces the compositor provides.  Or
worst case just refuse to run.  But I don't expect to see as much
variation as you suggest in the example above, I think most of the
functionality you mention will be in the core set of interfaces and
something like "meego shell services" will be something that MeeGo
will have to specify.

Kristian