tilp-devel — This list is intended to TiLP's developers, contributors and advanced users.

Re: [TiLP-devel] [tiemu-devel] More issues related to OS X (but not only)

[Kevin K. <kev...@ch...>]

> > * There's an issue with export?.h Romain, I'd like to discuss the proper
>
> it should have been fixed. I have compiled all stuffs with -fno-common and
> there were no errors.

Well, this (almost certainly) fixes the link failure on OS X, but there is 
still a problem: There's still only one TIEXPORT macro, controlled by all for 
TI*_EXPORT defines. This means that where e.g. libticalcs2 uses a function 
from libticables2, that function is declared as dllexport instead of 
dllimport. I wonder how and why this works, because it is clearly wrong. 
There needs to be a different export macro for each library, i.e.:
#ifdef TICABLES_EXPORT
#define TICABLESEXPORT __declspec(dllexport)
#else
#define TICABLESEXPORT __declspec(dllimport)
#endif
and then use TICABLESEXPORT instead of TIEXPORT throughout libticables2 (yes, 
this needs a global replace in each library).
Also, where are these TI*_EXPORT defined? In the M$VC projects only? These 
need to be defined from configure.ac too!
Taking this into account, it is a miracle that this works at all on Win32.

        Kevin Kofler

Re: [TiLP-devel] More issues related to OS X (but not only)

[Romain <ro...@li...>]

Hi,

> * There's an issue with export?.h Romain, I'd like to discuss the prope=
r

no problems with TiLP but TiEmu complains (mainly due to function pointer=
s).
Being fixed...

roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] More issues related to OS X (but not only)

[Romain <ro...@li...>]

Hi,

> * There's an issue with export?.h Romain, I'd like to discuss the prope=
r

it should have been fixed. I have compiled all stuffs with -fno-common an=
d
there were no errors.

>         Kevin Kofler

roms.

>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] More issues related to OS X (but not only)

[Romain <ro...@li...>]

Hi,

> * ZPedro mentioned that having libticables2 silently built without USB
> support
> when libusb isn't detected can be confusing and annoying. I agree, and

Fixed. A big warning message is displayed if libusb was not found.

> this is an issue for GNU/Linux too. What about requiring --disable-usb
> (or --without-libusb or something) to be passed explicitly to disable U=
SB

this flag already exists as --disable-SilverLink. I renamed it to
--disable-libusb.

roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] More issues related to OS X (but not only)

[Romain <ro...@li...>]

Hi,

> * ZPedro mentioned that having libticables2 silently built without USB
> support
> when libusb isn't detected can be confusing and annoying. I agree, and
> think
> this is an issue for GNU/Linux too. What about requiring --disable-usb
> (or --without-libusb or something) to be passed explicitly to disable U=
SB
> support, and erroring out if libusb is not found otherwise? Or what abo=
ut
> showing a Big Fat Warning at the end of configure, when everyone comes
> back
> to look at the screen before running make?

I fully agree. Will be fixed.

> * I'm going to remove the Project Builder (build/osx) projects, because

please do.

> * There's an issue with export?.h Romain, I'd like to discuss the prope=
r
> solution with you, lest I accidentally break M$VC again. In ZPedro's
> words:
>> libticonv does configure well, but it fails with multiply-defined
>> symbols
>> errors, where one version of each symbol is in TEXT const, and all
>> others in
>> DATA common. After checking the source files where these sybols
>> were "defined", I find out that they're normal initialised global vars
>> in
>> charset.c, but in the other files they are "imported" as uninitialised
>> global vars, since TIEXPORT, as I compile with gcc 4.0 (therefore ther=
e
>> is
>> the -fvisibility thing), is defined in as attribute(something) and
>> extern is
>> no longer there. While this works on some systems (I don't know, but I
>> don't
>> think it's allowed by the C standard), it doesn't work on OSX to have
>> one
>> module define const int a=3D0 and the others have const int a; (the la=
tter
>> is
>> put in a common section in the DATA segment, while the former is in TE=
XT
>> const, and the linker cannot redirect a reference to a symbol in the
>> DATA
>> segment to a symbol in the TEXT segment). I ended up hacking export4.h
>> to
>> put extern before the attribute stuff (could not remove the attribute
>> stuff
>> or put #if 0 for the condition before, or since -fvisibility is set to
>> hidden nothing would have been externally visible...) Of course, I get=
 a
>> warning that a global initialised var was declared extern, but at leas=
t
>> it
>> builds.
> I've always wondered what that "extern for some platforms only" mess wa=
s
> about. Really, extern is part of the C standard, and thus should be use=
d
> the
> same on all platforms. The current export?.h mixes up extern with
> visibility
> attributes, which are really unrelated issues. I can see how "extern" c=
an
> be
> related to dllimport (they're both importing symbols from somewhere), b=
ut
> not
> dllexport (or visibility)!
> By the way, this affects all libs, not just libticonv.

export?.h and stdint?.h were never a good solution for me. I will be
interested in providing a better solution but should be it easy?

roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] tilibs.h #ifdef mess cleaned up (was: Re: QMake

[Romain <ro...@li...>]

Hi,

> #include <ticonv.h>

OK for me (and better).

> Anyway, you're free to fix the tilibs.h headers and the other inclusion=
s

He is working fine in fact. I didn't see you replaced <tilp2/ticables.h>
by <ticables.h>.

No need to fix this header (better).

> Oh, and "Win32 =3D MinGW for you", well, not any more than Win32 =3D M$=
VC for
> you. ;-) Sorry, but I can't stand the:

I agree.

> IMHO, the different file system structure you picked for your
> M$VC/InnoSetup
> builds is already enough of a mess, we don't need a third.

I agree but I feel NSIS scripts as unreadable. The only advantage of NSIS
for me is cross-buildingof packages.

Flame-war closed ;-)

roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

[TiLP-devel] More issues related to OS X (but not only)

[Kevin K. <kev...@ch...>]

* ZPedro mentioned that having libticables2 silently built without USB support 
when libusb isn't detected can be confusing and annoying. I agree, and think 
this is an issue for GNU/Linux too. What about requiring --disable-usb 
(or --without-libusb or something) to be passed explicitly to disable USB 
support, and erroring out if libusb is not found otherwise? Or what about 
showing a Big Fat Warning at the end of configure, when everyone comes back 
to look at the screen before running make?

* I'm going to remove the Project Builder (build/osx) projects, because these 
haven't been updated since tilibs1 and don't work at all (there's none for 
libticonv, the ones for the other libs refer to no-longer-existing files 
etc.). People who want to resurrect these can always get them from the 
tilibs1 branches. For now, the supported way to build on OS X is the same as 
for all other *nixes and MinGW/MSYS (through the normal build system, i.e. 
currently autotools).

* There's an issue with export?.h Romain, I'd like to discuss the proper 
solution with you, lest I accidentally break M$VC again. In ZPedro's words:
> libticonv does configure well, but it fails with multiply-defined symbols
> errors, where one version of each symbol is in TEXT const, and all others in
> DATA common. After checking the source files where these sybols
> were "defined", I find out that they're normal initialised global vars in
> charset.c, but in the other files they are "imported" as uninitialised
> global vars, since TIEXPORT, as I compile with gcc 4.0 (therefore there is
> the -fvisibility thing), is defined in as attribute(something) and extern is
> no longer there. While this works on some systems (I don't know, but I don't
> think it's allowed by the C standard), it doesn't work on OSX to have one
> module define const int a=0 and the others have const int a; (the latter is
> put in a common section in the DATA segment, while the former is in TEXT
> const, and the linker cannot redirect a reference to a symbol in the DATA
> segment to a symbol in the TEXT segment). I ended up hacking export4.h to
> put extern before the attribute stuff (could not remove the attribute stuff
> or put #if 0 for the condition before, or since -fvisibility is set to
> hidden nothing would have been externally visible...) Of course, I get a
> warning that a global initialised var was declared extern, but at least it
> builds.
I've always wondered what that "extern for some platforms only" mess was 
about. Really, extern is part of the C standard, and thus should be used the 
same on all platforms. The current export?.h mixes up extern with visibility 
attributes, which are really unrelated issues. I can see how "extern" can be 
related to dllimport (they're both importing symbols from somewhere), but not 
dllexport (or visibility)!
By the way, this affects all libs, not just libticonv.

* It looks like libintl is giving trouble again on OS X. (It doesn't detect 
the dylib (this is how OS X calls the so files), so it tries to link the 
local static one, and then fails because some dependencies are linked to the 
dylib and the 2 versions conflict.) I've asked ZPedro for the corresponding 
config.log and config.status files. I'm waiting for these before making any 
changes.

* I'm also about to commit fixes for a few obvious bugs.

        Kevin Kofler

Re: [TiLP-devel] [tiemu-devel] QMake MinGW specs

[Kevin K. <kev...@ch...>]

> > Usage:
> > cross-MinGW: qmake-qt4 -win32 -spec win32-cross-g++
> > MSYS: /c/qt4/bin/qmake -spec win32-msys-g++
> > (The MSYS line assumes Qt 4 is in C:\qt4, please adjust.)
>
> In this case, is Qmake -foo -bar -.... -... easier than ./configure with
> no args?

In the cross-MinGW case, the alternative is:
./configure --host=i386-mingw32
which is pretty much the same thing.

In the MSYS case, well, QMake defaults to the native mingw32-make, and that 
may well just work. (You'll need to use mingw32-make instead of make if you 
go that route though.) If you want QMake to default to using the MSYS make, 
then that's something you can change in your QMake configuration. What make 
to configure for is really something for the user to decide.

> > tilibs public headers shouldn't require the client program to run
> > autoconf tests. stdint.h is included with GCC in all current versions
>
> I agree but stdint.h does not exist under Windows (at least MSVC) thus it
> _needs_ to be detected.

That's what __GNUC__ is for.

Note that the header _does_ exist on MinGW, and in fact you _must_ use it on 
MinGW, or MinGW's stdint.h will conflict with the windows.h-based definitions 
in your stdints?.h, which is how I discovered this problem in the first 
place!

> > (assuming the GCC-provided headers are shipped, but I think TIGCC is the
> > only
> > port which doesn't do that ;-) ), so I think it's safe to assume that
> > __GNUC__ implies HAVE_STDINT_H. Incidentally, this is also what the QMake
> > project now does:
> > *-g++:CFLAGS += -DHAVE_STDINT_H
>
> you are replacing autoconf probing by hand-written specs. Is this
> normal/better?

I could probe it (Qt itself uses QMake to probe a lot of things), but I don't 
see the point. I've found one target which needs it (MinGW), I've found a 
superset which allows it (GCC), so this is a valid fix. (I could define 
HAVE_STDINT_H only for MinGW too, but as all GCCs provide it, I think this 
way is better. Maybe on other GCC targets your hack also conflicts with the 
real stdint.h.)

That said, I think the proper fix would be to write:
#if defined(__GNUC__) || defined(HAVE_STDINT_H)
in the header file in the first place.

> > tilibs.h should just:
> > #include <ticonv.h>
> > #include <ticables.h>
> > #include <tifiles.h>
> > #include <ticalcs.h>
> > and be done with it, no crazy #ifdefs.
>
> This is currently this, isn't it?

No (as you have noticed by the fact that my change broke M$VC ;-) ).
There were at least 3 different methods:
#include "ticonv.h"
#include <tilp2/ticonv.h>
#include <libticonv/ticonv.h>
depending on the target. The right way to include installed headers is of 
course to use angle brackets, and the extra path is not needed because that's 
what pkg-config is for (or for M$VC, the project file should take care of the 
include paths, at least in theory...).

        Kevin Kofler

Re: [TiLP-devel] [tiemu-devel] tilibs.h #ifdef mess cleaned up (was: Re: QMake

[Kevin K. <kev...@ch...>]

> You are pleased to revert your change. Again, Win32 = MinGW for you.
> By doing this, the header does not compile under MSVC any longer!

Why do the:
#include <ticonv.h>
in the various tilibs work (yes, I changed some #include "ticonv.h" to 
#include <ticonv.h> and I hope these didn't add to the breakage, but there 
were ALREADY some using <ticonv.h>!) and these not? Is this due to different 
project setup?

Anyway, you're free to fix the tilibs.h headers and the other inclusions for 
the #ifdef _MSC_VER case. (I can't test M$VC, so it's best if you fix it.) I 
think the result would look like this:
#ifdef _MSC_VER
#include "ticonv.h"
#include "ticables.h"
#include "tifiles.h"
#include "ticalcs.h"
#else
#include <ticonv.h>
#include <ticables.h>
#include <tifiles.h>
#include <ticalcs.h>
#endif

But please don't re-add any other #ifdefs unless you're 100% sure they are 
needed (I'm pretty sure they aren't, because that's really what pkg-config is 
for) and please let the non-M$VC #includes be done the right way (i.e. using 
angle brackets, not quotes, for installed headers).

Oh, and "Win32 = MinGW for you", well, not any more than Win32 = M$VC for 
you. ;-) Sorry, but I can't stand the:
#ifdef __WIN32__
#pragma warning disable(1234)
#endif
type mistakes (which will spit out extra warnings on MinGW because that's not 
a valid GCC pragma). I found some of these by chance again, but I can't 
nearly fix them as fast as you introduce them. ;-(

> The #ifdef __MACOSX__ was needed by native port of Mac OS (which obsolete
> because not maintained, I agree). Again, MacOSX != X11!

* But with the changes, stuff actually BUILDS for OS X (modulo bugs I'm going 
to fix right now, ZPedro told me what he had to fix). (Though to be honest, 
he hasn't tried building the projects where tilibs.h is in yet. Still, 
there's no way it would have built with the old #ifdefs which refer to 
non-existent directories!)
* This has nothing to do with X11. It has to do with using a standard Unix 
file system layout or an arbitrary one. This is a completely different issue 
from X11.
* _I'm_ not going to be the one maintaining the arbitrary, 
different-just-to-be-different file system structure for OS X, if someone 
else wants to maintain that, it's fine with me, but it needs to be done 
throughout, including "make install". (Otherwise, it only breaks things!) 
IMHO, the different file system structure you picked for your M$VC/InnoSetup 
builds is already enough of a mess, we don't need a third.
* It's perfectly possible to build non-X11 versions of programs using the 
tilibs with this file system layout. KTIGCC 2.00 is most likely going to 
support Qt/Mac 4, so this will be an example. :-) As I said, these are really 
orthogonal issues.

        Kevin Kofler

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[Romain <ro...@li...>]

Hi,

> I can test it, I have a ppc g5 imac, and a intel dual core macbook. No
> chance it works on both is there ;-)

thank you very much for your help!

roms.

>
> 2006/9/21, Kevin Kofler <kev...@ch...>:
>> > Now I'll clean up the USB/libusb stuff and then the SVN will be read=
y
>> for
>> > testing on OS X.
>>
>> Done, awaiting testing.
>>
>>         Kevin Kofler
>>
>> ----------------------------------------------------------------------=
---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e
>> your
>> opinions on IT & business topics through brief surveys -- and earn cas=
h
>> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
>> _______________________________________________
>> TiLP-devel mailing list
>> TiL...@li...
>> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>>
>
>
> --
> Cheers,
>  James Rubingh
> http://www.wrive.com
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[Romain <ro...@li...>]

Hi,

>> Now I'll clean up the USB/libusb stuff and then the SVN will be ready
>> for
>> testing on OS X.
>
> Done, awaiting testing.

ok, I will give a check at code on tomorrow.

>
>         Kevin Kofler

roms.

>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[Romain <ro...@li...>]

Hi,

> Resolved: OS X has the prerequisite functions, so it definitely should
> just
> work. I have enabled it. If there are any problems, we can always disab=
le

good.

> old libticables1-era code either.) So I'm going to switch OS X to use
> libusb,

ok for me.

> Now I'll clean up the USB/libusb stuff and then the SVN will be ready f=
or
> testing on OS X.

For information, a libusb-win32 exists but given that it's incomplete and
it needs a driver (a kind of kernel to userland gateway), the current
ticables2 support is the best.

>
>         Kevin Kofler

roms.

>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] libticables2 OS X support

[Romain <ro...@li...>]

Hi,

> I'm trying to resurrect OS X support in libticables2 because I want

good idea...

> ). I cleaned up some of the mess, but there are 2 issues remaining:
> * USB linking. macos/link_slv.c needs to be ported to the new interface
> expected by the libticables2. But can't we just use libusb?

I know that JB used OSX' IOKit due to lack of libusb support but support
may have changed (=3Dimproved).

> http://libusb.sourceforge.net says it works on OS X. That way we could =
use
> the same code as for Linux and BSD instead of fiddling with the IOKit,

it would be better

> * virtual link. Currently, this isn't built on OS X. Shouldn't this jus=
t
> work?
> It only uses standard POSIX IPC as far as I can tell.

It should but it has never been tested.

>
>         Kevin Kofler
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] tilibs.h #ifdef mess cleaned up (was: Re: QMake

[Romain <ro...@li...>]

Hi,

>> $PREFIX/include. tilibs.h should just:
>> #include <ticonv.h>
>> #include <ticables.h>
>> #include <tifiles.h>
>> #include <ticalcs.h>
>> and be done with it, no crazy #ifdefs.
>
> This is done now, throughout the LPG repository.

You are pleased to revert your change. Again, Win32 =3D MinGW for you.
By doing this, the header does not compile under MSVC any longer!

The #ifdef __MACOSX__ was needed by native port of Mac OS (which obsolete
because not maintained, I agree). Again, MacOSX !=3D X11!

roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] QMake MinGW specs

[Romain <ro...@li...>]

Hi,

> for cross-MinGW and for MSYS at:
> http://www.tigen.org/kevin.kofler/pcprogs/qmake4-mingw-mkspecs.7z
> (These are for QMake 4. I recommend QMake 4 for MinGW targets because
> QMake 3
> hardcodes even more DOS-shell-stuff, and also sets some weird default
> linker
> flags which are more likely to be a problem than to be helpful. However=
,
> if
> you want QMake to generate an M$VC project or an M$VC nmake file, you n=
eed
> either QMake 3 or a QMake 4 patched with the "additional compiler suppo=
rt"
> patches.)
> Usage:
> cross-MinGW: qmake-qt4 -win32 -spec win32-cross-g++
> MSYS: /c/qt4/bin/qmake -spec win32-msys-g++
> (The MSYS line assumes Qt 4 is in C:\qt4, please adjust.)

In this case, is Qmake -foo -bar -.... -... easier than ./configure with
no args?

tilibs public headers shouldn't require the client program to run
> autoconf tests. stdint.h is included with GCC in all current versions

I agree but stdint.h does not exist under Windows (at least MSVC) thus it
_needs_ to be detected.

> (assuming the GCC-provided headers are shipped, but I think TIGCC is th=
e
> only
> port which doesn't do that ;-) ), so I think it's safe to assume that
> __GNUC__ implies HAVE_STDINT_H. Incidentally, this is also what the QMa=
ke
> project now does:
> *-g++:CFLAGS +=3D -DHAVE_STDINT_H

you are replacing autoconf probing by hand-written specs. Is this
normal/better?

> * tilibs.h doesn't find <tilp2/ticonv.h> etc. with the current
> cross-mingw32-gtkaio.sh. Fix:
> export C_INCLUDE_PATH=3D"$C_INCLUDE_PATH":~/.wine/c/tiemu/include
> I can add that to our cross-mingw32-gtkaio.sh, but I'd much better
> the "tilp2/" prefixes were just yanked from the various copies of
> tilibs.h.
> They're not needed, pkg-config already puts the $PREFIX/include/tilp2
> folder
> into the include search path. And the extra C_INCLUDE_PATH wouldn't be
> needed
> with them, as $PREFIX/include/tilp2 is found by pkg-config unlike
> $PREFIX/include. tilibs.h should just:
> #include <ticonv.h>
> #include <ticables.h>
> #include <tifiles.h>
> #include <ticalcs.h>
> and be done with it, no crazy #ifdefs.

This is currently this, isn't it?
>
>         Kevin Kofler
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"








--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[James R. <ep...@gm...>]

I can test it, I have a ppc g5 imac, and a intel dual core macbook. No
chance it works on both is there ;-)

2006/9/21, Kevin Kofler <kev...@ch...>:
> > Now I'll clean up the USB/libusb stuff and then the SVN will be ready for
> > testing on OS X.
>
> Done, awaiting testing.
>
>         Kevin Kofler
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


-- 
Cheers,
 James Rubingh
http://www.wrive.com

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[Kevin K. <kev...@ch...>]

> Now I'll clean up the USB/libusb stuff and then the SVN will be ready for
> testing on OS X.

Done, awaiting testing.

        Kevin Kofler

Re: [TiLP-devel] [tiemu-devel] libticables2 OS X support

[Kevin K. <kev...@ch...>]

Answering my own questions:

> * virtual link. Currently, this isn't built on OS X. Shouldn't this just
> work? It only uses standard POSIX IPC as far as I can tell.

Resolved: OS X has the prerequisite functions, so it definitely should just 
work. I have enabled it. If there are any problems, we can always disable it 
again.

> * USB linking. macos/link_slv.c needs to be ported to the new interface
> expected by the libticables2. But can't we just use libusb?
> http://libusb.sourceforge.net says it works on OS X. That way we could use
> the same code as for Linux and BSD instead of fiddling with the IOKit, and
> that would be much easier for me to do without an OS X box to test with and
> much more likely to work.

Resolved too: There is really no way we're going to update and maintain the 
OS-X-specific code for USB. There's just too many things to change, and it is 
not worth it because libusb exists for a reason. (The only thing we can't 
provide with the libusb API is slv_check, but that wasn't implemented by the 
old libticables1-era code either.) So I'm going to switch OS X to use libusb, 
it really ought to work. Binaries (hopefully universal ones, the packager 
mentions his main packages are now universal binaries, but doesn't say 
anything specifically about the libusb ones) of libusb for OS X are available 
at:
http://www.ellert.se/twain-sane/

Now I'll clean up the USB/libusb stuff and then the SVN will be ready for 
testing on OS X.

        Kevin Kofler

[TiLP-devel] libticables2 OS X support

[Kevin K. <kev...@ch...>]

I'm trying to resurrect OS X support in libticables2 because I want KTIGCC to 
work on OS X too. (There's at least one interested user, see:
http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=3281.topic
). I cleaned up some of the mess, but there are 2 issues remaining:
* USB linking. macos/link_slv.c needs to be ported to the new interface 
expected by the libticables2. But can't we just use libusb? 
http://libusb.sourceforge.net says it works on OS X. That way we could use 
the same code as for Linux and BSD instead of fiddling with the IOKit, and 
that would be much easier for me to do without an OS X box to test with and 
much more likely to work.
* virtual link. Currently, this isn't built on OS X. Shouldn't this just work? 
It only uses standard POSIX IPC as far as I can tell.

        Kevin Kofler

[TiLP-devel] tilibs.h #ifdef mess cleaned up (was: Re: QMake MinGW specs)

[Kevin K. <kev...@ch...>]

> * tilibs.h doesn't find <tilp2/ticonv.h> etc. with the current
> cross-mingw32-gtkaio.sh. Fix:
> export C_INCLUDE_PATH="$C_INCLUDE_PATH":~/.wine/c/tiemu/include
> I can add that to our cross-mingw32-gtkaio.sh, but I'd much better
> the "tilp2/" prefixes were just yanked from the various copies of tilibs.h.
> They're not needed, pkg-config already puts the $PREFIX/include/tilp2
> folder into the include search path. And the extra C_INCLUDE_PATH wouldn't
> be needed with them, as $PREFIX/include/tilp2 is found by pkg-config unlike
> $PREFIX/include. tilibs.h should just:
> #include <ticonv.h>
> #include <ticables.h>
> #include <tifiles.h>
> #include <ticalcs.h>
> and be done with it, no crazy #ifdefs.

This is done now, throughout the LPG repository.

This also yanks the strange __MACOSX__ #ifdefs which assume a non-standard 
install location for the libs on OS X, which isn't what "make install" does 
(at least not anymore). So this should get us one step closer to build again 
on OS X. Still, there seems to be issues building some of the libs, I'm 
hoping I can get ZPedro to report what exactly is broken so we can fix it. 
I'd like at least KTIGCC and TiEmu 3 to work on OS X, if we can get actual 
cable communications to work too (so TiLP 2 works too), that would of course 
be nice.

        Kevin Kofler

[TiLP-devel] TiLP2 v1.00: stable release

[Romain <ro...@li...>]

Hi,

I have just released on ticalc.org the final release of TiLP2 (v1.00) and
the framework (1.0.0/1.0.0/1.0.0/1.0.0).

Please note that Titanium/USB support still _not_ work under Linux.

Enjoy, roms.
--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] [tiemu-devel] QMake MinGW specs

[Kevin K. <kev...@ch...>]

> Usage:
> cross-MinGW: qmake-qt4 -win32 -spec win32-cross-g++
> MSYS: /c/qt4/bin/qmake -spec win32-msys-g++
> (The MSYS line assumes Qt 4 is in C:\qt4, please adjust.)

Oops, I forgot:
Installation: These directories go to /usr/share/qt4/mkspecs. (That's on 
Fedora, I don't know where they go to on Window$ and I can't guarantee the 
location is the same in other GNU/Linux distros either.)

        Kevin Kofler

[TiLP-devel] QMake MinGW specs

[Kevin K. <kev...@ch...>]

I have now successfully tested gfm.pro with both QMake 3 and 4. QMake supports 
generating MinGW makefiles. Unfortunately however, the default MinGW makefile 
template assumes the dumb mingw32-make.exe (using the dumb command.com resp. 
cmd.exe DOS shell). Luckily, this isn't hard to fix, you just have to edit 
the templates (simple text files). You can find working makefile templates 
for cross-MinGW and for MSYS at:
http://www.tigen.org/kevin.kofler/pcprogs/qmake4-mingw-mkspecs.7z
(These are for QMake 4. I recommend QMake 4 for MinGW targets because QMake 3 
hardcodes even more DOS-shell-stuff, and also sets some weird default linker 
flags which are more likely to be a problem than to be helpful. However, if 
you want QMake to generate an M$VC project or an M$VC nmake file, you need 
either QMake 3 or a QMake 4 patched with the "additional compiler support" 
patches.)
Usage:
cross-MinGW: qmake-qt4 -win32 -spec win32-cross-g++
MSYS: /c/qt4/bin/qmake -spec win32-msys-g++
(The MSYS line assumes Qt 4 is in C:\qt4, please adjust.)

