Subject:
Re: [nanogui] Flicker with dynamic images
From:
"Robert S. Grimes" ####@####.####
Date:
13 Apr 2009 14:42:50 -0000
Message-Id: <49E34F66.7050609@rcn.com>
Hi Vladimir,
I was working with the CVS, but its kernel for the mcf5329 is older that
the one I have, and more importantly, doesn't support 320(w) x 240 (h) -
only 240x320 - which doesn't match my hardware. At least, that was the
case about a month ago.
Oddly, when I did use the other kernel with the (misconfigured)
settings, I believe I still saw the flickering.
So I'm still not sure what to do now!
Thanks,
-Bob
Vladimir Ananiev wrote:
> Just try to use CVS version of Nano-X, personally I have never seen such issues.
>
> On Mon, Apr 13, 2009 at 8:26 AM, Franco Chalissery
> ####@####.#### wrote:
>
>> Hi,
>>
>> I have the same issue which i have posted in the group, anyways for
>> me the mouse pointer moves here and there irrespective of the touch
>> made by the stylus. I think there is something to be done with the
>> sensitivity or pressure reading . I think we are on the same boat ;-).
>>
>> As a you have addressed as launcher works it is same for me also.
>> screen saver will also comes up but no input will be taken.
>>
>> -Thanks
>> Franco
>>
>> On 4/13/09, Robert S. Grimes ####@####.#### wrote:
>>
>>> Hi,
>>>
>>> I'm working with a board derived from the Freescale/LogicPD mcf5329
>>> evaluation board, and using the microwindows-0.90 package which is
>>> included in ltib-cf_nommu-20081215 from Freescale's web site. The
>>> framebuffer (kernel is linux-2.6.26) is set up for a 320 wide by 240
>>> high LCD. The penguin shows fine on power-up.
>>>
>>> But, when I try to run some of the demo apps, I get mixed results at
>>> best. As a good example of exactly where I'm at, if I
>>> run /usr/nanox/launcher.sh, I get what appears to be a 3 x 3 matrix of
>>> icons, presumably for launching other demo apps; the icons included are
>>> (top row) Tetrix, Slider, Terminal; (middle row) Clock, Magnifier,
>>> Scribble, (bottom row) Roach, Tux, and NXEyes. This matrix has its
>>> lower left corner aligned with the lower left corner of the screen, and
>>> does not occupy the entire screen; the remainder (about the top 25% and
>>> the rightmost 10%) seems to be some patterned background. All this
>>> appears good - I say "appears" as I'm not really sure what to expect.
>>> However, there is a big problem - the bottom ~20% of the screen has a
>>> flicker that exhibits itself as random row-wide artifacts. What I mean
>>> is that it seems some rows really are not being drawn - for example, row
>>> 200 might be drawn, row 201 gets skipped, and row 202 gets drawn where
>>> 201 should be. I say this because it appears that the labels of the
>>> bottom three icons (i.e. Roach, Tux, and NXEyes jump up and down a row
>>> or two. The rest of the display is rock-solid.
>>>
>>> After playing with this a while, I've discovered something. After about
>>> 15 seconds, the launcher.sh demo goes into a random screensaver mode.
>>> Some screensavers look really good, such as a "searchlight" that
>>> illuminates a small circle that is moved over the display, the rest of
>>> which is black - simulating a flashlight searching in a darkened room.
>>> For this screensaver, every thing is sharp, and there is no flicker
>>> whatsoever. Other screensavers, such as one that looks like lighting
>>> flashes, exhibits the flicker over large portions of the display - not
>>> just the bottom portion.
>>>
>>> Other screensavers show either extreme, or behavior in between them.
>>> What seems to be going on is that the more dynamic the graphics, the
>>> more the flicker is exhibited. Put another way, the more static the
>>> display, the less flicker is noticed. I would expect that a totally
>>> static display might well show no flicker whatsoever. (Note: I don't
>>> know if the launcher.sh main screen is indeed fully static - it would
>>> appear to be, but perhaps something at the very bottom isn't).
>>>
>>> This would seem to be timing related or something, but I haven't been
>>> able to find anything amiss in the stock code. I did come across
>>> something regarding priority of the LCD controller on the internal
>>> crossbar switch, but it appears that it has already been elevated to the
>>> highest priority by the kernel.
>>>
>>> I'm completely stumped by this - anyone have any ideas on what might be
>>> amiss, or what to investigate?
>>>
>>> Thanks,
>>> -Bob
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ####@####.####
>>> For additional commands, e-mail: ####@####.####
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>
