*> [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 <[email protected]> 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. * >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
