📄 technical.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><HTML> <HEAD> <TITLE>LIRC - Linux Infrared Remote Control</TITLE> <LINK REL=stylesheet TYPE="text/css" HREF="../lirc.css"> <META NAME="description" CONTENT="LIRC - Linux Infra-red Remote Control"> <META NAME="keywords" CONTENT="linux, kernel module, remote control, animax, multimedia"> </HEAD> <BODY BACKGROUND="../images/marb18.jpg" BGCOLOR="#FFFFFF" TEXT="#000000" ALINK="#8080FF"> <TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="0"> <TR> <TD CLASS="menu" WIDTH="100%" HEIGHT="150"> <IMG SRC="../images/diode.gif" ALT="" WIDTH="300" HEIGHT="150" BORDER="0" HSPACE="20" VSPACE="0" ALIGN="LEFT"> <IMG SRC="../images/lirc.gif" ALT="" WIDTH="300" HEIGHT="150" BORDER="0" HSPACE="20" VSPACE="0" ALIGN="RIGHT"> </TD> </TR> <TR> <TD WIDTH="100%"> <BR> <TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="0"> <TR> <TD WIDTH="15%"> <BR></TD> <TD WIDTH="70%" ALIGN="LEFT" VALIGN="TOP"> <BR><!-- Text ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- Overview ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <A NAME="overview"></A><HR> <CENTER><H1>Driver Model</H1></CENTER> <HR WIDTH="70%"> <PRE> | +------------------------------------------------------+S | | 'gpm -t msc -m /dev/lircm' or a well configured X |O | | (see section 'Configuring lircmd') for details |F | +--------------+---------------------------------------+T | |W | /dev/lircm (named pipe (FIFO) ==> one connection)A | |R | +-----------+-----------+ +-------------------------------+E | | mouse daemon (lircmd) | | tools (irexec, irxevent, ...) | | | configured with | | configured with ~/.lircrc | | | lircmd.conf | | | | +-----------+-----------+ +-----------+-------------------+ | | | | +-------------+-------------+ | | | /dev/lircd (socket ==> multiple connections) | |S | +----------------+--------------------------+O | | decoder daemon (lircd), irrecord or mode2 | TCP/IPF | | lircd is configured through lircd.conf +--- portT | User space | | 8765W | +------------------+------------------------+A | |R | |E | | | | | | | | +---------------------------------+---------------------------------- | Kernel space | (character device | | driver ==> | +------------+----------+ one connection) | | | | /dev/lirc /dev/ttySx | | | | +------------+-------------+ +-----+---------------+ | | LIRC device driver | | Linux serial driver | | | (with ioctl-interface) | | | | +------------+-------------+ +----------+----------+ | | |--+--------------------+----------------------------+------------------ | | | | +----------+------------+ | | | | | | +-------+----------------+ +----+-----+ +-------+-----------------+H | | serial / parallel port | | TV cards | | Irman/RemoteMaster/etc. |W | +------------------------+ +----------+ +-------------------------+ |</PRE> <A NAME="formats"></A><HR> <H1 ALIGN="CENTER">Formats</H1> <HR WIDTH="70%"> <UL> <LI><B>/dev/lirc:</B><BR> <P> highly depends on the mode selected with ioctls: </P> <DL> <DT>LIRC_MODE_MODE2</DT> <DD> <P> outputs packets containing an int value describing a IR signal </P> <UL> <LI>bits 0-23 contain the length of the pulse/space in microseconds</LI> <LI>bit 24 is either 0, meaning space, or 1, meaning pulse</LI> <LI>all other bits are unused</LI> </UL> <P> Lengths greater than or equal to 16 seconds are clamped to 0xffffff. </P> <P>References:</P> <UL> <LI>drivers/lirc_serial/lirc_serial.c</LI> <LI>drivers/lirc_parallel/lirc_parallel.c</LI> <LI>tools/mode2.c (dumps the output from the driver to stdout)</LI> </UL> <BR> </DD> <DT>LIRC_MODE_CODE</DT> <DD> <P> outputs chars (8 bits) </P> </DD> <DT>LIRC_MODE_LIRCCODE</DT> <DD> <P> outputs codes of configurable length in big endian byte order </P> </DD> </DL> </LI> <LI><B>/dev/lircd:</B><BR> <P> outputs strings containing all information about the remote and the pressed button. </P> <P>References:</P> <UL> <LI>daemons/lircd.c</LI> <LI>tools/irw.c</LI> </UL> <BR> </LI> <LI><B>/dev/lircm:</B><BR> <BR> <UL> <LI>MouseSystems<BR> 5 byte packets: <UL> <LI>byte 1: button information</LI> <LI>byte 2: change on X axis</LI> <LI>byte 3: change on Y axis</LI> <LI>byte 4,5: 0</LI> </UL> </LI> <LI>IMPS/2<BR> 4 byte packets: check the source code for details </LI> <LI>IntelliMouse<BR> 4 byte packets: check the source code for details </LI> </UL> <P>References:</P> <UL> <LI>daemons/lircmd.c</LI> </UL> </LI> </UL> <A NAME="lirc_dev"></A><HR> <H1 ALIGN="CENTER">Writing TV card drivers using lirc_dev</H1> <HR WIDTH="70%"> <P> The <em>lirc_dev</em> module is a helper and abstraction layer for other modules. It registers <em>/dev/lirc</em> device in a system (including support for devfs) and waits for plugin registration. After that it serves device requests (open, read, poll, ioctl, close) and if needed calls callback functions from plugin(s) to communicate with the physical device. </P> <P> Plugins can be registered and unregistered many times. The current implementation allows two concurrent plugins, but can be easily changed by increasing the MAX_IRCTL_DEVICES definition. It also allows receiving of scan codes, which have more than 8 bits. Current limit for a scan code is 16*8 bits and also can be changed by increasing the BUFLEN definition. </P> <P> For an API description see <em>lirc_dev.h</em>. The lirc_gpio module can be treated as examples of using this API.<br> This code contains many lines with debug messages (activated by <em>debug</em> option) and they will sustain until more tests will be performed. </P> <P> <B>Warning:</B> Due to the used kernel API it requires kernel 2.2.4 or higher.<br> Any suggestions and questions are welcome. <A href="mailto:alipowski@kki.net.pl">Artur Lipowski</A> </P> <!-- Writing LIRC Applications +++++++++++++++++++++++++++++++++++++++ --> <A NAME="applications"></A><HR> <H1 ALIGN="CENTER">Writing Applications for LIRC</H1> <HR WIDTH="70%"> <P> As LIRC is able to both receive and send IR commands there are two possible types of applications. Programs that send IR commands like <em>xrc</em> and <em>rc</em> or programs that receive commands like <em>irexec</em>, <em>irxevent</em> and <em>irpty</em>. Both types of applications will have to connect to the lircd daemon using the socket interface usually located in /dev/lircd. Communication on the socket uses human readable format. The end of a line is indicated by a newline character. </P> <P> Whenever lircd receives a IR signal it will broadcast the following string to each client:</P> <PRE> <code> <repeat count> <button name> <remote control name></PRE> <P> <em>code</em> is a 64-bit encoding (in hexadecimal representation) of the IR signal. It's usage in applications is deprecated and should be ignored. The <em>repeat count</em> shows how long the user has been holding down a button. The counter will start at 0 and increment each time a new IR signal has been received. The <em>button name</em> and <em>remote control name</em> are defined in the lircd config file. Their purpose should be quite self-explanatory. They must not contain any whitespace.<BR> The only other situation when lircd broadcasts to all clients is when it receives the SIGHUP signal and successfully re-reads its config file. Then it will send a SIGHUP packet to its clients indicating that its configuration might have changed. This feature is <NOBR>e.g.</NOBR> used in <em>xrc</em> to rebuild the list of supported remote controls each time lircd's configuration changes. The format of the packet will be explained later. </P> <P> Applications that want to send out IR commands can use the following commands: </P> <PRE> SEND_ONCE <remote control name> <button name> [<repeat count>] SEND_START <remote control name> <button name> SEND_STOP <remote control name> <button name></PRE> <P> The SEND_ONCE directive tells lircd to send the IR signal associated with the given remote control and button name, and then repeat it <var>repeat count</var> times. <var>repeat count</var> is a decimal number between 0 and 600. If <var>repeat count</var> is not specified or is less than the minimum number of repeats allowed for that remote control, then this minimum value will be used instead. SEND_START tells lircd to start repeating the given button until it receives a SEND_STOP command. As repeating of IR signals is very CPU intensive on most systems there should be a limit on the time for repeating buttons in every application. The number of repeats is internally limited to 600 which for most remotes is equal to one minute of repeating. lircd won't accept any new send commands while it is repeating. </P> <P> lircd also understands the following commands: </P> <PRE> VERSION LIST [<remote control name>]</PRE> <P> The response to the VERSION command will be a packet containing lircd's version.<BR> The LIST command without further arguments can be used to get a list of all remote controls known to lircd. If a name of a supported remote control is given as argument all buttons of the given remote control are listed in the reply packet. Have a look at <em>xrc</em> for an example how this can be used. </P> <P> There still remains to explain the format of lircd's reply packets. Here is a formal description of the packets: </P> <PRE> BEGIN <command> [SUCCESS|ERROR] [DATA n n lines of data] END</PRE> <P> The protocol guarantees that broadcasted messages won't interfere with reply packets. But broadcasts may appear at any point between packets. <em>command</em> is the command lircd is currently processing. Its an exact copy of the command the client application has sent. The only exception are SIGHUP packages where <em>command</em> is substituted with SIGHUP. Note that SIGHUP packages may appear just after you have sent a command to lircd, so you have to make sure you don't confuse them with replies. SIGHUP packages come without any further data while each reply to a command contains either SUCCESS or ERROR⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -