On Thu, 2009-10-15 at 11:22 -0300, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Thu, Oct 15, 2009 at 6:38 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> > Same questions as Stefan I'm afraid.
> >
> > In any case, I think the front-ends should be creating the port
> > themselves, so they would know which one to handle.
> >
> > See the recent (and less recent) work done in NetworkManager for DUN
> > support.
>
>
> Basically I want to avoid the code done in NetworkManager, simply
> because it doesn't work for anything but the one that create the port.
> So what Im proposing is that udev take care of setting the
> capabilities to the port, not the applet manually doing it, but to
> make it possible there must be something indicating that it is a port
> to dun profile channel (or spp if that matters).
It's not the applet doing it, but the daemon. And it will run
ModemManager on the device.
> The other suggestion
> is that this port should be somehow stored so it is recreated after
> boot, but as Stefan cleverly point out this would be a bit difficult
> since some device insist in changing the channel/hide the service each
> time the profile got in use, so perhaps it is not a good idea in the
> end.
>
> What Im still missing is how I attach the information to the port so
> that udev properly recognized and nobody has to do workarounds, store
> the return of Serial.Connect("dun") and then wait it to be announced
> by udev, than I can do it directly on bluetoothd and has to duplicate
> this code on front-ends.
That's fine if you want to hack around the device. NM/MM will add the
necessary properties to the udev device when it creates the device.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
