Tasnim Ahmed writes:

> next vhl-tools was a good initiative but the main guy got in NDAs with
> pocketlinux, agendacomputing and the big name VTech, so he could post
> nothing more on the site obviously... a dead project.

I can neither confirm nor deny reports that I'm under NDA with any of those
organizations.  :-)

No, seriously, I've signed nothing that keeps me from doing interesting work
on Linux PDA platforms.  (When you do decide to deal with NDAs, always make
clear what you do *not* want to know.)  What mostly happened was three
things:

1) Lack of third party development.  It was a big effort to get all the
vhl-tools stuff together, and I'm not sure I could do such a thing again
soon after that.  I was hoping that there would be a lot of people stepping
up to help, and there weren't.  I don't blame anyone for this, nor am I
especially unhappy about it; it's just the state of the world.  The main
PocketLinux distribution was plagued by "only transvirtual knows how to do a
clean full rebuild from source" too.  So I wandered off and did other things
for a while.

I'm glad to see that people can make use of the material that's available on
vhl-tools.

2) I got interested in Squeak ( http://www.squeak.org/
http://www.huv.com/uSeeker/smalltalk/helio.html ), and as a result,
interested in possible systemic performance improvements for the Linux VR
devices.  You can see some of the results in the snow ABI.  But that kind of
toolchain/ABI work isn't very flashy, and it's had a low motivation factor
as well---after all, it's the kind of thing where you work all weekend on
the desktop Unix box and fire up the MIPS machine once at the end to verify
that things are still working.

3) Diablo 2 ate my life.

Also, my real paying job has been hectic.  My job doesn't have much to do
with building distributions for small Linux/MIPS boxes either :-)

If you'd like to add pgui stuff to the vhl-tools site or project, or start
hosting stuff there, let me know.  My usual policy on sourceforge projects
is "show me one good update, and I'll add you".

> microwindows is not for the helio. Huge libraries and speed issues.

I've always been mystified by the low performance of microwindows on the
Linux VR devices, relative to X and W.

Some of the library size problem is just SVR4 ABI; some of it is mwin's
decision to include drivers for all bitdepths in the libraries.  I haven't
looked at the numbers for this though.

> pocketlinux dropped helio and that was a good thing cuz it was more java
> less linux and only java on 75MHz was not going to impress anyone anyways.

PocketLinux did make some impressive contributions to Helio development.  I
don't know if we ever would have gotten the system booting (on real
hardware, not the emulator) without their efforts. They still have brownie
points with me.

I think that some of the insights from snow may be applicable to the
PocketLinux java system on the Helio.

> finally PicoGUI currently my pick and I would like to see it alive. The
> response time was perfect, better than VT-OS, tpcal always did work for me
> and pico-linux was no exception perfect calibration of the touch panel,
> however its a long way to go like virtual keyboard, grafitti recognition,
> 4bpp theme, silkscreen, buttons, and finally speaker and mic drivers.

pgui's architecture has always seemed like the right way to handle things on
small devices.  Well, at least a way that held promise and should be
experimented with.  I think I said as much on
http://vhl-tools.sourceforge.net/issues.html .  I didn't look at pgui much
earlier because it seemed like all the clients were written in perl, and
perl didn't fit very well on a Helio.

The trick to tpcal is that you need to move the pen around a little after
placing it on the screen the very first time.  This is because I did not
fully remove the averaging code from the VR41xx microwindows pen driver when
I cut&pasted it into the TX3912 mwin pen driver.  The first sample is
ignored, and the tx3912 kernel tp driver does not send multiple samples at
the same location the way the VR41xx panel drivers does.

> about 4bpp the kernel micah has used in the ROM has a 1bpp fbdev driver
> compiled in, and its a 2.4.0test1 kernel I saw 2.4.0test7 kernel on image
> available at www.kernelconcepts.de/helio with a 4bpp fbdev driver
> built in,
> 1bpp has VideoRAM=3KB and 4bpp has four times i.e. 12KB.

You should be able to choose 1bpp/4bpp by way of the kernel configuration.
It's hiding in make menuconfig, under video options.  The 1bpp option exists
because it made porting W and Squeak much easier; neither one had a good
4bpp linear greyscale driver.  But *everyone* supports monochrome linear
bitmaps.  So you should be able to just reconfig and rebuild.

Unless you're using a different kernel from what I was using.  Quite
possible.  To be honest, a lot of what I did surprises me now---"oh yeah, I
*did* write that".... :-/  Somebody was asking me about non-XIP kernels for
the Agenda VR3 and it took me a while to realize that I had written hfload
and really did understand what was going on.

Jay


_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel

Reply via email to