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 g
On Sun, Dec 07, 2014 at 06:31:32PM +, almin...@gmail.com 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 w
I am currently looking into porting libinput for freebsd by making mtdev
optional and abstracting epoll so it can be nicely replaced with kqueue.
Having a basic abstraction on top of the udev functionality would be useful for
me too since i could replace it with devd.
On Sun Dec 07 2014 11:12:0
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 w
Hi libinput developers,
libinput seems like a nice project and I would like to use it the only
input implementation for my compositor, swc (currently it is optional
and there is also a rudimentary EV_REL-only implementation).
Unfortunately, even though libinput provides a "path" context which
all
