Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB
On Wed, Feb 15, 2006 at 11:25:33AM +0100, Volker Christian wrote: Package: hal Version: 0.4.8-8 Severity: important Connecting a Windows-CE device via USB causes a call to hald-probe-serial. This is bad for a Windows-CE device as hald-probe-serial is trying to open the ttyUSBx device what causes the Windows-CE device to start the connection-initiation-sequence. This sequence couldn't succeed, because no program is waiting for a connection on the pc-side. This wouldn't be that bad if the Windows-CE device would accept a second triggering of the connection-initiation-seqnence by appropriate desktop software (synce-serial). But unfortunately, Windows-CE devices didn't allow a second trigger. Hence, with the present hal-package no USB connection with an Windows-CE device is possible. A proper solution would be the integration of the SynCE package (especially the synce-serial package) into hal, such that synce-serial-start would be called instead of hald-probe-serial on device-connect and that synce-serial-abort would be called after the device is unplugged. Please let me know how we could achieve this goal - or maybe an other appropriate solution. Imho the correct solution for hal is not to probe USB serial ports. The only reason for the serial port prober is that you can't know if /dev/ttyS3 actually corresponds to a real device. But that's not an issue for USB. Now i must admin that i don't know a lot about how synce works, but it's my opinion that hal should remain a facts database and shouldn't start triggering system setup programs. That should be done on a higher level. What do you think ? Sjoerd -- Protozoa are small, and bacteria are small, but viruses are smaller than the both put together. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB
On Thu, Feb 16, 2006 at 05:54:38PM +0100, Volker Christian wrote: On Thursday 16 February 2006 13:53, Sjoerd Simons wrote: Imho the correct solution for hal is not to probe USB serial ports. The only reason for the serial port prober is that you can't know if /dev/ttyS3 actually corresponds to a real device. But that's not an issue for USB. I agree, this is not really an issue for USB. I think this is a todo for upstream, isn't it? :-) Yeah. Now i must admin that i don't know a lot about how synce works, but it's my opinion that hal should remain a facts database and shouldn't start triggering system setup programs. That should be done on a higher level. I agree also. But unfortunately, i am not a udev/hal expert. Could you please give me some hints how i could automate this triggering at a higher level? I am willing to integrate this in the synce software. Desired behaviour: === Everytimes a pda is connected to an usb-port a special command (synce-serial-start) should be called - this initiates a ppp-connection. Everytimes a pda is disconnected from the usb-port an other command (synce-serial-abort) should be called - this shuts down the ppp-connection. This would mean you need to create a small daemon to manage synce devices, which does the following: * On startup, search for pda devices in hal's database, if a valid one is run start synce-serial-start * After that, listen for device-added events from hal. If such an events adds an pda then also start synce-serial-start Sjoerd -- All Finagle Laws may be bypassed by learning the simple art of doing without thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB
On Thursday 16 February 2006 13:53, Sjoerd Simons wrote: On Wed, Feb 15, 2006 at 11:25:33AM +0100, Volker Christian wrote: Package: hal Version: 0.4.8-8 Severity: important Connecting a Windows-CE device via USB causes a call to hald-probe-serial. This is bad for a Windows-CE device as hald-probe-serial is trying to open the ttyUSBx device what causes the Windows-CE device to start the connection-initiation-sequence. This sequence couldn't succeed, because no program is waiting for a connection on the pc-side. This wouldn't be that bad if the Windows-CE device would accept a second triggering of the connection-initiation-seqnence by appropriate desktop software (synce-serial). But unfortunately, Windows-CE devices didn't allow a second trigger. Hence, with the present hal-package no USB connection with an Windows-CE device is possible. A proper solution would be the integration of the SynCE package (especially the synce-serial package) into hal, such that synce-serial-start would be called instead of hald-probe-serial on device-connect and that synce-serial-abort would be called after the device is unplugged. Please let me know how we could achieve this goal - or maybe an other appropriate solution. Imho the correct solution for hal is not to probe USB serial ports. The only reason for the serial port prober is that you can't know if /dev/ttyS3 actually corresponds to a real device. But that's not an issue for USB. I agree, this is not really an issue for USB. I think this is a todo for upstream, isn't it? :-) Now i must admin that i don't know a lot about how synce works, but it's my opinion that hal should remain a facts database and shouldn't start triggering system setup programs. That should be done on a higher level. I agree also. But unfortunately, i am not a udev/hal expert. Could you please give me some hints how i could automate this triggering at a higher level? I am willing to integrate this in the synce software. Desired behaviour: === Everytimes a pda is connected to an usb-port a special command (synce-serial-start) should be called - this initiates a ppp-connection. Everytimes a pda is disconnected from the usb-port an other command (synce-serial-abort) should be called - this shuts down the ppp-connection. What do you think ? As already said above, i completely agree with you. Thank you very much. Volker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB
Package: hal Version: 0.4.8-8 Severity: important Connecting a Windows-CE device via USB causes a call to hald-probe-serial. This is bad for a Windows-CE device as hald-probe-serial is trying to open the ttyUSBx device what causes the Windows-CE device to start the connection-initiation-sequence. This sequence couldn't succeed, because no program is waiting for a connection on the pc-side. This wouldn't be that bad if the Windows-CE device would accept a second triggering of the connection-initiation-seqnence by appropriate desktop software (synce-serial). But unfortunately, Windows-CE devices didn't allow a second trigger. Hence, with the present hal-package no USB connection with an Windows-CE device is possible. A proper solution would be the integration of the SynCE package (especially the synce-serial package) into hal, such that synce-serial-start would be called instead of hald-probe-serial on device-connect and that synce-serial-abort would be called after the device is unplugged. Please let me know how we could achieve this goal - or maybe an other appropriate solution. best regards Volker Christian [EMAIL PROTECTED] Maintainer of the SynCE-packages -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages hal depends on: ii adduser 3.82 Add and remove users and groups ii dbus-10.23.4-8 simple interprocess messaging syst ii dbus-glib-1 0.23.4-8 simple interprocess messaging syst ii libc6 2.3.5-12.1 GNU C Library: Shared libraries an ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libglib2.0-0 2.8.6-1The GLib library of C routines ii libhal-storage0 0.4.8-8Hardware Abstraction Layer - share ii libhal0 0.4.8-8Hardware Abstraction Layer - share ii libpopt0 1.7-5 lib for parsing cmdline parameters ii pciutils 1:2.1.11-15.3 Linux PCI Utilities ii udev 0.070-2/dev/ management daemon ii usbutils 0.71+cvs20051029-4 USB console utilities hal recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
