nanogui: Thread: Nano-X For PSP

> malpha from git is running without error.

Good.  Try replacing git mdemo.c with 0.91 mdemo,
it should compile.

If it doesn't work, then I
think the problem is somewher in src/mwin.
It seems that it is failing before drawing the arc
segment is drawn, but after the win32 combo box
and edit box are drawn.  You will want to
comment out the "CreateWindowEx" calls
in mdemo.c::CreateAppWindow() and see
whether that stops the fault.  One of the controls
is causing the failure.


If it works, then the changed
mdemo if the culprit, and there's only two things
that have changed:

1. The new mdemo is using allocated extra window
bytes and stored via SetWindowLong.  There
may be an struct offset size issue.

2. Something to do with the random() routine
called in SetTimer().  Comment out the SetTimer()
call in the new mdemo.c.

Finally, try running some of the other nano-X
demos, like nxclock or nxeyes, nxroach, or
tuxchess.  These use a completely different
API and it would be nice to see whether they
work.  Note that the server is linked into the
application, so you can just run the binary
file alone, as in the mdemo/malpha case.

Regards,

Greg







===== Original Message =====

> When I use following file from git to replace 0.91 working code, mdemo
> will fail with the same result.
> The other parts is still 0.91 working code.
================
src/mwin dir
include/ dir
src/drivers/genfont.c
src/engine/devfont.c
================

> emulation is OK.
> mine is OK too.

mdemo uses images, perhaps that's an issue. Try
whether malpha runs.

Also, mdemo.c could have changed, see whether the working 0.91
mdemo works with the changed files.

There was a case where mdemo.c used floating point, make
sure that it's not defined in the file.

There's quite a few changes in the src/mwin dir, did
that have to be changed?

I'm thinking this could be related to image drawing or floating
point. Have you tried running any of the simpler nano-X
demos?

Regards,

Greg







I try to replace file one by one, by it too hard to locate the real file
which causes this issue.

There are great diffs in src/mwin and include dir.

2010-03-11



yut616



发件人： Greg Haerr
发送时间： 2010-03-11 11:46:49
收件人： ####@####.####
抄送：
主题： Re: Re: Re: [nanogui] Re: Nano-X For PSP
:I get a clean git code, and compile again, It could display the mdemo now,
but it hang the whole system (352) immediately, it needs to power off/on to
restart again.
Does it work on the simulator?
I've attached the diff of the difference between what
was in your 0.91 source that works, and my git
repository. There's not that much different.
I assume you're running the psp-build.sh to convert
the files properly.
I did notice on some of the config.psp files looks
like they possibly used mipsel compiler. Is that
the processor/compiler in use for psp?
: And the mdemo window does not display completely.
What do you mean, is it wrong colors, or what? Please
describe.
You could run some other programs instead, perhaps
demo2 or some other executables...
Note that the 0.91 working version, and my patch
now should bring up the psp debug window and
print "Microwindows init...". Is that happening?
:
: I will check this later.
:
: Attached file is another link error patch.
I've applied it. Funny - this was in the patch from the "working"
0.91a patch that works on your system. You will see it
in the attached patch. It's removed now. Again!
Regards,
Greg
:
:
:
: ======= 2010-03-11 04:34:04 您在来信中写道：=======
:
: >> I could run mdemo which built from attached code (0.91)
: >> on my PSP 3.52 system without any modification.
: >
: >> But I still could not run git code on my 3.52 system.
: >
: >I diffed the entire tree and applied the small changes,
: >try it again. Check to make sure that the mdemo file is
: >in fact being fully built and linked without errors. There
: >were some changes in the build process that could have
: >caused these to fail. Also, run src/contrib/psp-build.sh,
: >this is new.
: >
: >There really weren't many changes, other than an
: >enhanced kbd driver, and a CFLAGS change
: >in Makefile.rules: -D_PSP_W_VERSION=371
: >
: >Regards,
: >
: >Greg
: >
:
: = = = = = = = = = = = = = = = = = = = =
:
:
: 　　　　　　　　致
: 礼！
:
:
: ####@####.####
: ####@####.####
: 　　　　　　　　　　2010-03-11
:
--------------------------------------------------------------------------------
:
: --------------------------------------------------------------------- 
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####


--------------------------------------------------------------------- 
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####



---------------------------------------
购物券大派送！ 

YuTao - 

I have cleaned up mdemo.c for your debugging the
PSP port.  I have attached the new version from git.
It defaults to the older 3d graph demo, with timer.
This is set with:
#define GRAPH3D 1

If PSP has floating point, it should run as-is.

If it doesn't work, change the following:

#define TIMERDEMO    0

This will turn off the timer support.  This may be
our PSP port problem.




You can also go back to the original mdemo.c
showing win32 controls by doing:

#define GRAPH3D    0
#define CONTROLS   1

Then try running this with TIMERDEMO set to 0.
(this should work)

Then try running this with TIMEREMO set to 1.
If this fails, we know it's in the timer code,
which is in:

src/mwin/winmain.c::MsSelect()

Depending on which modes mdemo works or
fails, we should know the problem.  Since
nxclock doesn't update, it could be timer.

Regards,

Greg

