Device information for PDAs

David Zeuthen davidz at redhat.com
Tue Mar 29 14:05:03 PST 2005


On Wed, 2005-03-30 at 02:33 +0400, Andrei Yurkevich wrote:
> The issue with two ports only makes sense on PalmOS PDAs. IIRC, one of
> them is for HotSync while the other can be used for PPP communication
> between the PDA and the PC. Moreover, the Serial Port 0 is used as
> HotSync on certain models (some Sony Clies), while the Port 1 is used on
> all the others. 

OK, so for the 'visor' driver we assume port 1 (like the device
information file I mentioned does) and have a whitelist for devices to
use port 0?

> One more issue are the weird Microsoft Magneto aka
> Pocket PC 2005 devices that will appear later this year. Those beasts
> are going to have a serial device accompanied by a mass-storage
> interface. All the PDA-specific communication will go via the serial
> device while the mass-storage interface will be used to mount their
> filesystem as a storage card or whatever.
> 
> Taking this into account, I suppose that we'd better stick with USB
> interface or even the usb device as the device that represents the PDA
> and making "pda.serial_device" a strlist, storing both ports in case of
> Palm device, 

There's a problem with doing this since it will be difficult to maintain
as the serial port object is created much later than the USB interface
object. There's also the problem on what to do when the serial port
driver (visor, pl2303 etc.) unbinds from the USB interface.

Also, with the approach of storing things on the actual serial port
object it will be much easier to support e.g. Bluetooth, IRDA and legacy
serial devices once HAL gains support for these [1].

So, I'd really like to keep it simple and just put the 'pda' capability
and properties on the serial port device instead - that's really where
they belong IMHO. Can we do this?

> however adding some "pda.palm.hotsync_port" and
> "pda.palm.raw_port" to distinguish between the two. Or, we can even
> treat the port as a platform-specific thing making it
> "pda.palm.hotsync_device" and "pda.palm.raw_device" for PalmOS PDAs and
> "pda.pocketpc.serial_device" for Windows CE PDAs.

I'd rather just assign another capability and set of properties to the
other serial port if we really want to expose this. Is this really
important to support initially?

> > So, Andrei, does this approach work for you? Would it work for the iPaq
> > and Pocket PC's too? If so, would you be interested in extending the
> > 10-usb-pda.fdi file?
> 
> Sure, I would gladly take care of the fdi file for PDAs.

That sounds excellent!

Cheers,
David

[1] : at some point I think that I expressed that we shouldn't have
Bluetooth devices in HAL, but I think I changed my mind - we should have
a list of the Bluetooth devices that is connected and authenticated,
e.g. it would look like

 - UHCI Host Controller
  - USB Bluetooth Adapter
   - USB Interface
    - Bluetooth Host Adapter (e.g. tells that the BT interface is hci0)
     + Bluetooth Mouse (with BT address)
      + Input Device (e.g. /dev/input/event42)
     + Bluetooth PDA (with BT address)
      + Serial Device (e.g. /dev/ttySomeThing)

The device objects marked with a + still needs kernel support to work
with HAL. E.g. one implementation would be a new sysfs bus,
bluetooth_device, and then the logical class devices spawned off (like
the input and serial device at leaf levels above) would link to these
bus devices.



_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list