[PATCH] [weston, v4] weston.ini: Add natural scroll support to weston.ini This adds support for enabling/disabling natural scrolling via a boolean in weston.ini:

[Pekka Paalanen]

On Tue, 7 Feb 2017 11:00:03 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Mon, Feb 06, 2017 at 12:00:08PM +0200, Pekka Paalanen wrote:
> > On Mon, 6 Feb 2017 10:36:56 +1000
> > Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >   
> > > On Sun, Feb 05, 2017 at 07:30:18PM -0500, Jiayi Zhao wrote:  
> > > > ​​
> > > > Hmmm, after using udev_device_has_tag(udev_device, "ID_INPUT_TOUCHPAD"),
> > > > I'm getting linking errors. Quick google of this leads to: libraries on the
> > > > command line should be after the object files being compiled.
> > > > Is this a bug?    
> > > 
> > > come to think of it, tags are a bit different. you need
> > > udev_device_get_property_value() instead. and you need to make sure that
> > > libudev is linked in - that's where your linking errors come from.  
> > 
> > Hi,
> > 
> > needing udev API raises further considerations.
> > 
> > A fundamental question is whether udev-using backends should actually
> > expose udev as part of their API to libweston users (main.c) or whether
> > it should expose its own abstraction. Since we (I, at least) do not
> > really have a good understanding what all things one might want, it
> > might be easier and more flexible to assume that udev will be part of
> > libweston's DRM backend specific API.
> > 
> > IOW, in compositor-drm.h, the configure_device vfunc should probably
> > get a new argument referring to the udev thing. This breaks the library
> > ABI, forcing a libweston major version bump.
> > 
> > Therefore when the DRM-backend is enabled, weston (main.c) should link
> > to libudev for using it, and the backend-specific API needs to grow
> > things to support the use of udev. This calls for configure.ac changes.
> > 
> > So far Weston has not been using libudev, which is why you got the
> > linker errors: it is not linked into Weston, it is only linked to the
> > specific backends.
> > 
> > Also, it has been possible to build Weston and libweston without
> > libudev by disabling the backends that depended on it. I'm not sure
> > supporting that is worthwhile, though, considering DRM is really the
> > main backend which already depends on libudev.  
> 
> afaict libinput isn't optional and libinput requires libudev. So now we're
> only talking about whether you explicitly link to it or not, it's already a
> requirement anyway.

Hi Peter,

cool, didn't know that.

> two points regarding the API discussion, and both sum up as "not needed for
> this particular feature".
> 
> if udev were unavailable, it'd be easier to have a policy of "if the device
> has tapping, treat it as touchpad for the natural scroll setting". that's
> good enough and skirts any usage of libudev in main.c.

I wonder if that belongs in libweston or the user... I suppose in
libweston it'd be more useful.

> but we already have a libinput device here and libinput links to libudev. We
> easily get the udev device from the libinput device, the only change here  
> is linking libudev explicitly. no API changes to libweston needed at all.

Didn't know that was possible either, even easier.

> changing the API for a little feature like this seems excessive unless you
> have explicit use-cases where exposing udev through the API is required. 

You just said udev is already exposed, so nothing more is needed.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170207/2dc01937/attachment.sig>