Outdated documentation of "-i / --input" in Readme file

[Stefichen5]

The readme file (https://github.com/ardera/flutter-pi/blob/master/README.md) still mentions the "-i/--input" parameter. This has been removed a while ago. This can be very misleading (I fell for it and was wondering why it did not work).

Are there any plans to bring back the parameter (and maybe even the ability to build without udev)? If not, please remove it from Readme.

Thanks a lot for the great work at this really great project!

[ardera]

Oh, yeah thanks for reporting that. I'll fix it

Are there any plans to bring back the parameter (and maybe even the ability to build without udev)? If not, please remove it from Readme.

I'm afraid it's not possible to remove the udev dependency, flutter-pi uses libinput now for touch support, and libinput has a required dependency on libudev. It might be possible to bring back support for -i since libinput does have a manual path backend too: https://wayland.freedesktop.org/libinput/doc/latest/api/#concepts_initialization
but I'm not sure it'd be useful. In the past the -i parameter was only there because flutter-pi manually used the linux evdev devices directly

Thanks a lot for the great work at this really great project!

Thanks, appreciate it!

[Stefichen5]

Thank you for the clarification. I was asking because I am developing for a more "minimalistic" linux system which originally does not have udev, libinput or systemd and it would be nice to get flutter-pi running in that configuration too. In my case I got it running by compiling the libraries manually and adding them to the device. But I am wondering if an alternative input system would be (easily) doable (with a switch between it and the libinput based one during compile time).

Thanks again. I was really surprised how easy it was to get started with flutter-pi.

[ardera]

An alternative input system would definitely be doable, though libinput doesn't do anything other than handling user input, so I think adding a raw evdev backend would just be reimplementing libinput inside flutter-pi, not sure that's worth it

The libsystemd dependency does not mean it requires systemd, if that's what you were thinking of :) libsystemd is actually just an utility library used by many systemd tools, I just used it because it has IMO the best linux-native event loop implementation. If you use eudev you should be able to get flutter-pi running without udev and systemd. Though I've never tried that

[Stefichen5]

I made myself a quick and dirty implementation of a tslib based input system (and was able to get rid of libinput and udev) which was surprisingly easy. Would that be something that you would be interested in looking at (maybe a Pull Request)? Or would you prefer something else (libevdev...)? If there are multiple input methods, both would need maintainance. (no promises, I have a baby coming in the next few days so I can't say how fast I can have it in a more presentable state than just the current "working" one).

About libsystemd: Yes, I have seen it only needs the library, which makes integration into my system easier.

I have not read into the source code too much but I really like certain aspects of it (e.g. how easy it was to get rid of libinput/udev and change it to tslib)

Also: Maybe I should open a new issue if we talk about these topics more, we have gone off-topic from my original issue quite a bit ;-)

[ardera]

@Stefichen5 sorry, completely forgot about this. Yes you can definitely create a PR for tslib-based input. Other than not needing libinput/libudev, does it have any other advantages/disadvantages? I have never tested tslib so I don't really know how good it is compared to libinput.