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
[VT console provider] Input device not recognised after disconnect/reconnect cycle #3149
Comments
Aha! This is because in For |
Not all `ConsoleProvider`s will send a `removed` event on the `DeviceObserver` (in fact, only logind will), so we can't rely on that to clean up the handle in `device_watchers`. Furthermore, libinput itself will notice a device going away (by monitoring the fd) and generate `LIBINPUT_EVENT_DEVICE_REMOVED`, which we might process *before* the udev `REMOVED` event, and in *that* case, `device_removed` will have already deleted the `LibInputDevice` and so the udev event handler will *also* not clean up `device_watchers`. Resolve this by cleaning up `device_watchers` *only* in `device_removed`, and rely on the `DeviceObserver::removed` codepath triggering a libinput removal event. Fixes: #3149
Not all `ConsoleProvider`s will send a `removed` event on the `DeviceObserver` (in fact, only logind will), so we can't rely on that to clean up the handle in `device_watchers`. Furthermore, libinput itself will notice a device going away (by monitoring the fd) and generate `LIBINPUT_EVENT_DEVICE_REMOVED`, which we might process *before* the udev `REMOVED` event, and in *that* case, `device_removed` will have already deleted the `LibInputDevice` and so the udev event handler will *also* not clean up `device_watchers`. Resolve this by cleaning up `device_watchers` *only* in `device_removed`, and rely on the `DeviceObserver::removed` codepath triggering a libinput removal event. Fixes: #3149
Thanks for tracking this down. I can now reproduce |
Not all `ConsoleProvider`s will send a `removed` event on the `DeviceObserver` (in fact, only logind will), so we can't rely on that to clean up the handle in `device_watchers`. Furthermore, libinput itself will notice a device going away (by monitoring the fd) and generate `LIBINPUT_EVENT_DEVICE_REMOVED`, which we might process *before* the udev `REMOVED` event, and in *that* case, `device_removed` will have already deleted the `LibInputDevice` and so the udev event handler will *also* not clean up `device_watchers`. Resolve this by cleaning up `device_watchers` *only* in `device_removed`, and rely on the `DeviceObserver::removed` codepath triggering a libinput removal event. Fixes: #3149
Not all `ConsoleProvider`s will send a `removed` event on the `DeviceObserver` (in fact, only logind will), so we can't rely on that to clean up the handle in `device_watchers`. Furthermore, libinput itself will notice a device going away (by monitoring the fd) and generate `LIBINPUT_EVENT_DEVICE_REMOVED`, which we might process *before* the udev `REMOVED` event, and in *that* case, `device_removed` will have already deleted the `LibInputDevice` and so the udev event handler will *also* not clean up `device_watchers`. Resolve this by cleaning up `device_watchers` *only* in `device_removed`, and rely on the `DeviceObserver::removed` codepath triggering a libinput removal event. Fixes: #3149 (cherry picked from commit 5205713)
When using
--console=vt
, my USB keyboard works both if it is plugged in before Mir is started or if it is plugged in after Mir has started.However, when it is unplugged, Mir (correctly) notices it has disappeared, but never notices when it is plugged back in.
This is specific to the
LinuxVirtualTerminal
console provider; when using logind I can plug and unplug the device multiple times and it works as expected.The text was updated successfully, but these errors were encountered: