[PATCH weston 1/3] Introduce pointer lock interface

[Jason Ekstrand]

On Thu, Sep 18, 2014 at 2:26 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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.
>

Technically, those haven't been merged yet... So, technically, we could
have it inherit the version from the wl_pointer.  That said, I think we'll
regret if we do.  Even if we did do that, it would cause problems, not
because we couldn't update wl_pointer, but because we really couldn't
update wl_pointer_lock.  All in all, it's a bad plan.


>
> > > > 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
>

Fortunately, that's stuck in weston for now.


>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140918/eafe81a1/attachment.html>