Fix some typos in some documents
This commit is contained in:
parent
ecdc00abea
commit
fa68c5cc9d
@ -356,14 +356,14 @@
|
||||
|
||||
<p>
|
||||
<sup>1</sup><small>NXMU and NXSU are interchangeable other than (1) certain start-up
|
||||
and initializeation APIs (as described below), and (2) timing. With NXSU, NX APIs
|
||||
and initialization APIs (as described below), and (2) timing. With NXSU, NX APIs
|
||||
execute immediately; with NXMU, NX APIs defer and serialize the operations and, hence,
|
||||
introduce different timing and potential race conditions that you would not experience
|
||||
with NXSU.</small>
|
||||
</p>
|
||||
|
||||
<p><b>NXNULL?</b>
|
||||
At one time, I also envisoned a <i>NULL</i> front-end that did not support windowing
|
||||
At one time, I also envisioned a <i>NULL</i> front-end that did not support windowing
|
||||
at all but, rather, simply provided the entire framebuffer or LCD memory as one dumb window.
|
||||
This has the advantage that the same NX APIs can be used on the one dumb window as
|
||||
for the other NX windows.
|
||||
@ -765,7 +765,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
|
||||
<p>
|
||||
<b>Description:</b>
|
||||
In the general case, a line with width can be represented as a parallelogram with a triangle at the top and bottom.
|
||||
Triangles and parallelograms are both degenerate versions of a trapeziod.
|
||||
Triangles and parallelograms are both degenerate versions of a trapezoid.
|
||||
This function breaks a wide line into triangles and trapezoids.
|
||||
This function also detects other degenerate cases:
|
||||
</p>
|
||||
@ -777,7 +777,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
|
||||
If <code>x1 == x2</code> then the line is vertical and also better represented as a rectangle.
|
||||
</li>
|
||||
<li>
|
||||
If the width of the line is 1, then there are no triangles at the top and bottome
|
||||
If the width of the line is 1, then there are no triangles at the top and bottom
|
||||
(this may also be the case if the width is narrow and the line is near vertical).
|
||||
</li>
|
||||
<li>
|
||||
@ -1321,7 +1321,7 @@ int nx_eventnotify(NXHANDLE handle, int signo);
|
||||
the client must observe the rules for using <code>mq_notifiy()</code>:
|
||||
<ul>
|
||||
<li>
|
||||
Only one event is signaled. Upon receipt of the signal, if the client
|
||||
Only one event is signalled. Upon receipt of the signal, if the client
|
||||
wishes further notifications, it must call <code>nx_eventnotify()</code> again.
|
||||
</li>
|
||||
<li>
|
||||
@ -1425,7 +1425,7 @@ int nx_requestbkgd(NXHANDLE handle,
|
||||
<ul>
|
||||
<li>
|
||||
If you want to implement a windowless solution. The single screen
|
||||
can be used to creat a truly simple graphic environment. In this
|
||||
can be used to create a truly simple graphic environment. In this
|
||||
case, you should probably also de-select <code>CONFIG_NX_MULTIUSER</code> as well.
|
||||
</li>
|
||||
<li>
|
||||
@ -3430,7 +3430,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
|
||||
That interface may be driven by window callback functions so that keyboard input <i>only</i> goes to the top window.
|
||||
<dt><code>CONFIG__NXCONSOLE_KBDBUFSIZE</code>:
|
||||
<dd>If <code>CONFIG_NXCONSOLE_NXKBDIN</code> is enabled, then this value may be used to
|
||||
define the size of the per-window keyboar input buffer. Default: 16
|
||||
define the size of the per-window keyboard input buffer. Default: 16
|
||||
<dt><code>CONFIG_NXCONSOLE_NPOLLWAITERS</code>:
|
||||
<dd>The number of threads that can be waiting for read data available.
|
||||
Default: 4
|
||||
@ -3473,7 +3473,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
|
||||
<li>
|
||||
<p>
|
||||
Use the <i>bdf-converter</i> program to convert the BDF font to the NuttX font format.
|
||||
This will result in a C header file containing defintions.
|
||||
This will result in a C header file containing definitions.
|
||||
That header file should be installed at, for example, <code>graphics/nxfonts/nxfonts_myfont.h</code>.
|
||||
</p>
|
||||
</li>
|
||||
|
@ -723,7 +723,7 @@ int execv(FAR const char *path, FAR char *const argv[]);
|
||||
<p>
|
||||
Note the inefficiency when <code>execv()</code> or <code>execl()</code> is called in the normal, two-step process:
|
||||
(1) first call <code>vfork()</code> to create a new thread, then (2) call <code>execv()</code> or <code>execl()</code> to replace the new thread with a program from the file system.
|
||||
Since the new thread will be terminated by the <code>execv()</code> or <code>execl()</code> call, it really served no purpose other than to support Unix compatility.
|
||||
Since the new thread will be terminated by the <code>execv()</code> or <code>execl()</code> call, it really served no purpose other than to support Unix compatibility.
|
||||
</p>
|
||||
<p>
|
||||
The non-standard binfmt function <code>exec()</code> needs to have (1) a symbol table that provides the list of symbols exported by the base code, and (2) the number of symbols in that table.
|
||||
@ -1000,7 +1000,7 @@ int posix_spawn_file_actions_destroy(FAR posix_spawn_file_actions_t *file_action
|
||||
</pre></ul>
|
||||
<p>
|
||||
<b>Description:</b>
|
||||
The <code>posix_spawn_file_actions_destroy()</code> function destroys the object referenced by <code>file_actions</code> which was previously initializeed by <code>posix_spawn_file_actions_init()</code>, returning any resources obtained at the time of initialization to the system for subsequent reuse.
|
||||
The <code>posix_spawn_file_actions_destroy()</code> function destroys the object referenced by <code>file_actions</code> which was previously initialized by <code>posix_spawn_file_actions_init()</code>, returning any resources obtained at the time of initialization to the system for subsequent reuse.
|
||||
A <code>posix_spawn_file_actions_t</code> may be reinitialized after having been destroyed, but must not be reused after destruction, unless it has been reinitialized.
|
||||
</p>
|
||||
<p>
|
||||
@ -1931,8 +1931,8 @@ interface of the same name.
|
||||
|
||||
<p>
|
||||
<b>Description:</b>
|
||||
<code>sched_rr_get_interval()</code> writes the timeslice interval
|
||||
for task identified by <code>pid</code> into the timespec structure
|
||||
<code>sched_rr_get_interval()</code> writes the timeslice interval
|
||||
for task identified by <code>pid</code> into the timespec structure
|
||||
pointed to by <code>interval</code>. If pid is zero, the timeslice
|
||||
for the calling process is written into 'interval. The
|
||||
identified process should be running under the SCHED_RR
|
||||
|
Loading…
Reference in New Issue
Block a user