Greg Haerr ha scritto:
Carlo's response regarding the OS framebuffer driver sounds
like something that can definitely be related to visual strangeness.
Notice this also applies to a system where there isn't really
a memory-mapped framebuffer, but some other mechanism
for drawing.
Regards,
Greg
Hi, Greg.
I digged a bit more on the problem of my framebuffer - lcd latency.
My embedded system has a framebuffer driver which reads /dev/fb0 and
writes commands to the lcd controller either automatically (i.e.
periodically) or on demand (via ioctl in user space). Writing directly
to /dev/fb0 results into an immediate and total refresh of the lcd
image, either with the driver working periodically and on demand.
I have several user space processes, and only one of them (let's call it
process #1) is statically linked to and uses nano-x libs (with
LINK_APP_INTO_SERVER = Y).
- 1st scenario: driver periodically reading /dev/fb0 and writing to the
lcd controller, process #1 calls nano-x primitives to draw objects (e.g.
via GrCopyArea) and goes to sleep, no other processes [R]un during and
after process #1 is scheduled. The result is (often but not always) a
partial lcd refresh followed by the refresh completion on the successive
periodic driver read/write.
- 2nd scenario: periodic driver r/w disabled, process #1 calls nano-x
primitives, sends via ioctl to /dev/fb0 the refresh command and goes to
sleep. No change results on the lcd. It's necessary to send another
ioctl to see the total lcd refresh.
- 3rd scenario: periodic driver r/w disabled, process #1 calls nano-x
primitives, calls sched_yield() to release cpu (but all other processes
aren't waiting to be scheduled and continue to sleep), sends via ioctl
to /dev/fb0 the refresh command and goes to sleep. No change results on
the lcd. As above, it's necessary to send another ioctl to see the total
lcd refresh.
- Last and resolving scenario: periodic driver r/w disabled, process #1
calls nano-x primitives, sends a message to process #2 and calls
sched_yield(), process #2 is scheduled, catches the message, does
nothing more and goes to sleep, process #1 wakes up again immediately
and sends via ioctl the refresh command and goes to sleep. The LCD
refresh is always immediate and complete.
I didn't investigate into nano-x code deeply, but I suppose that the
user space nano-x API calls are queued and not necessarily immediately
executed if the scheduler doesn't deal with some kind of process
rescheduling.
Best regards,
--
Carlo Zinato
Viscount International S.p.A.
R&D Labs, Ancona, Italy
Tel. & fax 0039 071 2905127/2905142
[EMAIL PROTECTED]
No virus found in this outgoing message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.4.1/1515 - Release Date: 23/06/2008 19.16
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
