On 01/26/2011 03:57 PM, Kristian Høgsberg wrote:
On Wed, Jan 26, 2011 at 8:22 AM, Tiago Vignatti
<[email protected]> 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.
/BR
/Marcus
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
