On 10 Aug 2021, at 11:26, ropers <rop...@gmail.com> wrote: > Would this also preserve the LED status (Num, Scroll Lock, etc.)?
Nope, only encoding, custom keymap (if any), bell and repeat. LEDs have escaped my attention because they are handled by lower level drivers (pckbd, ukbd, etc), not wskbd. Preserving LEDs would also require preserving caps/num/scroll lock statuses. I am reluctant to add this extra complexity with no clear use cases. > On 09/08/2021, Sergii Rudchenko <rudchen...@gmail.com> wrote: > > I was in doubt about locking, but tracing the path of ioctl handling > > I have not found anything preventing two CPU cores from executing > > wskbd ioctls in parallel on amd64 (and it is a NOLOCK syscall). In > > fact, now I wonder why wskbd_softc is not protected. I have found that wskbd_softc does not need a lock because if there is an open file descriptor to wskbd other calls to open(2) fail with EBUSY. The lock is still needed for the new wskbd_config because it can accessed by iocts on different wskbd units. On 10 Aug 2021, at 11:26, ropers <rop...@gmail.com> wrote: > (I'm nobody important and probably can't help, but I'm curious.) That makes two of us). Thank you for replying! Best regards, Sergii Rudchenko
