Well yes in the end it all goes down to evdev so an abstration on top of that would be needed.
Abstracting udev/devd is probably the easier thing to do. Replacing evdev would be harder, at least for me. I'll see how far I can get. Getting rid of mtdev for now just means one less headache, but I guess if a good enough evdev abstraction can be made it could be put back. I'll keep things in my repo for now to experiment on. If anyone else is interested they can have a look at https://github.com/almindor/libinput branch portable. Thanks, Ales 2014-12-07 16:09 GMT-07:00 Peter Hutterer <[email protected]>: > On Sun, Dec 07, 2014 at 06:31:32PM +0000, [email protected] wrote: > > I am currently looking into porting libinput for freebsd by making mtdev > > optional and abstracting epoll so it can be nicely replaced with kqueue. > > one question regarding mtdev: it has no dependencies outside of > linux/input.h which you need for evdev anyway in libinput. so wouldn't it > be > easier to ship mtdev rather than patching around it? > > > Having a basic abstraction on top of the udev functionality would be > > useful for me too since i could replace it with devd. > > compiling out libudev in its current form is a no-go, it needs more work > than that. udev is now a lot deeper integrated than just in the public API. > look at evdev.c to see how we're using the udev_device there. specifically, > we use it to avoid race conditions when devices disappear and re-appear > with > the same device node. > > that said, while it's fairly deeply integrated we only use a handful of > calls. so you could figure out either how to do a fake libudev that wraps > those few calls on BSD or a simple and clean abstraction within libinput > that you can wrap it some other way. I'm obviously in favour of the > former :) > > Cheers, > Peter > > > > On Sun Dec 07 2014 11:12:02 GMT-0700 (MST), Thiago Macieira wrote: > > > On Saturday 06 December 2014 23:33:13 Michael Forney wrote: > > > > Currently, libinput is the only system component I would like to use > > > > that has a hard libudev dependency, so unless libinput would consider > > > > making this optional, I'll have to figure out something else. > > > > > > Do you mind my asking why you want this? Is it because you have a > different > > > component that does the same job as udev? Or you're trying to make a > very > > > constrained device (RAM and Flash) and you need to make room? > > > > > > -- > > > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > > > Software Architect - Intel Open Source Technology Center > > > PGP/GPG: 0x6EF45358; fingerprint: > > > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > > > > > _______________________________________________ > > > wayland-devel mailing list > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > > > -- > > Sent from my Jolla > > _______________________________________________ > > wayland-devel mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > -- Feel the power of Opensource. Feel the power of Free Pascal.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
