Dear list et. al., I missed it again... this time I think the patch is OK, but I forgot to use claws-mail so it's probably garbled. Re-sending last message, please just drop the previous. --alec On 13/12/15 19:34, J William Piggott wrote: > > > On 12/13/2015 03:23 AM, Michael Kerrisk (man-pages) wrote: >> Hello Alec, >> >> On 12 December 2015 at 07:34, Alec Leamas <leamas.alec@xxxxxxxxx> wrote: >>> On Fri, 11 Dec 2015 20:16:00 +0100 >>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> wrote: >> >> [Excellent walk though of fixes snipped] And a not so excellent patch... somethinh wnt terribly wromg when I generated the patch - it seems like most of my changes wasn't included. Making a fresh retry, please ignore the last, broken patch. >> >>> Revised patch: >> >> Patches on top of patches is confusing. For the next round, just send >> a fresh complete patch. A few more comments below. Indeed, and that's what I thought I did... >>> +Drivers for this kind of hardware work in >>> .B LIRC_MODE_LIRCCODE. >> >> .BR LIRC_MODE_LIRCCODE . All '^\.B ' fixed >> .BR LIRC_MODE_MODE2 . >> >> (i.e., add space before '.') Probably there are other instances to fix as well. Hopefully found and fixed them all. >>> .SH Reading using LIRC_MODE_MODE2 drivers > > s/using/input with the/ Fixed. >>> +.IR lirc_t. >> >> .IR lirc_t . Fixed. >>> -Value reflects a pulse duration (us). >>> +.BR LIRC_MODE2_PULSE >> >> s/$/ ./ >> (And at various other places below.) > s/below/above and below/ Fixed four occurences, unsure where to apply this. >> >>> +Value reflects a pulse duration (microseconds). >>> .TP 4 >>> -.B LIRC_MODE2_FREQUENCY >>> +.BR LIRC_MODE2_FREQUENCY >>> Value reflects a frequency (hz), see the LIRC_SET_MEASURE_CARRIER ioctl. >>> .TP 4 >>> -.B LIRC_MODE2_TIMEOUT >>> +.BR LIRC_MODE2_TIMEOUT >>> The package reflects a timeout, see the LIRC_SET_REC_TIMEOUT_REPORTS ioctl. >>> >>> .SH Reading using LIRC_MODE_LIRCCODE drivers. >> >> s/.$// >> > s/using/input with the/ Fixed > > s/read() on the device must be done/Device input must be read/ fixed >> s/the driver/the write() call/ >> >> Start new sentence on new line. Fixed >> >>> returns >> >> s/returns/fails with the error/ >> >>> -.B EINVAL >>> +.BR EINVAL >> >> .BR EINVAL . >> Fixed >>> Many require a third argument, usually an int. >> >> Put the"int" on a separate line as >> >> .IR int . Fixed > >>> @@ -88,111 +114,117 @@ the device can rely on working with the default settings initially. >>> .P >>> \fI/dev/lirc*\fR devices always supports the following commands: >>> .TP 4 >>> -.B LIRC_GET_FEATURES void >>> +.BR LIRC_GET_FEATURES void > > Why? (and others below) Don't know, I have read your remarks as 's/^\.B /\.BR /' When should it be .BR, and when .B ? >>> Driver returns integer values, each of which representing a decoded button >> >> s/representing/represents/ Fixed >>> +If a device returns an error code for > > s/ for/ for/ > Fixed >>> +.BR LIRC_GET_REC_MODE >> >> s/$/ ,/ >> >>> it is safe to assume it is not a lirc device. >>> >>> .BR >> >> Remove that last line. fixed >> >>> .SH Optional Commands >>> .Ped. >>> +Some lirc devices supports the following commands. >> >> s/supports/supports/ > > s/supports/support/ > Fixed >> >>> +Unless otherwise stated these returns \fIENOIOCTLCMD\fR >> >> s/returns/fail with the error/ >> >>> +or \fIENOSYS\fR if the operation >>> +isn't supported and \fIEINVAL\fR if operation failed. >> >> s/and/or with the error/ > > s/ and/, or with the error/ > >> s/operation/the operation/ Fixed (?) >>> .TP >>> -.B LIRC_GET_LENGTH " (\fIvoid\fP)" >>> +.BR LIRC_GET_LENGTH " (\fIvoid\fP)" >>> Return the positive length of the returned codes for > > s/ length/ length/ > >>> -.B LIRC_LIRCCODE >>> +.BR LIRC_LIRCCODE See above. When is using .BR right, and when .B? >>> type >>> drivers, otherwise >> >> s/$/ fail with the error/ Fixed >>> -.B LIRC_GET_MAX_TIMEOUT. >>> +.BR LIRC_GET_MAX_TIMEOUT. >> >> s/.$/ .$/ Fixed >>> Some receivers are equipped with special wide band receiver which is >>> intended to be used to learn output of existing remote. > > s/receivers/devices/ > s/receiver which is/receivers which are/ > s/output/the output/ > s/existing/an existing/ Fixed >>> Calling that ioctl with (1) will enable it, and with (0) disable it. >>> @@ -223,123 +255,136 @@ This might be useful of receivers that have otherwise narrow band receiver > > s/useful of receivers/useful for devices/ > s/have otherwise/otherwise have/ > s/receiver/receivers/ Fixed > >>> that prevents them to be used with some remotes. > > which prevent them from being used with certain remotes. > >>> Wide band receiver might also be more precise. > > s/receiver/receivers/ > s/might/may/ Fixed > >>> On the other hand its disadvantage usually is reduced range of reception. >>> -Note: wide band receiver might be implictly enabled if you enable >>> +Note: wide band receiver might be implicitly enabled if you enable >>> carrier reports. >>> In that case it will be disabled as soon as you disable carrier reports. >>> Trying to disable wide band receiver while carrier reports are active will >>> do nothing > > s/wide/a wide/ > s/$/.$/ Fixed. >>> >>> .TP >>> -.B LIRC_SETUP_START " (\fIvoid\fP)", LIRC_SETUP_END " (\fIvoid\fP)" >>> +.BR LIRC_SETUP_START " (\fIvoid\fP)", LIRC_SETUP_END " (\fIvoid\fP)" >>> Setting of several driver parameters can be optimized by encapsulating >>> the according ioctl calls with > > does 'according' make sense here? accompanying? Fixed (usinng 'actual') > >>> +for example by flashing a LED. > > s/a/an/ Fixed >>> +.BR LIRC_MODE_RAW >> >> s/$/ ./ >> (And other instances below) Fixed >>> +That this file is not public is a bug, see > > This file not being public is a bug, see Fixed On 13/12/15 19:34, J William Piggott wrote: > >> .SH Reading using LIRC_MODE_MODE2 drivers > s/using/input with the/ Fixed >> read() on the device must be done in blocks matching >> the bit count, rounded up so it matches full bytes. > s/read() on the device must be done/Device input must be read/ Fixed > Driver returns integer values, each of which representing a decoded button > s/representing/represents/ Fixed >> +If a device returns an error code for > s/ for/ for/ Fixed >> +Some lirc devices supports the following commands. > s/supports/support/ Fixed > Unless otherwise stated these returns \fIENOIOCTLCMD\fR> > s/returns/fail with the error/ Fixed >> Return the positive length of the returned codes for > s/ length/ length/ Fixed together with some other double spaces. >> Some receivers are equipped with special wide band receiver which is >> intended to be used to learn output of existing remote. > s/receivers/devices/ > s/receiver which is/receivers which are/ > s/output/the output/ > s/existing/an existing/ Fixed >> Calling that ioctl with (1) will enable it, and with (0) disable it. >> @@ -223,123 +255,136 @@ This might be useful of receivers that have otherwise narrow band receiver > s/useful of receivers/useful for devices/ > s/have otherwise/otherwise have/ > s/receiver/receivers/ Fixed >> that prevents them to be used with some remotes. > which prevent them from being used with certain remotes. Fixed >> Wide band receiver might also be more precise. > s/receiver/receivers/ > s/might/may/ Fixed >> Trying to disable wide band receiver while carrier reports are active will >> do nothing > s/wide/a wide/ > s/$/.$/ Fixed >> etting of several driver parameters can be optimized by encapsulating >> the according ioctl calls with > does 'according' make sense here? accompanying? Fixed, (usingf 'actual') >> -to give visual user feedback e.g., by flashing a LED. >> +incoming IR signal could be done. > s/could be done/is possible/ Fixed >> or example by flashing a LED. > s/a/an/ Fixed >> +That this file is not public is a bug, see > This file not being public is a bug, see Fixed New patch (hopefully in better shape...) >From 0864603b5f912be5e9b43dc690b313e1ba83b0f5 Mon Sep 17 00:00:00 2001 From: Alec Leamas <leamas.alec@xxxxxxxxx> Date: Mon, 14 Dec 2015 10:47:08 +0100 Subject: [PATCH] Adding new lirc.4 manpage --- doc/man-source/lirc.4 | 396 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 396 insertions(+) create mode 100644 doc/man-source/lirc.4 diff --git a/doc/man-source/lirc.4 b/doc/man-source/lirc.4 new file mode 100644 index 0000000..f468364 --- /dev/null +++ b/doc/man-source/lirc.4 @@ -0,0 +1,396 @@ +.TH LIRC 4 "Aug 2015" "Linux" "Linux Programmer's Manual" + + +.\" Copyright (c) 2015, Alec Leamas +.\" +.\" %%%LICENSE_START(GPLv2+_DOC_FULL) +.\" This is free documentation; you can redistribute it and/or +.\" modify it under the terms of the GNU General Public License as +.\" published by the Free Software Foundation; either version 2 of +.\" the License, or (at your option) any later version. +.\" +.\" The GNU General Public License's references to "object code" +.\" and "executables" are to be interpreted as the output of any +.\" document formatting or typesetting system, including +.\" intermediate and printed output. +.\" +.\" This manual is distributed in the hope that it will be useful, +.\" but WITHOUT ANY WARRANTY; without even the implied warranty of +.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +.\" GNU General Public License for more details. +.\" +.\" You should have received a copy of the GNU General Public +.\" License along with this manual; if not, see +.\" <http://www.gnu.org/licenses/>. +.\" %%%LICENSE_END +.SH NAME +lirc \- lirc devices +.SH DESCRIPTION +.P +\fB/dev/lirc*\fR are character devices providing a low-level +bi-directional interface to infra-red (IR) remotes. +When receiving data, the driver works in two different modes depending +on the underlying hardware. +.P +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 . +Such hardware usually does not support sending IR signals. +Furthermore, it usually only works with a specific remote which is +bundled with, for example, a TV-card. +.P +Other hardware provides a stream of pulse/space durations. +Such drivers work in +.BR LIRC_MODE_MODE2 . +Sometimes, this kind of hardware also supports +sending IR data. +Such hardware can be used with (almost) any kind of remote. +.P +The \fBLIRC_GET_REC_MODE\fR ioctl allows probing for the mode. + +.SH Reading input with the LIRC_MODE_MODE2 drivers +.P +In the \fBLIRC_MODE_MODE2 mode\fR, the driver read() provides 32-bit values +representing a space or a pulse duration, by convention typed as +.IR lirc_t . +The time of the duration (microseonds) is encoded in the lower 24 bits. +The upper 8 bit reflects the type of package: +.TP 4 +.BR LIRC_MODE2_SPACE . +Value reflects a space duration (microseconds). +.TP 4 +.BR LIRC_MODE2_PULSE . +Value reflects a pulse duration (microseconds). +.TP 4 +.BR LIRC_MODE2_FREQUENCY . +Value reflects a frequency (hz), see the LIRC_SET_MEASURE_CARRIER ioctl. +.TP 4 +.BR LIRC_MODE2_TIMEOUT . +The package reflects a timeout, see the LIRC_SET_REC_TIMEOUT_REPORTS ioctl. + +.SH Reading input with the LIRC_MODE_LIRCCODE drivers +.P +In the \fBLIRC_MODE_LIRCCODE\fR +mode, the data returned by read() reflects decoded +button presses. +The length of each packet can be retrieved using +the \fBLIRC_GET_LENGTH\fR ioctl. +Device must be read in blocks matching +the bit count, rounded up so it matches full bytes. + +.SH Sending data. +.P +When sending data, only the \fBLIRC_MODE_PULSE\fR +mode is supported. +The data written to the character device using write() is a pulse/space +sequence of integer values. +Pulses and spaces are only marked implicitly by their position. +The data must start and end with a pulse, thus it must always include an +odd number of samples. +The write() function blocks until the data has been transmitted by the +hardware. +If more data is provided than the hardware can send, the write() call +fails with the error +.BR EINVAL + +.SH SUPPORTED IOCTL COMMANDS +.P +.nf +#include " (\fIuapi/lirc.h\fP)" +int ioctl(int fd, int cmd, ...); +.fi +.P +The following ioctls can be used to probe or change specific lirc +hardware settings. +Many require a third argument, usually an +.IR int . +.P +In general, each driver should have a default set of settings. +The driver implementation is expected to re-apply the default settings +when the device is closed by userspace, so that every application opening +the device can rely on working with the default settings initially. + +.BR +.SH Always Supported Commands +.P +\fI/dev/lirc*\fR devices always supports the following commands: +.TP 4 +.BR LIRC_GET_FEATURES void +Returns a bitmask of combined features bits, see FEATURES. +Some drivers have dynamic features which are not updated until after +an init() command. +.TP 4 +.BR LIRC_GET_REC_MODE void +Returns the receive mode, one of +.RS 4 +.TP +.BR LIRC_MODE_MODE2 +Driver return a sequence of pulse/space durations. +.TP +.BR LIRC_MODE_LIRCCODE +Driver returns integer values, each of which represents a decoded button +press. +.RE +.P +If a device returns an error code for +.BR LIRC_GET_REC_MODE +it is safe to assume it is not a lirc device. + +.SH Optional Commands +.P +Some lirc devices support the following commands. +Unless otherwise stated these fails with the error \fIENOIOCTLCMD\fR +or with the error\fIENOSYS\fR if the operation +isn't supported, or with the error \fIEINVAL\fR if the operation failed. +.TP +.BR LIRC_SET_REC_MODE " (\fIint\fP)" +Set the receive mode, either +.BR LIRC_MODE_LIRCCODE +or +.BR LIRC_MODE_MODE2 . + +.TP +.BR LIRC_GET_LENGTH " (\fIvoid\fP)" +Return the positive length of the returned codes for +.BR LIRC_LIRCCODE +type +drivers, otherwise fail with the error +.BR ENOIOCTLCMD . +.TP +.BR LIRC_GET_SEND_MODE " (\fIvoid\fP)" +Returns the send mode; currently only +.BR LIRC_MODE_PULSE +is supported. +.TP +.BR LIRC_SET_SEND_MODE " (\fIint\fP)" +Set the send mode. +Obsolete since only +.BR LIRC_MODE_PULSE +is supported. +.TP +.BR LIRC_SET_SEND_CARRIER " (\fIint\fP)" +Set the modulation frequency. The argument is the frequency (Hz). +.TP +.BR SET_SEND_DUTY_CYCLE " (\fIint\fP)" +Set the carrier duty cycle. +The argument is an int (0 < value < 100) which +describes the pulse width in percent of the total cycle. +Currently, no special meaning is defined for 0 or 100, but the values +are reserved for future use. +.TP +.BR LIRC_GET_MIN_TIMEOUT " (\fIvoid\fP)", LIRC_GET_MAX_TIMEOUT " (\fIvoid\fP)" +Some devices have internal timers that can be used to detect when +there's no IR activity for a long time. +This can help lircd in detecting that a IR signal is finished and +can speed up the decoding process. +Returns an integer value with the minimum/maximum timeout that can be +set. +Some devices have a fixed timeout, in that case +.BR LIRC_GET_MIN_TIMEOUT +and +.BR LIRC_GET_MAX_TIMEOUT +will return the same value even though the timeout cannot be changed. +.TP +.BR LIRC_SET_REC_TIMEOUT " (\fIint\fP)" +Sets the integer value for IR inactivity timeout. +To be accepted, the value must be within the limits defined by +.BR LIRC_GET_MIN_TIMEOUT +and +.BR LIRC_GET_MAX_TIMEOUT . +A value of 0 (if supported by the hardware) disables all hardware timeouts +and data should be reported as soon as possible. +If the exact value cannot be set, then the next possible value +.I greater +than the given value should be set. +.TP +.BR LIRC_SET_REC_TIMEOUT_REPORTS " (\fIint\fP)" +Enables/disables (1/0) timeout packages in +.BR LIRC_MODE_MODE2 . +By default, timeout reports should be turned off. +.TP +.BR LIRC_SET_REC_CARRIER " (\fIint\fP)" +Set the receive carrier frequency (Hz). +.TP +.BR LIRC_SET_REC_CARRIER_RANGE " (\fIint\fP)" +First time called sets the lower bound of the carrier range, second time +the upper bound (Hz). +.TP +.BR LIRC_SET_MEASURE_CARRIER " (\fIint\fP)" +Enable/disable (1/0) the measure mode. +If enabled, from the next key press on, the driver will send +.BR LIRC_MODE2_FREQUENCY +packets. By default this should be turned off. +.TP +.BR LIRC_GET_REC_RESOLUTION " (\fIvoid\fP)" +Returns the driver resolution (microseconds). +.TP +.BR LIRC_GET_MIN_FILTER_PULSE void, LIRC_GET_MAX_FILTER_PULSE void +Some devices are able to filter out spikes in the incoming signal +using given filter rules. +These ioctls return the hardware capabilities that describe the bounds +of the possible filters. +Filter settings depend on the IR protocols that are expected. +lircd derives the settings from all protocols definitions found in its +config file. +.TP +.BR LIRC_GET_MIN_FILTER_SPACE " (\fIvoid\fP)", LIRC_GET_MAX_FILTER_SPACE " (\fIvoid\fP)" +See +.BR LIRC_GET_MIN_FILTER_PULSE +.TP +.BR LIRC_SET_REC_FILTER " (\fIint\fP)" +Pulses/spaces shorter than this (microseconds) are filtered out by hardware. +.TP +.BR LIRC_SET_REC_FILTER_PULSE " (\fIint\fP)", LIRC_SET_REC_FILTER_SPACE " (\fIint\fP)" +Pulses/spaces shorter than this (microseconds) are filtered out by hardware. +If filters cannot be set independently for pulse/space, the corresponding +ioctls must return an error and +.BR LIRC_SET_REC_FILTER +shall be used instead. +.TP +.BR LIRC_SET_WIDEBAND_RECEIVER " (\fIint\fP)" +Some devices are equipped with special wide band receiver which are +intended to be used to learn the output of an existing remote. +Calling that ioctl with (1) will enable it, and with (0) disable it. +This might be useful for devices that otherwise have narrow band receivers +that prevent them to be used with certain remotes. +Wide band receivers may also be more precise. +On the other hand its disadvantage usually is reduced range of reception. +Note: wide band receiver may be implicitly enabled if you enable +carrier reports. +In that case it will be disabled as soon as you disable carrier reports. +Trying to disable a wide band receiver while carrier reports are active will +do nothing. + +.TP +.BR LIRC_SETUP_START " (\fIvoid\fP)", LIRC_SETUP_END " (\fIvoid\fP)" +Setting of several driver parameters can be optimized by encapsulating +the actual ioctl calls with +.BR LIRC_SETUP_START/LIRC_SETUP_END . +When a driver receives a +.BR LIRC_SETUP_START +ioctl it can choose to not commit further setting changes to the hardware +until a +.BR LIRC_SETUP_END +is received. +But this is open to the driver implementation and every driver +must also handle parameter changes which are not encapsulated by +.BR LIRC_SETUP_START +and +.BR LIRC_SETUP_END . +Drivers can also choose to ignore these ioctls. + +.TP +.BR LIRC_NOTIFY_DECODE " (\fIvoid\fP)" +This ioctl is called by lircd whenever a successful decoding of an +incoming IR signal is possible.. +This can be used by supporting hardware to give visual user feedback, +for example by flashing an LED. + +.SH FEATURES +.P +The features returned by +.BR LIRC_GET_FEATURES +is a bitmask combining the following bits: +.TP 8 +.BR LIRC_CAN_REC_RAW +The driver is capable of receiving using +.BR LIRC_MODE_RAW . +.TP 8 +.BR LIRC_CAN_REC_PULSE +The driver is capable of receiving using +.BR LIRC_MODE_PULSE . +.TP 8 +.BR LIRC_CAN_REC_MODE2 +The driver is capable of receiving using +.BR LIRC_MODE_MODE2 . +.TP 8 +.BR LIRC_CAN_REC_LIRCCODE +The driver is capable of receiving using +.BR LIRC_MODE_LIRCCODE . +.TP 8 +.BR LIRC_CAN_SET_SEND_CARRIER +Driver supports changing the modulation frequency using +.BR LIRC_SET_SEND_CARRIER . +.TP 8 +.BR LIRC_CAN_SET_SEND_DUTY_CYCLE +Driver supports changing the duty cycle using +.BR LIRC_SET_SEND_DUTY_CYCLE . +.TP 8 +.BR LIRC_CAN_SET_TRANSMITTER_MASK +Enables the given set of transmitters. +The first transmitter is encoded by the least significant bit, etc. +When an invalid bit mask is given, for example a bit is set even though the +device does not have so many transmitters, returns the number of available +transmitters and does nothing otherwise. +.TP 8 +.BR LIRC_CAN_SET_REC_CARRIER +Driver supports setting the receive carrier frequency using +.BR LIRC_SET_REC_CARRIER . +.TP 8 +.BR LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE +Driver supports +.BR LIRC_SET_REC_DUTY_CYCLE_RANGE +.TP 8 +.BR LIRC_CAN_SET_REC_CARRIER_RANGE +Driver supports +.BR LIRC_SET_REC_CARRIER_RANGE +.TP 8 +.BR LIRC_CAN_GET_REC_RESOLUTION +Driver supports +.BR LIRC_GET_REC_RESOLUTION +.TP 8 +.BR LIRC_CAN_SET_REC_TIMEOUT +Driver supports +.BR LIRC_SET_REC_TIMEOUT +.TP 8 +.BR LIRC_CAN_SET_REC_FILTER +Driver supports +.BR LIRC_SET_REC_FILTER +.TP 8 +.BR LIRC_CAN_MEASURE_CARRIER +Driver supports measuring of the modulation frequency using +.BR LIRC_MEASURE_CARRIER +.TP 8 +.BR LIRC_CAN_USE_WIDEBAND_RECEIVER +Driver supports learning mode using +.BR LIRC_SET_WIDEBAND_RECEIVER +.TP 8 +.BR LIRC_CAN_NOTIFY_DECODE +Driver supports +.BR LIRC_NOTIFY_DECODE . +.TP 8 +.BR LIRC_CAN_SEND_RAW +Driver supports sending using +.BR LIRC_SEND_RAW +.TP 8 +.BR LIRC_CAN_SEND_PULSE +Driver supports sending using +.BR LIRC_MODE_PULSE +.TP 8 +.BR LIRC_CAN_SEND_MODE2 +Driver supports sending using +.BR LIRC_SEND_MODE2 +.TP 8 +.BR LIRC_CAN_SEND_LIRCCODE +Driver supports sending +.BR LIRC_SEND_LIRCCODE +(this is uncommon, since +.BR LIRCCODE +drivers reflect hardware like TV-cards which usually does not support +sending.) + +.SH BUGS +.P +Using these devices requires the kernel source header file lirc.h. +This file not being public is a bug, see +https://bugzilla.kernel.org/show_bug.cgi?id=75751. +For the time being the file is bundled in the lirc package, +see http://www.lirc.org. +.P +This manual page should really be part of the upstream man-pages project. + + +.SH SEE ALSO +.P +https://www.kernel.org/doc/htmldocs/media_api/lirc_dev.html -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
