From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: jcaden@libresoft.es
Cc: Santiago Carot-Nemesio <scarot@libresoft.es>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: HDP proposed API
Date: Tue, 4 May 2010 17:50:51 +0300 [thread overview]
Message-ID: <p2h2d5a2c101005040750n6c5ea46dk4722b6ca3bea5543@mail.gmail.com> (raw)
In-Reply-To: <201005041254.37990.jcaden@libresoft.es>
Hi,
On Tue, May 4, 2010 at 1:54 PM, José Antonio Santos Cadenas
<jcaden@libresoft.es> wrote:
> Hi all,
>
> Next a simple example program in python using the api that we proposed in this thread.
>
> We still use the name Device but maybe a better name can be used.
>
> Regards.
>
> ----------
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
>
> import dbus
> import dbus.service
> from dbus.mainloop.glib import DBusGMainLoop
> import gobject
> import os
>
> DBusGMainLoop(set_as_default=True)
> loop = gobject.MainLoop()
>
> obj_path = "/python/tester/hdp"
>
> bus = dbus.SystemBus()
>
> # This object receives the information from the daemon
> class HDP(dbus.service.Object):
> def __init__(self, bus, obj_path):
> self.bus = bus
> dbus.service.Object.__init__(self, self.bus, obj_path)
> @dbus.service.method('org.bluez.HdpAgent',
> in_signature='o', out_signature='',
> sender_keyword='sender')
> def DeviceConnected(self, path, sender=None):
> print "Connected new device %s: (sender %s)" % (path, sender)
> @dbus.service.method('org.bluez.HdpAgent',
> in_signature='o', out_signature='',
> sender_keyword='sender')
> def DeviceDisconnected(self, path, sender=None):
> print "Device %s: disconnected (sender: %s)" % (path, sender)
> @dbus.service.method('org.bluez.HdpAgent',
> in_signature='oq', out_signature='',
> sender_keyword='sender')
> def DeletedDc(self, dev, mdlid, sender=None):
> print "Data channel: %d deleted on dev %s (sender %s)" % \
> (mdlid, dev, sender)
> @dbus.service.method('org.bluez.HdpAgent',
> in_signature='oqh', out_signature='',
> sender_keyword='sender')
> def CreatedDc(self, dev, mdlid, fd, sender=None):
> print "Data channel: %d created on dev %s: fd: %d " % \
> (mdlid, dev, fd, sender)
>
> hdp_obj = HDP(bus, obj_path);
>
> manager = dbus.Interface(bus.get_object("org.bluez", "/"),
> "org.bluez.Manager")
> hdp = dbus.Interface(bus.get_object("org.bluez", manager.DefaultAdapter()),
> "org.bluez.Hdp")
>
> data_spec = 1
> session_path = hdp.CreateSession(obj_path, data_spec)
>
> session = dbus.Interface(bus.get_object("org.bluez", session_path),
> "org.bluez.HdpSession")
>
> # Configuration of the session, adding suported features
> source_role = 0
> mdep = session.AllocateMdep(source_role)
> session.AddFeature(mdep, 4100, "Pulse oximeter")
>
> sink_role = 1 # Sink role
> mdep2 = session.AllocateMdep(sink_role)
> session.AddFeature(mdep2, 4111, "Scale")
> session.AddFeature(mdep2, 4100, "Pulse oximeter sink")
>
> # Now start the session
> # Starts a MCAP session and register in the SDP
> session.Start()
>
> # *****************************************************************************
> # Now, if you start the main loop, the HDP events will be notified in HDP class
> # *****************************************************************************
>
> # Connect to a remote device
> addr = "XX:XX:XX:XX:XX:XX"
Where do I get this address from, and more importantly how do the
application associate that this device supports hdp? To me bdaddr is
meaningless in the API, we have done this mistake before and we
learned the hard way that the API should be convenient to use and
bdaddr hardly is.
> dev_path = session.Connect(addr)
> dev = dbus.Interface(bus.get_object("org.bluez", dev_path),
> "org.bluez.HDPDevice")
>
> dcid = dev.OpenDc(rem_mdep, conf)
> fd = dev.GetDcFd(dcid)
>
> # You can use the fd for write or read data.
> # If the read/write operation fails, reconnection will be performed getting
> # the file descriptor again
>
> while some_condition:
> try:
> os.write(fd, "some_data")
> except:
> fd = dev.GetDcFd(dcid) # Implicit reconeciton of dc
>
> dev.DeleteDc(dcid) # Close data channel
> dev.DeleteAllDc() # Close all data channels for this mcl (device+session)
>
> if power_save:
> session.Disconnect(dev_path, False)
> # Close the connection with the remote devide for power save,
> # Reconnections will be possible
> else:
> session.Disconnect(dev_path, True)
> # Close the connection with the remote devide forever and clean state
> # Reconnections will NOT be possible
IMHO leaving the application to decide when to do save power is a bad idea.
> hdp.DeleteSession(session_path)
> # Close the session, all connections and data channels will be closed
>
Sorry but this is way too complicated for my taste, I guess the one
shared by Elvis sometime ago has more potential because the device
path design is reused, and so is the device driver code I suppose,
which is much more convenient if we want to maintain this upstream.
Instead of trying to figure out alone you 2 should be cooperating.
--
Luiz Augusto von Dentz
Computer Engineer
next prev parent reply other threads:[~2010-05-04 14:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 7:55 HDP proposed API Santiago Carot-Nemesio
2010-05-04 10:04 ` Luiz Augusto von Dentz
2010-05-04 10:13 ` José Antonio Santos Cadenas
2010-05-04 10:54 ` José Antonio Santos Cadenas
2010-05-04 14:50 ` Luiz Augusto von Dentz [this message]
2010-05-05 10:11 ` Santiago Carot-Nemesio
2010-05-05 10:53 ` Santiago Carot-Nemesio
2010-05-05 0:07 ` Elvis Pfützenreuter
2010-05-05 10:57 ` José Antonio Santos Cadenas
2010-05-05 12:13 ` Elvis Pfützenreuter
2010-05-05 13:10 ` Elvis Pfützenreuter
2010-05-05 13:18 ` José Antonio Santos Cadenas
2010-05-05 13:22 ` Elvis Pfützenreuter
2010-05-05 13:36 ` José Antonio Santos Cadenas
2010-05-05 0:32 ` Elvis Pfützenreuter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p2h2d5a2c101005040750n6c5ea46dk4722b6ca3bea5543@mail.gmail.com \
--to=luiz.dentz@gmail.com \
--cc=jcaden@libresoft.es \
--cc=linux-bluetooth@vger.kernel.org \
--cc=scarot@libresoft.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).