Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1857450imm; Tue, 22 May 2018 10:25:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpdB81KDFB4EtQ7Vx+PSdHHu23zetKemIK3Z7gEP+2K/0F0kC7ta0N3UUxPet8It6+20oGy X-Received: by 2002:a17:902:28e8:: with SMTP id f95-v6mr26315516plb.250.1527009933182; Tue, 22 May 2018 10:25:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527009933; cv=none; d=google.com; s=arc-20160816; b=0yQRNvxb1uaS0cNJMQF10se3S2gKCXPe4gP0dAi5J6VBJk6caH/kYcEgvw4SHUhFX5 OpylYL8IAISwL2vKBNwT06fOqvappQS3GOaXo4pqmaBUiLT17FC0oSaWuNQntESAX1ga kIsZawNnIMBWSqK4KhduoMwXhpQ+4Sw7JbgEEukrnA140RMadQ4t1GoHgiw1UfIP5bgY bRFcdtN/AsWlsA68dNF1Rj73rCwRIxUm4pCQrdHvze9AcGdmWcwCerueMsoaGfg8pTK8 nVyhSiZ6QxJSEQn9TnsoBmDIJz/tyrX/rLTaGHJEPNzBaLREAkEF18rVAx3NdI/HCF4Z Ycsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=xJUiKTT6q/9oKzcmLQXLhP65ffPS2imCZJFjCVXG58w=; b=lw+WZEG9O4Vs0SIXln4jxRUbH4THMt4h4isJ9q2gJA4gvQqbzwbBu1pF+/xrDcyIW7 vvWAw9VH1o+KIxGalNxgFPjeDkkTxAtvFQv1dMW/riC+EVVLO4mch1mbEcDDnBlGK50H GMYbsitli5E/Ts7VLfmFWdMNhN1XmWJcNl1OE/d/zbVBdk+aMweytvBmu5xL/9xEahRR h/L2wI26LA0TkMaIYueigPfx1tEJFjixQ29wZS9Vt4T21rvTpV3tpt0T4O+pmBSl0wtX bFRy3AaHa6k99XqswRAC2fshReN2I2FhqwhvilG7P/nGt2qsqG1hNEc8UB6mcZm6XQs4 ra5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qmEyoQuo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w5-v6si13202831pgq.550.2018.05.22.10.25.18; Tue, 22 May 2018 10:25:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qmEyoQuo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751676AbeEVRYz (ORCPT + 99 others); Tue, 22 May 2018 13:24:55 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:39554 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbeEVRYx (ORCPT ); Tue, 22 May 2018 13:24:53 -0400 Received: by mail-wm0-f68.google.com with SMTP id f8-v6so1900170wmc.4; Tue, 22 May 2018 10:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xJUiKTT6q/9oKzcmLQXLhP65ffPS2imCZJFjCVXG58w=; b=qmEyoQuo1SD96S6C2O86b5ZChkGsjySPn6nlYvcKYHtpJWkkrGUQFLKym9S1Okt8Xf RCnwjx5xR8zKzjZzwVcuqlYEJY0+4wTs/5qk0cZZ10kZxcNa+Pl02nlOrbnx5U3R1rxT BsTpVyujqBE8w+m6RRnVRq36T34+2MV7ijdJXFjbknRZUd5XX9sUhQWV/Z2UyfB+rKcG d3vl2jDqF0X1FzUO98y8BeUcvSPLD0H914nGircMjsBSRvxluTLG/eCXIUO4o7yu+K74 lBdXM/liU+z3EOGHiODQPC2py7B6tCENPqmQpj/WKe4+5Ip1nm107LKDDvv4lb9a1KUn xsxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xJUiKTT6q/9oKzcmLQXLhP65ffPS2imCZJFjCVXG58w=; b=bIRFwUBuNZYSzSRhuxydEwnDJU+JAIwuzbz4y9Zo7nEntHsFe89S1l9x+8Ha1lWa+/ 4w02uV+6MHeJCD2tCDkUUh+lorOlIkxSnT3ThM0j8hJ25qVlaHwdukZswsfav76f4PKx xAja/GvR7M8XGq25UJTcgtYXjNcym070KD8TVCNCom3w1O3gMutcZ1s6C4qydBOgUvPC OvZimarw5lc7Q87r4TPAoycaRATyfjLSX8ESVaFCbDvPZIdx5t+usi2rG+gHkEJMDr0J uVQbIfwOg+2/opfZzcBpZlmUOPVnPl4hqzl6/Q4qM3ruGIkbeivHsqqcH96/s4wmjpCa kosw== X-Gm-Message-State: ALKqPwfwy5P7KxuyLoR9+D0/XFnHYZT7lpLa68jbgBENgB4SJRQHtVcO FoiKz1KfvBlCrKmO+WNpN4URJIN1bLxCGV9Iz1w= X-Received: by 2002:a2e:3613:: with SMTP id d19-v6mr14917339lja.100.1527009892130; Tue, 22 May 2018 10:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6818:0:0:0:0:0 with HTTP; Tue, 22 May 2018 10:24:51 -0700 (PDT) In-Reply-To: <20180522135020.y3xxmtvhdui2so3t@camel2.lan> References: <20180522135020.y3xxmtvhdui2so3t@camel2.lan> From: VDR User Date: Tue, 22 May 2018 10:24:51 -0700 Message-ID: Subject: Re: [PATCH v4 0/3] IR decoding using BPF To: Matthias Reichl , Sean Young , "mailing list: linux-media" , Linux Kernel Mailing List , Alexei Starovoitov , Mauro Carvalho Chehab , Daniel Borkmann , netdev@vger.kernel.org, Devin Heitmueller , Y Song , Quentin Monnet Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean, I'd like to echo Matthias's appreciation for your work with this BPF project. I'm very much looking forward to the possibility of using my remotes directly with decoders generated from the existing lircd.conf's. Excited seeing your work progress! Cheers, Derek On Tue, May 22, 2018 at 6:50 AM, Matthias Reichl wrote: > Hi Sean, > > On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote: >> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most >> widely used IR protocols, but there are many protocols which are not >> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, >> many of which are not supported by rc-core. There is a "long tail" of >> unsupported IR protocols, for which lircd is need to decode the IR . >> >> IR encoding is done in such a way that some simple circuit can decode it; >> therefore, bpf is ideal. >> >> In order to support all these protocols, here we have bpf based IR decoding. >> The idea is that user-space can define a decoder in bpf, attach it to >> the rc device through the lirc chardev. >> >> Separate work is underway to extend ir-keytable to have an extensive library >> of bpf-based decoders, and a much expanded library of rc keymaps. >> >> Another future application would be to compile IRP[3] to a IR BPF program, and >> so support virtually every remote without having to write a decoder for each. >> It might also be possible to support non-button devices such as analog >> directional pads or air conditioning remote controls and decode the target >> temperature in bpf, and pass that to an input device. > > Thanks a lot, this looks like a very interesting feature to me! > > Unfortunately I don't have time to test it ATM, but please keep > me posted - also on ir-keytable progress - I'm rather excited > to give it a try. > > so long & thanks, > > Hias > >> >> Thanks, >> >> Sean Young >> >> [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR >> [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/ >> [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation >> >> Changes since v3: >> - Implemented review comments from Quentin Monnet and Y Song (thanks!) >> - More helpful and better formatted bpf helper documentation >> - Changed back to bpf_prog_array rather than open-coded implementation >> - scancodes can be 64 bit >> - bpf gets passed values in microseconds, not nanoseconds. >> microseconds is more than than enough (IR receivers support carriers upto >> 70kHz, at which point a single period is already 14 microseconds). Also, >> this makes it much more consistent with lirc mode2. >> - Since it looks much more like lirc mode2, rename the program type to >> BPF_PROG_TYPE_LIRC_MODE2. >> - Rebased on bpf-next >> >> Changes since v2: >> - Fixed locking issues >> - Improved self-test to cover more cases >> - Rebased on bpf-next again >> >> Changes since v1: >> - Code review comments from Y Song and >> Randy Dunlap >> - Re-wrote sample bpf to be selftest >> - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type) >> - Rebase on bpf-next >> - Introduced bpf_rawir_event context structure with simpler access checking >> >> Sean Young (3): >> bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not >> found >> media: rc: introduce BPF_PROG_LIRC_MODE2 >> bpf: add selftest for lirc_mode2 type program >> >> drivers/media/rc/Kconfig | 13 + >> drivers/media/rc/Makefile | 1 + >> drivers/media/rc/bpf-lirc.c | 308 ++++++++++++++++++ >> drivers/media/rc/lirc_dev.c | 30 ++ >> drivers/media/rc/rc-core-priv.h | 22 ++ >> drivers/media/rc/rc-ir-raw.c | 12 +- >> include/linux/bpf_rcdev.h | 30 ++ >> include/linux/bpf_types.h | 3 + >> include/uapi/linux/bpf.h | 53 ++- >> kernel/bpf/core.c | 11 +- >> kernel/bpf/syscall.c | 7 + >> kernel/trace/bpf_trace.c | 2 + >> tools/bpf/bpftool/prog.c | 1 + >> tools/include/uapi/linux/bpf.h | 53 ++- >> tools/include/uapi/linux/lirc.h | 217 ++++++++++++ >> tools/lib/bpf/libbpf.c | 1 + >> tools/testing/selftests/bpf/Makefile | 8 +- >> tools/testing/selftests/bpf/bpf_helpers.h | 6 + >> .../testing/selftests/bpf/test_lirc_mode2.sh | 28 ++ >> .../selftests/bpf/test_lirc_mode2_kern.c | 23 ++ >> .../selftests/bpf/test_lirc_mode2_user.c | 154 +++++++++ >> 21 files changed, 974 insertions(+), 9 deletions(-) >> create mode 100644 drivers/media/rc/bpf-lirc.c >> create mode 100644 include/linux/bpf_rcdev.h >> create mode 100644 tools/include/uapi/linux/lirc.h >> create mode 100755 tools/testing/selftests/bpf/test_lirc_mode2.sh >> create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_kern.c >> create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_user.c >> >> -- >> 2.17.0 >>