* Re: HDP proposed API
From: José Antonio Santos Cadenas @ 2010-05-05 13:36 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <E956E54B-C1C5-4FCA-A677-1E549CF3B3D2@signove.com>
El Wednesday 05 May 2010 15:22:16 Elvis Pfützenreuter escribió:
> > So you mean do fd-passing with the pipe file descriptor to the client and then HDP will write the data in the L2CAP socket using splice, am I right?
>
> I guess they meant using splice for the pipe (because as far as I understood, it is for pipes only), so the data exchanged between bluez and application is zero-copy.--
I'm reading splice documentation and I understand that can be used with any type of fd,
but one of the fd should be a pipe. This is ok for that case.
I see one problem. The pipes are unidirectional so for a full duplex data channel
HDP will need two pipes (what means 4 fd and pass 2 to the client, one for read
and other for write). We should find an easy way to solve this. Proposals are
welcome :)
^ permalink raw reply
* Re: Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase
From: Stefan Seyfried @ 2010-05-05 15:02 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth
In-Reply-To: <4BE14819.4080903@greffrath.com>
On Wed, 05 May 2010 12:27:37 +0200
Fabian Greffrath <fabian@greffrath.com> wrote:
> Dear Bluez list,
>
> I am sorry, I know this is the worst way to start getting in touch
> with a software project, but I accidently attached the wrong patch to
> my previous email. It's configure_device() that must be patched.
> Please find a corrected patch attached (it has been written against
> bluez 4.63 but applies perfectly against 4.64).
I have one questions about the code from a cursory look (hint:
sending the patch inline would help commenting on it)
* where does the 249 in "char name[249];" come from? Is it from the BT
spec? Or from somewhere else? A comment in the code might help. (If this
is a number from the spec that is used all over the same code file and
explained elsewhere, this question is obviously moot)
Then it would probably good if you could send the patch against current
git (even if it still applies cleanly) and in a format that "git am" can
process directly. That makes it very easy for the maintainers to apply the
code and in the same run makes sure you get proper attribution for your
contribution ;)
Have fun,
Stefan
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
^ permalink raw reply
* Re: Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase
From: Fabian Greffrath @ 2010-05-05 15:14 UTC (permalink / raw)
To: Stefan Seyfried; +Cc: linux-bluetooth
In-Reply-To: <20100505170202.3d6b1dcb@susi.home.s3e.de>
Am 05.05.2010 17:02, schrieb Stefan Seyfried:
> I have one questions about the code from a cursory look (hint:
> sending the patch inline would help commenting on it)
Alright, I'll know for the next time.
> * where does the 249 in "char name[249];" come from? Is it from the BT
> spec? Or from somewhere else? A comment in the code might help. (If this
> is a number from the spec that is used all over the same code file and
> explained elsewhere, this question is obviously moot)
I took this part of the patch over from tools/hciconfig.c:433 and
indeed I think the fact that a device name may be up to 248 characters
long is part of the BT spec:
<http://www.palowireless.com/infotooth/tutorial/k1_gap.asp#Bluetooth%20Parameter%20Representation>
> Then it would probably good if you could send the patch against current
> git (even if it still applies cleanly) and in a format that "git am" can
> process directly. That makes it very easy for the maintainers to apply the
> code and in the same run makes sure you get proper attribution for your
> contribution ;)
Thanks again. I'd like to get some more feedback for the current patch
and will then repost it in the desired format.
BTW, I'll be on vacation from May 7th to 14th, so please excuse if I
reply with some days delay.
^ permalink raw reply
* choosing SCO parameters at run time
From: takeiteasy @ 2010-05-05 21:57 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I have a question related to SCO packet path configuration for
Bluetooth HSP/HFP profiles. As I understand,
we need to use SCO routing option in etc/bluetooth/audio.conf to
select the voice path to be over HCI or PCM.
It seems the option is configured at the init time.Can I select PCM or
HCI routing at runtime?
One of the ways we are looking at is to have the application layer
make calls to bluez stack via d-bus say in headset.c
to set the relevant variable.
regards
^ permalink raw reply
* Re: choosing SCO parameters at run time
From: Johan Hedberg @ 2010-05-05 22:44 UTC (permalink / raw)
To: takeiteasy; +Cc: linux-bluetooth
In-Reply-To: <h2q995d6c6b1005051457y48748e8am16cb509bd7b6d969@mail.gmail.com>
Hi,
On Wed, May 05, 2010, takeiteasy wrote:
> I have a question related to SCO packet path configuration for
> Bluetooth HSP/HFP profiles. As I understand,
> we need to use SCO routing option in etc/bluetooth/audio.conf to
> select the voice path to be over HCI or PCM.
> It seems the option is configured at the init time.Can I select PCM or
> HCI routing at runtime?
That variable isn't intended to trigger a SCO routing change but to
simply tell BlueZ & Pulse Audio (or whatever audio subsystem you use)
what the hardware platforms configuration is. I.e. the actual routing of
your bluetooth controller needs to be configured separately (and afaik
there's no standard HCI command through which it could be done which
further promotes the idea that BlueZ shouldn't have any code for it).
Johan
^ permalink raw reply
* Re: choosing SCO parameters at run time
From: Marcel Holtmann @ 2010-05-06 4:25 UTC (permalink / raw)
To: Johan Hedberg; +Cc: takeiteasy, linux-bluetooth
In-Reply-To: <20100505223214.GA3699@jh-x301>
Hi Johan,
> > I have a question related to SCO packet path configuration for
> > Bluetooth HSP/HFP profiles. As I understand,
> > we need to use SCO routing option in etc/bluetooth/audio.conf to
> > select the voice path to be over HCI or PCM.
> > It seems the option is configured at the init time.Can I select PCM or
> > HCI routing at runtime?
>
> That variable isn't intended to trigger a SCO routing change but to
> simply tell BlueZ & Pulse Audio (or whatever audio subsystem you use)
> what the hardware platforms configuration is. I.e. the actual routing of
> your bluetooth controller needs to be configured separately (and afaik
> there's no standard HCI command through which it could be done which
> further promotes the idea that BlueZ shouldn't have any code for it).
in theory this is possible and I know of a few chips that can change the
routing before establishing the SCO link. However this is all highly
vendor specific and needs extensive kernel and driver support.
So while possible, I haven't seen it in practice at all. Especially with
modern chips supports more than one SCO over PCM.
Regards
Marcel
^ permalink raw reply
* [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 5:22 UTC (permalink / raw)
To: linux-bluetooth
Hi!
My USB bluetooth adapter stopped working with new versions of bluez.
Latest version which works is 4.32.
I initially reported bug for ubuntu package in launchpad here
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
i tried also opensuse livecd and problem remained there too, so looks
like it's not ubuntu specific.
jhe at #bluez-devel suggested to me to collect hcidump output on
bluetoothd startup, and then write to this mailinglist. I attached
suggested hcidumps for bluez versions 4.64 and 4.32, and looks like
4.64 stops initialization process after it cannot read parameter
'Default Link Policy Settings' from device.
Can you please take a look at this bug?
Thanks in advance.
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: Santiago Carot-Nemesio @ 2010-05-06 7:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, epx, claudio.takahasi, jcaden
In-Reply-To: <201005051255.09394.jcaden@libresoft.es>
Hi,
El mié, 05-05-2010 a las 12:55 +0200, José Antonio Santos Cadenas
escribió:
> Hi all,
>
> Here is a new proposoal that tries to integrate all that have been comented
> and proposed in the list, as well as we talked yesterday on the IRC.
>
> There is still one thing that should be discussed, the fd passin issue.
> We think that we must talk about this and find the best way for
> the implementation as Elvis sugested.
>
> Regards.
>
> ---------------------------------------
>
> BlueZ D-Bus HDP API description
> ***********************************
>
> Health Device Profile hierarchy
> ===============================
>
> Service org.bluez
> Interface org.bluez.Hdp
> Object path [variable prefix]/{hci0,hci1,...}
>
> Methods object CreateSession(object path, dict config)
>
> Returns the object path for the new HDP session.
> The path parameter is the path of the remote object
> with the callbacks to nofity events (see
> org.bluez.HdpAgent at the end of this document)
> This petition starts an mcap session and also register
> in the SDP is needed
> Dict is defined as bellow:
> { "data_spec" : The data_spec is the data exchange
> specficication (see section 5.2.10 of
> the specification document),
> (optional)
> "end_points" : [{ (optional)
> "mdepid" : uint8, (optional)
> "role" : uint8, (mandatory)
> "specs" :[{ (mandatory)
> "dtype" : uint16, (mandatory)
> "description" : string, (optional)
> }]
> }]
> }
>
> if "data_spec" is not set, no SDP record will be
> registerd, so all the other data in the dictionary
> will be ignored
>
> Session will be closed by the call or implicitly when
> the programs leaves the bus.
>
> Possible errors: org.bluez.Error.InvalidArguments
>
> void DeleteSession(object path)
>
> Delete the HDP session identified by the object path.
> Also session will be closed if the procces that started
> it is removed from the D-Bus.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
>
> array remote_session_properties GetRemotesSessions()
>
> Returns an array with the remote session_properties
> of all the visible devices.
> remote_session_properties is a dictionary like:
> [{"session_id": a_session_identification (int or string,
> probably the SDP handler + btaddr)
> "data_spec" : the remote data spec,
> "end_points":
> ["mdepid": uint8,
> "role" : uint8,
> "specs" : [{
> "dtype" : uint16,
> "description" : string, (optional)
> }]
> ]
> }]
>
> Note that only remotes with a SDP record will be
> notified by this function.
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.HdpSession
> Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}
>
> object Connect(remote_session_id)
>
> Connects with the remote session and returns its object
> path.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.HdpError
>
> void Disconnect(object device, boolean delete)
>
> Disconnect from the remote device. If delete is true, any
> status will also be deleted. Otherwise, the status will
> be keeped for allowing future reconnections.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.HdpRemoteSession
> Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}/rem_session_id
>
> boolean Echo(array{byte})
>
> Sends an echo petition to the remote session. Return True
> if response matches with the buffer sended. If some error
> is detected False value is returned and the associated
> MCL is closed.
>
> uint16 OpenDc(byte mdepid, byte config)
>
> Creates a new data channel with the indicated config
> to the remote MCAP Data End Point (MDEP).
> The configuration should indicate the channel quality of
> service.
> Returns the data channel id.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.HdpError
>
> file_descriptor GetDcFd(uint16 mdlid)
>
> Gets a file descriptor where data can be readed or
> writed for receive or sent by the data channel.
> Returns the file descriptor
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> void DeleteDc(uint16 mdlid)
>
> Deletes a data channel so it will not be available for
> use.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> void DeleteAllDc()
>
> Deletes all data channels so it will not be available
> for use. Typically this function is called when the
> connection with the remote device will be closed
> permanently
>
> Possible errors: org.bluez.Error.HdpError
>
> uint16 FirstRelDc()
>
> Returns the identificator of the first reliable data
> channel (ERTM) connected for this device.
>
> Possible errors: org.bluez.Error.HdpError
I miss a method to get a ReliableChannel, not only the first reliable
used for association, confirmed services, faults or abnormal conditions
defined in iso/ieee11073-20601. May be better next method instead above
one:
uint16 GetReliableDc(boolean first)
Returns the identificator of a reliable data
channel (ERTM) connected for this device. If first
is True, the first reliable data channel file
descriptor is returned.
Possible errors: org.bluez.Error.HdpError
Some coments?
>
> uint16 GetBestEfforDc()
>
> Returns the id of a best effort (streamming) data
> channel if any.
>
> Possible errors: org.bluez.Error.NotFound
>
> array getStatus()
>
> Returns an array with all the data channels available
>
> returned array:
> [uint16, ...]
>
> Possible errors: org.bluez.Error.NotFound
>
> HDPAgent hierarchy
> ==================
>
> (this object is implemented by the HDP client an receives notifications)
>
> Service unique name
> Interface org.bluez.HdpAgent
> Object path freely definable
>
> void DeviceConnected(object path)
>
> This method is called whenever a new device connection
> has been established over the control channel of the
> current HDP session. The objectpath contains the object
> path of the remote device.
>
> void DeviceDisconnected(object path)
>
> This method is called when a remote device is
> disconnected definitively. Any future reconnections
> will fail. Also all data channels associated to this
> device will be closed.
>
> void CreatedDc(object path, uint16 mdlid, filedescriptor fd)
>
> This method is called when a new data channel is created
> The path contains the object path of the device whith
> the new connection is created, the mdlid the data
> channel identificator and the fd is the file descriptor
> where the data can be readed or writed.
>
> void DeletedDc(object path, uint16 mdlid)
>
> This method is called when a data channel is closed.
> After this call the data channel will not be valid and
> can be reused for future created data channels.
>
> void DataReady(object path, uint16 mdlid, filedescriptor fd)
>
> This method is called when there is new data that can be
> readed in a data channel
>
> void RemoteSession(dict remote_session_properties)
>
> This methos is called when a new session is discorevered
> in a remote device. See Hdp.GetRemotes to know how the
> dictionary is formed.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [bugreport]
From: Fabian Greffrath @ 2010-05-06 7:34 UTC (permalink / raw)
To: Serhiy Kachaniuk; +Cc: linux-bluetooth
In-Reply-To: <p2q793f89501005052222u4393c8dfhb55bea4454c454b9@mail.gmail.com>
Am 06.05.2010 07:22, schrieb Serhiy Kachaniuk:
> My USB bluetooth adapter stopped working with new versions of bluez.
> Latest version which works is 4.32.
> I initially reported bug for ubuntu package in launchpad here
> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/453885 , but then
> i tried also opensuse livecd and problem remained there too, so looks
> like it's not ubuntu specific.
Could you please post the output of 'sudo hciconfig -a'? I am
especially interested in the Name part.
^ permalink raw reply
* buffer starvation with multiple ACL link
From: suraj @ 2010-05-06 7:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Luis.Rodriguez, Jothikumar.Mothilal
In-Reply-To: <1273062798.19162.6.camel@atheros013-desktop>
Hi,
I am seeing a strange issue with multiple ACL connection with CSR chip.
I am having 2 ACL link, one with FTP going on and another streaming
A2DP.
The moment the A2DP link goes out of range ,I see that the FTP also
stops. It resumes as soon as A2DP comes back in range.
On further analysis I could verify that since the A2DP link is
blocked( due to remote being OoR) the controller's ACL buffers with A2DP
data are stuck.
But at the host level this is not considered and Bluez keeps sending
A2DP data until it blocks all the ACL buffers which in turns blocks FTP
also.
I was expecting controller to flush these packets sometime and free the
A2DP buffers. Not sure, what is the default Flush timeout value.
Do we have any patch for this issue?
Regards
Suraj
^ permalink raw reply
* [PATCH] MCAP: Added default abort callback
From: Jose Antonio Santos Cadenas @ 2010-05-06 8:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <1272962595-4108-1-git-send-email-sancane@gmail.com>
Also check if mcl was closed during a callback
---
mcap/mcap.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/mcap/mcap.c b/mcap/mcap.c
index 5068054..404d7be 100644
--- a/mcap/mcap.c
+++ b/mcap/mcap.c
@@ -183,6 +183,10 @@ static void default_mdl_deleted_cb(struct mcap_mdl *mdl, gpointer data)
{
debug("MCAP Unmanaged mdl deleted");
}
+static void default_mdl_aborted_cb(struct mcap_mdl *mdl, gpointer data)
+{
+ debug("MCAP Unmanaged mdl aborted");
+}
static uint8_t default_mdl_conn_req_cb(struct mcap_mcl *mcl,
uint8_t mdepid, uint16_t mdlid,
uint8_t *conf, gpointer data)
@@ -207,6 +211,7 @@ static void set_default_cb(struct mcap_mcl *mcl)
mcl->cb->mdl_connected = default_mdl_connected_cb;
mcl->cb->mdl_closed = default_mdl_closed_cb;
mcl->cb->mdl_deleted = default_mdl_deleted_cb;
+ mcl->cb->mdl_aborted = default_mdl_aborted_cb;
mcl->cb->mdl_conn_req = default_mdl_conn_req_cb;
mcl->cb->mdl_reconn_req = default_mdl_reconn_req_cb;
}
@@ -1045,11 +1050,13 @@ static void process_md_create_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32
/* Callback to upper layer */
rsp = mcl->cb->mdl_conn_req(mcl, mdep_id, mdl_id, &conf,
mcl->cb->user_data);
+ if (mcl->state == MCL_IDLE)
+ return;
if ((cfga != 0) && (cfga != conf)) {
/* Remote device set default configuration but upper profile */
/* has changed it. Protocol Error: force closing the MCL by */
- /* using remote device using UNESPECIFIED_ERROR response */
+ /* remote device using UNESPECIFIED_ERROR response */
send4B_cmd(mcl, MCAP_MD_CREATE_MDL_RSP, MCAP_UNESPECIFIED_ERROR,
mdl_id);
return;
@@ -1102,6 +1109,9 @@ static void process_md_reconnect_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
/* Callback to upper layer */
rsp = mcl->cb->mdl_reconn_req(mdl, mcl->cb->user_data);
+ if (mcl->state == MCL_IDLE)
+ return;
+
if (rsp != MCAP_SUCCESS) {
send4B_cmd(mcl, MCAP_MD_CREATE_MDL_RSP, rsp, mdl_id);
return;
@@ -1734,12 +1744,7 @@ static gboolean mcl_control_cb(GIOChannel *chan, GIOCondition cond, gpointer dat
int sk, len;
uint8_t buf[MCAP_CC_MTU];
- if (cond & G_IO_NVAL) {
- error("Revise G_IO_NVAL");
- goto fail;
- }
-
- if (cond & (G_IO_ERR | G_IO_HUP))
+ if (cond & (G_IO_ERR | G_IO_HUP | G_IO_NVAL))
goto fail;
sk = g_io_channel_unix_get_fd(chan);
--
1.7.0.4
^ permalink raw reply related
* Re: [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 9:56 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <4BE270EE.5080306@greffrath.com>
2010/5/6 Fabian Greffrath:
> Could you please post the output of 'sudo hciconfig -a'? I am especially
> interested in the Name part.
>
For bluez version 4.60 (I'm at work now, i have 4.64 version only at home):
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING
RX bytes:664 acl:0 sco:0 events:18 errors:0
TX bytes:73 acl:0 sco:0 commands:19 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)
And for 4.32:
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN
RX bytes:1362 acl:0 sco:0 events:46 errors:0
TX bytes:693 acl:0 sco:0 commands:47 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'Broadcom BCM2035'
Class: 0x0a0100
Service Classes: Networking, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x3 LMP Ver: 1.1 (0x1) LMP Subver: 0x800
Manufacturer: Broadcom Corporation (15)
^ permalink raw reply
* Re: [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 10:01 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth
In-Reply-To: <4BE270EE.5080306@greffrath.com>
2010/5/6 Fabian Greffrath:
> Could you please post the output of 'sudo hciconfig -a'? I am especially
> interested in the Name part.
>
Interesting moment: when run without sudo with version 4.60 it shows
name, but prints error on getting class of device:
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING
RX bytes:3059 acl:0 sco:0 events:70 errors:0
TX bytes:797 acl:0 sco:0 commands:75 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'Broadcom BCM2035'
Can't read class of device on hci0: Connection timed out (110)
^ permalink raw reply
* Re: [bugreport]
From: Fabian Greffrath @ 2010-05-06 10:05 UTC (permalink / raw)
To: Serhiy Kachaniuk; +Cc: linux-bluetooth
In-Reply-To: <y2t793f89501005060301t9bdc8c73v266a798160027d4d@mail.gmail.com>
Am 06.05.2010 12:01, schrieb Serhiy Kachaniuk:
> Interesting moment: when run without sudo with version 4.60 it shows
> name, but prints error on getting class of device:
Maybe a stupid question, but do you have an application like GNOME's
bluetooth applet running (that keeps the shared lib in memory) while
switching bluez versions?
^ permalink raw reply
* Re: [bugreport]
From: Bastien Nocera @ 2010-05-06 10:11 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: Serhiy Kachaniuk, linux-bluetooth
In-Reply-To: <4BE2947F.9030103@greffrath.com>
On Thu, 2010-05-06 at 12:05 +0200, Fabian Greffrath wrote:
> Am 06.05.2010 12:01, schrieb Serhiy Kachaniuk:
> > Interesting moment: when run without sudo with version 4.60 it shows
> > name, but prints error on getting class of device:
>
> Maybe a stupid question, but do you have an application like GNOME's
> bluetooth applet running (that keeps the shared lib in memory) while
> switching bluez versions?
gnome-bluetooth doesn't use libbluetooth, and a newly started app would
be using the library that's on disk anyway, not the one in memory if
they were different (you could see that in lsof which would show an
older running application as using the library with a "(deleted)"
comment).
^ permalink raw reply
* Re: [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 10:18 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth
In-Reply-To: <4BE2947F.9030103@greffrath.com>
2010/5/6 Fabian Greffrath:
> Maybe a stupid question, but do you have an application like GNOME's
> bluetooth applet running (that keeps the shared lib in memory) while
> switching bluez versions?
>
Yeah, kbluetooth was running, but switching bluez version implies
bluetoothd restart.
Anyway, here is what i get after terminating kbluetooth and manually
stopping and starting bluetoothd:
First run without sudo:
$ hciconfig -a
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING
RX bytes:664 acl:0 sco:0 events:18 errors:0
TX bytes:73 acl:0 sco:0 commands:19 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)
Second run without sudo:
$ hciconfig -a
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING
RX bytes:664 acl:0 sco:0 events:18 errors:0
TX bytes:77 acl:0 sco:0 commands:20 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)
Third run without sudo, and 'Name:' appears:
$ hciconfig -a
hci0: Type: USB
BD Address: 00:1A:7D:0A:C8:8A ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING
RX bytes:664 acl:0 sco:0 events:18 errors:0
TX bytes:83 acl:0 sco:0 commands:21 errors:0
Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'Broadcom BCM2035'
Can't read class of device on hci0: Connection timed out (110)
Same result with sudo: first one or two runs didn't get name, but later did
^ permalink raw reply
* Re: [bugreport]
From: Fabian Greffrath @ 2010-05-06 10:20 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Serhiy Kachaniuk, linux-bluetooth
In-Reply-To: <1273140706.13354.1376.camel@localhost.localdomain>
Am 06.05.2010 12:11, schrieb Bastien Nocera:
> gnome-bluetooth doesn't use libbluetooth, and a newly started app would
> be using the library that's on disk anyway, not the one in memory if
> they were different (you could see that in lsof which would show an
> older running application as using the library with a "(deleted)"
> comment).
Alright, thanks for the clarification. ;)
^ permalink raw reply
* Re: [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 10:32 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth
In-Reply-To: <4BE298C4.7090904@greffrath.com>
2010/5/6 Fabian Greffrath:
> Next stupid question: You know that your adapter requires the
> "bluez-firmware" package?
>
Hum, ubuntu doesn't have such a package, and with bluez 4.32 this
dongle works ok without it... But i can try to install it from
sources.
^ permalink raw reply
* Re: [bugreport]
From: Fabian Greffrath @ 2010-05-06 10:34 UTC (permalink / raw)
To: Serhiy Kachaniuk; +Cc: linux-bluetooth
In-Reply-To: <g2n793f89501005060332o92891cfodefea94611b1e642@mail.gmail.com>
Am 06.05.2010 12:32, schrieb Serhiy Kachaniuk:
> Hum, ubuntu doesn't have such a package, and with bluez 4.32 this
> dongle works ok without it... But i can try to install it from
> sources.
There is a Debian package, maybe you should try it out:
<http://packages.debian.org/sid/bluez-firmware>
^ permalink raw reply
* Re: [bugreport]
From: Serhiy Kachaniuk @ 2010-05-06 10:39 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth
In-Reply-To: <4BE29B51.80304@greffrath.com>
2010/5/6 Fabian Greffrath:
> There is a Debian package, maybe you should try it out:
> <http://packages.debian.org/sid/bluez-firmware>
>
Installed it, but no change :(
package installs this files:
/lib/firmware/BCM2033-MD.hex
/lib/firmware/BCM2033-FW.bin
/lib/firmware/STLC2500_R4_00_03.ptc
/lib/firmware/STLC2500_R4_00_06.ssf
/lib/firmware/STLC2500_R4_02_02_WLAN.ssf
/lib/firmware/STLC2500_R4_02_04.ptc
but my adapter's name is Broadcom BCM2035, not BCM2033
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: Santiago Carot-Nemesio @ 2010-05-06 12:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, epx, claudio.takahasi, jcaden
In-Reply-To: <1273129699.2094.12.camel@mosquito>
El jue, 06-05-2010 a las 09:08 +0200, Santiago Carot-Nemesio escribió:
> Hi,
>
> El mié, 05-05-2010 a las 12:55 +0200, José Antonio Santos Cadenas
> escribió:
> > Hi all,
> >
> > Here is a new proposoal that tries to integrate all that have been comented
> > and proposed in the list, as well as we talked yesterday on the IRC.
> >
> > There is still one thing that should be discussed, the fd passin issue.
> > We think that we must talk about this and find the best way for
> > the implementation as Elvis sugested.
> >
> > Regards.
> >
> > ---------------------------------------
> >
> > BlueZ D-Bus HDP API description
> > ***********************************
> >
> > Health Device Profile hierarchy
> > ===============================
> >
> > Service org.bluez
> > Interface org.bluez.Hdp
> > Object path [variable prefix]/{hci0,hci1,...}
> >
> > Methods object CreateSession(object path, dict config)
> >
> > Returns the object path for the new HDP session.
> > The path parameter is the path of the remote object
> > with the callbacks to nofity events (see
> > org.bluez.HdpAgent at the end of this document)
> > This petition starts an mcap session and also register
> > in the SDP is needed
> > Dict is defined as bellow:
> > { "data_spec" : The data_spec is the data exchange
> > specficication (see section 5.2.10 of
> > the specification document),
> > (optional)
> > "end_points" : [{ (optional)
> > "mdepid" : uint8, (optional)
> > "role" : uint8, (mandatory)
> > "specs" :[{ (mandatory)
> > "dtype" : uint16, (mandatory)
> > "description" : string, (optional)
> > }]
> > }]
> > }
> >
> > if "data_spec" is not set, no SDP record will be
> > registerd, so all the other data in the dictionary
> > will be ignored
> >
> > Session will be closed by the call or implicitly when
> > the programs leaves the bus.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> >
> > void DeleteSession(object path)
> >
> > Delete the HDP session identified by the object path.
> > Also session will be closed if the procces that started
> > it is removed from the D-Bus.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> >
> > array remote_session_properties GetRemotesSessions()
> >
> > Returns an array with the remote session_properties
> > of all the visible devices.
> > remote_session_properties is a dictionary like:
> > [{"session_id": a_session_identification (int or string,
> > probably the SDP handler + btaddr)
> > "data_spec" : the remote data spec,
> > "end_points":
> > ["mdepid": uint8,
> > "role" : uint8,
> > "specs" : [{
> > "dtype" : uint16,
> > "description" : string, (optional)
> > }]
> > ]
> > }]
> >
> > Note that only remotes with a SDP record will be
> > notified by this function.
> >
> > --------------------------------------------------------------------------------
> >
> > Service org.bluez
> > Interface org.bluez.HdpSession
> > Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}
> >
> > object Connect(remote_session_id)
> >
> > Connects with the remote session and returns its object
> > path.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.HdpError
> >
> > void Disconnect(object device, boolean delete)
> >
> > Disconnect from the remote device. If delete is true, any
> > status will also be deleted. Otherwise, the status will
> > be keeped for allowing future reconnections.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HdpError
> >
> > --------------------------------------------------------------------------------
> >
> > Service org.bluez
> > Interface org.bluez.HdpRemoteSession
> > Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}/rem_session_id
> >
> > boolean Echo(array{byte})
> >
> > Sends an echo petition to the remote session. Return True
> > if response matches with the buffer sended. If some error
> > is detected False value is returned and the associated
> > MCL is closed.
> >
> > uint16 OpenDc(byte mdepid, byte config)
> >
> > Creates a new data channel with the indicated config
> > to the remote MCAP Data End Point (MDEP).
> > The configuration should indicate the channel quality of
> > service.
> > Returns the data channel id.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.HdpError
> >
> > file_descriptor GetDcFd(uint16 mdlid)
> >
> > Gets a file descriptor where data can be readed or
> > writed for receive or sent by the data channel.
> > Returns the file descriptor
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HdpError
> >
> > void DeleteDc(uint16 mdlid)
> >
> > Deletes a data channel so it will not be available for
> > use.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HdpError
> >
> > void DeleteAllDc()
> >
> > Deletes all data channels so it will not be available
> > for use. Typically this function is called when the
> > connection with the remote device will be closed
> > permanently
> >
> > Possible errors: org.bluez.Error.HdpError
> >
> > uint16 FirstRelDc()
> >
> > Returns the identificator of the first reliable data
> > channel (ERTM) connected for this device.
> >
> > Possible errors: org.bluez.Error.HdpError
>
> I miss a method to get a ReliableChannel, not only the first reliable
> used for association, confirmed services, faults or abnormal conditions
> defined in iso/ieee11073-20601. May be better next method instead above
> one:
>
> uint16 GetReliableDc(boolean first)
>
> Returns the identificator of a reliable data
> channel (ERTM) connected for this device. If first
> is True, the first reliable data channel file
> descriptor is returned.
>
> Possible errors: org.bluez.Error.HdpError
>
> Some coments?
>
> >
> > uint16 GetBestEfforDc()
> >
> > Returns the id of a best effort (streamming) data
> > channel if any.
> >
> > Possible errors: org.bluez.Error.NotFound
> >
> > array getStatus()
> >
> > Returns an array with all the data channels available
> >
> > returned array:
> > [uint16, ...]
> >
> > Possible errors: org.bluez.Error.NotFound
Because different quality of service is used for specific data traffic
in iso/ieee11073-20601, its possible that applications only are
interested in to get one kind of data channel. May be that above three
functions can be defined like next two:
array GetReliableDc()
Returns an array with all the data channels with ERTM
configuration. First of all is the FirstReliable channel
used for specific traffic.
Possible errors: org.bluez.Error.HdpError
array GetBestEffortDc()
Returns an array with all the data channels with Straming
configuration.
Possible errors: org.bluez.Error.HdpError
Whit this change I don't see neccessary the getStatus() function.
What do you think?
> >
> > HDPAgent hierarchy
> > ==================
> >
> > (this object is implemented by the HDP client an receives notifications)
> >
> > Service unique name
> > Interface org.bluez.HdpAgent
> > Object path freely definable
> >
> > void DeviceConnected(object path)
> >
> > This method is called whenever a new device connection
> > has been established over the control channel of the
> > current HDP session. The objectpath contains the object
> > path of the remote device.
> >
> > void DeviceDisconnected(object path)
> >
> > This method is called when a remote device is
> > disconnected definitively. Any future reconnections
> > will fail. Also all data channels associated to this
> > device will be closed.
> >
> > void CreatedDc(object path, uint16 mdlid, filedescriptor fd)
> >
> > This method is called when a new data channel is created
> > The path contains the object path of the device whith
> > the new connection is created, the mdlid the data
> > channel identificator and the fd is the file descriptor
> > where the data can be readed or writed.
> >
> > void DeletedDc(object path, uint16 mdlid)
> >
> > This method is called when a data channel is closed.
> > After this call the data channel will not be valid and
> > can be reused for future created data channels.
> >
> > void DataReady(object path, uint16 mdlid, filedescriptor fd)
> >
> > This method is called when there is new data that can be
> > readed in a data channel
> >
> > void RemoteSession(dict remote_session_properties)
> >
> > This methos is called when a new session is discorevered
> > in a remote device. See Hdp.GetRemotes to know how the
> > dictionary is formed.
>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase
From: Fabian Greffrath @ 2010-05-06 14:42 UTC (permalink / raw)
To: Stefan Seyfried; +Cc: linux-bluetooth
In-Reply-To: <20100505170202.3d6b1dcb@susi.home.s3e.de>
Hi bluez,
Am Mittwoch, den 05.05.2010, 17:02 +0200 schrieb Stefan Seyfried:
> Then it would probably good if you could send the patch against current
> git (even if it still applies cleanly) and in a format that "git am" can
> process directly. That makes it very easy for the maintainers to apply the
> code and in the same run makes sure you get proper attribution for your
> contribution ;)
I have reapplied my patch against current git, I have replaced the
obscure 249 in "char name[249];" by MAX_NAME_LENGTH as defined in
src/adapter.h and I am now posting it inline. Happy reviewing! ;)
>From 5447e55aeeda8a2307de0b7765abd8883c5f16a9 Mon Sep 17 00:00:00 2001
From: Fabian Greffrath <fabian+bluez@greffrath.com>
Date: Thu, 6 May 2010 16:37:43 +0200
Subject: [PATCH] Instantly fix non-UTF-8 local device names during device configuration phase
---
plugins/hciops.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 05c3d4e..836c291 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -81,6 +81,7 @@ static void configure_device(int index)
struct hci_dev_info di;
uint16_t policy;
int dd, err;
+ char name[MAX_NAME_LENGTH + 1];
if (hci_devinfo(index, &di) < 0)
return;
@@ -96,6 +97,30 @@ static void configure_device(int index)
return;
}
+ if (hci_read_local_name(dd, sizeof(name), name, 1000) < 0) {
+ error("Can't read local name on hci%d: %s (%d)\n",
+ index, strerror(errno), errno);
+ return;
+ }
+
+ name[MAX_NAME_LENGTH] = '\0';
+
+ if (!g_utf8_validate(name, -1, NULL)) {
+ char *utf8_name;
+
+ utf8_name = g_convert(name, -1, "UTF-8", "ISO-8859-1", NULL, NULL, NULL);
+ if (utf8_name) {
+ debug("Fix invalid non-UTF-8 device name \"%s\" on hci%d to \"%s\"",
+ name, index, utf8_name);
+ if (hci_write_local_name(dd, utf8_name, 2000) < 0) {
+ error("Can't change local name on hci%d: %s (%d)\n",
+ index, strerror(errno), errno);
+ return;
+ }
+ g_free(utf8_name);
+ }
+ }
+
/* Set page timeout */
if ((main_opts.flags & (1 << HCID_SET_PAGETO))) {
write_page_timeout_cp cp;
--
1.7.1
^ permalink raw reply related
* Re: Detect invalid (i.e. non-UTF-8) device names and fix them during initialization phase
From: Johan Hedberg @ 2010-05-06 15:03 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: Stefan Seyfried, linux-bluetooth
In-Reply-To: <1273156964.25110.1.camel@vfrodo>
Hi,
On Thu, May 06, 2010, Fabian Greffrath wrote:
> Am Mittwoch, den 05.05.2010, 17:02 +0200 schrieb Stefan Seyfried:
> > Then it would probably good if you could send the patch against current
> > git (even if it still applies cleanly) and in a format that "git am" can
> > process directly. That makes it very easy for the maintainers to apply the
> > code and in the same run makes sure you get proper attribution for your
> > contribution ;)
>
> I have reapplied my patch against current git, I have replaced the
> obscure 249 in "char name[249];" by MAX_NAME_LENGTH as defined in
> src/adapter.h and I am now posting it inline. Happy reviewing! ;)
BlueZ will (or at least should) set the name for the adapter as follows:
1. If there's a name in /var/lib/bluetooth/... use that
2. Else if there's a name in main.conf use that
3. If all else fails set the name to "BlueZ"
So I fail to see why this patch is needed at all. It sounds like there's
something else wrong in the initialization process which makes the
initialzation fail if the adapter contains some invalid default name (we
shouldn't as far as I see be trying to read the name at all from the
adapter before we've written it ourselves from the host side). I.e. I
suspect the patch might be just working around the real issue instead of
fixing it.
Johan
^ permalink raw reply
* Re: choosing SCO parameters at run time
From: takeiteasy @ 2010-05-06 18:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1273119951.22838.298.camel@localhost.localdomain>
On Wed, May 5, 2010 at 9:25 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johan,
>
>> > I have a question related to SCO packet path configuration for
>> > Bluetooth HSP/HFP profiles. As I understand,
>> > we need to use SCO routing option in etc/bluetooth/audio.conf to
>> > select the voice path to be over HCI or PCM.
>> > It seems the option is configured at the init time.Can I select PCM or
>> > HCI routing at runtime?
>>
>> That variable isn't intended to trigger a SCO routing change but to
>> simply tell BlueZ & Pulse Audio (or whatever audio subsystem you use)
>> what the hardware platforms configuration is. I.e. the actual routing of
>> your bluetooth controller needs to be configured separately (and afaik
>> there's no standard HCI command through which it could be done which
>> further promotes the idea that BlueZ shouldn't have any code for it).
>
> in theory this is possible and I know of a few chips that can change the
> routing before establishing the SCO link. However this is all highly
> vendor specific and needs extensive kernel and driver support.
>
> So while possible, I haven't seen it in practice at all. Especially with
> modern chips supports more than one SCO over PCM.
>
> Regards
>
> Marcel
>
>
>
Hi,
We know we can change the routing in hardware (over pcm/hci) but still
we want to know
if we can get a provision/interface in the stack to change this
particular variable dynamically.
If we need to do it ourselves, is it appropriate to put the dbus based
call in headset.c (or)
do we need to take care in other places?
regards
^ permalink raw reply
* [PATCH] Changed MDP profile name and macros to HDP
From: Elvis Pfützenreuter @ 2010-05-06 20:38 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
lib/sdp.c | 6 +++---
lib/sdp.h | 12 ++++++------
tools/sdptool.c | 6 +++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/sdp.c b/lib/sdp.c
index aa22c63..ca3b4c4 100644
--- a/lib/sdp.c
+++ b/lib/sdp.c
@@ -201,9 +201,9 @@ static struct tupla ServiceClass[] = {
{ VIDEO_SOURCE_SVCLASS_ID, "Video Source" },
{ VIDEO_SINK_SVCLASS_ID, "Video Sink" },
{ VIDEO_DISTRIBUTION_SVCLASS_ID, "Video Distribution" },
- { MDP_SVCLASS_ID, "MDP" },
- { MDP_SOURCE_SVCLASS_ID, "MDP Source" },
- { MDP_SINK_SVCLASS_ID, "MDP Sink" },
+ { HDP_SVCLASS_ID, "HDP" },
+ { HDP_SOURCE_SVCLASS_ID, "HDP Source" },
+ { HDP_SINK_SVCLASS_ID, "HDP Sink" },
{ APPLE_AGENT_SVCLASS_ID, "Apple Agent" },
{ 0 }
};
diff --git a/lib/sdp.h b/lib/sdp.h
index 5b2901f..9c15ace 100644
--- a/lib/sdp.h
+++ b/lib/sdp.h
@@ -140,9 +140,9 @@ extern "C" {
#define VIDEO_SOURCE_SVCLASS_ID 0x1303
#define VIDEO_SINK_SVCLASS_ID 0x1304
#define VIDEO_DISTRIBUTION_SVCLASS_ID 0x1305
-#define MDP_SVCLASS_ID 0x1400
-#define MDP_SOURCE_SVCLASS_ID 0x1401
-#define MDP_SINK_SVCLASS_ID 0x1402
+#define HDP_SVCLASS_ID 0x1400
+#define HDP_SOURCE_SVCLASS_ID 0x1401
+#define HDP_SINK_SVCLASS_ID 0x1402
#define APPLE_AGENT_SVCLASS_ID 0x2112
/*
@@ -212,9 +212,9 @@ extern "C" {
#define VIDEO_SOURCE_PROFILE_ID VIDEO_SOURCE_SVCLASS_ID
#define VIDEO_SINK_PROFILE_ID VIDEO_SINK_SVCLASS_ID
#define VIDEO_DISTRIBUTION_PROFILE_ID VIDEO_DISTRIBUTION_SVCLASS_ID
-#define MDP_PROFILE_ID MDP_SVCLASS_ID
-#define MDP_SOURCE_PROFILE_ID MDP_SROUCE_SVCLASS_ID
-#define MDP_SINK_PROFILE_ID MDP_SINK_SVCLASS_ID
+#define HDP_PROFILE_ID HDP_SVCLASS_ID
+#define HDP_SOURCE_PROFILE_ID HDP_SROUCE_SVCLASS_ID
+#define HDP_SINK_PROFILE_ID HDP_SINK_SVCLASS_ID
#define APPLE_AGENT_PROFILE_ID APPLE_AGENT_SVCLASS_ID
/*
diff --git a/tools/sdptool.c b/tools/sdptool.c
index 89166ae..1de53e8 100644
--- a/tools/sdptool.c
+++ b/tools/sdptool.c
@@ -322,9 +322,9 @@ static struct uuid_def uuid16_names[] = {
{ 0x1303, "VideoSource", NULL, 0 },
{ 0x1304, "VideoSink", NULL, 0 },
{ 0x1305, "VideoDistribution", NULL, 0 },
- { 0x1400, "MDP", NULL, 0 },
- { 0x1401, "MDPSource", NULL, 0 },
- { 0x1402, "MDPSink", NULL, 0 },
+ { 0x1400, "HDP", NULL, 0 },
+ { 0x1401, "HDPSource", NULL, 0 },
+ { 0x1402, "HDPSink", NULL, 0 },
{ 0x2112, "AppleAgent", NULL, 0 },
};
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox