From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 007431580B9 for ; Mon, 23 Aug 2021 20:11:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A5B0E0B7D; Mon, 23 Aug 2021 20:11:35 +0000 (UTC) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3B3D6E0B1C for ; Mon, 23 Aug 2021 20:11:35 +0000 (UTC) Received: by mail-pj1-x102c.google.com with SMTP id mq3so12690036pjb.5 for ; Mon, 23 Aug 2021 13:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=+ZEBg6rh237+eYFVouI34gjCqozBVlsw/qjI/F0n27k=; b=IKMzi0D6Pzca34dF1UXX9trJ+rTCBf66NmWw57oLhv9SxuKPSSyMsP1A0FI/TOAuQ+ a+xyP8i2QmqnWHIqu3zk/IOrXeJgLVz7XgF2242/TMUVYb1MjPYCBDjMNuMrarYeulzx eHUFhIOeLhSncplbPUQSgyLbns/aVNA6djd/R1YKM4tvVLtYtpdfKWczTe3bP5zqil9g rg5DmlBRU+atKJAba78SkoKPi2xcjgOfT9w8GAONPwqmzV+lCEhb42/YNUpAC3l2vj4x hQdqYYRdR7cUwL7zA3lWn5/L3LGQm3GeE1hZNs1c4E0gjQkFCuzAKNlpjYQosUfROu+Z JnzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=+ZEBg6rh237+eYFVouI34gjCqozBVlsw/qjI/F0n27k=; b=OtilvXQjO7z/dJhpJKzbmbJTxeQ3IswGtI0U/HJO7NN9qjpErhPstIDxQ27/d296OK SfXhtzYWVkd9SqcSmstfhh6an5LxaySZL99xmFb5AS2v6CaxCa8V4XS8sZmt0ADjhvNT nqjR5a6FQVHEW2c8CgsM5A5r2Jpgy6EhvPXZgCcz6mdCl2HC4f/mqY41bHmsWrrDKUFf JA1JrVVQ7mHIQ2pfNdb/kgTj4voEP408uWfWW7ttToxBIkABNQBXq2+ImSp3hcWsjtD8 NFhmKjQs1UbycDCozA3VIXCPJEVEEqYeatuPNufZEHqHC0votQbo4RWfoRrZOZuq8rcg MncA== X-Gm-Message-State: AOAM531VFpNNsdJoIz0RZAZvqpaTbrPiClzbieQe3KcuizD0GoDCkxr+ 9TiRwLlY3VC2ZYOUDUaa7JFy7RtS8R0= X-Google-Smtp-Source: ABdhPJwzxhPOOQsUCQyZMMsWzetTr6F9f/79Z3q1P9M8fKEQRbYxIe1BFzXRuGYk7IfILOlqJklIIA== X-Received: by 2002:a17:902:db0b:b0:12d:bd2c:6e6e with SMTP id m11-20020a170902db0b00b0012dbd2c6e6emr29402310plx.26.1629749494083; Mon, 23 Aug 2021 13:11:34 -0700 (PDT) Received: from [192.168.247.5] ([108.180.126.133]) by smtp.gmail.com with ESMTPSA id x189sm18933907pfx.99.2021.08.23.13.11.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Aug 2021 13:11:33 -0700 (PDT) From: Daniel Frey To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] udev and IR receiver problem Message-ID: <09fe93a1-3b27-30fe-ebd8-d18df8e04687@gmail.com> Date: Mon, 23 Aug 2021 13:11:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 5e923cc4-fffc-4c91-bff0-9b1f0e0c1945 X-Archives-Hash: cb42925d6c743aa661a3fc7fa8656b44 Hi all, I've been struggling with an odd udev problem. Any udev experts on here? Some background: My 13-year-old HTPC finally kicked the bucket. After looking around, stock levels of PC parts around here are close to nonexistant. I had a newer donor board/ram/cpu around that's 5-7 years old. I have set up gentoo from scratch on this device (not using any old stage4-esque backups.) This HTPC case has an iMon device: Bus 001 Device 003: ID 15c2:0038 SoundGraph Inc. GD01 MX LCD Display/IR Receiver It has worked well over the last 13 years but it has had problems with its driver early on. I tried to recover the SSD that was from the dead PC and it worked exactly twice (the third time I tried to get some configs from it the SSD failed completely.) It has a bit of a strange setup compared to other IR devices: it creates two separate input devices. During boot, udev used to automatically create a third device (an infrared device) that chains the two separate devices together so the kernel IR can receive all remote events. The problem I'm having is this: When booting, udev triggers the events from the kernel and sets up the two devices: # ls -l /dev/input/by-id total 0 lrwxrwxrwx 1 root root 10 Aug 23 12:44 usb-15c2_0038-event-mouse -> ../event10 lrwxrwxrwx 1 root root 9 Aug 23 12:44 usb-15c2_0038-mouse -> ../mouse1 The kernel IR sees this as well: # ir-keytable Found /sys/class/rc/rc0/ with: Name: iMON Remote (15c2:0038) Driver: imon Default keymap: rc-imon-pad Input device: /dev/input/event10 LIRC device: /dev/lirc0 Supported kernel protocols: rc-6 imon Enabled kernel protocols: imon bus: 3, vendor/product: 15c2:0038, version: 0x0001 Repeat delay = 500 ms, repeat period = 125 ms The problem is, this is missing the device that chains them together. It's usually postpended with 'if00' or something similar to indicate it's the infrared device. On boot, it does not create a device for it under /dev/input/by-id like it used to, so making lircd chain to it becomes difficult, especially if you plug in another USB input device. The kernel does indeed report the device to udev: # dmesg | grep "iMON Remote" [ 1.423629] rc rc0: iMON Remote (15c2:0038) as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0 [ 1.423734] input: iMON Remote (15c2:0038) as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/rc/rc0/input10 This IR receiver also supports multiple protocols and keymaps. As I use Microsoft's remote keymaps, I do change this as a part of the /etc/init.d/lircd startup (I load the keymap and change the receiver's protocol before starting lircd.) Note that during testing I've removed this for testing thinking that perhaps it was changing something in the kernel - no dice, no new events or anything of the sort. It has nothing to do with this problem. Now here's the really strange part: If I drop to bash and issue `udevadm trigger` it is created and appears correctly! This only happens modifying the keymap/protocol (changing it to RC-6 compatibility): # ls -l /dev/input/by-id/ total 0 lrwxrwxrwx 1 root root 10 Aug 23 13:03 usb-15c2_0038-event-if00 -> ../event10 lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-event-mouse -> ../event9 lrwxrwxrwx 1 root root 9 Aug 23 13:03 usb-15c2_0038-mouse -> ../mouse0 As you can see, the infrared device is created. This device should be created at boot time, regardless or not if it has had the protocol changed and/or custom keymap applied. I tried something quick in /etc/udev/rules.d/70-remote-control.rules: KERNEL=="event*",ATTRS{name}="iMON Remote (15c2:0038)",SYMLINK="input/remote" But it does not work, even after reloading the rules and forcing the trigger event. I've kind of worked around this for now by adding a manual `udevadm trigger` command in /etc/init.d/lircd after modifying the protocol and keymap. However, there must be a way to make this work as intended with an udev rule. The issue being that this device doesn't have anything unique identifying it other than its name. Anyone have any insight on how to solve this problem? Dan