-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #1585 #1663
base: main
Are you sure you want to change the base?
Fix #1585 #1663
Conversation
Unplugging and then plugging in a USB device causes the operating system to reset the keymap. To avoid Plover sending key presses for keys it had previously configured but which are not mapped after the reset it is necessary to reset the keyboard emulator when resetting the machine after reconnecting so that Plover assumes the default keymap and any unmapped symbols will be added again
This will not fix all the cases where the internal and external keymap are different (e.g. the user manually reset the keymap), but I suppose it's an improvement. There's also the case where the keymap of different keyboards are different (I haven't thought carefully about this possibility yet) Also need to take a look at what happens if the engine is refreshed "automatically" when the keyboard is plugged in. |
You're right, this is only aimed to deal with this issue in the context of dis- and reconnecting the machine, because that definitely leads to a change in the keymap and can easily be addressed. For the other cases it would be necessary to listen for keymap changes and then react accordingly, but that is of course more complicated and OS specific. It's definitely something that should be addressed at some point, but I think that for now this change at least improves the situation, fixing the problem in a situation that people commonly encounter. The case of different keymaps for different keyboards/machines is interesting and worth a look, although I can imagine that it would only matter when using plover with the machine set to use a keyboard as input because for all other protocols I think it can only be connected to one machine. I'm not sure I understand what you mean with the engine being refreshed "automatically" when the keyboard is plugged in, can you clarify that? |
I was thinking about something like openstenoproject/plover_plugins_registry#46 , but looks like at the moment it doesn't matter for the keyboard machine. (Later on, there may be feature to filter to only keyboards with specific names, so when that keyboard is disconnected and reconnected this would apply?) |
That plug-in is just calling the same function that is used when reconnecting manually once the serial port that was previously used becomes available, so this fix would also apply then. If the filtering for a specific keyboard is done by selecting a port according to the device id that would still entail reconnecting in the same way by calling the reset machine function as soon as the port with the associated device id becomes available. Although, I have to admit that I'm not sure if filtering serial ports by device id is something that exists for Windows or OSX, but then it's also a hypothetical future feature and at the moment the keyboard machine is different from the other machines configurable in plover |
Summary of changes
Disconnecting and reconnecting the machine causes certain characters to not be output in the translation anymore. Specifically, this affects all characters that are not in the default keymap and that have been used output by Plover, meaning that Plover has added them to the keymap, before the machine was disconnected.
Unplugging and then plugging in a USB device causes the operating system to reset the keymap. To avoid Plover sending keypresses for keys it had previously configured but which are not mapped after the reset (leading to empty outputs) it is necessary to reset the keyboard emulator when resetting the machine after reconnecting so that Plover assumes the default keymap and any unmapped symbols will be added again.
Closes #1585
Pull Request Checklist