Note that:
* I had to add a definition of HAVE_STDINT_H to gfm.pro, because the tilibs 
headers depend on this. (I get a conflicting definition on MinGW between the 
windows.h hack in stdints2.h and the real stdint.h definitions (included 
indirectly by some system or GTK+ header file) if I don't define it.) This is 
bad. tilibs public headers shouldn't require the client program to run 
autoconf tests. stdint.h is included with GCC in all current versions 
(assuming the GCC-provided headers are shipped, but I think TIGCC is the only 
port which doesn't do that ;-) ), so I think it's safe to assume that 
__GNUC__ implies HAVE_STDINT_H. Incidentally, this is also what the QMake 
project now does:
*-g++:CFLAGS += -DHAVE_STDINT_H

* tilibs.h doesn't find <tilp2/ticonv.h> etc. with the current 
cross-mingw32-gtkaio.sh. Fix:
export C_INCLUDE_PATH="$C_INCLUDE_PATH":~/.wine/c/tiemu/include
I can add that to our cross-mingw32-gtkaio.sh, but I'd much better 
the "tilp2/" prefixes were just yanked from the various copies of tilibs.h. 
They're not needed, pkg-config already puts the $PREFIX/include/tilp2 folder 
into the include search path. And the extra C_INCLUDE_PATH wouldn't be needed 
with them, as $PREFIX/include/tilp2 is found by pkg-config unlike 
$PREFIX/include. tilibs.h should just:
#include <ticonv.h>
#include <ticables.h>
#include <tifiles.h>
#include <ticalcs.h>
and be done with it, no crazy #ifdefs.

        Kevin Kofler

Re: [TiLP-devel] TiLP-devel Digest, Vol 4, Issue 10

[Romain <ro...@li...>]

Hi,

> I enabled snooping of the USB comms (by echoing Y to
> /sys/module/usbcore/parameters/usbfs_snoop - thx google!) and the resul=
t
> had been as follows:

I have already done this...

> Sep 18 21:53:48 localhost kernel: [17326218.580000] usb 3-2: control
> read: bRequest=3D06 bRrequestType=3D80 wValue=3D0300 wIndex=3D0000 wLen=
gth=3D00ff
> Sep 18 21:53:49 localhost kernel: [17326219.580000] usb 3-2: usbfs:
> USBDEVFS_CONTROL failed cmd tilp-2 rqt 128 rq 6 len 255 ret -110
> Sep 18 21:53:49 localhost kernel: [17326219.580000] usb 3-2:
> usbdev_ioctl: SETCONFIGURATION

> found <TI-89 Titanium> on #1, version <3.00>
> ... magically became ...
> found <> on #1, version <3.00>
>
> and then timeout!

This problem is common to all kernel versions and appears with lsusb even=
.

> For the moment I'm stuck, here, just to let you know on what's I'm doin=
g

Me, too. This is the reason why I have stopped investigation. But, I have
located entry point in usbcore which may fault. But, this entry point
calls a function which calls a function...

> Rgds,
>
> Michele

Thanks, roms.

>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> TiLP-devel mailing list
> TiL...@li...
> https://lists.sourceforge.net/lists/listinfo/tilp-devel
>


--=20
Romain Li=E9vin :		<ro...@li...>
Web site :		http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"

Re: [TiLP-devel] TiLP-devel Digest, Vol 4, Issue 10

[Michele <md...@mc...>]

Hi all,

I'm slowly digging in and trying to understand how things works. I 
googled more looking for a reply to my questions, but found anything, so 
reverted trying to directly ask to the ML:

Observed facts:

1 - the Titanium seems is regularly recognized and registered by the USB 
subsystem

This is part from my cat /proc/bus/usb/devices

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0451 ProdID=e004 Rev= 3.00
S:  Manufacturer=Texas Instruments Incorporated
S:  Product=TI-89 Titanium
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

2 - TiLP-2 just launched recognize the calc (extract from logs)

ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>

3 - TiLP-2 try to talk to the calc and it fails (extract from logs)

(tilp-2:29716): ticables-WARNING **: usb_clear_halt (could not 
clear/halt ep 2: Connessione scaduta).
(tilp-2:29716): ticables-WARNING **: usb_clear_halt (could not 
clear/halt ep 129: Connessione scaduta).

'Connessione scaduta' is Italian, and means it went timeout

4 - on the main screen, TiLP-2 reports correctly the name of the calc, 
TI89t USB w/DirectLink on #1


I enabled snooping of the USB comms (by echoing Y to 
/sys/module/usbcore/parameters/usbfs_snoop - thx google!) and the result 
had been as follows:

5a - When connecting/turning on the calc the USB traffic was:
Sep 18 21:53:16 localhost kernel: [17326186.384000] usb 3-2: new full 
speed USB device using ohci_hcd and address 6

5b - When launching TiLP the following passed on USB channel:
Sep 18 21:53:38 localhost kernel: [17326208.312000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.312000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.312000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.316000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.320000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.320000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.320000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.320000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.324000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.328000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.428000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.432000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.436000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.436000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.436000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.436000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.440000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.444000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.444000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.444000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.444000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.448000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.452000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.452000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.452000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.452000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.456000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.556000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.560000] usb 3-2: control 
read: data 04 03 09 04
Sep 18 21:53:38 localhost kernel: [17326208.560000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:38 localhost kernel: [17326208.560000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0302 wIndex=0409 wLength=00ff
Sep 18 21:53:38 localhost kernel: [17326208.564000] usb 3-2: control 
read: data 1e 03 54 00 49 00 2d 00 38 00 39 00 20 00 54 00 69 00 74 00 
61 00 6e 00 69 00 75 00 6d 00
Sep 18 21:53:38 localhost kernel: [17326208.564000] usb 3-2: 
usbdev_ioctl: SETCONFIGURATION
Sep 18 21:53:38 localhost kernel: [17326208.564000] usb 3-2: 
usbdev_ioctl: CLAIMINTERFACE
Sep 18 21:53:38 localhost kernel: [17326208.564000] usb 3-2: 
usbdev_ioctl: CLEAR_HALT
Sep 18 21:53:38 localhost kernel: [17326208.568000] usb 3-2: 
usbdev_ioctl: CLEAR_HALT
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: 
usbdev_ioctl: SUBMITURB
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: bulk urb
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: submit urb
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: direction=OUT
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: 
userurb=bff4edf4
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: 
transfer_buffer_length=9
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: actual_length=0
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: data: 00 00 
00 04 01 00 00 04 00
Sep 18 21:53:38 localhost kernel: [17326208.572000] usb 3-2: 
usbdev_ioctl: REAPURBDELAY
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: urb complete
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: direction=OUT
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
userurb=bff4edf4
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
transfer_buffer_length=9
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: actual_length=9
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: data: 00 00 
00 04 01 00 00 04 00
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
usbdev_ioctl: REAPURBDELAY
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
usbdev_ioctl: SUBMITURB
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: bulk urb
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: submit urb
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: direction=IN
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
userurb=b7eb7e40
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
transfer_buffer_length=64
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: actual_length=0
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: data: c0 a6 
6a db 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 03 00 00 00 e2 22 86 01 10 00 00 00 03 00 00 00 11 00 
00 00 03 00 00 00 00 00 00 00 00 00 00 00
Sep 18 21:53:38 localhost kernel: [17326208.576000] usb 3-2: 
usbdev_ioctl: REAPURBDELAY
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: urb complete
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: direction=IN
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: 
userurb=b7eb7e40
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: 
transfer_buffer_length=64
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: actual_length=9
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: data: 00 00 
00 04 02 00 00 03 ff 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 03 00 00 00 e2 22 86 01 10 00 00 00 03 00 00 00 11 00 
00 00 03 00 00 00 00 00 00 00 00 00 00 00
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: 
usbdev_ioctl: REAPURBDELAY
Sep 18 21:53:38 localhost kernel: [17326208.580000] usb 3-2: 
usbdev_ioctl: RELEASEINTERFACE
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb4: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb4: 
usbdev_ioctl: IOCTL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb1: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb1: 
usbdev_ioctl: IOCTL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb 3-2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb3: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb 3-2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb3: 
usbdev_ioctl: IOCTL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb2: 
usbdev_ioctl: CONNECTINFO
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb usb2: 
usbdev_ioctl: IOCTL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb 3-2: 
usbdev_ioctl: CONTROL
Sep 18 21:53:48 localhost kernel: [17326218.580000] usb 3-2: control 
read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
Sep 18 21:53:49 localhost kernel: [17326219.580000] usb 3-2: usbfs: 
USBDEVFS_CONTROL failed cmd tilp-2 rqt 128 rq 6 len 255 ret -110
Sep 18 21:53:49 localhost kernel: [17326219.580000] usb 3-2: 
usbdev_ioctl: SETCONFIGURATION
Sep 18 21:53:54 localhost kernel: [17326224.580000] usb 3-2: 
usbdev_ioctl: CLAIMINTERFACE
Sep 18 21:53:54 localhost kernel: [17326224.580000] usb 3-2: 
usbdev_ioctl: CLEAR_HALT
Sep 18 21:53:59 localhost kernel: [17326229.580000] usb 3-2: 
usbdev_ioctl: RESETEP
Sep 18 21:53:59 localhost kernel: [17326229.580000] usb 3-2: 
usbdev_ioctl: CLEAR_HALT
Sep 18 21:54:06 localhost kernel: [17326234.584000] usb 3-2: 
usbdev_ioctl: RESETEP


6 - Looking the happenings from TiLP point of view, this had been the 
result:

TiLP - Version 0.23, (C) 1999-2006 Romain Lievin
THIS PROGRAM COMES WITH ABSOLUTELY NO WARRANTY
PLEASE READ THE DOCUMENTATION FOR DETAILS
built on Sep 14 2006 23:00:07
tilp-INFO: setlocale: <it_IT.UTF-8>
tilp-INFO: bindtextdomain: <\locale>
tilp-INFO: textdomain: <tilp2>
ticables-INFO: ticables library version 0.1.4
ticables-INFO: setlocale: <it_IT.UTF-8>
ticables-INFO: bindtextdomain: </usr/local/share/locale>
ticables-INFO: textdomain: <libticables2>
ticables-INFO: kernel: 2.6.15-26-386
tifiles-INFO: tifiles library version 0.2.7
tifiles-INFO: setlocale: <it_IT.UTF-8>
tifiles-INFO: bindtextdomain: </usr/local/share/locale>
tifiles-INFO: textdomain: <libtifiles2>
ticalcs-INFO: ticalcs library version 0.2.6
ticalcs-INFO: setlocale: <it_IT.UTF-8>
ticalcs-INFO: bindtextdomain: </usr/local/share/locale>
ticalcs-INFO: textdomain: <libticalcs2>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
tilp-INFO: Searching for link cables...
ticables-INFO: Link cable probing:
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
tilp-INFO: Searching for hand-helds on DirectLink...
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <TI-89 Titanium> on #1, version <3.00>
ticalcs-INFO:   PC->TI: Buffer Size Request (1024 bytes)
ticalcs-INFO:   TI->PC: Buffer Size Allocation (1023 bytes)
ticables-INFO: Check for lib-usb support:
ticables-INFO:     usb support: available.
ticables-INFO: Check for lib-usb usability:
ticables-INFO:     usb filesystem (/proc/bus/usb): mounted
ticables-INFO:  found <> on #1, version <3.00>

(tilp-2:29716): ticables-WARNING **: usb_clear_halt (could not 
clear/halt ep 2: Connessione scaduta).


(tilp-2:29716): ticables-WARNING **: usb_clear_halt (could not 
clear/halt ep 129: Connessione scaduta).



-----------------

an interesting fact is that initially TiLP seems to regularly recognize 
the calc, but on the last try suddenly the calc... WHOPS!

found <TI-89 Titanium> on #1, version <3.00>
... magically became ...
found <> on #1, version <3.00>

and then timeout!

------------------

For the moment I'm stuck, here, just to let you know on what's I'm doing 
and asking for some advice, if somebody has one!

At the moment I'm trying to understand better what all these logs mean, 
but not ever google is your friend! BTW, I'm using ubuntu Dapper 6.06 on 
an Athlon 64 Venice3200+, that means a 32bit 2.6.15 kernel.

Rgds,

Michele