Subject:
Re: [nanogui] Re: Flicker with dynamic images
From:
"Robert S. Grimes" ####@####.####
Date:
30 Apr 2009 00:21:03 -0000
Message-Id: <1241050915.4108.19.camel@rsg.dvrdns.org>
Okay, here's my turn to eat a little of that old humble pie...
I no longer think that I'm ready for nano-X yet - seems there is
actually an issue with the framebuffer and/or my hardware. Attached is
a silly test program, which in pseudo-code goes like this:
test:
open framebuffer
write all zeros to it (i.e. erase the screen)
sleep(10) to allow inspection
lseek to beginning
write all ones to it (i.e. set all pixels white)
sleep(10)
lseek to beginning
write a pattern of 8x8 multi-colored boxes to screen
sleep(10)
close framebuffer
Running this shows a nice blank screen for 10 seconds, then a white
screen for 10 seconds, then finally some pretty boxes. Or at least,
that is what is supposed to happen.
What actually happens, sometimes, is that, sometimes it works, other
times the white screen shows the flicker/tearing/shearing throughout the
entire lower two-thirds of the screen. Of course, the black looks fine,
but surprisingly, the colored blocks also looks fine. Well, almost -
when the white shows the shearing, there is usually a small black
rectangle, maybe 3-4 pixels wide by 6-8 high, at the far left of the
screen, centered vertically about the first sheared line; this block is
also present on the white screen, along with an 6-8-pixel long vertical
black line at the same elevation, midway across the screen. I don't
know if that little line shows up with the colored boxes.
I don't thing there is anything wrong with my code - it's so simple -
but perhaps I'm missing something? Any ideas?
Thanks,
-Bob
P.S. I'm posting this here because of my existing topic; I'm also going
to describe this to the Freescale people, as it seems more in that
realm.
On Mon, 2009-04-27 at 17:19 -0700, Aaron J. Grier wrote:
> On Mon, Apr 27, 2009 at 08:34:19AM -0400, Robert S. Grimes wrote:
> > Aaron J. Grier wrote:
> > >have you attempted to write some small simple standalone nano-X
> > >programs to check the blit operations?
> > No, not yet - I kind of hoped the demos would serve that purpose.
> > I've been a bit reluctant to sort out the Makefile requirements, but I
> > suppose that's not terribly difficult, right? Is there a good sample
> > to start from?
>
> for this level of testing, you could get by just by adding the proper
> link flags to your standalone program. (-L and -l)
>
> the demos exercise things in aggregate -- it would be nice to know the
> smallest sequence of nano-X calls that demonstrate your shearing issues
> and work on a solution from there. I suspect this may not be a nano-X
> specific problem.
>
> > A tip from Aaron Grier led me to realize I could rule out (or in!) the
> > framebuffer as the culprit, by simply writing directly to it using
> > open(), lseek(), and write(). Doing so, I have been able to confirm
> > that the framebuffer appears to be working just fine. So I'm pretty
> > sure it ain't the hardware...
>
> the linux framebuffer driver mmap()s the framebuffer and writes to it
> directly. did you also check this with your standlone test? the
> framebuffer device driver may be doing additional locking / retrace for
> a write() vs direct mmap() access. doing repeated framebuffer writes in
> a tight loop may also be triggering problems.
>
> > >which low-level driver is nano-X using? (one of the stock fblin
> > >ones?)
> >
> > I believe so, but I'm not sure how to check that - how do I determine
> > which driver is in use? Or for that matter, which are available?
>
> (short brute force answer)
> trace through GdOpenScreen() and see where you end up. (:
>
> (longer brute force answer)
> what functions are pointed to in the global scrdev struct ?
>
[Content type text/x-csrc not shown. Download]
