vhidkb.1 (1802B)
1 .TH "VHIDKB" "1" "2022-08-29" "vhidkb" "User Commands" 2 .SH NAME 3 vhidkb \- virtual HID keyboard 4 .SH SYNOPSIS 5 \fBvhidkb\fR [\-h] [\-d \fIDEVICE\fR] [\-t \fIDELAY\fR] 6 .SH DESCRIPTION 7 \fBvhidkb\fR creates a virtual 256-key HID keyboard with N-key rollover using 8 the Linux \fI/dev/uhid\fR interface. Each key starts in the released state, and 9 each byte received over stdin toggles the key of that number. Keys are numbered 10 in accordance with the HID usage page 0x07. \fBvhidkb\fR destroys the virtual 11 keyboard and exits after reaching EOF. 12 .SH OPTIONS 13 .TP 14 \fB\-h\fR 15 Display a help message. 16 .TP 17 \fB\-d\fR \fIDEVICE\fR 18 Use \fIDEVICE\fR as the \fI/dev/uhid\fR interface instead of "/dev/uhid". 19 .TP 20 \fB\-t\fR \fIDELAY\fR 21 Wait \fIDELAY\fR milliseconds after the first process opens the HID device 22 before sending key events. If \fIDELAY\fR is negative, then key events are sent 23 even if no process has the HID device open. By default, \fBvhidkb\fR acts as if 24 "\-t 100" is passed as an option. 25 .SH NOTES 26 The \fB\-t\fR option exists as a hack to solve timing issues where an X server 27 opens the HID device, closes it, and then opens it again, all within a few tens 28 of milliseconds. (Why does Xorg do this? I don't know.) With 0ms \fIDELAY\fR, 29 the first opening causes \fBvhidkb\fR to start sending key events (assuming 30 some data is available on stdin), but these events will most likely end up 31 being discarded. 32 .P 33 By default, accessing \fI/dev/uhid\fR requires root privilages. For easy and 34 secure use, the author recommends creating a "uhid" group for the 35 \fI/dev/uhid\fR device and the \fBvhidkb\fR executable, with the latter having 36 its set-group-ID bit set. Changing the group of \fI/dev/uhid\fR can be 37 automated in init scripts. 38 .SH "SEE ALSO" 39 HID Usage Tables <https://usb.org/sites/default/files/hut1_3_0.pdf>