[PATCH weston 1/3] Introduce pointer lock interface

[Pekka Paalanen]

On Wed, 17 Sep 2014 22:35:40 +0200
Jonas Ådahl <jadahl at gmail.com> wrote:

> On Wed, Sep 17, 2014 at 11:16:06PM +0300, Giulio Camuffo wrote:
> > 2014-09-17 23:11 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
> > > On Wed, Sep 17, 2014 at 10:56:13PM +0300, Giulio Camuffo wrote:
> > >> I haven't looked at the implementation yet, just at the protocol, but
> > >> isn't _wl_pointer_lock.lock_pointer() returning a new wl_pointer a
> > >> problem? Objects should have a unique factory interface, or else the
> > >> version of the interface can't be determined.
> > >
> > > Is it really? In the implementation below, the wl_pointer object gets
> > > the same version as the wl_pointer object that is locked. It is also
> > > specified in the last paragraph of _wl_pointer_lock.lock_pointer.
> > 
> > Mmh, then maybe it is fine. I'm not convinced actually, but I'm too
> > tired now. :)

No, it's not fine. You cannot define exceptions to the versioning rules
in a protocol spec. We have common code in libwayland handling all
runtime versioning, and you just cannot implement any exceptions.

> > > Also, this would not be the first interface that creates objects that
> > > other interface do as well. For example wl_shm_pool.create_buffer and
> > > wl_drm.create_buffer both create wl_buffer's.
> > 
> > Yes, indeed wl_buffer and wl_callback version can't be increased, afaik.

wl_buffer and wl_callback are indeed the special cases, the version of
these interfaces can never be bumped, which means they are frozen for
all eternity. That is somewhat of a design mistake. You definitely do
not want to be repeating that mistake.

> Then, another example, (of a non-final protoc though):
> wl_input_method_context.grab_keyboard vs wl_seat.get_keyboard, both
> creating wl_keyboard objects.

I think that is a protocol design bug. wl_keyboard in core is already at
version 4, but you can only create wl_keyboard version 1 via
wl_input_method_context. You cannot bump wl_input_method_context
version without starting to get wl_keyboards of higher version. The
actual problem comes, when you bump input-method interface version
beyond what is currently the highest version of wl_seat, and then
someone adds a new thing to wl_keyboard. Input-method would start
dealing out wl_keyboard automatically with the new wl_keyboard thing
without clients or servers ever implementing the support for the new
thing.

Thanks for pointing it out, bug filed:
https://bugs.freedesktop.org/show_bug.cgi?id=84034


Thanks,
pq