Comment on Wayland anti-FUD

[Peter Hutterer]

On Sat, May 12, 2012 at 01:16:38PM +0300, Pekka Paalanen wrote:

[snip]

> > Another drawback of Wayland is, that the compositor is also
> > responsible for reading and dispatching input events. If there's
> > a new class of input device _all_ compositors must be adjusted.
> > You could of course invent some kind of generic compositor into
> > which one can load modules. And you could add an abstracted color
> > management and drawing module into it, keeping track of
> > properties of the single displays in a multihead setup. But this
> > would just duplicate everything X does.
> 
> Yes, Wayland duplicates or reimplements the useful things X does.
> The point is, Wayland changes everything else. Isn't that a good
> thing?
> 
> You are right about input plugins, but there are couple things
> that should make it not so bad:
> - a majority of input devices are evdev, so we mostly need only
> an evdev plugin

there are 3 X input drivers that matter to most people these days. evdev,
synaptics and wacom. All three are evdev drivers on Linux. the reason we
still have three of them is because the handling of the devices is complex -
what you want from a touchpad is different than what you want from a
keyboard.

you could bunch all of them up into a single driver and wayland doesn't have
the client legacy that X has but what you'll end up doing is moving the
touchpad/wacom-specific sections into the clients. and then you hope that
all clients have the same setup because otherwise that software-emulated
button on your touchpad won't work in some clients but will in others.

I suspect there will be a need for multiple plugins sooner or later, even if
all of them speak evdev.

Cheers,
  Peter

> - not all compositors need to talk to input devices directly,
> others are just Wayland clients to another compositor.
> 
> After all, drivers are supposed to exist in the kernel, offering
> an abstracted common API (which btw. is practically impossible
> for 3D graphics hardware, hence we need EGL/GL and friends).
> 
> > And last but not least: Desktop composition as it is used today
> > sucks. It's a huge productivity killer. Without any effects I can
> > quickly switch between desktops in well under 20ms and see if a
> > compile run finished in my console. With desktop effects I've to
> > wait for the effect to finish. There are usefull applications for
> > composition (I'm experimenting with it myself), but so far it's
> > just distracting eyecandy.
> 
> That is an argument against effects, not compositing. And
> personally I agree. :-)
> 
> If you have compositing but no transition effects, switching a
> desktop will be *faster* than if you did not have compositing,
> because when drawing a new desktop view:
> - the clients have already earlier rendered their windows, and
> - the server does not need to communicate with any client to
> draw the desktop
> 
> Wayland is not going to force bling-bling on anyone. It forces
> only compositing, whose only downside is that it takes more
> memory than strictly on-demand damage-based client-by-client
> drawing.
> 
> I do hope that all *implementations* of a Wayland compositor
> will allow to disable their effects.
>