We no long track the focused surface, but expect the compositor to set
focus when the focus changes. We do track the resource for the input
device that corresponds to the current surface, in case that goes away.
The visual interface was meant to be a generic mechanism for
specifying the content of a buffer. It goes back to before we had the
buffer factory interfaces (like wl_drm and wl_shm) and we wanted to
keep it open-ended enough that yuv, png or even svg buffer or so would
be possible.
Now that we have the buffer abstraction, we can add different buffer
types by introducing new interfaces that create buffers. It only
makes sense to leave it to those interfaces to specify the contents of
the buffers.
For wl_shm, this means that we now just specify the pixel format using
an enum. For EGL buffers, the exact pixel formats are controlled by
the implementation (part of wl_drm and similar), and from the client
point of view, everything is controlled using EGLConfigs.
So obvious in retrospect. The object system can do all the work for us
and keep track of pending calls as regular objects and we don't need to
abuse the resource system to get them cleaned up on client exit. We
don't need the custom key management or (broken) lookup, we just sue
object IDs. And last but not least, anybody can receive the callback,
not just display listeners.
