LIRCD-UINPUT(8)

✨ LIRCD-UINPUT(8) ✨ the system-manager girlie

okay so bestie, listen 💖 this is lircd-uinput, and she lives in the System Managers Manual. She's basically the glow-up translator between your remote control and the rest of your computer, and honestly? she ate.

---

🎀 NAME 🎀

lircd-uinput — forward lirc button presses as uinput events 🦋

---

🌸 SYNOPSIS 🌸

lircd-uinput [options]... [lircd output socket]
lircd-uinput [options]... [file]

---

💅 DESCRIPTION 💅

So here's the vibe: lircd-uinput reads decoded button-press events off a lircd(8) output socket, and then injects them as key events into the kernel uinput device. The kernel is like "oh, an input device? say less" and serves those events up to other apps on a /dev/input/event device — exactly like it would for actual physical input hardware. no cap. 🔥

lircd-uinput is literally designed to run as a systemd service. main character energy, obviously. 👑

The lircd output socket argument is an optional path to the lircd output socket. If you don't give her one, she defaults to the output value in the [lircd] section of the lirc_options config file, and if that's missing too she falls back to /var/run/lirc/lircd. defaults on defaults on defaults, it's giving prepared. ✨

If you hand her a plain file instead of a socket, she expects that file to contain button-press events formatted exactly as documented in lircd(8). In that case lircd-uinput sends the codes found in the file and then exits. one and done, periodt. 💖

⚠️ For any of this to work, release events must be sent to the uinput device. Go read REPEAT HANDLING below, bestie, don't skip it. 😭

lircd-uinput can only handle button events that are named using the official namespace — i.e. buttons the kernel actually knows about. See NOTES. 🧚

Unless the /dev/uinput default permissions get changed, lirc-uinput needs to run as root. See NOTES. 💀

The /dev/input/event device that the kernel creates is genuinely tricky to locate and it is not stable. See NOTES. 🙈

---

✨ OPTIONS ✨

• -u, --uinput <device> — the uinput kernel device. Defaults to /dev/uinput. 🎀
• -r, --release-suffix <suffix> — lircd-uinput generates different events depending on whether the button name ends with the release-suffix or not. Defaults to _EVUP. See REPEAT HANDLING. 💅
• -R, --repeat <delay[,period] | ,period> — sets the kernel autorepeat parameters of the created /dev/input/event device. delay is the time before a key event repeats, period is the time between repeated key events. Both values are in milliseconds, separated by a comma. Either value can be omitted or set to 0, in which case the kernel/system defaults are used. See REPEAT HANDLING. ⏱️
• -a, --add-release-events — generate synthetic release events. This option is mandatory unless lircd is using the deprecated --release option. The timeout used can be modified with the release-timeout key in the lircd-uinput section of the lirc_options.conf file. Useless if you're using a text file as input. See REPEAT HANDLING. 🫶
• -d, --disabled <disabled buttons file path> — the path of a file containing names of buttons to be disabled, one per line. By default, lircd-uinput sends all buttons found in the input. See NOTES. 🚫
• -O, --options-file <path> — options file holding default values. Defaults to /etc/lircd/lirc_options.conf. 🌸
• -L, --logfile <logfile path> — pick the log file: either the string 'syslog' (meaning syslog(1) should be used) or an actual log file path. The default is to use syslog. 📝
• -D, --loglevel [level] — decides how much logging info you get. level can be a symbolic syslog level: 'error', 'warning', 'info', 'notice' or ´debug'. lircd-uinput also defines three extra levels — 'trace', 'trace1' and 'trace2' — which give even more messages ('trace2' bringing the most). But heads up: in the log these messages are marked as 'debug'. 🐛
• -h, --help — display the usage summary. 🎀
• -v, --version — display version info. ⭐

---

🔁 REPEAT HANDLING 🔁

Once a keypress event lands, the kernel starts emitting repeat events to applications and keeps going until lircd-uinput emits a matching release event. Those release events could be created by lircd(8) using the deprecated --release option. Events like that typically have an _EVUP suffix tacked onto the original keypress event. 💅

The preferred way is for lircd-uinput to create release events itself using the --add-release-events option. Combining both of those options might give you unexpected results, bestie. don't do it. 😭

📌 Note that the linux kernel uses the suffix _UP (which was used by lircd prior to 0.10.0) for other purposes since 4.7.

Either way, the repeat events the kernel generates can be tweaked with the --repeat option. This can set the time between the keypress event and the first repeat event, and the time between each repeat event. The --repeat option should only be used if no other program or udev rule is automatically setting up key repeat parameters. By design, the repeat parameters can't be set in an atomic way during input device registration, so this option is prone to race conditions. ⚠️

Also note that lircd-uinput's repeat-event handling differs from lircd(8), which implements (emulates) hardware autorepeat in the events it sends to uinput (event.value == 2). lircd-uinput only sends keypress and release events, trusting the kernel's autorepeat support. trust the process, fr fr. 🫶

---

📋 NOTES 📋

By default, the dev/uinput device is not writable for regular users. So lircd-uinput needs to run as root unless those permissions get changed. 👑

One way to achieve this is a udev rule. The lirc distribution ships an example rule which makes the lircd-uinput device writable for users in the group lirc. Another way is to use lircd-setup(8) to change the permissions. As distributed, the lirc_options.conf file contains a commented example using setfacl(1). ✨

lircd-uinput can only forward lircd button events with names from the legal namespace defined by the kernel. A complete list of possible button names lives in /usr/include/linux/input-event-codes.h, and you can also get it with irrecord -l. Other button names are silently dropped. 💀

The event keycode depends on the name given to a button in the lircd config file — e.g., if the button is named KEY_1, the keycode 1 will be generated. 🎯

The kernel makes the events generated by lircd-uinput available on a /dev/input device like /dev/input/event12. That device name is not stable and typically varies after a reboot. The lirc distribution contains a udev rule which, if installed, creates a device link named /dev/lircd-uinput that you can always use. 🌈

lircd-uinput is designed to replace the currently deprecated --uinput option to lircd(8). However, lircd-uinput forwards all events unless blocked by the --disabled option. On the other hand, lircd --uinput does not forward all events — the heuristics used have been changed over versions. messy history, iykyk. 🫠

---

🐛 BUGS 🐛

Since the device name is fixed, only one instance of lircd-uinput can run on a system. one girl per system, periodt. 💅

---

🌸 SEE ALSO 🌸

• lircd(8)
• irrecord(1)
• http://www.kernel.org/doc/Documentation/input/event-codes.txt

---

okay that's the whole page bestie, you're so welcome 💖 she's from lircd.uinput 0.10.2 and her last change was way back in Jun 2017 — vintage, iconic, still slaying. mwah 🎀✨🦋