You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just for info in case you ever return to actkbd (for which many thanks).
In the README we have:
Update: On newer kernels several special buttons (like the Power switch) may appear as input devices as well. There is no way for the auto-detection code to tell them apart and it is quite possible that the actual keyboard will not be the one actkbd will select. Using udev to start actkbd is the best way to avoid this problem.
Firstly (a) I didn't get udev to work and (b) I'm not sure how launching via udev solves the path issue.
Secondly: I've discovered that apparently in /proc/bus/input/devices the keyboard is identifiable by always having the field EV: set to 120013. I've written a simple perl script to read /proc/bus/input/devices and select the eventN from the first entry where we have EV=120013 and then launch actkbd with this set in the '-d' parameter . In my limited testing it seems to work. Something for an updated linux.c if you ever return to it?
The text was updated successfully, but these errors were encountered:
Just for info in case you ever return to actkbd (for which many thanks).
In the README we have:
Firstly (a) I didn't get udev to work and (b) I'm not sure how launching via udev solves the path issue.
Secondly: I've discovered that apparently in /proc/bus/input/devices the keyboard is identifiable by always having the field EV: set to 120013. I've written a simple perl script to read /proc/bus/input/devices and select the eventN from the first entry where we have EV=120013 and then launch actkbd with this set in the '-d' parameter . In my limited testing it seems to work. Something for an updated linux.c if you ever return to it?
The text was updated successfully, but these errors were encountered: