Is libusb's lack of
support for
some Palms something specific that is being resolved, or is it more of
a
fundamental design issue?
I have a Z22 which doesn't support external storage, so I didn't know
that you
can sync files directly to sd cards in the palm; I was under the
impression
that you had to plug the sd card in directly and copy files with the
file
manager. Taking this into consideration, perhaps have the option that,
depending on the model and what it supports in terms of external media,
provide
a choice of where to install files (for each file installed) and block
certain
file types for unsupported devices.
I was referring to par, and while it isn't "purty", it does do the
job. Refining the process can be done at a later date, and figuring out
why it
works might help us in reverse-engineering other SplashData formats
(barring
any legal roadblocks).
My (probably faulty) concept for auto-detection works like this:
-ask the user for their model (Z22, Treo xxx, etc.) and connection type
(USB,
IR, Network, etc.)
-have a database of each model, how it connects etc.
-if necessary, load the visor module and add it to /etc/modules
-if model X is given, then try the sync with each of the 4 or however
many /dev
files it could be until it gets a sane response
-using the /dev file in the previous step, do a proper sync
There can't be that many new models released every year, so it
shouldn't be
hard to keep the database up-to-date. There probably is a problem with
this,
but I can't see one off the top of my head. Unless the device it uses
depends
on more that just the type of port and palm model?
I assume you mean the source code at: http://live.gnome.org/GnomePilot
I'll take a look at it as soon as I get the chance.
Evan
PS what bug-tracker does gnome-pilot use?
On Dec 27, 2007 5:15 PM, David A. Desrosiers <desrod gnu-designs com>
wrote:
On Thu, 2007-12-27
at 17:01
-0500, Evan wrote:
> I know it's fairly stable, but it's getting out-dated. I've heard
> various ideas being kicked around that I think are necessary but
that
> haven't gotten any work:
> - migrate from the visor module (deprecated) to hal in order
to
> support newer devices while maintaining support for older
ones
Not libusb does not support all USB-connected
Palm devices,
which is why
libusb is not the default for the library subsystem (you have to build
it with libusb support and do some other setup to get it configured on
your system).
> - prevent installation of non-prc/pdb files, as they cause errors
and
> lock-ups (this should be really easy?)
This too is going to be a problem with NVFS and
external
storage. I
regularly sync non-Palm files to my SD card using pilot-link's tools, so
forbidding them entirely isn't a good option.
Providing a logical method to send non-PalmOS files to external storage
(or error out) is a better solution.
> - automatically wrap pictures in pdb containers to make them
readable
> by
splash-photo
(somebody has already written a program to do this
> and released it under the mozilla licence, just requires some
> integration)
Last I knew, SplashData did not release their
storage format
or provide
any sort of API to write to. Do you have different information on the
matter?
There is a way to do this with par, but it's not purty..
./par c -a "stream" foo.jpg.pdb foo.jpg Foto Foto foo.jpg
> - run an auto-detect to determine which device, connection speed,
etc.
> to use rather than making the user enter it manually (should be
> easier when hal migration is complete)
Horse => Cart problem
How can you auto-detect which device you have, if you don't know the
right way to talk to it in order to connect and query that information
from the device?
Believe me, if this was easy, we'd have solved it years ago. The
problem
is that we have no documentation from any of the vendors, and the
devices they continue to ship, seem to have their own little
"quirks",
which some work on some endpoints, others want other endpoints, and the
timing and speeds are completely unpredictable (based on Palm-side CPU
speed, host CPU speed, connection type, driver subsystem, usb host
controller, and so on).
> I can program in java and .net and I'd be willing to learn c++ or
> whatever to implement some of these, but I don't know where to
begin.
Jump in, read the code, and get started. It's
all in C/C++
anyway, so if
you know Java, you should be able to understand the code enough to
close
existing bugs, or help implement features by adding patches to the
existing codebase.
--
David A. Desrosiers
desrod gnu-designs com
Skype...: 860-967-3820