> With your attached mdemo.c:
> the picture will follow the mouse to move.
> But the timer is still not work.

Ok - we know for sure that timers aren't working
for PSP for nano-X or mwin.  I have looked
at the code for src/nanox/srvmain.c::GsSelect()
and src/mwin/winmain.c::MwSelect() and can
see that they do NOT call the required
GdGetNextTimeout() and GdTimeout() functions,
so this was never implemented.

Now test mdemo.c with CONTROLS 1 and
TIMERDEMO 0.  Does it crash?  If not,
then we are fine, we just need to finish timers.
If it crashes, then this is what the first version
did, where the WM_TIMER callback is failing
and crashing.  (It may be just hanging, since
the timer never fires)


> x86 linux is fine for both.

Yes I have tested that.

Regards,

Greg





===== Original Message =====

--------------------------------------------------------------------- 
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.#### -

I have cleaned up mdemo.c for your debugging the
PSP port. I have attached the new version from git.
It defaults to the older 3d graph demo, with timer.
This is set with:
#define GRAPH3D 1

If PSP has floating point, it should run as-is.

If it doesn't work, change the following:

#define TIMERDEMO 0

This will turn off the timer support. This may be
our PSP port problem.




You can also go back to the original mdemo.c
showing win32 controls by doing:

#define GRAPH3D 0
#define CONTROLS 1

Then try running this with TIMERDEMO set to 0.
(this should work)

Then try running this with TIMEREMO set to 1.
If this fails, we know it's in the timer code,
which is in:

src/mwin/winmain.c::MsSelect()

Depending on which modes mdemo works or
fails, we should know the problem. Since
nxclock doesn't update, it could be timer.

Regards,

Greg





---------------------------------------
购物券大派送！ 

> 1. when set following:
CONTROLS 1 
TIMERDEMO 0
> It will hang the system as before. 

Ok, this means we have the original problem.
Try setting

ARCDEMO 0
USEBLIT 0

And see whether that works.

If it still fails, then we need to comment out,
successively, the child controls in CreateAppWindow():

CreateWindowEx(0L, APPCHILD,...

One of them is creating a control that is 
crashing the application.

Regards,

Greg

> 1. when set following:
CONTROLS 1 
TIMERDEMO 0
> It will hang the system as before. 

Try adding -DARCH_NEED_ALIGN32 to
your Arch.rules CFLAGS.  I notice this
is needed in LINUX-ARM architecture.

I'm not sure whether this is needed, but
it won't hurt.  It is used in mwin/winuser.c::SetWindowLong()

What processor is in the PSP?

Regards,

Greg

> 2. remark the whole section of child CreateWindowEx with "#if 
> CONTROLS_XXX" at line 516
> It will show all the dialog and works fine. mouse is fine.


Put them all back in, then comment out the CreateWindowEx
for:

"LISTBOX"

"EDIT"

"PROGBAR"

"BUTTON"

One of these is causing the problem.

Regards,

Greg 

> Everything goes fine when set " -DARCH_NEED_ALIGN32"  in PSP section of 
> Arch.rules.

I'll add that to git right now!


> Another lesson for  alignment.

Agreed.  Thanks for working this out.

It would still be interesting to know which control is
causing the problem.  I've been looking at them and
can't see where the SetWindowLong would have
been on a non-long boundary....

Regards,

Greg 

> I'd like to see you add a special thanks to ####@####.#### for 
> debug this issue in Changelog. :)

Done.  Thanks a lot for your debugging help!
Looks like we have a PSP port working!!

I don't have time now but I will look into the timer
issue and suggest some code to add.  We will
need to modify GsSelect() and MwSelect()
with calls to GdTimeout and GdGetNextTimeout(),
like the UNIX versions.

Let me know of any other issues.  The nano-X
applications for PSP should now have a window
manager working as well, right?

Regards,

Greg 

Hi Greg:

I have put some photos to web, please check attachment for the link.

Includes photos of nanox porting.

BTW:
Bookr: A document reader for the Sony PSP with native PDF rendering. (open source on sourceforge)

Maybe we could get some ideas from it.

2010-03-14 



yut616 



发件人： Greg Haerr 
发送时间： 2010-03-12  14:46:30 
收件人： YuTao 
抄送： nanogui 
主题： Re: Re: Re: [nanogui] Re: Nano-X For PSP 
> I'd like to see you add a special thanks to ####@####.#### for 
> debug this issue in Changelog. :)
Done.  Thanks a lot for your debugging help!
Looks like we have a PSP port working!!
I don't have time now but I will look into the timer
issue and suggest some code to add.  We will
need to modify GsSelect() and MwSelect()
with calls to GdTimeout and GdGetNextTimeout(),
like the UNIX versions.
Let me know of any other issues.  The nano-X
applications for PSP should now have a window
manager working as well, right?
Regards,
Greg 
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

: Includes photos of nanox porting.

Nice photos!  Does PSP have any filesystem, so
that we could bring in freetype or png library?



: Bookr: A document reader for the Sony PSP with native PDF rendering. (open 
source on sourceforge)
:
: Maybe we could get some ideas from it.

It uses a graphics library called Fitz, which I hadn't heard of.
There is an X11 version, so using NXLIB with nano-X could
work.

Regards,

Greg