Re: New manpage lirc.4 (Was: Possibly new manpages: lirc and lirc_ioctl)

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 12/14/2015 12:31 PM, Alec Leamas wrote:
> 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.

Too late. I already was offline for a bitand responding to the 
previous. Stand by :-).

Cheers,

Michael

> 
> --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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Fri, 11 Dec 2015 20:16:00 +0100
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html