Hello Sean, On 11/01/2018 01:12 PM, Sean Young wrote: > > Hi Micheal, > > On Thu, Nov 01, 2018 at 12:58:30PM +0100, Michael Kerrisk (man-pages) wrote: >> Hi Sean, >> >> One question about the patch below... >> On 11/01/2018 12:18 AM, Sean Young wrote: >>> There are no drivers that support LIRC_MODE_LIRCCODE any more; those >>> drivers were in the kernel staging area, so they were never part >>> of the mainline kernel. >>> >>> Signed-off-by: Sean Young <sean@xxxxxxxx> >>> --- >>> man4/lirc.4 | 90 +++++++++++++++++++++++++++-------------------------- >>> 1 file changed, 46 insertions(+), 44 deletions(-) >>> >>> diff --git a/man4/lirc.4 b/man4/lirc.4 >>> index 0adf11b3e..58ea1193c 100644 >>> --- a/man4/lirc.4 >>> +++ b/man4/lirc.4 >>> @@ -1,4 +1,5 @@ >>> .\" Copyright (c) 2015-2016, Alec Leamas >>> +.\" Copyright (c) 2018, Sean Young <sean@xxxxxxxx> >>> .\" >>> .\" %%%LICENSE_START(GPLv2+_DOC_FULL) >>> .\" This is free documentation; you can redistribute it and/or >>> @@ -33,12 +34,13 @@ When receiving data, the driver works in two different modes depending >>> on the underlying hardware. >>> .PP >>> Some hardware (typically TV-cards) decodes the IR signal internally >>> -and just provides decoded button presses as integer values. >>> -Drivers for this kind of hardware work in >>> -.BR LIRC_MODE_LIRCCODE >>> +and provide decoded button presses as scancode values. Drivers for this >>> +kind of hardware work in >>> +.BR LIRC_MODE_SCANCODE >>> mode. >>> Such hardware usually does not support sending IR signals. >>> -Furthermore, it usually only works with a specific remote which is >>> +Furthermore, they can only decode a limited set of IR protocols, usually >>> +only the protocol of the specific remote which is >>> bundled with, for example, a TV-card. >>> .PP >>> Other hardware provides a stream of pulse/space durations. >>> @@ -47,18 +49,20 @@ Such drivers work in >>> mode. >>> Sometimes, this kind of hardware also supports >>> sending IR data. >>> -Such hardware can be used with (almost) any kind of remote. >>> +Such hardware can be used with (almost) any kind of remote. This type >>> +of hardware can also be used in >>> +.BR LIRC_MODE_SCANCODE >>> +mode, in which case the kernel IR decoders will decode the IR. These >>> +decoders can be written in bpf(2) and attached to the lirc device. >> >> I presume what you mean is that the decoders can be written in >> eBPF (extended BPF)? Probably, that should be stated a bit more >> explicitly. > > That's right. Okay -- I tweaked the wording there a little to say "extended BPF". > There is a lot more to say about how those bpf programs > should be written, and attached to a lirc device. I guess that does not > belong in this man page; I'm not sure what should go in this man page > about that. Sounds like this info does belong in some manual page though. Maybe this one, or maybe a new lirc_bpf(7) (or similar) page? > Using the bpf(2) syscall it is possible to attached, detach, list > these ebpf programs. Some of this should go into bpf(2) and the bpf > helpers functions using by IR decoders should probably go in bpf_helpers > man page. Yes. Sounds like there should be some updates to the bpf_helpers page that is autogenerated from kernel sources. (See man-pages commit 53666f6c30451cde02.) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
