On Tue, 7 Feb 2017 11:00:03 +1000 Peter Hutterer <[email protected]> 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 <[email protected]> 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
pgpizxZLVAfpB.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
