Skip to content

L
linux
Commit c02dc9a8 authored by Andrew Morton's avatar Andrew Morton Committed by Linus Torvalds
Browse files
Options

[PATCH] Consistently use quotes for SGML attributes 

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Hans Ulrich Niedermann <linux-kernel@n-dimensional.de>

doc patch: Consistently use quotes for SGML attributes This makes it
possible to process the SGML files without SHORTTAG YES.
parent 2b5f9408
Show whitespace changes
Inline Side-by-side
Showing with 98 additions and 98 deletions
Documentation/DocBook/kernel-hacking.tmpl
View file @ c02dc9a8
......@@ -204,11 +204,11 @@
</para>
<para>
<filename class=headerfile>include/linux/interrupt.h</filename> lists the
<filename class="headerfile">include/linux/interrupt.h</filename> lists the
different BH's. No matter how many CPUs you have, no two BHs will run at
the same time. This made the transition to SMP simpler, but sucks hard for
scalable performance. A very important bottom half is the timer
BH (<filename class=headerfile>include/linux/timer.h</filename>): you
BH (<filename class="headerfile">include/linux/timer.h</filename>): you
can register to have it call functions for you in a given length of time.
</para>
......@@ -224,7 +224,7 @@
</para>
<para>
tasklets (<filename class=headerfile>include/linux/interrupt.h</filename>)
tasklets (<filename class="headerfile">include/linux/interrupt.h</filename>)
are like softirqs, except they are dynamically-registrable (meaning you
can have as many as you want), and they also guarantee that any tasklet
will only run on one CPU at any time, although different tasklets can
......@@ -241,7 +241,7 @@
<para>
You can tell you are in a softirq (or bottom half, or tasklet)
using the <function>in_softirq()</function> macro
(<filename class=headerfile>include/asm/hardirq.h</filename>).
(<filename class="headerfile">include/asm/hardirq.h</filename>).
</para>
<caution>
<para>
......@@ -330,7 +330,7 @@ asmlinkage long sys_mycall(int arg)
You create a character device and implement an appropriate ioctl
for it. This is much more flexible than system calls, doesn't have
to be entered in every architecture's
<filename class=headerfile>include/asm/unistd.h</filename> and
<filename class="headerfile">include/asm/unistd.h</filename> and
<filename>arch/kernel/entry.S</filename> file, and is much more
likely to be accepted by Linus.
</para>
......@@ -343,7 +343,7 @@ asmlinkage long sys_mycall(int arg)
<para>
Inside the ioctl you're in user context to a process. When a
error occurs you return a negated errno (see
<filename class=headerfile>include/linux/errno.h</filename>),
<filename class="headerfile">include/linux/errno.h</filename>),
otherwise you return <returnvalue>0</returnvalue>.
</para>
......@@ -429,7 +429,7 @@ cond_resched(); /* Will sleep */
<sect1 id="routines-printk">
<title>
<function>printk()</function>
<filename class=headerfile>include/linux/kernel.h</filename>
<filename class="headerfile">include/linux/kernel.h</filename>
</title>
<para>
......@@ -447,7 +447,7 @@ printk(KERN_INFO "i = %u\n", i);
</programlisting>
<para>
See <filename class=headerfile>include/linux/kernel.h</filename>;
See <filename class="headerfile">include/linux/kernel.h</filename>;
for other KERN_ values; these are interpreted by syslog as the
level. Special case: for printing an IP address use
</para>
......@@ -487,7 +487,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<function>get_user()</function>
/
<function>put_user()</function>
<filename class=headerfile>include/asm/uaccess.h</filename>
<filename class="headerfile">include/asm/uaccess.h</filename>
</title>
<para>
......@@ -525,7 +525,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-kmalloc">
<title><function>kmalloc()</function>/<function>kfree()</function>
<filename class=headerfile>include/linux/slab.h</filename></title>
<filename class="headerfile">include/linux/slab.h</filename></title>
<para>
<emphasis>[MAY SLEEP: SEE BELOW]</emphasis>
......@@ -593,10 +593,10 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<para>
If you are allocating at least <constant>PAGE_SIZE</constant>
(<filename class=headerfile>include/asm/page.h</filename>) bytes,
(<filename class="headerfile">include/asm/page.h</filename>) bytes,
consider using <function>__get_free_pages()</function>
(<filename class=headerfile>include/linux/mm.h</filename>). It
(<filename class="headerfile">include/linux/mm.h</filename>). It
takes an order argument (0 for page sized, 1 for double page, 2
for four pages etc.) and the same memory priority flag word as
above.
......@@ -619,13 +619,13 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<para>
Before inventing your own cache of often-used objects consider
using a slab cache in
<filename class=headerfile>include/linux/slab.h</filename>
<filename class="headerfile">include/linux/slab.h</filename>
</para>
</sect1>
<sect1 id="routines-current">
<title><function>current</function>
<filename class=headerfile>include/asm/current.h</filename></title>
<filename class="headerfile">include/asm/current.h</filename></title>
<para>
This global variable (really a macro) contains a pointer to
......@@ -638,8 +638,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-udelay">
<title><function>udelay()</function>/<function>mdelay()</function>
<filename class=headerfile>include/asm/delay.h</filename>
<filename class=headerfile>include/linux/delay.h</filename>
<filename class="headerfile">include/asm/delay.h</filename>
<filename class="headerfile">include/linux/delay.h</filename>
</title>
<para>
......@@ -652,7 +652,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-endian">
<title><function>cpu_to_be32()</function>/<function>be32_to_cpu()</function>/<function>cpu_to_le32()</function>/<function>le32_to_cpu()</function>
<filename class=headerfile>include/asm/byteorder.h</filename>
<filename class="headerfile">include/asm/byteorder.h</filename>
</title>
<para>
......@@ -675,7 +675,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-local-irqs">
<title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
<filename class=headerfile>include/asm/system.h</filename>
<filename class="headerfile">include/asm/system.h</filename>
</title>
<para>
......@@ -690,7 +690,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-softirqs">
<title><function>local_bh_disable()</function>/<function>local_bh_enable()</function>
<filename class=headerfile>include/linux/interrupt.h</filename></title>
<filename class="headerfile">include/linux/interrupt.h</filename></title>
<para>
These routines disable soft interrupts on the local CPU, and
......@@ -703,7 +703,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-processorids">
<title><function>smp_processor_id</function>()
<filename class=headerfile>include/asm/smp.h</filename></title>
<filename class="headerfile">include/asm/smp.h</filename></title>
<para>
<function>smp_processor_id()</function> returns the current
......@@ -715,7 +715,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-init">
<title><type>__init</type>/<type>__exit</type>/<type>__initdata</type>
<filename class=headerfile>include/linux/init.h</filename></title>
<filename class="headerfile">include/linux/init.h</filename></title>
<para>
After boot, the kernel frees up a special section; functions
......@@ -738,7 +738,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-init-again">
<title><function>__initcall()</function>/<function>module_init()</function>
<filename class=headerfile>include/linux/init.h</filename></title>
<filename class="headerfile">include/linux/init.h</filename></title>
<para>
Many parts of the kernel are well served as a module
(dynamically-loadable parts of the kernel). Using the
......@@ -768,7 +768,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-moduleexit">
<title> <function>module_exit()</function>
<filename class=headerfile>include/linux/init.h</filename> </title>
<filename class="headerfile">include/linux/init.h</filename> </title>
<para>
This macro defines the function to be called at module removal
......@@ -781,7 +781,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
<sect1 id="routines-module-use-counters">
<title> <function>MOD_INC_USE_COUNT</function>/<function>MOD_DEC_USE_COUNT</function>
<filename class=headerfile>include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/module.h</filename></title>
<para>
These manipulate the module usage count, to protect against
......@@ -839,7 +839,7 @@ foo_open (...)
<chapter id="queues">
<title>Wait Queues
<filename class=headerfile>include/linux/wait.h</filename>
<filename class="headerfile">include/linux/wait.h</filename>
</title>
<para>
<emphasis>[SLEEPS]</emphasis>
......@@ -874,7 +874,7 @@ foo_open (...)
There is a macro to do this:
<function>wait_event_interruptible()</function>
<filename class=headerfile>include/linux/sched.h</filename> The
<filename class="headerfile">include/linux/sched.h</filename> The
first argument is the wait queue head, and the second is an
expression which is evaluated; the macro returns
<returnvalue>0</returnvalue> when this expression is true, or
......@@ -900,7 +900,7 @@ foo_open (...)
<para>
Call <function>wake_up()</function>
<filename class=headerfile>include/linux/sched.h</filename>;,
<filename class="headerfile">include/linux/sched.h</filename>;,
which will wake up every process in the queue. The exception is
if one has <constant>TASK_EXCLUSIVE</constant> set, in which case
the remainder of the queue will not be woken.
......@@ -915,7 +915,7 @@ foo_open (...)
Certain operations are guaranteed atomic on all platforms. The
first class of operations work on <type>atomic_t</type>
<filename class=headerfile>include/asm/atomic.h</filename>; this
<filename class="headerfile">include/asm/atomic.h</filename>; this
contains a signed integer (at least 24 bits long), and you must use
these functions to manipulate or read atomic_t variables.
<function>atomic_read()</function> and
......@@ -943,7 +943,7 @@ foo_open (...)
The second class of atomic operations is atomic bit operations on a
<type>long</type>, defined in
<filename class=headerfile>include/asm/bitops.h</filename>. These
<filename class="headerfile">include/asm/bitops.h</filename>. These
operations generally take a pointer to the bit pattern, and a bit
number: 0 is the least significant bit.
<function>set_bit()</function>, <function>clear_bit()</function>
......@@ -982,7 +982,7 @@ foo_open (...)
<sect1 id="sym-exportsymbols">
<title><function>EXPORT_SYMBOL()</function>
<filename class=headerfile>include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/module.h</filename></title>
<para>
This is the classic method of exporting a symbol, and it works
......@@ -995,7 +995,7 @@ foo_open (...)
<sect1 id="sym-exportsymbols-gpl">
<title><function>EXPORT_SYMBOL_GPL()</function>
<filename class=headerfile>include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/module.h</filename></title>
<para>
Similar to <function>EXPORT_SYMBOL()</function> except that the
......@@ -1012,7 +1012,7 @@ foo_open (...)
<sect1 id="conventions-doublelinkedlist">
<title>Double-linked lists
<filename class=headerfile>include/linux/list.h</filename></title>
<filename class="headerfile">include/linux/list.h</filename></title>
<para>
There are three sets of linked-list routines in the kernel
......@@ -1039,7 +1039,7 @@ foo_open (...)
<para>
The filesystem code uses <function>ERR_PTR()</function>
<filename class=headerfile>include/linux/fs.h</filename>; to
<filename class="headerfile">include/linux/fs.h</filename>; to
encode a negative error number into a pointer, and
<function>IS_ERR()</function> and <function>PTR_ERR()</function>
to get it back out again: avoids a separate pointer parameter for
......
Documentation/DocBook/kernel-locking.tmpl
View file @ c02dc9a8
......@@ -87,7 +87,7 @@
<table>
<title>Expected Results</title>
<tgroup cols=2 align=left>
<tgroup cols="2" align="left">
<thead>
<row>
......@@ -133,7 +133,7 @@
<table>
<title>Possible Results</title>
<tgroup cols=2 align=left>
<tgroup cols="2" align="left">
<thead>
<row>
<entry>Instance 1</entry>
......@@ -222,14 +222,14 @@
<para>
There are two main types of kernel locks. The fundamental type
is the spinlock
(<filename class=headerfile>include/asm/spinlock.h</filename>),
(<filename class="headerfile">include/asm/spinlock.h</filename>),
which is a very simple single-holder lock: if you can't get the
spinlock, you keep trying (spinning) until you can. Spinlocks are
very small and fast, and can be used anywhere.
</para>
<para>
The second type is a semaphore
(<filename class=headerfile>include/asm/semaphore.h</filename>): it
(<filename class="headerfile">include/asm/semaphore.h</filename>): it
can have more than one holder at any time (the number decided at
initialization time), although it is most commonly used as a
single-holder lock (a mutex). If you can't get a semaphore,
......@@ -315,7 +315,7 @@
user context can be interrupted by a softirq, and secondly, the
critical region could be entered from another CPU. This is where
<function>spin_lock_bh()</function>
(<filename class=headerfile>include/linux/spinlock.h</filename>) is
(<filename class="headerfile">include/linux/spinlock.h</filename>) is
used. It disables softirqs on that CPU, then grabs the lock.
<function>spin_unlock_bh()</function> does the reverse. (The
'_bh' suffix is a historical reference to "Bottom Halves", the
......@@ -333,7 +333,7 @@
This works perfectly for <firstterm linkend="gloss-up"><acronym>UP
</acronym></firstterm> as well: the spin lock vanishes, and this macro
simply becomes <function>local_bh_disable()</function>
(<filename class=headerfile>include/linux/interrupt.h</filename>), which
(<filename class="headerfile">include/linux/interrupt.h</filename>), which
protects you from the softirq being run.
</para>
</sect1>
......@@ -463,7 +463,7 @@
<para>
This works perfectly for UP as well: the spin lock vanishes,
and this macro simply becomes <function>local_irq_disable()</function>
(<filename class=headerfile>include/asm/smp.h</filename>), which
(<filename class="headerfile">include/asm/smp.h</filename>), which
protects you from the softirq/tasklet/BH being run.
</para>
......@@ -545,7 +545,7 @@
</para>
<table>
<title>Table of Locking Requirements</title>
<TGROUP COLS=11>
<TGROUP COLS="11">
<TBODY>
<ROW>
<ENTRY></ENTRY>
......@@ -1026,7 +1026,7 @@ In practice, <type>atomic_t</type> would usually be used for
<structfield>refcnt</structfield>. There are a number of atomic
operations defined in
<filename class=headerfile>include/asm/atomic.h</filename>: these are
<filename class="headerfile">include/asm/atomic.h</filename>: these are
guaranteed to be seen atomically from all CPUs in the system, so no
lock is required. In this case, it is simpler than using spinlocks,
although for anything non-trivial using spinlocks is clearer. The
......@@ -1296,7 +1296,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
<table>
<title>Consequences</title>
<tgroup cols=2 align=left>
<tgroup cols="2" align="left">
<thead>
<row>
......@@ -1437,7 +1437,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
themselves (by calling <function>add_timer()</function> at the end
of their timer function). Because this is a fairly common case
which is prone to races, you should use <function>del_timer_sync()</function>
(<filename class=headerfile>include/linux/timer.h</filename>)
(<filename class="headerfile">include/linux/timer.h</filename>)
to handle this case. It returns the number of times the timer
had to be deleted before we finally stopped it from adding itself back
in.
......@@ -1749,7 +1749,7 @@ machines due to caching.
an exclusive lock. See <function>DEFINE_PER_CPU()</function>,
<function>get_cpu_var()</function> and
<function>put_cpu_var()</function>
(<filename class=headerfile>include/linux/percpu.h</filename>).
(<filename class="headerfile">include/linux/percpu.h</filename>).
</para>
<para>
......@@ -1757,7 +1757,7 @@ machines due to caching.
<type>local_t</type> type, and the
<function>cpu_local_inc()</function> and related functions,
which are more efficient than simple code on some architectures
(<filename class=headerfile>include/asm/local.h</filename>).
(<filename class="headerfile">include/asm/local.h</filename>).
</para>
<para>
......
Documentation/DocBook/mousedrivers.tmpl
View file @ c02dc9a8
......@@ -88,9 +88,9 @@
Each read from a bus mouse interface device returns a block of data.
The first three bytes of each read are defined as follows:
<table frame=all>
<table frame="all">
<title>Mouse Data Encoding</title>
<tgroup cols=2 align=left>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>Byte 0</entry>
......
Documentation/DocBook/parportbook.tmpl
View file @ c02dc9a8
......@@ -969,7 +969,7 @@ port->ops->write_data (port, d);
<para>
To recap, then:</para>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
......@@ -1387,7 +1387,7 @@ struct parport_operations {
<filename>/dev/parport0</filename>) allows you to:
</para>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
......@@ -1614,7 +1614,7 @@ struct parport_operations {
<filename>incluce/linux/parport.h</filename> and include:
</para>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem><para>
<constant>IEEE1284_MODE_COMPAT</constant></para></listitem>
<listitem><para>
......@@ -1713,7 +1713,7 @@ struct parport_operations {
affect future I/O operations. Available flags are:
</para>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem><para>
<constant>PP_FASTWRITE</constant></para></listitem>
<listitem><para>
......@@ -1759,7 +1759,7 @@ struct parport_operations {
<filename>include/linux/parport.h</filename>:
</para>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem><para>
<constant>PARPORT_CONTROL_STROBE</constant></para></listitem>
<listitem><para>
......
Documentation/DocBook/sis900.tmpl
View file @ c02dc9a8
......@@ -336,7 +336,7 @@ Those packages are listed in Document/Changes in kernel source
distribution. If you have to install the driver other than those bundled
in kernel release, you should have your driver file
<filename>sis900.c</filename> and <filename>sis900.h</filename>
copied into <filename class=directory>/usr/src/linux/drivers/net/</filename> first.
copied into <filename class="directory">/usr/src/linux/drivers/net/</filename> first.
There are two alternative ways to install the driver
</Para>
......
Documentation/DocBook/via-audio.tmpl
View file @ c02dc9a8
......@@ -227,7 +227,7 @@
<sect1 id="version191"><title>
Version 1.9.1
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
DSP read/write bugfixes from Thomas Sailer.
......@@ -252,7 +252,7 @@ Version 1.9.1
<sect1 id="version1115"><title>
Version 1.1.15
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Support for variable fragment size and variable fragment number (Rui
......@@ -325,7 +325,7 @@ Version 1.1.15
<sect1 id="version1114"><title>
Version 1.1.14
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Use VM_RESERVE when available, to eliminate unnecessary page faults.
......@@ -337,7 +337,7 @@ Version 1.1.14
<sect1 id="version1112"><title>
Version 1.1.12
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
mmap bug fixes from Linus.
......@@ -349,7 +349,7 @@ Version 1.1.12
<sect1 id="version1111"><title>
Version 1.1.11
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Many more bug fixes. mmap enabled by default, but may still be buggy.
......@@ -368,7 +368,7 @@ Version 1.1.11
<sect1 id="version1110"><title>
Version 1.1.10
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Many bug fixes. mmap enabled by default, but may still be buggy.
......@@ -380,7 +380,7 @@ Version 1.1.10
<sect1 id="version119"><title>
Version 1.1.9
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Redesign and rewrite audio playback implementation. (faster and smaller, hopefully)
......@@ -478,7 +478,7 @@ Version 1.1.9
<sect1 id="version118"><title>
Version 1.1.8
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Clean up interrupt handler output. Fixes the following kernel error message:
......@@ -501,7 +501,7 @@ Version 1.1.8
<sect1 id="version117"><title>
Version 1.1.7
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Fix module unload bug where mixer device left registered
......@@ -514,7 +514,7 @@ Version 1.1.7
<sect1 id="version116"><title>
Version 1.1.6
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Rewrite via_set_rate to mimic ALSA basic AC97 rate setting
......@@ -546,7 +546,7 @@ Version 1.1.6
<sect1 id="version115"><title>
Version 1.1.5
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Disable some overly-verbose debugging code
......@@ -573,7 +573,7 @@ Version 1.1.5
<sect1 id="version114"><title>
Version 1.1.4
</title>
<itemizedlist spacing=compact>
<itemizedlist spacing="compact">
<listitem>
<para>
Completed rewrite of driver. Eliminated SoundBlaster compatibility
......
Documentation/DocBook/videobook.tmpl
View file @ c02dc9a8
......@@ -176,8 +176,8 @@ int __init myradio_init(struct video_init *v)
<para>
The types available are
</para>
<table frame=all><title>Device Types</title>
<tgroup cols=3 align=left>
<table frame="all"><title>Device Types</title>
<tgroup cols="3" align="left">
<tbody>
<row>
<entry>VFL_TYPE_RADIO</><entry>/dev/radio{n}</><entry>
......@@ -299,8 +299,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
allows the applications to find out what sort of a card they have found and
to figure out what they want to do about it. The fields in the structure are
</para>
<table frame=all><title>struct video_capability fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_capability fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>name</><entry>The device text name. This is intended for the user.</>
......@@ -373,8 +373,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
<para>
The video_tuner structure has the following fields
</para>
<table frame=all><title>struct video_tuner fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_tuner fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>int tuner</><entry>The number of the tuner in question</entry>
......@@ -406,8 +406,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
</tgroup>
</table>
<table frame=all><title>struct video_tuner flags</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_tuner flags</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_TUNER_PAL</><entry>A PAL TV tuner</entry>
......@@ -429,8 +429,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
</tgroup>
</table>
<table frame=all><title>struct video_tuner modes</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_tuner modes</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_MODE_PAL</><entry>PAL Format</entry>
......@@ -580,8 +580,8 @@ static int current_volume=0;
<para>
Then we fill in the video_audio structure. This has the following format
</para>
<table frame=all><title>struct video_audio fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_audio fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>audio</><entry>The input the user wishes to query</>
......@@ -615,8 +615,8 @@ static int current_volume=0;
</tgroup>
</table>
<table frame=all><title>struct video_audio flags</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_audio flags</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_AUDIO_MUTE</><entry>The audio is currently muted. We
......@@ -633,8 +633,8 @@ static int current_volume=0;
</tgroup>
</table>
<table frame=all><title>struct video_audio modes</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_audio modes</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_SOUND_MONO</><entry>Mono sound</entry>
......@@ -862,8 +862,8 @@ static struct video_device my_camera
We use the extra video capability flags that did not apply to the
radio interface. The video related flags are
</para>
<table frame=all><title>Capture Capabilities</title>
<tgroup cols=2 align=left>
<table frame="all"><title>Capture Capabilities</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VID_TYPE_CAPTURE</><entry>We support image capture</>
......@@ -1204,8 +1204,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
inputs to the video card). Our example card has a single camera input. The
fields in the structure are
</para>
<table frame=all><title>struct video_channel fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_channel fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
......@@ -1227,8 +1227,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
</tbody>
</tgroup>
</table>
<table frame=all><title>struct video_channel flags</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_channel flags</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_VC_TUNER</><entry>Channel has a tuner.</entry>
......@@ -1238,8 +1238,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
</tbody>
</tgroup>
</table>
<table frame=all><title>struct video_channel types</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_channel types</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_TYPE_TV</><entry>Television input.</entry>
......@@ -1251,8 +1251,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
</tbody>
</tgroup>
</table>
<table frame=all><title>struct video_channel norms</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_channel norms</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>VIDEO_MODE_PAL</><entry>PAL encoded Television</entry>
......@@ -1337,8 +1337,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
for every other pixel in the image. The other common formats the interface
defines are
</para>
<table frame=all><title>Framebuffer Encodings</title>
<tgroup cols=2 align=left>
<table frame="all"><title>Framebuffer Encodings</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>GREY</><entry>Linear greyscale. This is for simple cameras and the
......@@ -1475,8 +1475,8 @@ static struct video_buffer capture_fb;
display. The video_window structure is used to describe the way the image
should be displayed.
</para>
<table frame=all><title>struct video_window fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>struct video_window fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>width</><entry>The width in pixels of the desired image. The card
......@@ -1512,8 +1512,8 @@ static struct video_buffer capture_fb;
<para>
Each clip is a struct video_clip which has the following fields
</para>
<table frame=all><title>video_clip fields</title>
<tgroup cols=2 align=left>
<table frame="all"><title>video_clip fields</title>
<tgroup cols="2" align="left">
<tbody>
<row>
<entry>x, y</><entry>Co-ordinates relative to the display</>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7