nanogui: Thread: Flicker with dynamic images

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

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: ####@####.####
>
>

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: ####@####.####
>
>

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: ####@####.####
>
>
>   

Hi Ricardo,

Ricardo Jasinski wrote:
> Hi Robert,
>
> I believe the first thing to do would be switching to the latest CVS
> version from the repository. Many have found issues with the
> touchscreen library, and quite a few have been resolved from what I've
> seen recently on this list.
>   
I had switched from CVS to the Freescale version because the former's 
kernel doesn't support 320 (x) x 240 (h) LCD screen layout.  Not sure 
what to do about this...

> Secondly, could you easily run some tests using a higher frequency
> system clock? The fact that the artifacts appear at the bottom of the
> screen might suggest that the screen is not being updated as often as
> it should be. Alternatively, you could slow your system down and see
> if things gets worse.
>   
I'm not sure about how to do this, but I'll give it a shot.  I'll only 
be able to run slower, though - but if that makes things worse, that'll 
be useful!

> Third, you could try running the other demos, which might give us new
> insights into these issues - perhaps they are related to cpu usage,
> somehow?
>   
Okay, I'll give them a shot.  As I'm not sure what they are supposed to 
do, it's difficult to know how their performance agrees or differs from 
what they should be doing!  It's also difficult to describe how they 
fail (and by the way, they all do fail, as far as I can tell).  But I'll 
try to describe things as well as I can.

I won't be able to get to this until tomorrow, though, so I'm still open 
to other ideas...

Thanks,
-Bob

> Good luck,
>
> Ricardo.
>
>
> 2009/4/12 Robert S. Grimes ####@####.####
>   
>> 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: ####@####.####
>>
>>
>>     
>
>
>
>   

Hi Bob,

I had switched from CVS to the Freescale version because the former's kernel
> doesn't support 320 (x) x 240 (h) LCD screen layout.  Not sure what to do
> about this...
>

we are using a 600 x 800 (i.e., 600 pixels wide) LCD, which is not iirc a
default configuration. I remember we got down to two alternatives, hacking
the original source code (looking for XRES, YRES definitions) or simply
running "setportrait left" at system initialization. We've gone with this
second choice and it has worked ou well for us.

 Third, you could try running the other demos, which might give us new
>> insights into these issues - perhaps they are related to cpu usage,
>> somehow?
>>
>>
> Okay, I'll give them a shot.  As I'm not sure what they are supposed to do,
> it's difficult to know how their performance agrees or differs from what
> they should be doing!


You can compile the demos on any linux host and run them just to get a feel
for what they should look like. I think it is doable on a windows host as
well. In our company, we've downloaded a linux virtual machine and done all
the cross-compiling stuff from within it.

Good luck,

Ricardo.

Hi Bob,

I had switched from CVS to the Freescale version because the former's kernel
> doesn't support 320 (x) x 240 (h) LCD screen layout.  Not sure what to do
> about this...
>

we are using a 600 x 800 (i.e., 600 pixels wide) LCD, which is not iirc a
default configuration. I remember we got down to two alternatives, hacking
the original source code (looking for XRES, YRES definitions) or simply
running "setportrait left" at system initialization. We've gone with this
second choice and it has worked ou well for us.

 Third, you could try running the other demos, which might give us new
>> insights into these issues - perhaps they are related to cpu usage,
>> somehow?
>>
>>
> Okay, I'll give them a shot.  As I'm not sure what they are supposed to do,
> it's difficult to know how their performance agrees or differs from what
> they should be doing!


You can compile the demos on any linux host and run them just to get a feel
for what they should look like. I think it is doable on a windows host as
well. In our company, we've downloaded a linux virtual machine and done all
the cross-compiling stuff from within it.

Good luck,

Ricardo.

Hi All,

 I have tried with the CVS version and found the problem remains the
same. If possible can anyone please answer my queries below:

  1) In  the "src/config" file or other than "src/config" should i
want to mention my display size ( H 800 and V 480 ) ?

  2) Is there any hack in code to give the pressure value, if the
problem is pressure sensing is not done properly?

  3) All the demos are running exactly in display including demo's but
nxcal cannot read touch value and it remains the same for me, my x
axis co-ordinate "+" come exactly at the top left corner so display
size is taken properly.

  4) i have given printf statements in drivers mou_touchscreen.c and
saw the co-ordinates are not the same for driver x, y co-ordinates and
nano-x x,y co-ordinates, will this be a problem?

  I attached my config file with this mail.

Thanks
Franco

Hi Ricardo,


On Mon, 2009-04-13 at 08:18 -0300, Ricardo Jasinski wrote:
> Hi Robert,
> 
> I believe the first thing to do would be switching to the latest CVS
> version from the repository. Many have found issues with the
> touchscreen library, and quite a few have been resolved from what I've
> seen recently on this list.

I just realized something - what repository are you talking about?
LTIB, or microwindows?  I had assumed you meant LTIB, but now I'm not so
sure...

I've made no progress getting this to work, or even narrowing down where
the problem might be...

*sigh*

Hi Bob,

I meant the nano-X CVS repository. Instructions from
http://www.microwindows.org/CVS.html:

*Nano-X CVS Instructions:*

1. Set your CVSROOT environment variable
export ####@####.####
2. Run "cvs login" and use a password of "guest"
3. Run "cvs co microwin"
4. Watch the source tree spill onto your hard drive

Cheers,

Ricardo.


2009/4/15 Robert S. Grimes ####@####.####

> Hi Ricardo,
>
>
> On Mon, 2009-04-13 at 08:18 -0300, Ricardo Jasinski wrote:
> > Hi Robert,
> >
> > I believe the first thing to do would be switching to the latest CVS
> > version from the repository. Many have found issues with the
> > touchscreen library, and quite a few have been resolved from what I've
> > seen recently on this list.
>
> I just realized something - what repository are you talking about?
> LTIB, or microwindows?  I had assumed you meant LTIB, but now I'm not so
> sure...
>
> I've made no progress getting this to work, or even narrowing down where
> the problem might be...
>
> *sigh*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>


-- 
----------------------------------------------
Ricardo Pereira Jasinski
####@####.####
Tel: (41) 9955-2852

LME - Laboratório de Microeletrônica da UTFPR
   UTFPR Microelectronics Lab
   www.lme.cpdtt.cefetpr.br
   Tel: +55 41 3310 4756