donniebreve

@1999shaswat just put two lines in the config with the keyboard name. If the program can't find the first, it will try the second.

#46 brought this up again. I think we should implement something like a systemd or udev trigger to create a separate instance for each keyboard. Do we need a *ctl...

I'm interested in transitioning this project into something that supports different layers, similar to most custom keyboard firmwares these days. Currently this project does not support multiple layers.

I'm on board. I think this has to be a configuration file option if we want users to be able to take advantage of it. Trying to explain to people...

Env variable or systemctl command line argument (not sure if that's possible) are fine as well.

Actually this is being handled by #52

#52 also includes a PathChanged watch on the configuration file. The PR aims to make systemd detect device changes and configuration file changes, which means the binary wouldn't be modified....

I switched to @yarcod's branch and couldn't install: ``` shell # Stopping the service systemctl --user stop touchcursor.path Failed to stop touchcursor.path: Unit touchcursor.path not loaded. make: [Makefile:49: install] Error...

This looks great @yarcod. I'll pull down the latest changes and try them out soon. > Edit: Also, I lack the Github know-how to be able to handle the review...

I've finally made some time to sit with this and investigate further. I've found that the current setup (touchcursor.service and touchcursor.path) will only **start** the touchcursor service, but won't **restart**...