Bug 104426

access to serial devices will not be granted by default. There could be   
a modem connected which would open a hole for dialers. 
 
if hal is able to detect that the connected device is not a modem but a  
harmless device we can add it by default to some ressource class. Please  
attach output from lshal with the device connected.  
 
camera access is already fixed. 

Created attachment 46023 [details]
output from lshal after pressing HotSync button on a USB Palm m130

The /dev/ttyUSB0 exists only after pressing HotSync button, not after pluging
the Palm into the USB. After HotSync /dev/ttyUSB0 dissapears from /dev again.

The device actually provides two serial ports. ttyUSB1 has additional 
properties that indicate it's a pda. ttyUSB0 looks like a regular serial port. 
So with the current information it's not possible to have a generic match rule 
that could distinguish pda and modem. 

Hmm, those pda properties come 
from /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi 
 
They explicitely match for the second serial port and don't add the properties 
to the first. 

I'll add a pda class to resmgr and include it in class desktop. Then all 
that's needed to support pda access is proper detection from hal, reassigning 
to hal maintainer. 

Yes, on pressing HotSync button, two ports will be created, and the second port
will have the properties of a pda.

Ludwig: is it enough to set  pda.platform = 'palm' for both ports and you match 
in hal-resmgr for this key, or is it also need to add  pda.platform = 'palm' (or 
something else) to the usb-device?

reassign to lnussel: as disccussed, check if there are any security problems. If 
not I change the fdi file for the second serial port, but if there are any 
objection we must use maybe suseplugger for this.

Seems there are too many different devices to be able to determine the correct 
serial port. Let's hope the visor driver only matches actually only pda and 
not some mobile+pda combo devices. I'll add all devices that have pda.platform 
set into the resmgr class pda now. Danny will fix the hal fdi file for pdas so 
both serial ports get that property. 

fixed in the HAL fdi file and pushed upstream. Reassign back to ludwig.

Veerapuram: can you tell me which of the both serial ports is the really hotsync 
interface? ttyUSB0 or ttyUSB1. I would like to add this special case correct to 
the HAL fdi file.

In my case pilot-xfer was able to communicate with ttyUSB0, not with ttyUSB1.
USB Palm m130. I'll wonder if other models are using different tty, but I'm not
sure.
Veerapuram: Is it same in your case?

@Ladislav: can you please attach a output of lshal to the bug?

Already attached in comment #2.

Created attachment 46872 [details]
udev rules

Comment on attachment 46872 [details]
udev rules

Ah!! sorry was on leave.
@Ladislav, @Danny: In my case, it is the second port (i.e,) ttyUSB1. I have
Handspring Visor and Tungsten T5.

Also, I have written a udev rules file for creating a link when such devices
are attached.  Don't know whether that would help you in anyway, however
attaching it here.  Also, I modified the /etc/group file and added the
corresponding user to the uucp group for write access. Will attach lshal output
shortly.

@Ladislav: overlooked the attachment ;)
@Veerapuram: please attach the output of lshal for each of the both devices. Is 
it ttyUSB1 in both cases?

Created attachment 46878 [details]
lshal output after pressing hotsync button in Tungsten T5 

Attaching the log of lshal command after during hotsync operation with Tungsten
T5 palm device.

Created attachment 46882 [details]
lshal output after pressing hotsync button in Handspring Visor (USB cradle)

Attaching the output of lshal during the hotsync operation with Handspring
Visor device (USB cradle).

@Danny: Yes, it is ttyUSB1 (or the second port, in general) for the devices that
I have here.

a new hal-resmgr which adds pdas to resmgr is checked in 

@Veerapuram: Looks like the visor kernel module isn't loaded for the Tungsten T5 
and the Visor. Or is it? If not: is there a special reason? The devices should 
be handled by this module (vendorID and product ID match for this).

Can you please load the module and attach a new version for lshal?

@Veerapuram: is the output of lshal from a SUSE 9.3 ? Looks like a machine with 
a old kernel and like the output of a hal version<=0.4.x

@Danny: <for #22>: The visor module was loaded, however, the device wasn't
syncing because of disabling those udev rules.  Attaching the new logs after
modifying the /etc/group to let the user have proper rights on the usb port.

for #23: Yes, I am using SuSE 9.3 :)

Created attachment 47305 [details]
After adding the user to the uucp group

Created attachment 47306 [details]
After adding the user to the uucp group

o.k. I added the devices for 10.0 to HAL to detect them as pda. Thanks.

No probs.  If you want logs generated in a 10.0, can get you that as well. :)

You could me send them from the upcommit Beta 4 next week to verify if the 
changes work (send them pleas directly).

Sure, the moment I get Beta 4 here, will mail you the logs.  Thanks.