PDAs in HAL (Was: Plans for hal 0.5.x)

David Zeuthen david at fubar.dk
Thu Dec 16 13:45:57 PST 2004

On Thu, 2004-12-16 at 22:29 +0300, Andrei Yurkevich wrote:
> > We would match the USB interface (marked with *) like this (copied of
> > Dave Malcoms list)
> > 
> >   <!-- Aceeca MEZ1000 -->
> >   <device>
> >     <match key="info.bus" string="usb">
> >       <match key="usb.vendor_id" int="0x4766">
> >         <match key="usb.product_id" int="0x0001">
> >           <merge key="info.category" type="string">pda</merge>
> >           <append key="info.capabilities" type="string"> pda</merge>
> >           <merge key="pda.serial.use_net" type="bool">true</merge>
> >           <merge key="pda.access_method=serial" type="bool">true</merge>
> >         </match>
> >       </match>
> >     </match>
> >   </device>
> > 
> > (yes, we will change info.capabilities to be of type 'stringlist' when
> > we get down to that)
> That's just what I do right now. However, the specifications for 
> properties that go into PDAs should be discussed further, but in general 
> this is ok.

OK, I committed this; it looks like this


It would be cool to get the whole list of PDA's that Dave got.

> > OK, so device marked with * now got the capability 'pda' and
> > applications, like gnome-pilot, can query those. Specifically, some
> > devices will have pda.access_method=serial. Now, to actually find the
> > serial device node to use, being ** and ***, we'd need to tag those like
> > this
> > 
> >   <device>
> >     <match key="info.category" string="serial">
> >       <match key="@info.parent:pda.access_method" string="serial">
> >         <append key="info.category" type="string">pda_endpoint_serial</merge>
> >         <append key="info.capabilities" type="string"> pda_endpoint_serial</merge>
> >         <merge key="pda_endpoint_serial.pda_device" type="copy_property">info.parent</merge>
> >       </match>
> >     </match>
> >   </device>
> > 
> > So, that pretty much gives this algorithm for finding PDA's
> > 
> >  1. Find device object of capability 'pda'; this goes into the UI
> > 
> >  2. To actually access the device with UDI=foo (of cap. 'pda') check
> >     whether you support pda.access_method and do the right thing.
> > 
> >     - E.g. if you support pda.access_method=serial, use hal to search
> >       for device objects where pda_endpoint_serial=foo (where foo is
> >       the UID of the 'pda' device object).
> > 
> >     - (for Dave's PDA with two serial interfaces the program would get
> >        two pda_endpoint_serial device objects back - this problem will
> >        be left for the application to deal with; if there are any
> >        properties we can sanely put in hald (e.g. serial.index=0 and
> >        serial.index=1) to help out here, I'm all for it - I do feel I
> >        need to understand why there are two serial lines though).
> I suspect that one of these is a stale serial connection. I don't 
> exactly know how the things are done with Palm devices, but with Pocket 
> PCs you only get a USB Interface node when you plug in the device. You 
> can read the usb-serial device name from it (for example /dev/tts/USB0, 
> but the device entry in /dev is not there yet!). Then you pass that 
> device name to a program that establishes a connection with your PDA 
> over that interface - as that program opens /dev/tts/USB0, udev creates 
> it and after that a 'Serial Port' node appears in HAL device list. If 
> you disconnect the PDA, the connection will not drop instantly, and the 
> 'Serial Port' device will stay there. Now if plug the PDA back in and 
> establish a connection once again, you get another 'Serial Port' device, 
> and so on. So basically, there is no need for pda_endpoint_serial=foo on 
> those serial ports. The 'USB Interface' device entry corresponds to 
> USB-serial device that is used to talk to the PDA and that's enough. On 
> the other hand, those 'Serial Port' devices could be tagged with pid of 
> the process that has established a connection over it, so that it could 
> be terminated when PDA is unplugged (and the serial port entry will go 
> away then).

I can say this is not true for the Palm Tungsten. This device appear as
a USB device exactly when you hit the sync button. And the device nodes
for serial connections appear exactly when the visor driver is bound to
the USB interface. Which is basically momentarily. Also, one could look
in the visor driver why two serial devices are created. 

Of course, other PDA's may user other kernel drivers, but I'm pretty
sure that once the kernel sees the USB device/interface, then the driver
is bound and device nodes are created instantly.


hal mailing list
hal at lists.freedesktop.org

More information about the Hal mailing list