*> [T.J. ] That is like saying that everyone uses the same mouse. They
might work the same to the average person, but a developer knows the
difference. Wayland at present only works on*
*> Linux and it is not being designed with portability in mind. The
actual Wayland devs are working only with Linux and that is really all they
are concerned with. Granted, there are efforts *
*> to patch Wayland for other systems, but they not really high priority. *

Technically, Wayland is the protocol definition, not the implementation
(i.e. think X11 vs X.org). Weston is the reference implementation.

While it is true that most of the Wayland/Weston developers are also X.org
developers (and most come from Linux), they are making all the right moves
to avoid lock-in to Linux or a particular Wayland implementation. For
example, while there are multiple Wayland implementations (i.e. a Wayland
window manager or widget toolkit is effectively a Wayland protocol
implementation), inconsistencies between an implementation and the
specification are treated as bugs in the implementation. As another
example, Wayland avoids relying on FreeDesktop technologies like dbus and
systemd.

You may be interested to know that the Wayland protocol is not tied to a
particular rendering technology or paradigm. To use the OSI analogy,
Wayland lives in the presentation layer--it's concerned with helping
applications identify and interact with the host's output devices, input
devices, and pixel memory buffers (on both an individual level and by
groupings). The protocol itself is not concerned with users, sessions, or
GPU infrastructure, nor is it concerned with widget sets, windowing,
decorations, etc.

-Jude



On Mon, Mar 23, 2015 at 3:16 PM, T.J. Duchene <t.j.duchene@???> wrote:

>
>
>
>
>
>
>
> *[T.J. ] Hi Jude! *
>
> Wayland is basically just that--a complete rewrite of X, built around
> design requirements that were not present when X11 was designed. Think of
> Wayland as X12, and think of Xwayland as the X11 compatibility layer.
>
> *[T.J. ] Yes, I know. =)*
>
>
>
> Also, userspace mode setting these days is a racy prospect at best that is
> incredibly difficult to coordinate without the kernel's help. This is
> because the sequencing of low-level hardware events from contemporary video
> devices (i.e. DMA, power changes, suspend/resume, external displays) can
> interfere with the sequence of user mode setting ioctl()'s to the point
> where the state of the video hardware can easily get out-of-sync with
> userspace's understanding of it, causing userspace to issue ioctls that
> leaving you with a locked-up display. The kernel *should* be handling
> mode-setting requests these days, because only the kernel is in a position
> to correctly sequence mode-setting requests with ongoing low-level hardware
> events (such as by blocking or deferring the relevant hardware interrupts).
>
>
>
> This isn't a Linux-only thing, by the way. All the BSDs have or (in
> NetBSD's case) will soon have KMS enabled by default. Windows NT has had
> it for decades.
>
>
>
> *[T.J. ] That is like saying that everyone uses the same mouse. They
> might work the same to the average person, but a developer knows the
> difference. Wayland at present only works on Linux and it is not being
> designed with portability in mind. The actual Wayland devs are working
> only with Linux and that is really all they are concerned with. Granted,
> there are efforts to patch Wayland for other systems, but they not really
> high priority. *
>