Use mdoc macros instead of man ones.
This commit is contained in:
parent
8aa6473f4a
commit
61d6e22ad7
|
@ -1,4 +1,4 @@
|
|||
.\" $NetBSD: speaker.4,v 1.7 2001/09/22 16:21:42 wiz Exp $
|
||||
.\" $NetBSD: speaker.4,v 1.8 2002/01/21 17:58:19 wiz Exp $
|
||||
.\"
|
||||
.\" Copyright (c) 1993 Christopher G. Demetriou
|
||||
.\" All rights reserved.
|
||||
|
@ -53,7 +53,9 @@ indication. Writes to the device are interpreted as 'play strings' in a
|
|||
simple ASCII melody notation. An ioctl() for tone generation at arbitrary
|
||||
frequencies is also supported.
|
||||
.Pp
|
||||
Sound-generation does \fInot\fR monopolize the processor; in fact, the driver
|
||||
Sound-generation does
|
||||
.Em not
|
||||
monopolize the processor; in fact, the driver
|
||||
spends most of its time sleeping while the PC hardware is emitting
|
||||
tones. Other processes may emit beeps while the driver is running.
|
||||
.Pp
|
||||
|
@ -82,8 +84,9 @@ Play strings are interpreted left to right as a series of play command groups;
|
|||
letter case is ignored. Play command groups are as follows:
|
||||
.Pp
|
||||
CDEFGAB -- letters A through G cause the corresponding note to be played in the
|
||||
current octave. A note letter may optionally be followed by an \fIaccidental
|
||||
sign\fR, one of # + or -; the first two of these cause it to be sharped one
|
||||
current octave. A note letter may optionally be followed by an
|
||||
.Em accidental sign ,
|
||||
one of # + or -; the first two of these cause it to be sharped one
|
||||
half-tone, the last causes it to be flatted one half-tone. It may also be
|
||||
followed by a time value number and by sustain dots (see below). Time values
|
||||
are interpreted as for the L command below;.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
.\" $NetBSD: st.4,v 1.20 2001/12/19 18:34:33 wiz Exp $
|
||||
.\" $NetBSD: st.4,v 1.21 2002/01/21 17:59:22 wiz Exp $
|
||||
.\"
|
||||
.\" Copyright (c) 1996
|
||||
.\" Julian Elischer <julian@freebsd.org>. All rights reserved.
|
||||
|
@ -248,7 +248,9 @@ Attempts to write past EOM and how EOM is reported are handled slightly
|
|||
differently based upon whether EARLY WARNING recognition is enabled in
|
||||
the driver.
|
||||
.Pp
|
||||
If EARLY WARNING recognitions is \fBnot\fR enabled, then detection
|
||||
If EARLY WARNING recognitions is
|
||||
.Em not
|
||||
enabled, then detection
|
||||
of EOM (as reported in SCSI Sense Data with an EOM indicator)
|
||||
causes the write operation to be flagged with I/O error (EIO).
|
||||
This has the effect for the user application of not knowing actually
|
||||
|
@ -256,12 +258,16 @@ how many bytes were read (since the return of the
|
|||
.Xr read 2
|
||||
system call is set to \(mi1).
|
||||
.Pp
|
||||
If EARLY WARNING recognition \fBis\fR enabled, then detection of EOM
|
||||
If EARLY WARNING recognition
|
||||
.Em is
|
||||
enabled, then detection of EOM
|
||||
(as reported in SCSI Sense Data with an EOM indicator)
|
||||
has no immediate effect except that
|
||||
the driver notes that EOM has been detected. If the write completing
|
||||
didn't transfer all data that was requested, then the residual count
|
||||
(counting bytes \fBnot\fR written)
|
||||
(counting bytes
|
||||
.Em not
|
||||
written)
|
||||
is returned to the user application. In any event, the next attempt
|
||||
to write (if that is the next action the user application takes)
|
||||
is immediately completed with no data transferred, and a residual
|
||||
|
|
Loading…
Reference in New Issue