About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / DocBook / media / v4l / lirc_device_interface.xml

Custom Search

Based on kernel version 4.7.2. Page generated on 2016-08-22 22:45 EST.

1	<section id="lirc_dev">
2	<title>LIRC Device Interface</title>
5	<section id="lirc_dev_intro">
6	<title>Introduction</title>
8	<para>The LIRC device interface is a bi-directional interface for
9	transporting raw IR data between userspace and kernelspace. Fundamentally,
10	it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number
11	of standard struct file_operations defined on it. With respect to
12	transporting raw IR data to and fro, the essential fops are read, write
13	and ioctl.</para>
15	<para>Example dmesg output upon a driver registering w/LIRC:</para>
16	  <blockquote>
17	    <para>$ dmesg |grep lirc_dev</para>
18	    <para>lirc_dev: IR Remote Control driver registered, major 248</para>
19	    <para>rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0</para>
20	  </blockquote>
22	<para>What you should see for a chardev:</para>
23	  <blockquote>
24	    <para>$ ls -l /dev/lirc*</para>
25	    <para>crw-rw---- 1 root root 248, 0 Jul  2 22:20 /dev/lirc0</para>
26	  </blockquote>
27	</section>
29	<section id="lirc_read">
30	<title>LIRC read fop</title>
32	<para>The lircd userspace daemon reads raw IR data from the LIRC chardev. The
33	exact format of the data depends on what modes a driver supports, and what
34	mode has been selected. lircd obtains supported modes and sets the active mode
35	via the ioctl interface, detailed at <xref linkend="lirc_ioctl"/>. The generally
36	preferred mode is LIRC_MODE_MODE2, in which packets containing an int value
37	describing an IR signal are read from the chardev.</para>
39	<para>See also <ulink url="http://www.lirc.org/html/technical.html">http://www.lirc.org/html/technical.html</ulink> for more info.</para>
40	</section>
42	<section id="lirc_write">
43	<title>LIRC write fop</title>
45	<para>The data written to the chardev is a pulse/space sequence of integer
46	values. Pulses and spaces are only marked implicitly by their position. The
47	data must start and end with a pulse, therefore, the data must always include
48	an uneven number of samples. The write function must block until the data has
49	been transmitted by the hardware. If more data is provided than the hardware
50	can send, the driver returns EINVAL.</para>
52	</section>
54	<section id="lirc_ioctl">
55	<title>LIRC ioctl fop</title>
57	<para>The LIRC device's ioctl definition is bound by the ioctl function
58	definition of struct file_operations, leaving us with an unsigned int
59	for the ioctl command and an unsigned long for the arg. For the purposes
60	of ioctl portability across 32-bit and 64-bit, these values are capped
61	to their 32-bit sizes.</para>
63	<para>The following ioctls can be used to change specific hardware settings.
64	In general each driver should have a default set of settings. The driver
65	implementation is expected to re-apply the default settings when the device
66	is closed by user-space, so that every application opening the device can rely
67	on working with the default settings initially.</para>
69	<variablelist>
70	  <varlistentry>
71	    <term>LIRC_GET_FEATURES</term>
72	    <listitem>
73	      <para>Obviously, get the underlying hardware device's features. If a driver
74	      does not announce support of certain features, calling of the corresponding
75	      ioctls is undefined.</para>
76	    </listitem>
77	  </varlistentry>
78	  <varlistentry>
79	    <term>LIRC_GET_SEND_MODE</term>
80	    <listitem>
81	      <para>Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd.</para>
82	    </listitem>
83	  </varlistentry>
84	  <varlistentry>
85	    <term>LIRC_GET_REC_MODE</term>
86	    <listitem>
87	      <para>Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE
88	      are supported by lircd.</para>
89	    </listitem>
90	  </varlistentry>
91	  <varlistentry>
92	    <term>LIRC_GET_SEND_CARRIER</term>
93	    <listitem>
94	      <para>Get carrier frequency (in Hz) currently used for transmit.</para>
95	    </listitem>
96	  </varlistentry>
97	  <varlistentry>
98	    <term>LIRC_GET_REC_CARRIER</term>
99	    <listitem>
100	      <para>Get carrier frequency (in Hz) currently used for IR reception.</para>
101	    </listitem>
102	  </varlistentry>
103	  <varlistentry>
104	    <term>LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE</term>
105	    <listitem>
106	      <para>Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently,
107	      no special meaning is defined for 0 or 100, but this could be used to switch
108	      off carrier generation in the future, so these values should be reserved.</para>
109	    </listitem>
110	  </varlistentry>
111	  <varlistentry>
112	    <term>LIRC_GET_REC_RESOLUTION</term>
113	    <listitem>
114	      <para>Some receiver have maximum resolution which is defined by internal
115	      sample rate or data format limitations. E.g. it's common that signals can
116	      only be reported in 50 microsecond steps. This integer value is used by
117	      lircd to automatically adjust the aeps tolerance value in the lircd
118	      config file.</para>
119	    </listitem>
120	  </varlistentry>
121	  <varlistentry>
122	    <term>LIRC_GET_M{IN,AX}_TIMEOUT</term>
123	    <listitem>
124	      <para>Some devices have internal timers that can be used to detect when
125	      there's no IR activity for a long time. This can help lircd in detecting
126	      that a IR signal is finished and can speed up the decoding process.
127	      Returns an integer value with the minimum/maximum timeout that can be
128	      set. Some devices have a fixed timeout, in that case both ioctls will
129	      return the same value even though the timeout cannot be changed.</para>
130	    </listitem>
131	  </varlistentry>
132	  <varlistentry>
133	    <term>LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE}</term>
134	    <listitem>
135	      <para>Some devices are able to filter out spikes in the incoming signal
136	      using given filter rules. These ioctls return the hardware capabilities
137	      that describe the bounds of the possible filters. Filter settings depend
138	      on the IR protocols that are expected. lircd derives the settings from
139	      all protocols definitions found in its config file.</para>
140	    </listitem>
141	  </varlistentry>
142	  <varlistentry>
143	    <term>LIRC_GET_LENGTH</term>
144	    <listitem>
145	      <para>Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE).
146	      Reads on the device must be done in blocks matching the bit count.
147	      The bit could should be rounded up so that it matches full bytes.</para>
148	    </listitem>
149	  </varlistentry>
150	  <varlistentry>
151	    <term>LIRC_SET_{SEND,REC}_MODE</term>
152	    <listitem>
153	      <para>Set send/receive mode. Largely obsolete for send, as only
154	      LIRC_MODE_PULSE is supported.</para>
155	    </listitem>
156	  </varlistentry>
157	  <varlistentry>
158	    <term>LIRC_SET_{SEND,REC}_CARRIER</term>
159	    <listitem>
160	      <para>Set send/receive carrier (in Hz).</para>
161	    </listitem>
162	  </varlistentry>
163	  <varlistentry>
164	    <term>LIRC_SET_TRANSMITTER_MASK</term>
165	    <listitem>
166	      <para>This enables the given set of transmitters. The first transmitter
167	      is encoded by the least significant bit, etc. When an invalid bit mask
168	      is given, i.e. a bit is set, even though the device does not have so many
169	      transitters, then this ioctl returns the number of available transitters
170	      and does nothing otherwise.</para>
171	    </listitem>
172	  </varlistentry>
173	  <varlistentry>
174	    <term>LIRC_SET_REC_TIMEOUT</term>
175	    <listitem>
176	      <para>Sets the integer value for IR inactivity timeout (cf.
177	      LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if
178	      supported by the hardware) disables all hardware timeouts and data should
179	      be reported as soon as possible. If the exact value cannot be set, then
180	      the next possible value _greater_ than the given value should be set.</para>
181	    </listitem>
182	  </varlistentry>
183	  <varlistentry>
184	    <term>LIRC_SET_REC_TIMEOUT_REPORTS</term>
185	    <listitem>
186	      <para>Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By
187	      default, timeout reports should be turned off.</para>
188	    </listitem>
189	  </varlistentry>
190	  <varlistentry>
191	    <term>LIRC_SET_REC_FILTER_{,PULSE,SPACE}</term>
192	    <listitem>
193	      <para>Pulses/spaces shorter than this are filtered out by hardware. If
194	      filters cannot be set independently for pulse/space, the corresponding
195	      ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead.</para>
196	    </listitem>
197	  </varlistentry>
198	  <varlistentry>
199	    <term>LIRC_SET_MEASURE_CARRIER_MODE</term>
200	    <listitem>
201	      <para>Enable (1)/disable (0) measure mode. If enabled, from the next key
202	      press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default
203	      this should be turned off.</para>
204	    </listitem>
205	  </varlistentry>
206	  <varlistentry>
208	    <listitem>
210	      with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER
211	      with the upper bound.</para>
212	    </listitem>
213	  </varlistentry>
214	  <varlistentry>
215	    <term>LIRC_NOTIFY_DECODE</term>
216	    <listitem>
217	      <para>This ioctl is called by lircd whenever a successful decoding of an
218	      incoming IR signal could be done. This can be used by supporting hardware
219	      to give visual feedback to the user e.g. by flashing a LED.</para>
220	    </listitem>
221	  </varlistentry>
222	  <varlistentry>
223	    <term>LIRC_SETUP_{START,END}</term>
224	    <listitem>
225	      <para>Setting of several driver parameters can be optimized by encapsulating
226	      the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a
227	      driver receives a LIRC_SETUP_START ioctl it can choose to not commit
228	      further setting changes to the hardware until a LIRC_SETUP_END is received.
229	      But this is open to the driver implementation and every driver must also
230	      handle parameter changes which are not encapsulated by LIRC_SETUP_START
231	      and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.</para>
232	    </listitem>
233	  </varlistentry>
234	  <varlistentry>
235	    <term>LIRC_SET_WIDEBAND_RECEIVER</term>
236	    <listitem>
237	      <para>Some receivers are equipped with special wide band receiver which is intended
238	      to be used to learn output of existing remote.
239	      Calling that ioctl with (1) will enable it, and with (0) disable it.
240	      This might be useful of receivers that have otherwise narrow band receiver
241	      that prevents them to be used with some remotes.
242	      Wide band receiver might also be more precise
243	      On the other hand its disadvantage it usually reduced range of reception.
244	      Note: wide band receiver might be implictly enabled if you enable
245	      carrier reports. In that case it will be disabled as soon as you disable
246	      carrier reports. Trying to disable wide band receiver while carrier
247	      reports are active will do nothing.</para>
248	    </listitem>
249	  </varlistentry>
250	</variablelist>
251	<section id="lirc_dev_errors">
252	  &return-value;
253	</section>
254	</section>
255	</section>
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.