Fix banding on the R61580 LCD

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4136 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2011-12-05 19:59:10 +00:00
parent 71b618c639
commit dd328baad8

View File

@ -13,7 +13,7 @@
<h1><big><font color="#3c34ec"><i>NuttX Operating System<p>User's Manual</i></font></big></h1>
<p><small>by</small></p>
<p>Gregory Nutt<p>
<p>Last Updated: July 19, 2011</p>
<p>Last Updated: December 5, 2011</p>
</td>
</tr>
</table>
@ -1549,58 +1549,83 @@ interface of the same name.
<h3><a name="mqnotify">2.4.7 mq_notify</a></h3>
<p>
<b>Function Prototype:</b>
<b>Function Prototype:</b>
<pre>
#include &lt;mqueue.h&gt;
int mq_notify(mqd_t mqdes, const struct sigevent *notification);
</pre>
</p>
<p>
<b>Description:</b> If the &quot;notification&quot; input parameter
is not NULL, this function connects the task with the message queue such
that the specified signal will be sent to the task whenever the message
changes from empty to non-empty. One notification can be attached
to a message queue.
<b>Description:</b> If the <code>notification</code> input parameter
is not <code>NULL</code>, this function connects the task with the message queue such
that the specified signal will be sent to the task whenever the message
changes from empty to non-empty. One notification can be attached
to a message queue.
</p>
<p>
If &quot;notification&quot; is NULL, the attached notification
is detached (if it was held by the calling task) and the queue
is available to attach another notification.
If <code>notification</code>; is <code>NULL</code>, the attached notification
is detached (if it was held by the calling task) and the queue
is available to attach another notification.
</p>
<p>
When the notification is sent to the registered task, its registration
will be removed. The message queue will then be available for
registration.
When the notification is sent to the registered task, its registration
will be removed. The message queue will then be available for
registration.
<p>
<b>Input Parameters:</b>
<ul>
<li><i>mqdes</i>. Message queue descriptor
<li><i>notification</i>. Real-time signal structure containing:
<ul>
<li><i>sigev_notify</i>. Should be SIGEV_SIGNAL (but actually
ignored)
<li><i>sigev_signo</i>. The signo to use for the notification
<li><i>sigev_value</i>. Value associated with the signal
</ul>
</ul>
<b>Input Parameters:</b>
<ul>
<li>
<code>mqdes</code>. Message queue descriptor
</li>
<li><code>notification</code>. Real-time signal structure containing:
<ul>
<li><code>sigev_notify</code>. Should be SIGEV_SIGNAL (but actually ignored)
<li><code>sigev_signo</code>. The signo to use for the notification
<li><code>sigev_value</code>. Value associated with the signal
</ul>
</ul>
</p>
<p>
<b>Returned Values:</b> None.
<b>Returned Values:</b>
On success <code>mq_notify()</code> returns 0; on error, -1 is returned, with
<code>errno</code> set to indicate the error:
<ul>
<li>
<code>EBADF</code>. The descriptor specified in <code>mqdes</code> is invalid.
</li>
<li>
<code>EBUSY</code>. Another process has already registered to receive notification
for this message queue.
</li>
<li>
<code>EINVAL</code>. <code>sevp->sigev_notify</code> is not one of the permitted values; or
<code>sevp->sigev_notify</code> is <code>SIGEV_SIGNAL</code> and <code>sevp->sigev_signo</code> is not a
valid signal number.
</li>
<li>
<code>ENOMEM</code>. Insufficient memory.
</li>
</ul>
</p>
<p>
<b>Assumptions/Limitations:</b>
<b>Assumptions/Limitations:</b>
</p>
<p>
<b> POSIX Compatibility:</b> Comparable to the POSIX interface
of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>The notification signal will be sent to the registered task even if
another task is waiting for the message queue to become non-empty. This is
inconsistent with the POSIX specification which states, &quot;If a process
has registered for notification of message arrival at a message queue and
some process is blocked in <i>mq_receive</i> waiting to receive a message
when a message arrives at the queue, the arriving message shall satisfy the
appropriate <i>mq_receive()</i> ... The resulting behavior is as if the
message queue remains empty, and no notification shall be sent.&quot;
</ul>
<b>POSIX Compatibility:</b> Comparable to the POSIX interface of the same name.
Differences from the full POSIX implementation include:
<ul>
<li>
The notification signal will be sent to the registered task even if
another task is waiting for the message queue to become non-empty. This is
inconsistent with the POSIX specification which states, &quot;If a process
has registered for notification of message arrival at a message queue and
some process is blocked in <i>mq_receive</i> waiting to receive a message
when a message arrives at the queue, the arriving message shall satisfy the
appropriate <i>mq_receive()</i> ... The resulting behavior is as if the
message queue remains empty, and no notification shall be sent.&quot;
</li>
</ul>
</p>
<H3><a name="mqsetattr">2.4.8 mq_setattr</a></H3>