On Wed, Mar 21, 2001 at 01:49:53PM -0500, Hollis R Blanchard wrote:
> On Wed, 21 Mar 2001, Greg KH wrote:
> >
> > I don't understand what you mean by this. Yes, while the visor is
> > attached electronically through USB to the machine, the driver can talk
> > to the device. When it isn't it can't. How can I change this behavior?
>
> After the driver has printed
> 'visor.c: Handspring Visor: port 1, is for Generic use and is bound to ttyUSB0'
> do you consider the Handspring to be electronically attached?
Yes I do, but no programs currently use the "Generic" port, only the
HotSync port (in this case it would be ttyUSB1).
> If so, then why would opening /dev/ttyUSB0 return ENODEV? The open man page
> says:
It shouldn't. Please turn on usb-serial debugging and try this, and
send me the kernel debug log when this happens. If it does it it is a
driver bug and should be fixed.
> From a user's point of view, having to press the hotsync button and then run
> pilot-xfer (etc) within a split second is irritating and easy to miss. I would
> be much happier if the open would block (much like opening a busy /dev/dsp
> blocks) until the device comes online or the call is cancelled.
I agree it's a pain in the butt. So whip up a hotplug script that calls
pilot-xfer when the device is recognized. I do that and it works great.
Someone else posted a way to do this with devfs. Yet another way is the
way gnome-pilot does it, which is by watching the usbdevfs for a change.
This is a user space problem, there is nothing the kernel can do about
it, sorry.
Hope this helps,
greg k-h
--
greg@(kroah|wirex).com
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
