* [PATCH 3/3] android/hidhost: Set info request from HAL is not supported
From: Ravi kumar Veeramally @ 2013-11-11 12:15 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384172130-29837-1-git-send-email-ravikumar.veeramally@linux.intel.com>
Data from hal_cmd_hidhost_set_info is usefull only when we create
UHID device. Once device is created all the transactions will be
done through the fd. There is no way to use this information
once device is created with HID internals.
---
android/hidhost.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/android/hidhost.c b/android/hidhost.c
index 816fe3e..6579ff3 100644
--- a/android/hidhost.c
+++ b/android/hidhost.c
@@ -857,7 +857,11 @@ static uint8_t bt_hid_virtual_unplug(struct hal_cmd_hidhost_virtual_unplug *cmd,
static uint8_t bt_hid_info(struct hal_cmd_hidhost_set_info *cmd, uint16_t len)
{
- DBG("Not Implemented");
+ /* Data from hal_cmd_hidhost_set_info is usefull only when we create
+ * UHID device. Once device is created all the transactions will be
+ * done through the fd. There is no way to use this information
+ * once device is created with HID internals. */
+ DBG("Not supported");
return HAL_STATUS_FAILED;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] android/hidhost: Remove deprecated idle opcode from ipc document
From: Ravi kumar Veeramally @ 2013-11-11 12:15 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384172130-29837-1-git-send-email-ravikumar.veeramally@linux.intel.com>
Idle time is deprecated in HID 1_1. So remove it from ipc document
and update GET_REPORT and VIRTUAL_UNPLUG opcode values.
---
android/hal-ipc-api.txt | 10 ++--------
android/hal-msg.h | 4 ++--
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 91ea280..57f4c13 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -614,20 +614,14 @@ Notifications:
0x01 = Boot
0xff = Unsupported
- Opcode 0x84 - Idle Time notification
-
- Notification parameters: Remote address (6 octets)
- Status (1 octet)
- Idle time (2 octets)
-
- Opcode 0x85 - Get Report notification
+ Opcode 0x84 - Get Report notification
Notification parameters: Remote address (6 octets)
Status (1 octet)
Report length (2 octets)
Report data (variable)
- Opcode 0x86 - Virtual Unplug notification
+ Opcode 0x85 - Virtual Unplug notification
Notification parameters: Remote address (6 octets)
Status (1 octet)
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 569c8ea..1d20afd 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -472,7 +472,7 @@ struct hal_ev_hidhost_proto_mode {
uint8_t mode;
} __attribute__((packed));
-#define HAL_EV_HIDHOST_GET_REPORT 0x85
+#define HAL_EV_HIDHOST_GET_REPORT 0x84
struct hal_ev_hidhost_get_report {
uint8_t bdaddr[6];
uint8_t status;
@@ -480,7 +480,7 @@ struct hal_ev_hidhost_get_report {
uint8_t data[0];
} __attribute__((packed));
-#define HAL_EV_HIDHOST_VIRTUAL_UNPLUG 0x86
+#define HAL_EV_HIDHOST_VIRTUAL_UNPLUG 0x85
struct hal_ev_hidhost_virtual_unplug {
uint8_t bdaddr[6];
uint8_t status;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] android/hidhost: Handle uhid output and feature events
From: Ravi kumar Veeramally @ 2013-11-11 12:15 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
Data read on uhid events output and feature has to be send through
SET_REPORT request to HID device.
---
android/hidhost.c | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/android/hidhost.c b/android/hidhost.c
index 683938f..816fe3e 100644
--- a/android/hidhost.c
+++ b/android/hidhost.c
@@ -155,7 +155,42 @@ static void hid_device_free(struct hid_device *dev)
static void handle_uhid_event(struct hid_device *dev, struct uhid_event *ev)
{
- DBG("UHID_OUTPUT UHID_FEATURE unsupported");
+ int fd;
+ uint8_t *req = NULL;
+ uint8_t req_size = 0;
+
+ if (!(dev->ctrl_io))
+ return;
+
+ switch (ev->type) {
+ case UHID_OUTPUT:
+ req_size = 1 + ev->u.output.size;
+ req = g_try_malloc0(req_size);
+ if (!req)
+ return;
+
+ req[0] = HID_MSG_SET_REPORT | HID_DATA_TYPE_OUTPUT;
+ memcpy(req + 1, ev->u.output.data, ev->u.output.size);
+ break;
+
+ case UHID_FEATURE:
+ req_size = sizeof(struct uhid_feature_req);
+ req = g_try_malloc0(req_size);
+ if (!req)
+ return;
+
+ req[0] = HID_MSG_SET_REPORT | HID_DATA_TYPE_FEATURE;
+ memcpy(req + 1, (ev + sizeof(ev->type)), req_size - 1);
+ break;
+ }
+
+ fd = g_io_channel_unix_get_fd(dev->ctrl_io);
+
+ if (write(fd, req, req_size) < 0)
+ error("error writing hid_set_report: %s (%d)",
+ strerror(errno), errno);
+
+ g_free(req);
}
static gboolean uhid_event_cb(GIOChannel *io, GIOCondition cond,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/3] gdbus: Don't try to remove removed sources
From: Bastien Nocera @ 2013-11-11 12:13 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZKWPY2UMOuexvPMHKpiJJ8efgA_xxWOU1yXV_d6LKy9=g@mail.gmail.com>
On Mon, 2013-11-11 at 11:32 +0200, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Sat, Nov 9, 2013 at 7:04 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Sat, 2013-11-09 at 18:02 +0100, Bastien Nocera wrote:
> >> When we return FALSE from idle handlers, the source is removed.
> >> This will be causing warnings in glib 2.40.
> >>
> >> See https://bugzilla.gnome.org/show_bug.cgi?id=710724
> >
> > Note that there's plenty of other places where this should be fixed.
> > I'll leave those up to somebody who doesn't get RSI ;)
>
> Btw, did you really got a problem or was just by looking at the code?
> process_changes always call remove_pending so perhaps the problem was
> just in generic_unregister, so the change to process_changes was not
> really necessary.
I really had the problem, and the patch fixed it. Resetting the id for
idle callbacks and timeouts needs to happen at the end of each callback
function, or you might be trying to remove an invalid source ID.
^ permalink raw reply
* Re: [PATCH 2/3] all: Use G_SOURCE_REMOVE/G_SOURCE_CONTINUE macros
From: Bastien Nocera @ 2013-11-11 11:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <BCD6D340-765E-45BB-AC3E-7A0C98348773@holtmann.org>
On Mon, 2013-11-11 at 17:04 +0900, Marcel Holtmann wrote:
<snip>
> problem is that we currently only require GLib 2.28 and this got introduced in GLib 2.32.
You'd take that with an if GLIB_VERSION() #define G_SOURCE_... compat
helper?
^ permalink raw reply
* Re: Oops in rfcomm_sock_getsockopt on net-next as of 20131111
From: Marcel Holtmann @ 2013-11-11 11:05 UTC (permalink / raw)
To: Bjørn Mork; +Cc: linux-bluetooth@vger.kernel.org development, netdev
In-Reply-To: <874n7j6xei.fsf@nemi.mork.no>
Hi Bjorn,
> I got this when I booted my laptop with todays net-next:
>
> [ 16.064546] BUG: unable to handle kernel paging request at 00000c8bfd080975
> [ 16.064558] IP: [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
> [ 16.064561] PGD 0
> [ 16.064564] Oops: 0000 [#1] SMP
> [ 16.064637] Modules linked in: rfcomm bnep xt_hl binfmt_misc ip6table_filter ip6_tables x_tables nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun loop fuse iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss iwlmvm mac80211 snd_pcm snd_page_alloc thinkpad_acpi nvram snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq iwlwifi coretemp uvcvideo cdc_mbim cdc_wdm videobuf2_vmalloc videobuf2_memops cdc_ncm kvm_intel videobuf2_core snd_seq_device psmouse usbnet lpc_ich videodev kvm snd_timer evdev serio_raw mfd_core mii cfg80211 i2c_i801 snd soundcore battery ac i915 i2c_algo_bit drm_kms_helper drm i2c_core acpi_cpufreq video wmi processor button btusb bluetooth rfkill ext4 crc16 jbd2 mbcache nbd sg sd_mod crc_t10dif sr_mod cdrom crct10dif_common ahci libahci microcode libata scsi_mod thermal thermal_sys ehci_pci uhci_hcd ehci_hcd e1000e usbcore ptp pps_core usb_common
> [ 16.064656] CPU: 1 PID: 3153 Comm: bluetoothd Not tainted 3.12.0+ #136
> [ 16.064658] Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
> [ 16.064660] task: ffff88022e50a440 ti: ffff8800b78b4000 task.ti: ffff8800b78b4000
> [ 16.064669] RIP: 0010:[<ffffffffa07f65b3>] [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
> [ 16.064670] RSP: 0018:ffff8800b78b5ed8 EFLAGS: 00010246
> [ 16.064672] RAX: 00000c8bfd080975 RBX: ffff8800b688b140 RCX: 00007fff7ae042f8
> [ 16.064674] RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff8800b688b140
> [ 16.064676] RBP: ffff8800b78b5f28 R08: 00007fff7ae042fc R09: 00007fff7ae042f8
> [ 16.064678] R10: 00007fff7ae042f8 R11: ffff8800b83ec180 R12: ffff8800b78bc800
> [ 16.064680] R13: 00007fff7ae042f8 R14: 0000000000000003 R15: ffff8800b78bc800
> [ 16.064682] FS: 00007f020d523740(0000) GS:ffff88023b000000(0000) knlGS:0000000000000000
> [ 16.064685] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 16.064687] CR2: 00000c8bfd080975 CR3: 00000000b78a2000 CR4: 00000000000007e0
> [ 16.064688] Stack:
> [ 16.064692] ffff8800b78b5f08 00007fff7ae042fc ffffffff8139b647 00007fff7ae04570
> [ 16.064696] ffff8800b78b5f50 ffff8800b688b140 0000000000000012 0000000000000003
> [ 16.064700] 0000000000000011 00007f020e6abce0 ffff8800b78b5f78 ffffffff812b8215
> [ 16.064701] Call Trace:
> [ 16.064708] [<ffffffff8139b647>] ? sysret_check+0x1b/0x56
> [ 16.064714] [<ffffffff812b8215>] SyS_getsockopt+0x79/0x99
> [ 16.064718] [<ffffffff8139b622>] system_call_fastpath+0x16/0x1b
> [ 16.064756] Code: a0 31 c0 48 c7 c7 08 e0 7f a0 e8 35 45 9f e0 41 83 ff 12 0f 85 1e 01 00 00 4c 8b 7b 20 f6 05 a6 7a 00 00 04 49 8b 87 18 05 00 00 <4c> 8b 20 74 18 4c 89 fa 48 c7 c6 8f b9 7f a0 31 c0 48 c7 c7 30
> [ 16.064763] RIP [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
> [ 16.064764] RSP <ffff8800b78b5ed8>
> [ 16.064766] CR2: 00000c8bfd080975
> [ 16.064769] ---[ end trace f71c8d4720ff0e6f ]---
>
>
> I am using standard Debian startup scripts AFAIK, doing:
>
> /usr/bin/rfcomm -f /etc/bluetooth/rfcomm.conf bind all
>
> where my rfcomm.conf is completely empty except for comments. The
> reported userspace version is
>
> RFCOMM configuration utility ver 4.99
>
> Let me know if there is any other information you need to debug this
> further.
known issue. Check 0be087f56118b67479b6e1a542d1dcf54fa83615 from bluetooth-next tree. We just have not pushed that through wireless-next and net-next yet.
Regards
Marcel
^ permalink raw reply
* Oops in rfcomm_sock_getsockopt on net-next as of 20131111
From: Bjørn Mork @ 2013-11-11 10:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: netdev
Hello,
I got this when I booted my laptop with todays net-next:
[ 16.064546] BUG: unable to handle kernel paging request at 00000c8bfd080975
[ 16.064558] IP: [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
[ 16.064561] PGD 0
[ 16.064564] Oops: 0000 [#1] SMP
[ 16.064637] Modules linked in: rfcomm bnep xt_hl binfmt_misc ip6table_filter ip6_tables x_tables nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun loop fuse iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss iwlmvm mac80211 snd_pcm snd_page_alloc thinkpad_acpi nvram snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq iwlwifi coretemp uvcvideo cdc_mbim cdc_wdm videobuf2_vmalloc videobuf2_memops cdc_ncm kvm_intel videobuf2_core snd_seq_device psmouse usbnet lpc_ich videodev kvm snd_timer evdev serio_raw mfd_core mii cfg80211 i2c_i801 snd soundcore battery ac i915 i2c_algo_bit drm_kms_helper drm i2c_core acpi_cpufreq video wmi processor button btusb bluetooth rfkill ext4 crc16 jbd2 mbcache nbd sg sd_mod crc_t10dif sr_mod cdrom crct10dif_common ahci libahci microcode libata scsi_mod thermal thermal_sys ehci_pci uhci_hcd ehci_hcd e1000e usbcore ptp pps_core usb_common
[ 16.064656] CPU: 1 PID: 3153 Comm: bluetoothd Not tainted 3.12.0+ #136
[ 16.064658] Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
[ 16.064660] task: ffff88022e50a440 ti: ffff8800b78b4000 task.ti: ffff8800b78b4000
[ 16.064669] RIP: 0010:[<ffffffffa07f65b3>] [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
[ 16.064670] RSP: 0018:ffff8800b78b5ed8 EFLAGS: 00010246
[ 16.064672] RAX: 00000c8bfd080975 RBX: ffff8800b688b140 RCX: 00007fff7ae042f8
[ 16.064674] RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff8800b688b140
[ 16.064676] RBP: ffff8800b78b5f28 R08: 00007fff7ae042fc R09: 00007fff7ae042f8
[ 16.064678] R10: 00007fff7ae042f8 R11: ffff8800b83ec180 R12: ffff8800b78bc800
[ 16.064680] R13: 00007fff7ae042f8 R14: 0000000000000003 R15: ffff8800b78bc800
[ 16.064682] FS: 00007f020d523740(0000) GS:ffff88023b000000(0000) knlGS:0000000000000000
[ 16.064685] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 16.064687] CR2: 00000c8bfd080975 CR3: 00000000b78a2000 CR4: 00000000000007e0
[ 16.064688] Stack:
[ 16.064692] ffff8800b78b5f08 00007fff7ae042fc ffffffff8139b647 00007fff7ae04570
[ 16.064696] ffff8800b78b5f50 ffff8800b688b140 0000000000000012 0000000000000003
[ 16.064700] 0000000000000011 00007f020e6abce0 ffff8800b78b5f78 ffffffff812b8215
[ 16.064701] Call Trace:
[ 16.064708] [<ffffffff8139b647>] ? sysret_check+0x1b/0x56
[ 16.064714] [<ffffffff812b8215>] SyS_getsockopt+0x79/0x99
[ 16.064718] [<ffffffff8139b622>] system_call_fastpath+0x16/0x1b
[ 16.064756] Code: a0 31 c0 48 c7 c7 08 e0 7f a0 e8 35 45 9f e0 41 83 ff 12 0f 85 1e 01 00 00 4c 8b 7b 20 f6 05 a6 7a 00 00 04 49 8b 87 18 05 00 00 <4c> 8b 20 74 18 4c 89 fa 48 c7 c6 8f b9 7f a0 31 c0 48 c7 c7 30
[ 16.064763] RIP [<ffffffffa07f65b3>] rfcomm_sock_getsockopt+0x62/0x251 [rfcomm]
[ 16.064764] RSP <ffff8800b78b5ed8>
[ 16.064766] CR2: 00000c8bfd080975
[ 16.064769] ---[ end trace f71c8d4720ff0e6f ]---
I am using standard Debian startup scripts AFAIK, doing:
/usr/bin/rfcomm -f /etc/bluetooth/rfcomm.conf bind all
where my rfcomm.conf is completely empty except for comments. The
reported userspace version is
RFCOMM configuration utility ver 4.99
Let me know if there is any other information you need to debug this
further.
Bjørn
^ permalink raw reply
* Re: [PATCH 1/3] gdbus: Don't try to remove removed sources
From: Luiz Augusto von Dentz @ 2013-11-11 9:32 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1384016658.3880.39.camel@nuvo>
Hi Bastien,
On Sat, Nov 9, 2013 at 7:04 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Sat, 2013-11-09 at 18:02 +0100, Bastien Nocera wrote:
>> When we return FALSE from idle handlers, the source is removed.
>> This will be causing warnings in glib 2.40.
>>
>> See https://bugzilla.gnome.org/show_bug.cgi?id=710724
>
> Note that there's plenty of other places where this should be fixed.
> I'll leave those up to somebody who doesn't get RSI ;)
Btw, did you really got a problem or was just by looking at the code?
process_changes always call remove_pending so perhaps the problem was
just in generic_unregister, so the change to process_changes was not
really necessary.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 3/3] obex: Use XDG_RUNTIME_DIR as a default root
From: Luiz Augusto von Dentz @ 2013-11-11 9:00 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1384091198.4593.6.camel@nuvo>
Hi Bastien,
On Sun, Nov 10, 2013 at 3:46 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Sat, 2013-11-09 at 18:03 +0100, Bastien Nocera wrote:
>> It's per-user, so we won't try to overwrite somebody else's
>> files in /tmp when that happens.
>
> There might be another useful directory instead. We could use
> g_get_user_cache_dir() instead of the run-time dir. This would save
> cross-partition moves by default, making the move to the Downloads dir
> atomic (a single rename, which can fail, iterate until we find a "free"
> filename).
>
> Is that better for you?
Yep, it sounds better. Regarding renaming that is up the agent, if you
really want to do that its probably fine but Im still not convinced
this is absolutely necessary if obexd is running with the same user as
the agent can just create the file while authorizing so you wouldn't
need to move after completed, but again this is completely up to the
agent to decide where the files should go.
Btw, what about fd passing? In theory we can create a different
version of the agent interface to enable passing fd directly, and in
fact we were thinking about this already as for some services you
wanted them to be dynamic so we were thinking on having this set by
the agent when it registers.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 1/3] gdbus: Don't try to remove removed sources
From: Johan Hedberg @ 2013-11-11 8:39 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1384016577.3880.36.camel@nuvo>
Hi Bastien,
On Sat, Nov 09, 2013, Bastien Nocera wrote:
> When we return FALSE from idle handlers, the source is removed.
> This will be causing warnings in glib 2.40.
>
> See https://bugzilla.gnome.org/show_bug.cgi?id=710724
> ---
> gdbus/object.c | 3 +++
> 1 file changed, 3 insertions(+)
This patch has been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] android: Update bond state on incoming bonding
From: Johan Hedberg @ 2013-11-11 8:37 UTC (permalink / raw)
To: Lukasz Rymanowski; +Cc: linux-bluetooth, szymon.janc
In-Reply-To: <1383925711-26374-2-git-send-email-lukasz.rymanowski@tieto.com>
Hi Lukasz,
On Fri, Nov 08, 2013, Lukasz Rymanowski wrote:
> Before sending any ssp request or pin code request up to HAL library we
> need to send bond state change with bonding state. Otherwise incoming
> bonding is impossible.
> ---
> android/adapter.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
Wont this cause HAL_BOND_STATE_BONDING to be sent twice if the pairing
was locally initiated through create_bond()?
Johan
^ permalink raw reply
* Re: [RFC] android/hid: Handle virtual unplug event from hid device
From: Johan Hedberg @ 2013-11-11 8:33 UTC (permalink / raw)
To: Ravi kumar Veeramally; +Cc: linux-bluetooth
In-Reply-To: <1383920094-20498-1-git-send-email-ravikumar.veeramally@linux.intel.com>
Hi Ravi,
On Fri, Nov 08, 2013, Ravi kumar Veeramally wrote:
> If hid host receives the virtual unplug event from hid device
> recipient shall destroy or invalidate all bluetooth bonding and
> virtual cable information
> ---
> android/hal-msg.h | 1 +
> android/hidhost.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
Looks good enough to me, so the patch has been applied.
Johan
^ permalink raw reply
* Re: [PATCH 2/3] all: Use G_SOURCE_REMOVE/G_SOURCE_CONTINUE macros
From: Marcel Holtmann @ 2013-11-11 8:04 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <1384016586.3880.37.camel@nuvo>
Hi Bastien,
> Instead of TRUE/FALSE. This makes the source more readable.
> ---
> android/main.c | 4 ++--
> attrib/gattrib.c | 2 +-
> attrib/gatttool.c | 2 +-
> gdbus/mainloop.c | 6 +++---
> gdbus/object.c | 2 +-
> gdbus/watch.c | 2 +-
> gobex/gobex.c | 4 ++--
> obexd/client/session.c | 4 ++--
> obexd/client/transfer.c | 6 +++---
> obexd/plugins/messages-dummy.c | 2 +-
> obexd/plugins/messages-tracker.c | 2 +-
> obexd/plugins/phonebook-dummy.c | 6 +++---
> plugins/policy.c | 6 +++---
> profiles/audio/a2dp.c | 16 ++++++++--------
> profiles/audio/avctp.c | 12 ++++++------
> profiles/audio/avdtp.c | 14 +++++++-------
> profiles/audio/avrcp.c | 2 +-
> profiles/audio/player.c | 4 ++--
> profiles/cyclingspeed/cyclingspeed.c | 2 +-
> profiles/health/hdp.c | 4 ++--
> profiles/health/mcap.c | 2 +-
> profiles/health/mcap_sync.c | 18 +++++++++---------
> profiles/input/device.c | 10 +++++-----
> profiles/network/connection.c | 2 +-
> profiles/proximity/monitor.c | 4 ++--
> profiles/sap/server.c | 4 ++--
> src/adapter.c | 20 ++++++++++----------
> src/device.c | 16 ++++++++--------
> src/main.c | 4 ++--
> src/sdp-client.c | 2 +-
> src/shared/hciemu.c | 2 +-
> src/shared/tester.c | 18 +++++++++---------
> tools/btiotest.c | 6 +++---
> unit/test-gdbus-client.c | 4 ++--
> unit/test-gobex-transfer.c | 2 +-
> unit/test-gobex.c | 4 ++--
> unit/test-sdp.c | 2 +-
> 37 files changed, 111 insertions(+), 111 deletions(-)
>
> diff --git a/android/main.c b/android/main.c
> index 75004cf..a36269c 100644
> --- a/android/main.c
> +++ b/android/main.c
> @@ -377,7 +377,7 @@ static gboolean cmd_connect_cb(GIOChannel *io, GIOCondition cond,
> static gboolean quit_eventloop(gpointer user_data)
> {
> g_main_loop_quit(event_loop);
> - return FALSE;
> + return G_SOURCE_REMOVE;
> }
problem is that we currently only require GLib 2.28 and this got introduced in GLib 2.32.
Regards
Marcel
^ permalink raw reply
* [PATCH] obex: Use user's cache dir as a default root
From: Bastien Nocera @ 2013-11-10 14:24 UTC (permalink / raw)
To: linux-bluetooth
It's per-user, so we won't try to overwrite somebody else's
files in /tmp when that happens. It's also (unless we have a
particularly bizarre setup) on the same partition as the destination
folder which means we can atomically move the file to the destination
with a unique filename.
---
obexd/src/main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/obexd/src/main.c b/obexd/src/main.c
index 61a06b2..2f7d723 100644
--- a/obexd/src/main.c
+++ b/obexd/src/main.c
@@ -50,8 +50,6 @@
#include "obexd.h"
#include "server.h"
-#define DEFAULT_ROOT_PATH "/tmp"
-
#define DEFAULT_CAP_FILE CONFIGDIR "/capability.xml"
static GMainLoop *main_loop = NULL;
@@ -285,8 +283,10 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
- if (option_root == NULL)
- option_root = g_strdup(DEFAULT_ROOT_PATH);
+ if (option_root == NULL) {
+ option_root = g_build_filename(g_get_user_cache_dir(), "obexd", NULL);
+ g_mkdir_with_parents(option_root, 0700);
+ }
if (option_root[0] != '/') {
char *old_root = option_root, *home = getenv("HOME");
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH 3/3] obex: Use XDG_RUNTIME_DIR as a default root
From: Bastien Nocera @ 2013-11-10 13:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1384016598.3880.38.camel@nuvo>
On Sat, 2013-11-09 at 18:03 +0100, Bastien Nocera wrote:
> It's per-user, so we won't try to overwrite somebody else's
> files in /tmp when that happens.
There might be another useful directory instead. We could use
g_get_user_cache_dir() instead of the run-time dir. This would save
cross-partition moves by default, making the move to the Downloads dir
atomic (a single rename, which can fail, iterate until we find a "free"
filename).
Is that better for you?
> ---
> obexd/src/main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/obexd/src/main.c b/obexd/src/main.c
> index 61a06b2..15777f5 100644
> --- a/obexd/src/main.c
> +++ b/obexd/src/main.c
> @@ -50,8 +50,6 @@
> #include "obexd.h"
> #include "server.h"
>
> -#define DEFAULT_ROOT_PATH "/tmp"
> -
> #define DEFAULT_CAP_FILE CONFIGDIR "/capability.xml"
>
> static GMainLoop *main_loop = NULL;
> @@ -286,7 +284,7 @@ int main(int argc, char *argv[])
> }
>
> if (option_root == NULL)
> - option_root = g_strdup(DEFAULT_ROOT_PATH);
> + option_root = g_build_filename (g_get_user_runtime_dir (), "obexd", NULL);
>
> if (option_root[0] != '/') {
> char *old_root = option_root, *home = getenv("HOME");
^ permalink raw reply
* Reading RSSI value from an RFCOMM connection
From: Michael Kehm @ 2013-11-10 6:31 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi folks,
I am trying to get the RSSI value from an established RFCOMM connection.
While searching on the Internet for hints I found the following discussions:
http://comments.gmane.org/gmane.linux.bluez.user/9986
http://stackoverflow.com/questions/2149295/android-2-1-how-do-i-poll-the-rssi-value-of-an-existing-bluetooth-connection
http://sourceforge.net/mailarchive/forum.php?forum_name=bluez-devel&style=nested&viewmonth=200505&viewday=17
Most suggestions point to the hci_read_rssi API (int hci_read_rssi(int dd, uint16_t handle, int8_t *rssi, int to);).
I am using Python. As a basic skeleton I am using Albert Huang's rfcomm-client.py and rfcomm-server.py scripts.
Looking into bluez.py and inquiry-with-rssi.py samples, it helped me to understand how to access the hci layer but I am stuck in execution.
This is my script based on rfcomm-server.py:
import os, sys, struct, fcntl, array, binascii
import btcommon
import bluetooth._bluetooth as _bt
from bluetooth import *
#################################################################
# Added code
def get_acl_conn_handle (hci_sock, addr):
hci_fd = hci_sock.fileno ()
reqstr = struct.pack ("6sB17s", _bt.str2ba (addr), _bt.ACL_LINK, "\0" * 17)
request = array.array ("c", reqstr)
print "ACL_LINK:%s" % _bt.ACL_LINK
print "hci_fd:%s" % hci_fd
print "HCIGETCONNINFO:%s" % _bt.HCIGETCONNINFO
print "request:%s" % request
fcntl.ioctl (hci_fd, _bt.HCIGETCONNINFO, request, 1)
try:
fcntl.ioctl (hci_fd, _bt.HCIGETCONNINFO, request, 1)
except IOError, e:
raise BluetoothError ("There is no ACL connection to %s" % addr)
# XXX should this be "<8xH14x"?
handle = struct.unpack ("8xH14x", request.tostring ())[0]
return handle
#################################################################
server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)
port = server_sock.getsockname()[1]
uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"
advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)
print "Waiting for connection on RFCOMM channel %d" % port
client_sock, client_info = server_sock.accept()
print "Accepted connection from ", client_info
#################################################################
# Added code
rssi = 0
handle = get_acl_conn_handle(server_sock._sock, client_info[0])
rssi = bluez.hci_read_rssi(server_sock._sock, handle, rssi, 1000)
#################################################################
try:
client_sock.send(rssi)
print "sent [%s]" % rssi
except IOError:
pass
print "disconnected"
client_sock.close()
server_sock.close()
print "all done"
I have added/copied the get_acl_conn_handle function and the call to hci_read_rssi.
The problem is that I run into the following exception:
Traceback (most recent call last):
File "rfcomm-rssi.py", line 48, in <module>
handle = get_acl_conn_handle(server_sock._sock, client_info[0])
File "rfcomm-rssi.py", line 16, in get_acl_conn_handle
fcntl.ioctl (hci_fd, _bt.HCIGETCONNINFO, request, 1)
IOError: [Errno 22] Invalid argument
The print statements in get_acl_conn_handle return the following information:
ACL_LINK:1
hci_fd:3
HCIGETCONNINFO:-2147202859
request:array('c', '9\x91\x97g\x1d\x1c\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
I am bit lost on how to fix this.
If anyone can help me with my script above or if anyone has sample code in Python or C how to get the RSSI data from a RFCOMM connection then I would highly appreciate it.
Thanks in advance,
Michael
^ permalink raw reply
* Re: obexd broken for absolute paths
From: Bastien Nocera @ 2013-11-10 0:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJyKT65rUxdhtkQit3ok4Y7khHF0qjROL1-0YzZUUbMiA@mail.gmail.com>
On Sun, 2013-11-10 at 02:49 +0200, Luiz Augusto von Dentz wrote:
> Hi Bastian,
>
> On Sat, Nov 9, 2013 at 11:00 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Sat, 2013-11-09 at 20:35 +0200, Luiz Augusto von Dentz wrote:
> >> Hi Bastian,
> >>
> >> On Sat, Nov 9, 2013 at 7:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
> >> > On Fri, 2013-11-08 at 20:21 +0100, Bastien Nocera wrote:
> >> >> Heya,
> >> >>
> >> >> I was trying to test gnome-user-share's Bluetooth support for BlueZ 5,
> >> >> and was quite surprised it didn't work one bit, with transfers failing
> >> >> as soon as they were created.
> >> >>
> >> >> I made this simple change to test/simple-obex-agent so you could
> >> >> replicate the failure. Obviously, change the download path to exist on
> >> >> your system:
> >> >> - return properties['Name']
> >> >> + return ("%s/%s" % ("/home/hadess/Downloads/", properties['Name']))
> >> >>
> >> >> This will see OBEX Push transfers fail as soon as accepted.
> >> >
> >> > Turns out this is a feature of filesystem plugin in obexd, and a bit of
> >> > a problem as well:
> >> > - There's no way to change the folder without changing the service file
> >>
> >> Yep, I remember discussing with Gustavo Padovan that this should
> >> probably be set by the agent upon registration.
> >
> > I thought about that, but it's really a security issue. obexd might be
> > running in a different context than the "application" telling it where
> > to write. For example, my share application might be restricted to write
> > new files in ~/Downloads, but could tell obexd to write to ~/.ssh/etc.
>
> If obexd is running with a different user then yes, but I don't think
> this is the case otherwise we should pass fd not a path since the
> files should really belong to the agent not obexd.
Not a different user, a different security context, which is going to
happen when applications are sandboxed within the session.
> >> > - It doesn't default to use the XDG_RUNTIME_DIR
> >>
> >> That is a good default considering we don't implement the change
> >> above, otherwise for auto accept I believe tmp is usually a better
> >> option.
> >
> > This is what I intend to use in gnome-user-share. obexd would write
> > files with unique filenames to /run/user/<id>/obexd and move it
> > ~/Downloads after uniquifying the name (eg. sending 2 files called
> > "foo.jpg" should give me 2 files, not overwrite the first one as it does
> > now).
>
> Not sure what is the point of doing this, except if you want to use
> tmpfs while downloading and only really store on disk when the
> transfer is complete, overwrite is agent problem to select different
> path if the file already exist or alert the user it will overwrite.
There's no way of doing this in a race-free way. The right way to do
this would be for the agent to return a file descriptor, not a path.
A file with that path might be created between the time the filename is
considered "free" by the agent and obexd actually writing it. It might
even be racy when receiving multiple files with the same name.
^ permalink raw reply
* Re: obexd broken for absolute paths
From: Luiz Augusto von Dentz @ 2013-11-10 0:49 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1384030812.3880.47.camel@nuvo>
Hi Bastian,
On Sat, Nov 9, 2013 at 11:00 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Sat, 2013-11-09 at 20:35 +0200, Luiz Augusto von Dentz wrote:
>> Hi Bastian,
>>
>> On Sat, Nov 9, 2013 at 7:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
>> > On Fri, 2013-11-08 at 20:21 +0100, Bastien Nocera wrote:
>> >> Heya,
>> >>
>> >> I was trying to test gnome-user-share's Bluetooth support for BlueZ 5,
>> >> and was quite surprised it didn't work one bit, with transfers failing
>> >> as soon as they were created.
>> >>
>> >> I made this simple change to test/simple-obex-agent so you could
>> >> replicate the failure. Obviously, change the download path to exist on
>> >> your system:
>> >> - return properties['Name']
>> >> + return ("%s/%s" % ("/home/hadess/Downloads/", properties['Name']))
>> >>
>> >> This will see OBEX Push transfers fail as soon as accepted.
>> >
>> > Turns out this is a feature of filesystem plugin in obexd, and a bit of
>> > a problem as well:
>> > - There's no way to change the folder without changing the service file
>>
>> Yep, I remember discussing with Gustavo Padovan that this should
>> probably be set by the agent upon registration.
>
> I thought about that, but it's really a security issue. obexd might be
> running in a different context than the "application" telling it where
> to write. For example, my share application might be restricted to write
> new files in ~/Downloads, but could tell obexd to write to ~/.ssh/etc.
If obexd is running with a different user then yes, but I don't think
this is the case otherwise we should pass fd not a path since the
files should really belong to the agent not obexd.
>> > - It doesn't default to use the XDG_RUNTIME_DIR
>>
>> That is a good default considering we don't implement the change
>> above, otherwise for auto accept I believe tmp is usually a better
>> option.
>
> This is what I intend to use in gnome-user-share. obexd would write
> files with unique filenames to /run/user/<id>/obexd and move it
> ~/Downloads after uniquifying the name (eg. sending 2 files called
> "foo.jpg" should give me 2 files, not overwrite the first one as it does
> now).
Not sure what is the point of doing this, except if you want to use
tmpfs while downloading and only really store on disk when the
transfer is complete, overwrite is agent problem to select different
path if the file already exist or alert the user it will overwrite.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Debugging broken audio stream
From: Stanisław Pitucha @ 2013-11-09 22:33 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
I'm having issues with using a remote audio sink device and I can't
find any clear indications of a problem.
My current config is:
- kernel 3.11.6 (x86_64)
- bluez 5.10
- pulseaudio 4.0
- ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] (btusb driver)
The receiving device is Logitech's wireless audio adapter.
When sending data from android devices (4.1, 4.3) everything works
without issues, so I think the receiver seems ok.
On the laptop side which is having problems, the initial connection /
pairing works without issues, but the sound stream is very unstable
(unusable really: 1 second of sound, 5 of silence, repeat...) and
sometimes the connection drops / reconnects on its own. Sometimes it
works for a couple of seconds before failing.
Sometimes there's a stacktrace reported from the kernel (see
https://bugs.archlinux.org/task/37697 ), but not always.
The debug output from bluetoothd doesn't report any specific issues
(as far as I can tell from the log) until it disconnects completely
("Abort: Connection timed out (110)")
A full session in debug mode (connect, try to play some music,
connection times out, tries playing again, killing bluez) is available
at http://pastebin.com/n7qfumYR
Syslog contains pages of repeated messages like this (different
time/sizes in each line, chosen smallest/biggest I can see):
Nov 09 20:14:00 gumby pulseaudio[19585]: [bluetooth]
module-bluez5-device.c: Skipping 116 us (= 20 bytes) in audio stream
...
Nov 09 20:14:03 gumby pulseaudio[19585]: [bluetooth]
module-bluez5-device.c: Skipping 564192 us (= 99520 bytes) in audio
stream
I'm not sure how to prove the issue is definitely on either the bluez,
or pulseaudio's side...
What more can I do in this case? What other debugging options do I
have? Would capturing the bluetooth packets be useful at all?
I assume the bluetooth in laptop is not damaged/unsupported, because I
can exchange files between it and the android devices.
Any/all help appreciated.
--
KTHXBYE,
Stanisław Pitucha
^ permalink raw reply
* Re: obexd broken for absolute paths
From: Bastien Nocera @ 2013-11-09 21:00 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJtvdd0iDmcuUe7S9mi68U1nQOLTy577vu0T-kpa9wMBA@mail.gmail.com>
On Sat, 2013-11-09 at 20:35 +0200, Luiz Augusto von Dentz wrote:
> Hi Bastian,
>
> On Sat, Nov 9, 2013 at 7:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Fri, 2013-11-08 at 20:21 +0100, Bastien Nocera wrote:
> >> Heya,
> >>
> >> I was trying to test gnome-user-share's Bluetooth support for BlueZ 5,
> >> and was quite surprised it didn't work one bit, with transfers failing
> >> as soon as they were created.
> >>
> >> I made this simple change to test/simple-obex-agent so you could
> >> replicate the failure. Obviously, change the download path to exist on
> >> your system:
> >> - return properties['Name']
> >> + return ("%s/%s" % ("/home/hadess/Downloads/", properties['Name']))
> >>
> >> This will see OBEX Push transfers fail as soon as accepted.
> >
> > Turns out this is a feature of filesystem plugin in obexd, and a bit of
> > a problem as well:
> > - There's no way to change the folder without changing the service file
>
> Yep, I remember discussing with Gustavo Padovan that this should
> probably be set by the agent upon registration.
I thought about that, but it's really a security issue. obexd might be
running in a different context than the "application" telling it where
to write. For example, my share application might be restricted to write
new files in ~/Downloads, but could tell obexd to write to ~/.ssh/etc.
> > - It doesn't default to use the XDG_RUNTIME_DIR
>
> That is a good default considering we don't implement the change
> above, otherwise for auto accept I believe tmp is usually a better
> option.
This is what I intend to use in gnome-user-share. obexd would write
files with unique filenames to /run/user/<id>/obexd and move it
~/Downloads after uniquifying the name (eg. sending 2 files called
"foo.jpg" should give me 2 files, not overwrite the first one as it does
now).
Cheers
^ permalink raw reply
* Re: obexd broken for absolute paths
From: Luiz Augusto von Dentz @ 2013-11-09 18:35 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1384017476.3880.40.camel@nuvo>
Hi Bastian,
On Sat, Nov 9, 2013 at 7:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Fri, 2013-11-08 at 20:21 +0100, Bastien Nocera wrote:
>> Heya,
>>
>> I was trying to test gnome-user-share's Bluetooth support for BlueZ 5,
>> and was quite surprised it didn't work one bit, with transfers failing
>> as soon as they were created.
>>
>> I made this simple change to test/simple-obex-agent so you could
>> replicate the failure. Obviously, change the download path to exist on
>> your system:
>> - return properties['Name']
>> + return ("%s/%s" % ("/home/hadess/Downloads/", properties['Name']))
>>
>> This will see OBEX Push transfers fail as soon as accepted.
>
> Turns out this is a feature of filesystem plugin in obexd, and a bit of
> a problem as well:
> - There's no way to change the folder without changing the service file
Yep, I remember discussing with Gustavo Padovan that this should
probably be set by the agent upon registration.
> - It doesn't default to use the XDG_RUNTIME_DIR
That is a good default considering we don't implement the change
above, otherwise for auto accept I believe tmp is usually a better
option.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] obex: Use GLib helper function to manipulate paths
From: Bastien Nocera @ 2013-11-09 17:18 UTC (permalink / raw)
To: linux-bluetooth
Instead of trying to do it by hand. This also makes sure that
relative paths aren't used by the agent.
---
obexd/src/manager.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/obexd/src/manager.c b/obexd/src/manager.c
index cec8a39..f18896e 100644
--- a/obexd/src/manager.c
+++ b/obexd/src/manager.c
@@ -651,14 +651,14 @@ static void agent_reply(DBusPendingCall *call, void *user_data)
DBUS_TYPE_STRING, &name,
DBUS_TYPE_INVALID)) {
/* Splits folder and name */
- const char *slash = strrchr(name, '/');
+ gboolean is_relative = !g_path_is_absolute(name);
DBG("Agent replied with %s", name);
- if (!slash) {
- agent->new_name = g_strdup(name);
+ if (is_relative) {
+ agent->new_name = g_path_get_basename(name);
agent->new_folder = NULL;
} else {
- agent->new_name = g_strdup(slash + 1);
- agent->new_folder = g_strndup(name, slash - name);
+ agent->new_name = g_path_get_basename(name);
+ agent->new_folder = g_path_get_dirname(name);
}
}
--
1.8.4.2
^ permalink raw reply related
* Re: obexd broken for absolute paths
From: Bastien Nocera @ 2013-11-09 17:17 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1383938500.3880.23.camel@nuvo>
On Fri, 2013-11-08 at 20:21 +0100, Bastien Nocera wrote:
> Heya,
>
> I was trying to test gnome-user-share's Bluetooth support for BlueZ 5,
> and was quite surprised it didn't work one bit, with transfers failing
> as soon as they were created.
>
> I made this simple change to test/simple-obex-agent so you could
> replicate the failure. Obviously, change the download path to exist on
> your system:
> - return properties['Name']
> + return ("%s/%s" % ("/home/hadess/Downloads/", properties['Name']))
>
> This will see OBEX Push transfers fail as soon as accepted.
Turns out this is a feature of filesystem plugin in obexd, and a bit of
a problem as well:
- There's no way to change the folder without changing the service file
- It doesn't default to use the XDG_RUNTIME_DIR
> I must also mention the dreadful code in agent_reply() in obexd/src/manager.c:
> const char *slash = strrchr(name, '/');
> DBG("Agent replied with %s", name);
> if (!slash) {
> agent->new_name = g_strdup(name);
> agent->new_folder = NULL;
> } else {
> agent->new_name = g_strdup(slash + 1);
> agent->new_folder = g_strndup(name, slash - name);
> }
>
> Please use g_path_get_basename() and g_path_get_dirname(). This is even
> a security issue because I could pass relative paths and expect some
> system file to get overwritten.
I've sent a patch for this.
Cheers
^ permalink raw reply
* Re: [PATCH 1/3] gdbus: Don't try to remove removed sources
From: Bastien Nocera @ 2013-11-09 17:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1384016577.3880.36.camel@nuvo>
On Sat, 2013-11-09 at 18:02 +0100, Bastien Nocera wrote:
> When we return FALSE from idle handlers, the source is removed.
> This will be causing warnings in glib 2.40.
>
> See https://bugzilla.gnome.org/show_bug.cgi?id=710724
Note that there's plenty of other places where this should be fixed.
I'll leave those up to somebody who doesn't get RSI ;)
^ permalink raw reply
* [PATCH 3/3] obex: Use XDG_RUNTIME_DIR as a default root
From: Bastien Nocera @ 2013-11-09 17:03 UTC (permalink / raw)
To: linux-bluetooth
It's per-user, so we won't try to overwrite somebody else's
files in /tmp when that happens.
---
obexd/src/main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/obexd/src/main.c b/obexd/src/main.c
index 61a06b2..15777f5 100644
--- a/obexd/src/main.c
+++ b/obexd/src/main.c
@@ -50,8 +50,6 @@
#include "obexd.h"
#include "server.h"
-#define DEFAULT_ROOT_PATH "/tmp"
-
#define DEFAULT_CAP_FILE CONFIGDIR "/capability.xml"
static GMainLoop *main_loop = NULL;
@@ -286,7 +284,7 @@ int main(int argc, char *argv[])
}
if (option_root == NULL)
- option_root = g_strdup(DEFAULT_ROOT_PATH);
+ option_root = g_build_filename (g_get_user_runtime_dir (), "obexd", NULL);
if (option_root[0] != '/') {
char *old_root = option_root, *home = getenv("HOME");
--
1.8.4.2
^ 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