Hello all, I have been working on getting Hotsync to sync to a USB cradle using usbserial. I did some research, and as it turns out, the functions that wine uses to poll normal serial ports (like ioctl and tcgetattr) don't like usbserial devices very much. In fact, when I query my USB cradle using setserial, it gives me the same "Invalid Arguement" error that GetCommState does. Additionally, pilot-link doesn't even use these functions to communicate with a usbserial connected palm. The question now is, can we get tcgetattr to play nice with usbserial?
Best Regards, James Liggett
"James" == James Liggett jrliggett@cox.net writes:
James> Hello all, I have been working on getting Hotsync to sync to a James> USB cradle using usbserial. I did some research, and as it turns James> out, the functions that wine uses to poll normal serial ports James> (like ioctl and tcgetattr) don't like usbserial devices very James> much. In fact, when I query my USB cradle using setserial, it James> gives me the same "Invalid Arguement" error that GetCommState James> does. Additionally, pilot-link doesn't even use these functions James> to communicate with a usbserial connected palm. The question now James> is, can we get tcgetattr to play nice with usbserial?
What USB to serial adapter is used? The usbserial Atmel AVRIce uses a FTDI FT232 which is well supported. It works quite well, with the serial related patches I sent to the list( but some of them not yet in CVS). The problem you suspect is likely more usb related.
Bye
I'm not using a "real" adapter. I'm using the visor driver that is used to sync a USB palm with things like pilot-link. This driver emulates a serial port in much the same way that a real one does, or so I think. I was just pointing out that people have similar behavior with real adapters, so I thought it might be relevant. The visor driver calls itself a "serial converter", and it does add USB entries in my /dev/tts folder like a real adapter would. But, my palm cradle is plugged into an acutal USB port. I do have access to a real USB to serial adapter though; I'll play around with it. And another thing--I'm also looking into that WinMM crash that keeps Palm Desktop from running. The problem is that the function DRIVER_FindFromHDrvr is failing, returning a NULL value, which wine tries to derefrence in MMDRV_Install, and boom--wine crashes.
James
On Thu, 2005-07-07 at 10:51 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> Hello all, I have been working on getting Hotsync to sync to a James> USB cradle using usbserial. I did some research, and as it turns James> out, the functions that wine uses to poll normal serial ports James> (like ioctl and tcgetattr) don't like usbserial devices very James> much. In fact, when I query my USB cradle using setserial, it James> gives me the same "Invalid Arguement" error that GetCommState James> does. Additionally, pilot-link doesn't even use these functions James> to communicate with a usbserial connected palm. The question now James> is, can we get tcgetattr to play nice with usbserial?
What USB to serial adapter is used? The usbserial Atmel AVRIce uses a FTDI FT232 which is well supported. It works quite well, with the serial related patches I sent to the list( but some of them not yet in CVS). The problem you suspect is likely more usb related.
Bye
"James" == James Liggett jrliggett@cox.net writes:
James> I'm not using a "real" adapter. I'm using the visor driver that James> is used to sync a USB palm with things like pilot-link. This
Does the hotplug mechanisme create some /dev/ttyUSBx when you plug in the device? Or is the USB VID/PID at least know to the linix kernel drivers?
James> driver emulates a serial port in much the same way that a real James> one does, or so I think. I was just pointing out that people have James> similar behavior with real adapters, so I thought it might be James> relevant. The visor driver calls itself a "serial converter", and James> it does add USB entries in my /dev/tts folder like a real adapter James> would. But, my palm cradle is plugged into an acutal USB port. I James> do have access to a real USB to serial adapter though; I'll play James> around with it. And another thing--I'm also looking into that James> WinMM crash that keeps Palm Desktop from running. The problem is James> that the function DRIVER_FindFromHDrvr is failing, returning a James> NULL value, which wine tries to derefrence in MMDRV_Install, and James> boom--wine crashes.
Scan the mailing lists. I had another similar problem, Eric pointed me to some problems in my setup.
Yes, the hotplug (well, actually it's coldplug and udev) creates two USB devices, /dev/tts/USB0 and /dev/tts/USB1. With palm devices, these entries only show up when the palm is actually trying to hotsync, but palm desktop didn't really seem to care. It tried to use GetCommState when the devices showed up. If I run hotsync program without trying to sync, it doesn't complain. The errors only show after I pres the button. I have USB0 symlinked to /dev/pilot, and I am able to sync with this device using pilot-link compatible apps (mainly gnome-pilot.) Oh, and about that crash--does the mailing list archive have a search engine on it?
Thanks a lot, James
On Thu, 2005-07-07 at 22:28 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> I'm not using a "real" adapter. I'm using the visor driver that James> is used to sync a USB palm with things like pilot-link. This
Does the hotplug mechanisme create some /dev/ttyUSBx when you plug in the device? Or is the USB VID/PID at least know to the linix kernel drivers?
James> driver emulates a serial port in much the same way that a real James> one does, or so I think. I was just pointing out that people have James> similar behavior with real adapters, so I thought it might be James> relevant. The visor driver calls itself a "serial converter", and James> it does add USB entries in my /dev/tts folder like a real adapter James> would. But, my palm cradle is plugged into an acutal USB port. I James> do have access to a real USB to serial adapter though; I'll play James> around with it. And another thing--I'm also looking into that James> WinMM crash that keeps Palm Desktop from running. The problem is James> that the function DRIVER_FindFromHDrvr is failing, returning a James> NULL value, which wine tries to derefrence in MMDRV_Install, and James> boom--wine crashes.
Scan the mailing lists. I had another similar problem, Eric pointed me to some problems in my setup.
"James" == James Liggett jrliggett@cox.net writes:
James> device using pilot-link compatible apps (mainly gnome-pilot.) Oh, James> and about that crash--does the mailing list archive have a search James> engine on it?
Use google. Try "bonnes pouech MMDRV_Install"
Tried your lead, but no luck. I did find the conversation, but to my dismay it was a dead end. It ended with you saying that the problem had gone away out of the blue: http://www.winehq.com/hypermail/wine-devel/2003/05/0075.html
That's very odd. Btw, I saw that you sent a patch in to check the sanity of driver pointers returned by DRIVER_FindFromHDrvr. Why wasn't this committed? And, you were right about that Microquill memory manager bug, but I realized this after the fact. For a while I thought we weren't on the same page, but I saw a lot of the stuff about it in the archives while searching. So that's the cause of this crap? Anyway, thanks for you help. :)
Regards, James
On Fri, 2005-07-08 at 00:10 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> device using pilot-link compatible apps (mainly gnome-pilot.) Oh, James> and about that crash--does the mailing list archive have a search James> engine on it?
Use google. Try "bonnes pouech MMDRV_Install"
"James" == James Liggett jrliggett@cox.net writes:
James> Tried your lead, but no luck. I did find the conversation, but to James> my dismay it was a dead end. It ended with you saying that the James> problem had gone away out of the blue: James> http://www.winehq.com/hypermail/wine-devel/2003/05/0075.html
James> That's very odd. Btw, I saw that you sent a patch in to check the James> sanity of driver pointers returned by DRIVER_FindFromHDrvr. Why James> wasn't this committed? And, you were right about that Microquill James> memory manager bug, but I realized this after the fact. For a James> while I thought we weren't on the same page, but I saw a lot of James> the stuff about it in the archives while searching. So that's the James> cause of this crap? Anyway, thanks for you help. :)
There are two sided of the problem: - One is microquill not handling HeapValidate - Second is the loading of the sound driver using this not otherwise used function
Reg one: This is a plain bug in shsmp, and I just wrote a letter to Microquill. Reg two: Apply appended workaraound. Perhaps Eric can think about a more valid workaround for this Microquill problem.
Bye
Uwe Bonnes wrote:
There are two sided of the problem:
- One is microquill not handling HeapValidate
- Second is the loading of the sound driver using this not otherwise used
function
WinMM should not be using HeapValidate. There are many other ways of ensuring the handle that was passed is valid including using exception handling with magic values and handle tables.
Thanks, Uwe. I really apprecate all of this. I was wondering, why are we even using this library when there's been bugs in it that we discovered long ago, but never fixed? And another thing that bothers me: I've selected ALSA as my sound output, but the debug trace shows wineoss.drv loading. What's with that?
Jmaes
On Fri, 2005-07-08 at 09:49 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> Tried your lead, but no luck. I did find the conversation, but to James> my dismay it was a dead end. It ended with you saying that the James> problem had gone away out of the blue: James> http://www.winehq.com/hypermail/wine-devel/2003/05/0075.html James> That's very odd. Btw, I saw that you sent a patch in to check the James> sanity of driver pointers returned by DRIVER_FindFromHDrvr. Why James> wasn't this committed? And, you were right about that Microquill James> memory manager bug, but I realized this after the fact. For a James> while I thought we weren't on the same page, but I saw a lot of James> the stuff about it in the archives while searching. So that's the James> cause of this crap? Anyway, thanks for you help. :)
There are two sided of the problem:
- One is microquill not handling HeapValidate
- Second is the loading of the sound driver using this not otherwise used
function
Reg one: This is a plain bug in shsmp, and I just wrote a letter to Microquill. Reg two: Apply appended workaraound. Perhaps Eric can think about a more valid workaround for this Microquill problem.
Bye
"James" == James Liggett jrliggett@cox.net writes:
James> Thanks, Uwe. I really apprecate all of this. I was wondering, why James> are we even using this library when there's been bugs in it that James> we discovered long ago, but never fixed? And another thing that James> bothers me: I've selected ALSA as my sound output, but the debug James> trace shows wineoss.drv loading. What's with that?
It's not we, it is the application (in my case Xilinx ISE) using Smartheap. But recent mails indicate that the use of HeapValidate in winmm i dubios...
Bye
The patch you gave me fixed the crash in winmm, but now I get this:
err:seh:setup_exception stack overflow 496 bytes in thread 0009 eip 7bee164a esp 7b9d0e10 stack 0x7b9d0000-0x7bad0000
What's that?
Thanks, James
On Fri, 2005-07-08 at 23:17 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> Thanks, Uwe. I really apprecate all of this. I was wondering, why James> are we even using this library when there's been bugs in it that James> we discovered long ago, but never fixed? And another thing that James> bothers me: I've selected ALSA as my sound output, but the debug James> trace shows wineoss.drv loading. What's with that?
It's not we, it is the application (in my case Xilinx ISE) using Smartheap. But recent mails indicate that the use of HeapValidate in winmm i dubios...
Bye
"James" == James Liggett jrliggett@cox.net writes:
James> The patch you gave me fixed the crash in winmm, but now I get James> this: err:seh:setup_exception stack overflow 496 bytes in thread James> 0009 eip 7bee164a esp 7b9d0e10 stack 0x7b9d0000-0x7bad0000
James> What's that?
Another crash :-)
On Thu, 2005-07-07 at 10:51 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> Hello all, I have been working on getting Hotsync to sync to a James> USB cradle using usbserial. I did some research, and as it turns James> out, the functions that wine uses to poll normal serial ports James> (like ioctl and tcgetattr) don't like usbserial devices very James> much. In fact, when I query my USB cradle using setserial, it James> gives me the same "Invalid Arguement" error that GetCommState James> does. Additionally, pilot-link doesn't even use these functions James> to communicate with a usbserial connected palm. The question now James> is, can we get tcgetattr to play nice with usbserial?
What USB to serial adapter is used? The usbserial Atmel AVRIce uses a FTDI FT232 which is well supported. It works quite well, with the serial related patches I sent to the list( but some of them not yet in CVS).
Can you send me the patches so I can try them? I tried to use my Dad's *real* usb to serial converter that he uses to sync his IIIc to his USB-only laptop, but it doesn't seem to be supported in linux (It uses some weird chipset, like ATEN or something like that--ever heard of it?)
The problem you suspect is likely more usb related.
Bye
Thanks, James
"James" == James Liggett jrliggett@cox.net writes:
James> On Thu, 2005-07-07 at 10:51 +0200, Uwe Bonnes wrote: >> >>>>> "James" == James Liggett jrliggett@cox.net writes: >> James> Hello all, I have been working on getting Hotsync to sync to a James> USB cradle using usbserial. I did some research, and as it turns James> out, the functions that wine uses to poll normal serial ports James> (like ioctl and tcgetattr) don't like usbserial devices very James> much. In fact, when I query my USB cradle using setserial, it James> gives me the same "Invalid Arguement" error that GetCommState James> does. Additionally, pilot-link doesn't even use these functions James> to communicate with a usbserial connected palm. The question now James> is, can we get tcgetattr to play nice with usbserial? >> What USB to serial adapter is used? The usbserial Atmel AVRIce uses >> a FTDI FT232 which is well supported. It works quite well, with the >> serial related patches I sent to the list( but some of them not yet >> in CVS).
James> Can you send me the patches so I can try them? I tried to use my James> Dad's *real* usb to serial converter that he uses to sync his James> IIIc to his USB-only laptop, but it doesn't seem to be supported James> in linux (It uses some weird chipset, like ATEN or something like James> that--ever heard of it?)
If the chip is not supported in the linux kernel, no chance to access it with wine. Does lsusb know about the chip (VID/PID)?
Yes it does. And I found a driver, so it works now. I guess I spoke a little too soon...sorry about that.
James
On Tue, 2005-07-12 at 09:33 +0200, Uwe Bonnes wrote:
"James" == James Liggett jrliggett@cox.net writes:
James> On Thu, 2005-07-07 at 10:51 +0200, Uwe Bonnes wrote: >> >>>>> "James" == James Liggett <jrliggett@cox.net> writes: >> James> Hello all, I have been working on getting Hotsync to sync to a James> USB cradle using usbserial. I did some research, and as it turns James> out, the functions that wine uses to poll normal serial ports James> (like ioctl and tcgetattr) don't like usbserial devices very James> much. In fact, when I query my USB cradle using setserial, it James> gives me the same "Invalid Arguement" error that GetCommState James> does. Additionally, pilot-link doesn't even use these functions James> to communicate with a usbserial connected palm. The question now James> is, can we get tcgetattr to play nice with usbserial? >> What USB to serial adapter is used? The usbserial Atmel AVRIce uses >> a FTDI FT232 which is well supported. It works quite well, with the >> serial related patches I sent to the list( but some of them not yet >> in CVS). James> Can you send me the patches so I can try them? I tried to use my James> Dad's *real* usb to serial converter that he uses to sync his James> IIIc to his USB-only laptop, but it doesn't seem to be supported James> in linux (It uses some weird chipset, like ATEN or something like James> that--ever heard of it?)
If the chip is not supported in the linux kernel, no chance to access it with wine. Does lsusb know about the chip (VID/PID)?
Hi,
On Tue, Jul 12, 2005 at 12:48:36AM -0700, James Liggett wrote:
Yes it does. And I found a driver, so it works now. I guess I spoke a little too soon...sorry about that.
I knew it. ;) The chances of an unsupported USB-Serial chip in Linux should be very slim, since I'd think that such a chip is not the most high-end hardware device and should thus be reverse-engineered in a snap for a nice Linux driver (maybe using USB interception via VMWare or so).
Andreas Mohr
I did some research, and as it turns out, the functions that wine uses to poll normal serial ports (like ioctl and tcgetattr) don't like usbserial devices very much. In fact, when I query my USB cradle using setserial, it gives me the same "Invalid Arguement" error that GetCommState does. Additionally, pilot-link doesn't even use these functions to communicate with a usbserial connected palm. The question now is, can we get tcgetattr to play nice with usbserial?
What kernel is that?
Cheers, Kuba