* Re: [PATCH] IrMC sync server support
From: Marcel J.E. Mol @ 2010-08-17 8:48 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <AANLkTi=p5WD+WELPNo=URLVTnpaKQ4xFk9Efu2HiviYE@mail.gmail.com>
Hi,
On Mon, Aug 16, 2010 at 10:47:08PM +0300, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Mon, Aug 16, 2010 at 8:22 PM, Marcel J.E. Mol <marcel@mesa.nl> wrote:
> > On Thu, Aug 12, 2010 at 07:41:39AM -0400, Marcel Holtmann wrote:
> >> Hi Marcel,
> >>
> >> > A reasonable working IrMC SYNC server (only full phonebook sync support)
> >> > Support for cal and note by just returning nothing.
> >> > ---
> >> > Makefile.am | 3 +
> >> > plugins/irmc.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> > src/main.c | 12 ++-
> >> > src/obex.h | 1 +
> >> > 4 files changed, 502 insertions(+), 2 deletions(-)
> >> > create mode 100644 plugins/irmc.c
> >> >
> >> > diff --git a/Makefile.am b/Makefile.am
> >> > index 73e2f28..ce8c675 100644
> >> > --- a/Makefile.am
> >> > +++ b/Makefile.am
> >> > @@ -58,6 +58,9 @@ builtin_sources += plugins/pbap.c plugins/phonebook.h \
> >> > builtin_modules += syncevolution
> >> > builtin_sources += plugins/syncevolution.c
> >> >
> >> > +builtin_modules += irmc
> >> > +builtin_sources += plugins/irmc.c plugins/phonebook.h
> >> > +
> >> > builtin_nodist += plugins/phonebook.c
> >> >
> >> > libexec_PROGRAMS += src/obexd
> >> > diff --git a/plugins/irmc.c b/plugins/irmc.c
> >> > new file mode 100644
> >> > index 0000000..96fd807
> >> > --- /dev/null
> >> > +++ b/plugins/irmc.c
> >> > @@ -0,0 +1,488 @@
> >> > +/*
> >> > + *
> >> > + * OBEX IrMC Sync Server
> >> > ...
> >> > +#include "dbus.h"
> >> > +
> >> > +#define IRMC_CHANNEL 17
> >>
> >> we did have a list of defined RFCOMM channels for various protocols, but
> >> just don't remember where it is.
> >>
> >> Johan, we should put that into the doc/ directory actually. Can you dig
> >> up that list and commit it as text file.
> >>
> >
> > Any news on this one? Is 17 the correct channel for IrMC?
>
> I just took a look in the spec, it just say that the channel 'varies',
> which is not very revealing and it does not suggest anything. The only
> record that I found was using channel 11 which apparently we are not
> using too.
Ok, then 17 is just fine for IrMC then. I posted a 3th version at the end of
last week. Are there any new comments I have to take care of? Or can it be
considere for inclusion in the main tree now?
On the other hand, if the channel 'varies' it might be better to let the
plugin manager select a channel number for each service instead of allocating
a fixed one in the specific plugin code.
What did you found about channel 11 then? On my nokia 7710 channel 11 is used for
"OBEX File Transfer" (serivce 0x1106).
-Marcel
--
======-------- Marcel J.E. Mol MESA Consulting B.V.
=======--------- ph. +31-(0)6-54724868 P.O. Box 112
=======--------- marcel@mesa.nl 2630 AC Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
They couldn't think of a number, Linux user 1148 -- counter.li.org
so they gave me a name! -- Rupert Hine -- www.ruperthine.com
^ permalink raw reply
* Re: [PATCH 2/3] Maemo6 MCE: listen to adapter mode changes
From: Daniel Örstadius @ 2010-08-17 8:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTim2ni6aE3-9Rx+HGeFFmmG-by6PMh4zgrJFnk-m@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Fri, Aug 13, 2010 at 12:19 PM, Daniel Örstadius
<daniel.orstadius@gmail.com> wrote:
> Registers a callback in btd_adapter to get notified when
> the powered state of the adapter is changed. This is needed
> to update the state stored in the MCE if the adapter is powered
> on or off using for example SetProperty(Powered). The current
> setting of the MCE is saved in a variable and if the notification
> to the plugin does not match this value the MCE is updated
> accordingly using its DBus method for setting radio states.
>
Attaching updated patch.
/Daniel
[-- Attachment #2: 0001-Maemo6-MCE-listen-to-adapter-powered-state.patch --]
[-- Type: text/x-patch, Size: 3559 bytes --]
From 1d72b15a82d8d9fdfb194b96dfad0d3c9cb79a3a Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 17 Aug 2010 11:41:33 +0300
Subject: [PATCH] Maemo6 MCE: listen to adapter powered state
Registers a callback in btd_adapter to get notified when the
powered state of the adapter is changed. This is needed to update
the state stored in the MCE if the adapter is powered on or off
using for example SetProperty(Powered). The current setting of
the MCE is saved in a variable and if the notification to the
plugin does not match this value the MCE is updated accordingly
using its DBus method for setting radio states.
---
plugins/maemo6.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index 2ed5f12..f9d9c1f 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -43,11 +43,13 @@
#define MCE_SIGNAL_IF "com.nokia.mce.signal"
#define MCE_REQUEST_PATH "/com/nokia/mce/request"
#define MCE_SIGNAL_PATH "/com/nokia/mce/signal"
+#define MCE_RADIO_STATES_CHANGE_REQ "req_radio_states_change"
#define MCE_RADIO_STATES_GET "get_radio_states"
#define MCE_RADIO_STATES_SIG "radio_states_ind"
static guint watch_id;
static DBusConnection *conn = NULL;
+static gboolean mce_bt_set = FALSE;
static gboolean mce_signal_callback(DBusConnection *connection,
DBusMessage *message, void *user_data)
@@ -66,7 +68,11 @@ static gboolean mce_signal_callback(DBusConnection *connection,
dbus_message_iter_get_basic(&args, &sigvalue);
DBG("got signal with value %u", sigvalue);
- if (sigvalue & MCE_RADIO_STATE_BLUETOOTH)
+ /* set the adapter according to the mce signal
+ and remember the value */
+ mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH;
+
+ if (mce_bt_set)
btd_adapter_switch_online(adapter);
else
btd_adapter_switch_offline(adapter);
@@ -102,13 +108,48 @@ static void read_radio_states_cb(DBusPendingCall *call, void *user_data)
goto done;
}
- if (radio_states & MCE_RADIO_STATE_BLUETOOTH)
+ DBG("radio_states: %d", radio_states);
+
+ mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
+
+ if (mce_bt_set)
btd_adapter_switch_online(adapter);
+ else
+ btd_adapter_switch_offline(adapter);
done:
dbus_message_unref(reply);
}
+static void adapter_powered(struct btd_adapter *adapter, gboolean powered)
+{
+ DBusMessage *msg;
+ dbus_uint32_t radio_states = 0;
+ dbus_uint32_t radio_mask = MCE_RADIO_STATE_BLUETOOTH;
+
+ DBG("adapter_powered called with %d", (int) powered);
+
+ /* nothing to do if the states match */
+ if (mce_bt_set == powered)
+ return;
+
+ /* set the mce value according to the state of the adapter */
+ msg = dbus_message_new_method_call(MCE_SERVICE, MCE_REQUEST_PATH,
+ MCE_REQUEST_IF, MCE_RADIO_STATES_CHANGE_REQ);
+
+ if (powered)
+ radio_states = MCE_RADIO_STATE_BLUETOOTH;
+
+ dbus_message_append_args(msg, DBUS_TYPE_UINT32, &radio_states,
+ DBUS_TYPE_UINT32, &radio_mask);
+
+ if (!dbus_connection_send(conn, msg, NULL))
+ error("calling %s failed", MCE_RADIO_STATES_CHANGE_REQ);
+
+ dbus_message_unref(msg);
+}
+
+
static int mce_probe(struct btd_adapter *adapter)
{
DBusMessage *msg;
@@ -132,6 +173,9 @@ static int mce_probe(struct btd_adapter *adapter)
watch_id = g_dbus_add_signal_watch(conn, NULL, MCE_SIGNAL_PATH,
MCE_SIGNAL_IF, MCE_RADIO_STATES_SIG,
mce_signal_callback, adapter, NULL);
+
+ btd_adapter_register_powered_callback(adapter, adapter_powered);
+
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/3] Add mode callback to btd_adapter
From: Johan Hedberg @ 2010-08-17 8:28 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=afUGqbZy1fRmHsPFQQyFWkEUwi+4tYT22N2az@mail.gmail.com>
Hi Daniel,
On Fri, Aug 13, 2010, Daniel Örstadius wrote:
> From: Daniel Orstadius <daniel.orstadius@nokia.com>
> Date: Fri, 13 Aug 2010 16:38:08 +0300
> Subject: [PATCH] Add powered callback to btd_adapter
>
> With this patch callback functions can be registered to the
> btd_adapter struct. The functions are then called when the powered
> state of the adapter changes, with a boolean argument indicating
> the new state. The reason for adding the functionality is that the
> Maemo6 MCE plugin needs to be notified when the adapter is powered
> on or off.
> ---
> src/adapter.c | 32 ++++++++++++++++++++++++++++++++
> src/adapter.h | 7 +++++++
> 2 files changed, 39 insertions(+), 0 deletions(-)
Thanks. This patch is now pushed upstream.
Johan
^ permalink raw reply
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: alok barsode @ 2010-08-17 8:16 UTC (permalink / raw)
To: Alexander Orlenko
Cc: Gustavo F. Padovan, Andrei Emeltchenko, Bastien Nocera,
linux-bluetooth
In-Reply-To: <AANLkTimyr6JRKNndW-PmW-NPkVj0fJQ8eTNJmD9RqOR6@mail.gmail.com>
Hey Gustavo,
On Tue, Aug 17, 2010 at 10:25 AM, Alexander Orlenko <zxteam@gmail.com> wrote:
>> Why have you decided to write a binary for each functionality? What do
>> you think about have them all in only one binary? (or at least the
>> bluetoothd related ones)
>
> My mentor (Alok Barsode) advised to write different tools for
> different functionality. I originally wanted to write a one utility
> for all. At the beginning of the project, I asked the opinions what
> should I choose (a one binary or some binaries). But almost no one
> responded.
I had proposed different binaries so that we don't bloat up a single
binary. Also with a lot of
command line options its easy to have separate binaries. Other wise
the cmd line options would be huge. I think is the same reason why the
python scripts tests/ are separate and not put in 1 script.
Cheers,
Alok.
>
> On 17 August 2010 14:59, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>> Hi Alexander,
>>
>> * Alexander Orlenko <zxteam@gmail.com> [2010-08-16 10:24:23 +1100]:
>>
>>> Hi everyone,
>>>
>>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>>> Created project home page: http://code.google.com/p/bluez-tools
>>> Current release available for download: 0.1.18-6432
>>>
>>> Code of my project does not based on non-GTK parts of
>>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>>> interfaces.
>>> I will continue developing my project after end of GSoC.
>>
>> Why have you decided to write a binary for each functionality? What do
>> you think about have them all in only one binary? (or at least the
>> bluetoothd related ones)
>>
>>
>> --
>> Gustavo F. Padovan
>> http://padovan.org
>>
> --
> 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: [GSoC'10] : New Command Line Tool(s) for bluez
From: Alexander Orlenko @ 2010-08-17 4:55 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Andrei Emeltchenko, Bastien Nocera, linux-bluetooth
In-Reply-To: <20100817035921.GA5900@vigoh>
> Why have you decided to write a binary for each functionality? What do
> you think about have them all in only one binary? (or at least the
> bluetoothd related ones)
My mentor (Alok Barsode) advised to write different tools for
different functionality. I originally wanted to write a one utility
for all. At the beginning of the project, I asked the opinions what
should I choose (a one binary or some binaries). But almost no one
responded.
On 17 August 2010 14:59, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi Alexander,
>
> * Alexander Orlenko <zxteam@gmail.com> [2010-08-16 10:24:23 +1100]:
>
>> Hi everyone,
>>
>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>> Created project home page: http://code.google.com/p/bluez-tools
>> Current release available for download: 0.1.18-6432
>>
>> Code of my project does not based on non-GTK parts of
>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>> interfaces.
>> I will continue developing my project after end of GSoC.
>
> Why have you decided to write a binary for each functionality? What do
> you think about have them all in only one binary? (or at least the
> bluetoothd related ones)
>
>
> --
> Gustavo F. Padovan
> http://padovan.org
>
^ permalink raw reply
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Gustavo F. Padovan @ 2010-08-17 3:59 UTC (permalink / raw)
To: Alexander Orlenko; +Cc: Andrei Emeltchenko, Bastien Nocera, linux-bluetooth
In-Reply-To: <AANLkTimW1SmfZ+j=F7kTSwosdz=kh+g9ofcqdTeGE7CB@mail.gmail.com>
Hi Alexander,
* Alexander Orlenko <zxteam@gmail.com> [2010-08-16 10:24:23 +1100]:
> Hi everyone,
>
> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
> Created project home page: http://code.google.com/p/bluez-tools
> Current release available for download: 0.1.18-6432
>
> Code of my project does not based on non-GTK parts of
> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
> interfaces.
> I will continue developing my project after end of GSoC.
Why have you decided to write a binary for each functionality? What do
you think about have them all in only one binary? (or at least the
bluetoothd related ones)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Gustavo F. Padovan @ 2010-08-17 3:27 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Alexander Orlenko, Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <1281951653.9775.7.camel@localhost.localdomain>
Hi,
* Bastien Nocera <hadess@hadess.net> [2010-08-16 10:40:53 +0100]:
> On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
> > Hi everyone,
> >
> > I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
> > Created project home page: http://code.google.com/p/bluez-tools
> > Current release available for download: 0.1.18-6432
> >
> > Code of my project does not based on non-GTK parts of
> > libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
> > interfaces.
>
> Shame, but I won't hold you against that :)
>
> > I will continue developing my project after end of GSoC.
>
> Hopefully people will package it for distributions so we don't get as
> many requests for command-line pairing agents :)
What about put this inside the bluez source instead of keeping it
separated? I think it's a good a idea ship this together with
bluetoothd.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH v4 2/2] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Alan Ott @ 2010-08-16 20:20 UTC (permalink / raw)
To: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Alan Ott,
Marcel Holtmann, Stephane Chatty, Michael Poole, David S. Miller,
Bastien Nocera, Eric Dumazet, linux-input, linux-kernel,
linux-usb, linux-bluetooth, netdev
Cc: Alan Ott
In-Reply-To: <1281442367.12579.206.camel@localhost.localdomain>
This patch adds support or getting and setting feature reports for bluetooth
HID devices from HIDRAW.
Signed-off-by: Alan Ott <alan@signal11.us>
---
net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++++++--
net/bluetooth/hidp/hidp.h | 8 +++
2 files changed, 118 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index bfe641b..0e4880e 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -36,6 +36,7 @@
#include <linux/file.h>
#include <linux/init.h>
#include <linux/wait.h>
+#include <linux/mutex.h>
#include <net/sock.h>
#include <linux/input.h>
@@ -313,6 +314,86 @@ static int hidp_send_report(struct hidp_session *session, struct hid_report *rep
return hidp_queue_report(session, buf, rsize);
}
+static int hidp_get_raw_report(struct hid_device *hid,
+ unsigned char report_number,
+ unsigned char *data, size_t count,
+ unsigned char report_type)
+{
+ struct hidp_session *session = hid->driver_data;
+ struct sk_buff *skb;
+ size_t len;
+ int numbered_reports = hid->report_enum[report_type].numbered;
+
+ switch (report_type) {
+ case HID_FEATURE_REPORT:
+ report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_FEATURE;
+ break;
+ case HID_INPUT_REPORT:
+ report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_INPUT;
+ break;
+ case HID_OUTPUT_REPORT:
+ report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_OUPUT;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (mutex_lock_interruptible(&session->report_mutex))
+ return -ERESTARTSYS;
+
+ /* Set up our wait, and send the report request to the device. */
+ session->waiting_report_type = report_type & HIDP_DATA_RTYPE_MASK;
+ session->waiting_report_number = numbered_reports ? report_number : -1;
+ set_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ data[0] = report_number;
+ if (hidp_send_ctrl_message(hid->driver_data, report_type, data, 1))
+ goto err_eio;
+
+ /* Wait for the return of the report. The returned report
+ gets put in session->report_return. */
+ while (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
+ int res;
+
+ res = wait_event_interruptible_timeout(session->report_queue,
+ !test_bit(HIDP_WAITING_FOR_RETURN, &session->flags),
+ 5*HZ);
+ if (res == 0) {
+ /* timeout */
+ goto err_eio;
+ }
+ if (res < 0) {
+ /* signal */
+ goto err_restartsys;
+ }
+ }
+
+ skb = session->report_return;
+ if (skb) {
+ len = skb->len < count ? skb->len : count;
+ memcpy(data, skb->data, len);
+
+ kfree_skb(skb);
+ session->report_return = NULL;
+ } else {
+ /* Device returned a HANDSHAKE, indicating protocol error. */
+ len = -EIO;
+ }
+
+ clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ mutex_unlock(&session->report_mutex);
+
+ return len;
+
+err_restartsys:
+ clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ mutex_unlock(&session->report_mutex);
+ return -ERESTARTSYS;
+err_eio:
+ clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ mutex_unlock(&session->report_mutex);
+ return -EIO;
+}
+
static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, size_t count,
unsigned char report_type)
{
@@ -367,6 +448,10 @@ static void hidp_process_handshake(struct hidp_session *session,
case HIDP_HSHK_ERR_INVALID_REPORT_ID:
case HIDP_HSHK_ERR_UNSUPPORTED_REQUEST:
case HIDP_HSHK_ERR_INVALID_PARAMETER:
+ if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
+ clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ wake_up_interruptible(&session->report_queue);
+ }
/* FIXME: Call into SET_ GET_ handlers here */
break;
@@ -403,9 +488,11 @@ static void hidp_process_hid_control(struct hidp_session *session,
}
}
-static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
+/* Returns true if the passed-in skb should be freed by the caller. */
+static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
unsigned char param)
{
+ int done_with_skb = 1;
BT_DBG("session %p skb %p len %d param 0x%02x", session, skb, skb->len, param);
switch (param) {
@@ -417,7 +504,6 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
if (session->hid)
hid_input_report(session->hid, HID_INPUT_REPORT, skb->data, skb->len, 0);
-
break;
case HIDP_DATA_RTYPE_OTHER:
@@ -429,12 +515,27 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
__hidp_send_ctrl_message(session,
HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER, NULL, 0);
}
+
+ if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags) &&
+ param == session->waiting_report_type) {
+ if (session->waiting_report_number < 0 ||
+ session->waiting_report_number == skb->data[0]) {
+ /* hidp_get_raw_report() is waiting on this report. */
+ session->report_return = skb;
+ done_with_skb = 0;
+ clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
+ wake_up_interruptible(&session->report_queue);
+ }
+ }
+
+ return done_with_skb;
}
static void hidp_recv_ctrl_frame(struct hidp_session *session,
struct sk_buff *skb)
{
unsigned char hdr, type, param;
+ int free_skb = 1;
BT_DBG("session %p skb %p len %d", session, skb, skb->len);
@@ -454,7 +555,7 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
break;
case HIDP_TRANS_DATA:
- hidp_process_data(session, skb, param);
+ free_skb = hidp_process_data(session, skb, param);
break;
default:
@@ -463,7 +564,8 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
break;
}
- kfree_skb(skb);
+ if (free_skb)
+ kfree_skb(skb);
}
static void hidp_recv_intr_frame(struct hidp_session *session,
@@ -797,6 +899,7 @@ static int hidp_setup_hid(struct hidp_session *session,
hid->dev.parent = hidp_get_device(session);
hid->ll_driver = &hidp_hid_driver;
+ hid->hid_get_raw_report = hidp_get_raw_report;
hid->hid_output_raw_report = hidp_output_raw_report;
err = hid_add_device(hid);
@@ -857,6 +960,9 @@ int hidp_add_connection(struct hidp_connadd_req *req, struct socket *ctrl_sock,
skb_queue_head_init(&session->ctrl_transmit);
skb_queue_head_init(&session->intr_transmit);
+ mutex_init(&session->report_mutex);
+ init_waitqueue_head(&session->report_queue);
+
session->flags = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
session->idle_to = req->idle_to;
diff --git a/net/bluetooth/hidp/hidp.h b/net/bluetooth/hidp/hidp.h
index 8d934a1..00e71dd 100644
--- a/net/bluetooth/hidp/hidp.h
+++ b/net/bluetooth/hidp/hidp.h
@@ -80,6 +80,7 @@
#define HIDP_VIRTUAL_CABLE_UNPLUG 0
#define HIDP_BOOT_PROTOCOL_MODE 1
#define HIDP_BLUETOOTH_VENDOR_ID 9
+#define HIDP_WAITING_FOR_RETURN 10
struct hidp_connadd_req {
int ctrl_sock; // Connected control socket
@@ -154,6 +155,13 @@ struct hidp_session {
struct sk_buff_head ctrl_transmit;
struct sk_buff_head intr_transmit;
+ /* Used in hidp_get_raw_report() */
+ int waiting_report_type; /* HIDP_DATA_RTYPE_* */
+ int waiting_report_number; /* -1 for not numbered */
+ struct mutex report_mutex;
+ struct sk_buff *report_return;
+ wait_queue_head_t report_queue;
+
/* Report descriptor */
__u8 *rd_data;
uint rd_size;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 1/2] HID: Add Support for Setting and Getting Feature Reports from hidraw
From: Alan Ott @ 2010-08-16 20:20 UTC (permalink / raw)
To: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Alan Ott,
Marcel Holtmann, Stephane Chatty, Michael Poole, David S. Miller,
Bastien Nocera, Eric Dumazet, linux-input, linux-kernel,
linux-usb, linux-bluetooth, netdev
Cc: Alan Ott
In-Reply-To: <1281442367.12579.206.camel@localhost.localdomain>
Per the HID Specification, Feature reports must be sent and received on
the Configuration endpoint (EP 0) through the Set_Report/Get_Report
interfaces. This patch adds two ioctls to hidraw to set and get feature
reports to and from the device. Modifications were made to hidraw and
usbhid.
New hidraw ioctls:
HIDIOCSFEATURE - Perform a Set_Report transfer of a Feature report.
HIDIOCGFEATURE - Perform a Get_Report transfer of a Feature report.
Signed-off-by: Alan Ott <alan@signal11.us>
---
drivers/hid/hidraw.c | 105 +++++++++++++++++++++++++++++++++++++++--
drivers/hid/usbhid/hid-core.c | 37 ++++++++++++++-
include/linux/hid.h | 3 +
include/linux/hidraw.h | 3 +
4 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 47d70c5..7df1310 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -101,14 +101,14 @@ out:
}
/* the first byte is expected to be a report number */
-static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
+/* This function is to be called with the minors_lock mutex held */
+static ssize_t hidraw_send_report(struct file *file, const char __user *buffer, size_t count, unsigned char report_type)
{
unsigned int minor = iminor(file->f_path.dentry->d_inode);
struct hid_device *dev;
__u8 *buf;
int ret = 0;
- mutex_lock(&minors_lock);
dev = hidraw_table[minor]->hid;
if (!dev->hid_output_raw_report) {
@@ -141,14 +141,92 @@ static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t
goto out_free;
}
- ret = dev->hid_output_raw_report(dev, buf, count, HID_OUTPUT_REPORT);
+ ret = dev->hid_output_raw_report(dev, buf, count, report_type);
out_free:
kfree(buf);
out:
+ return ret;
+}
+
+/* the first byte is expected to be a report number */
+static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
+{
+ ssize_t ret;
+ mutex_lock(&minors_lock);
+ ret = hidraw_send_report(file, buffer, count, HID_OUTPUT_REPORT);
mutex_unlock(&minors_lock);
return ret;
}
+
+/* This function performs a Get_Report transfer over the control endpoint
+ per section 7.2.1 of the HID specification, version 1.1. The first byte
+ of buffer is the report number to request, or 0x0 if the defice does not
+ use numbered reports. The report_type parameter can be HID_FEATURE_REPORT
+ or HID_INPUT_REPORT. This function is to be called with the minors_lock
+ mutex held. */
+static ssize_t hidraw_get_report(struct file *file, char __user *buffer, size_t count, unsigned char report_type)
+{
+ unsigned int minor = iminor(file->f_path.dentry->d_inode);
+ struct hid_device *dev;
+ __u8 *buf;
+ int ret = 0, len;
+ unsigned char report_number;
+
+ dev = hidraw_table[minor]->hid;
+
+ if (!dev->hid_get_raw_report) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (count > HID_MAX_BUFFER_SIZE) {
+ printk(KERN_WARNING "hidraw: pid %d passed too large report\n",
+ task_pid_nr(current));
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (count < 2) {
+ printk(KERN_WARNING "hidraw: pid %d passed too short report\n",
+ task_pid_nr(current));
+ ret = -EINVAL;
+ goto out;
+ }
+
+ buf = kmalloc(count * sizeof(__u8), GFP_KERNEL);
+ if (!buf) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ /* Read the first byte from the user. This is the report number,
+ which is passed to dev->hid_get_raw_report(). */
+ if (copy_from_user(&report_number, buffer, 1)) {
+ ret = -EFAULT;
+ goto out_free;
+ }
+
+ ret = dev->hid_get_raw_report(dev, report_number, buf, count, report_type);
+
+ if (ret < 0)
+ goto out_free;
+
+ len = (ret < count) ? ret : count;
+
+ if (copy_to_user(buffer, buf, len)) {
+ ret = -EFAULT;
+ goto out_free;
+ }
+
+ ret = len;
+
+out_free:
+ kfree(buf);
+out:
+ return ret;
+}
+
static unsigned int hidraw_poll(struct file *file, poll_table *wait)
{
struct hidraw_list *list = file->private_data;
@@ -281,7 +359,24 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
default:
{
struct hid_device *hid = dev->hid;
- if (_IOC_TYPE(cmd) != 'H' || _IOC_DIR(cmd) != _IOC_READ) {
+ if (_IOC_TYPE(cmd) != 'H') {
+ ret = -EINVAL;
+ break;
+ }
+
+ if (_IOC_NR(cmd) == _IOC_NR(HIDIOCSFEATURE(0))) {
+ int len = _IOC_SIZE(cmd);
+ ret = hidraw_send_report(file, user_arg, len, HID_FEATURE_REPORT);
+ break;
+ }
+ if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGFEATURE(0))) {
+ int len = _IOC_SIZE(cmd);
+ ret = hidraw_get_report(file, user_arg, len, HID_FEATURE_REPORT);
+ break;
+ }
+
+ /* Begin Read-only ioctls. */
+ if (_IOC_DIR(cmd) != _IOC_READ) {
ret = -EINVAL;
break;
}
@@ -313,7 +408,7 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
-EFAULT : len;
break;
}
- }
+ }
ret = -ENOTTY;
}
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index b729c02..93db724 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -798,6 +798,40 @@ static int hid_alloc_buffers(struct usb_device *dev, struct hid_device *hid)
return 0;
}
+static int usbhid_get_raw_report(struct hid_device *hid,
+ unsigned char report_number, __u8 *buf, size_t count,
+ unsigned char report_type)
+{
+ struct usbhid_device *usbhid = hid->driver_data;
+ struct usb_device *dev = hid_to_usb_dev(hid);
+ struct usb_interface *intf = usbhid->intf;
+ struct usb_host_interface *interface = intf->cur_altsetting;
+ int skipped_report_id = 0;
+ int ret;
+
+ /* Byte 0 is the report number. Report data starts at byte 1.*/
+ buf[0] = report_number;
+ if (report_number == 0x0) {
+ /* Offset the return buffer by 1, so that the report ID
+ will remain in byte 0. */
+ buf++;
+ count--;
+ skipped_report_id = 1;
+ }
+ ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
+ HID_REQ_GET_REPORT,
+ USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ ((report_type + 1) << 8) | report_number,
+ interface->desc.bInterfaceNumber, buf, count,
+ USB_CTRL_SET_TIMEOUT);
+
+ /* count also the report id */
+ if (ret > 0 && skipped_report_id)
+ ret++;
+
+ return ret;
+}
+
static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf, size_t count,
unsigned char report_type)
{
@@ -807,7 +841,7 @@ static int usbhid_output_raw_report(struct hid_device *hid, __u8 *buf, size_t co
struct usb_host_interface *interface = intf->cur_altsetting;
int ret;
- if (usbhid->urbout) {
+ if (usbhid->urbout && report_type != HID_FEATURE_REPORT) {
int actual_length;
int skipped_report_id = 0;
if (buf[0] == 0x0) {
@@ -1149,6 +1183,7 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
usb_set_intfdata(intf, hid);
hid->ll_driver = &usb_hid_driver;
+ hid->hid_get_raw_report = usbhid_get_raw_report;
hid->hid_output_raw_report = usbhid_output_raw_report;
hid->ff_init = hid_pidff_init;
#ifdef CONFIG_USB_HIDDEV
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 42a0f1d..1b95b0b 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -503,6 +503,9 @@ struct hid_device { /* device report descriptor */
struct hid_usage *, __s32);
void (*hiddev_report_event) (struct hid_device *, struct hid_report *);
+ /* handler for raw input (Get_Report) data, used by hidraw */
+ int (*hid_get_raw_report) (struct hid_device *, unsigned char, __u8 *, size_t, unsigned char);
+
/* handler for raw output data, used by hidraw */
int (*hid_output_raw_report) (struct hid_device *, __u8 *, size_t, unsigned char);
diff --git a/include/linux/hidraw.h b/include/linux/hidraw.h
index dd8d692..4b88e69 100644
--- a/include/linux/hidraw.h
+++ b/include/linux/hidraw.h
@@ -35,6 +35,9 @@ struct hidraw_devinfo {
#define HIDIOCGRAWINFO _IOR('H', 0x03, struct hidraw_devinfo)
#define HIDIOCGRAWNAME(len) _IOC(_IOC_READ, 'H', 0x04, len)
#define HIDIOCGRAWPHYS(len) _IOC(_IOC_READ, 'H', 0x05, len)
+/* The first byte of SFEATURE and GFEATURE is the report number */
+#define HIDIOCSFEATURE(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x06, len)
+#define HIDIOCGFEATURE(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x07, len)
#define HIDRAW_FIRST_MINOR 0
#define HIDRAW_MAX_DEVICES 64
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Alan Ott @ 2010-08-16 20:20 UTC (permalink / raw)
To: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Alan Ott,
Marcel Holtmann, Stephane Chatty, Michael Poole, David S. Miller,
Bastien Nocera, Eric Dumazet, linux-input, linux-kernel,
linux-usb, linux-bluetooth, netdev
Cc: Alan Ott
In-Reply-To: <1281442367.12579.206.camel@localhost.localdomain>
This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
Alan Ott (2):
HID: Add Support for Setting and Getting Feature Reports from hidraw
Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
HIDIOCSFEATURE
drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
include/linux/hid.h | 3 +
include/linux/hidraw.h | 3 +
net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
net/bluetooth/hidp/hidp.h | 8 +++
6 files changed, 260 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH] IrMC sync server support
From: Luiz Augusto von Dentz @ 2010-08-16 19:47 UTC (permalink / raw)
To: Marcel J.E. Mol; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20100816172238.GA27814@joshua.mesa.nl>
Hi,
On Mon, Aug 16, 2010 at 8:22 PM, Marcel J.E. Mol <marcel@mesa.nl> wrote:
> On Thu, Aug 12, 2010 at 07:41:39AM -0400, Marcel Holtmann wrote:
>> Hi Marcel,
>>
>> > A reasonable working IrMC SYNC server (only full phonebook sync suppor=
t)
>> > Support for cal and note by just returning nothing.
>> > ---
>> > =A0Makefile.am =A0 =A0| =A0 =A03 +
>> > =A0plugins/irmc.c | =A0488 +++++++++++++++++++++++++++++++++++++++++++=
+++++++++++++
>> > =A0src/main.c =A0 =A0 | =A0 12 ++-
>> > =A0src/obex.h =A0 =A0 | =A0 =A01 +
>> > =A04 files changed, 502 insertions(+), 2 deletions(-)
>> > =A0create mode 100644 plugins/irmc.c
>> >
>> > diff --git a/Makefile.am b/Makefile.am
>> > index 73e2f28..ce8c675 100644
>> > --- a/Makefile.am
>> > +++ b/Makefile.am
>> > @@ -58,6 +58,9 @@ builtin_sources +=3D plugins/pbap.c plugins/phoneboo=
k.h \
>> > =A0builtin_modules +=3D syncevolution
>> > =A0builtin_sources +=3D plugins/syncevolution.c
>> >
>> > +builtin_modules +=3D irmc
>> > +builtin_sources +=3D plugins/irmc.c plugins/phonebook.h
>> > +
>> > =A0builtin_nodist +=3D plugins/phonebook.c
>> >
>> > =A0libexec_PROGRAMS +=3D src/obexd
>> > diff --git a/plugins/irmc.c b/plugins/irmc.c
>> > new file mode 100644
>> > index 0000000..96fd807
>> > --- /dev/null
>> > +++ b/plugins/irmc.c
>> > @@ -0,0 +1,488 @@
>> > +/*
>> > + *
>> > + * =A0OBEX IrMC Sync Server
>> > ...
>> > +#include "dbus.h"
>> > +
>> > +#define IRMC_CHANNEL =A0 =A0 =A0 17
>>
>> we did have a list of defined RFCOMM channels for various protocols, but
>> just don't remember where it is.
>>
>> Johan, we should put that into the doc/ directory actually. Can you dig
>> up that list and commit it as text file.
>>
>
> Any news on this one? Is 17 the correct channel for IrMC?
I just took a look in the spec, it just say that the channel 'varies',
which is not very revealing and it does not suggest anything. The only
record that I found was using channel 11 which apparently we are not
using too.
--=20
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] IrMC sync server support
From: Marcel J.E. Mol @ 2010-08-16 17:22 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1281613299.12579.266.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset*=utf-8''%E2%80%9Cus-ascii, Size: 2008 bytes --]
On Thu, Aug 12, 2010 at 07:41:39AM -0400, Marcel Holtmann wrote:
> Hi Marcel,
>
> > A reasonable working IrMC SYNC server (only full phonebook sync support)
> > Support for cal and note by just returning nothing.
> > ---
> > Makefile.am | 3 +
> > plugins/irmc.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > src/main.c | 12 ++-
> > src/obex.h | 1 +
> > 4 files changed, 502 insertions(+), 2 deletions(-)
> > create mode 100644 plugins/irmc.c
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 73e2f28..ce8c675 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -58,6 +58,9 @@ builtin_sources += plugins/pbap.c plugins/phonebook.h \
> > builtin_modules += syncevolution
> > builtin_sources += plugins/syncevolution.c
> >
> > +builtin_modules += irmc
> > +builtin_sources += plugins/irmc.c plugins/phonebook.h
> > +
> > builtin_nodist += plugins/phonebook.c
> >
> > libexec_PROGRAMS += src/obexd
> > diff --git a/plugins/irmc.c b/plugins/irmc.c
> > new file mode 100644
> > index 0000000..96fd807
> > --- /dev/null
> > +++ b/plugins/irmc.c
> > @@ -0,0 +1,488 @@
> > +/*
> > + *
> > + * OBEX IrMC Sync Server
> > ...
> > +#include "dbus.h"
> > +
> > +#define IRMC_CHANNEL 17
>
> we did have a list of defined RFCOMM channels for various protocols, but
> just don't remember where it is.
>
> Johan, we should put that into the doc/ directory actually. Can you dig
> up that list and commit it as text file.
>
Any news on this one? Is 17 the correct channel for IrMC?
-Marcel
--
======-------- Marcel J.E. Mol MESA Consulting B.V.
=======--------- ph. +31-(0)6-54724868 P.O. Box 112
=======--------- marcel@mesa.nl 2630 AC Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
They couldn't think of a number, Linux user 1148 -- counter.li.org
so they gave me a name! -- Rupert Hine -- www.ruperthine.com
^ permalink raw reply
* Re: [PATCH] Fix problem with filling ADR with unneeded semicolons
From: Johan Hedberg @ 2010-08-16 15:16 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1281969490-22315-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lucasz,
On Mon, Aug 16, 2010, Lukasz Pawlik wrote:
> Previously in a phonebook pull request ADR was filled with six
> semicolons when contact address entry was empty in phonebook. This
> patch fixes this problem. Address is send as an empty string.
> ---
> plugins/vcard.c | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
Thanks for the patch, but it'll need some coding style cleanup before
going upstream:
> +static gboolean address_fields_present(struct phonebook_contact * contact)
No space after *
> + if (contact->country && strlen(contact->country))
> + return TRUE;
> +
The last line isn't really empty byt has an extra tab. Please remove it.
> + if (address_fields_present(contact) == FALSE) {
> + vcard_printf(vcards, "ADR:");
> + return;
There's an extra tab at the end of the line. Please remove it.
> + }
> +
Same here.
Johan
^ permalink raw reply
* [PATCH] Fix problem with filling ADR with unneeded semicolons
From: Lukasz Pawlik @ 2010-08-16 14:38 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
Previously in a phonebook pull request ADR was filled with six
semicolons when contact address entry was empty in phonebook. This
patch fixes this problem. Address is send as an empty string.
---
plugins/vcard.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 80f8265..7333a68 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -155,6 +155,26 @@ static gboolean contact_fields_present(struct phonebook_contact * contact)
return FALSE;
}
+static gboolean address_fields_present(struct phonebook_contact * contact)
+{
+ if (contact->pobox && strlen(contact->pobox))
+ return TRUE;
+ if (contact->extended && strlen(contact->extended))
+ return TRUE;
+ if (contact->street && strlen(contact->street))
+ return TRUE;
+ if (contact->locality && strlen(contact->locality))
+ return TRUE;
+ if (contact->region && strlen(contact->region))
+ return TRUE;
+ if (contact->postal && strlen(contact->postal))
+ return TRUE;
+ if (contact->country && strlen(contact->country))
+ return TRUE;
+
+ return FALSE;
+}
+
static void vcard_printf_name(GString *vcards,
struct phonebook_contact *contact)
{
@@ -253,6 +273,11 @@ static void vcard_printf_email(GString *vcards, const char *email)
static void vcard_printf_adr(GString *vcards, struct phonebook_contact *contact)
{
+ if (address_fields_present(contact) == FALSE) {
+ vcard_printf(vcards, "ADR:");
+ return;
+ }
+
vcard_printf(vcards, "ADR:%s;%s;%s;%s;%s;%s;%s", contact->pobox,
contact->extended, contact->street,
contact->locality, contact->region,
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: alok barsode @ 2010-08-16 13:35 UTC (permalink / raw)
To: Alexander Orlenko; +Cc: Bastien Nocera, Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <AANLkTimPuCLfU5Xq8vH4+w3Ketf35RXN0P=Z0X50v6V8@mail.gmail.com>
Hi Alexander,
On Mon, Aug 16, 2010 at 5:36 PM, Alexander Orlenko <zxteam@gmail.com> wrote:
>> Shame, but I won't hold you against that :)
Its a lil joke ;) Bastien maintains (iirc) the gnome-bluetooth project.
No hard feelings ( I hope:) )
> Why? I wrote tool to generate gobjects from bluez/obexd doc api files.
> And my implementation has methods for easy properties access and
> supports properties caching (for example), and some others features.
>
> On 16 August 2010 20:40, Bastien Nocera <hadess@hadess.net> wrote:
>> On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
>>> Hi everyone,
>>>
>>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>>> Created project home page: http://code.google.com/p/bluez-tools
>>> Current release available for download: 0.1.18-6432
>>>
>>> Code of my project does not based on non-GTK parts of
>>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>>> interfaces.
>>
>> Shame, but I won't hold you against that :)
>>
>>> I will continue developing my project after end of GSoC.
>>
>> Hopefully people will package it for distributions so we don't get as
>> many requests for command-line pairing agents :)
>>
>> Cheers
>>
>>
> --
> 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
>
Cheers,
Alok.
^ permalink raw reply
* Re: [PATCH] Fix empty contact in missed calls problem
From: Johan Hedberg @ 2010-08-16 13:23 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281963827-20375-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 16, 2010, Radoslaw Jablonski wrote:
> Fixed problem with tracker queries for calls history - previously call
> without contact in phonebook was missing in some scenario for pull
> requests.
> ---
> plugins/phonebook-tracker.c | 28 ++++------------------------
> 1 files changed, 4 insertions(+), 24 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] Fix empty contact in missed calls problem
From: Radoslaw Jablonski @ 2010-08-16 13:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Fixed problem with tracker queries for calls history - previously call
without contact in phonebook was missing in some scenario for pull
requests.
---
plugins/phonebook-tracker.c | 28 ++++------------------------
1 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 705460d..618ce8d 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -96,7 +96,7 @@
"} GROUP BY ?c"
#define MISSED_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -115,10 +115,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -143,7 +139,7 @@
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define INCOMING_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -162,10 +158,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -190,7 +182,7 @@
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define OUTGOING_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -208,10 +200,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -235,7 +223,7 @@
"} ORDER BY DESC(nmo:sentDate(?call))"
#define COMBINED_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -254,10 +242,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -275,10 +259,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Alexander Orlenko @ 2010-08-16 12:06 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <1281951653.9775.7.camel@localhost.localdomain>
> Shame, but I won't hold you against that :)
Why? I wrote tool to generate gobjects from bluez/obexd doc api files.
And my implementation has methods for easy properties access and
supports properties caching (for example), and some others features.
On 16 August 2010 20:40, Bastien Nocera <hadess@hadess.net> wrote:
> On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
>> Hi everyone,
>>
>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>> Created project home page: http://code.google.com/p/bluez-tools
>> Current release available for download: 0.1.18-6432
>>
>> Code of my project does not based on non-GTK parts of
>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>> interfaces.
>
> Shame, but I won't hold you against that :)
>
>> I will continue developing my project after end of GSoC.
>
> Hopefully people will package it for distributions so we don't get as
> many requests for command-line pairing agents :)
>
> Cheers
>
>
^ permalink raw reply
* Re: [PATCH 2/2] Fix not storing tty id on pnatd plugin
From: Johan Hedberg @ 2010-08-16 11:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1281957191-6964-2-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Aug 16, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> The code used to create the port stored the id in a local variable
> instead of storing it in the client data which is used to release the
> port once disconnected.
Nice catch. The patch is now upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix using wrong argument in test-serial
From: Johan Hedberg @ 2010-08-16 11:22 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1281957191-6964-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Aug 16, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> ---
> test/test-serial | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/test/test-serial b/test/test-serial
> index ed151dc..cc496df 100755
> --- a/test/test-serial
> +++ b/test/test-serial
> @@ -29,7 +29,7 @@ if (len(args) < 1):
> print "Usage: %s <address> [service]" % (sys.argv[0])
> sys.exit(1)
>
> -address = sys.argv[0]
> +address = args[0]
>
> if (len(args) < 2):
> service = "spp"
The patch is now upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] Fix not storing tty id on pnatd plugin
From: Luiz Augusto von Dentz @ 2010-08-16 11:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1281957191-6964-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
The code used to create the port stored the id in a local variable
instead of storing it in the client data which is used to release the
port once disconnected.
---
plugins/pnat.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/plugins/pnat.c b/plugins/pnat.c
index f9136a4..3f5222f 100644
--- a/plugins/pnat.c
+++ b/plugins/pnat.c
@@ -238,7 +238,7 @@ static gboolean create_tty(struct dun_server *server)
{
struct dun_client *client = &server->client;
struct rfcomm_dev_req req;
- int dev, sk = g_io_channel_unix_get_fd(client->io);
+ int sk = g_io_channel_unix_get_fd(client->io);
memset(&req, 0, sizeof(req));
req.dev_id = -1;
@@ -251,13 +251,14 @@ static gboolean create_tty(struct dun_server *server)
BT_IO_OPT_DEST_CHANNEL, &req.channel,
BT_IO_OPT_INVALID);
- dev = ioctl(sk, RFCOMMCREATEDEV, &req);
- if (dev < 0) {
+ client->tty_id = ioctl(sk, RFCOMMCREATEDEV, &req);
+ if (client->tty_id < 0) {
error("Can't create RFCOMM TTY: %s", strerror(errno));
return FALSE;
}
- snprintf(client->tty_name, PATH_MAX - 1, "/dev/rfcomm%d", dev);
+ snprintf(client->tty_name, PATH_MAX - 1, "/dev/rfcomm%d",
+ client->tty_id);
client->tty_tries = TTY_TRIES;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix using wrong argument in test-serial
From: Luiz Augusto von Dentz @ 2010-08-16 11:13 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
test/test-serial | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/test-serial b/test/test-serial
index ed151dc..cc496df 100755
--- a/test/test-serial
+++ b/test/test-serial
@@ -29,7 +29,7 @@ if (len(args) < 1):
print "Usage: %s <address> [service]" % (sys.argv[0])
sys.exit(1)
-address = sys.argv[0]
+address = args[0]
if (len(args) < 2):
service = "spp"
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Bastien Nocera @ 2010-08-16 9:40 UTC (permalink / raw)
To: Alexander Orlenko; +Cc: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <AANLkTimW1SmfZ+j=F7kTSwosdz=kh+g9ofcqdTeGE7CB@mail.gmail.com>
On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
> Hi everyone,
>
> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
> Created project home page: http://code.google.com/p/bluez-tools
> Current release available for download: 0.1.18-6432
>
> Code of my project does not based on non-GTK parts of
> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
> interfaces.
Shame, but I won't hold you against that :)
> I will continue developing my project after end of GSoC.
Hopefully people will package it for distributions so we don't get as
many requests for command-line pairing agents :)
Cheers
^ permalink raw reply
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Alexander Orlenko @ 2010-08-15 23:24 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Bastien Nocera, linux-bluetooth
In-Reply-To: <AANLkTik3d0rY2QNrhevwzPz28VQwKuj7A5s-9l152H4Y@mail.gmail.com>
Hi everyone,
I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
Created project home page: http://code.google.com/p/bluez-tools
Current release available for download: 0.1.18-6432
Code of my project does not based on non-GTK parts of
libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
interfaces.
I will continue developing my project after end of GSoC.
On 21 May 2010 18:29, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
>
> On Thu, May 20, 2010 at 4:08 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Fri, 2010-05-21 at 00:04 +1100, Alexander Orlenko wrote:
> >> Hi everyone,
> >>
> >> My name is Alexander Orlenko, I am a GSoC student of this year. I am
> >> doing a project "bluez-tools",
> >> http://hostisdown.org/gsoc/projects/bluez-tools (a little more info
> >> about the project). I need some feedback about what approach should I
> >> take.
> >
> > I'm not sure whether you'd be interested, but you could base your code
> > on the non-GTK parts of libgnome-bluetooth, which already implements a
> > number of those things, and would just need to be wrapped up.
>
> There is also python code in bluez/test repository.
>
> -- Andrei
>
> >
> > Cheers
> >
> > --
> > 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: [PATCH] Bluetooth: Fix inconsistent lock state with RFCOMM
From: Marcel Holtmann @ 2010-08-14 19:39 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1281797213-10940-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> When receiving a rfcomm connection with the old dund deamon the following
> inconsistent lock state happens:
>
> [ 811.702999] =================================
> [ 811.702999] [ INFO: inconsistent lock state ]
> [ 811.702999] 2.6.35-rc1-01743-g41069ad-dirty #1
> [ 811.702999] ---------------------------------
> [ 811.702999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> [ 811.702999] krfcommd/3892 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 811.702999] (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] {IN-SOFTIRQ-W} state was registered at:
> [ 811.702999] [<ffffffff8108dfa6>] __lock_acquire+0x5b6/0x1560
> [ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
> [ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
> [ 811.702999] [<ffffffffa0043092>] 0xffffffffa0043092
> [ 811.702999] [<ffffffffa0044a3f>] 0xffffffffa0044a3f
> [ 811.702999] [<ffffffffa0047183>] 0xffffffffa0047183
> [ 811.702999] [<ffffffffa004798b>] 0xffffffffa004798b
> [ 811.702999] [<ffffffffa000db4b>] 0xffffffffa000db4b
> [ 811.702999] [<ffffffff81067efb>] tasklet_action+0xcb/0xe0
> [ 811.702999] [<ffffffff810685ee>] __do_softirq+0xae/0x150
> [ 811.702999] [<ffffffff81029c0c>] call_softirq+0x1c/0x30
> [ 811.702999] [<ffffffff8102bd75>] do_softirq+0x75/0xb0
> [ 811.702999] [<ffffffff8106823d>] irq_exit+0x8d/0xa0
> [ 811.702999] [<ffffffff8102b330>] do_IRQ+0x70/0xf0
> [ 811.702999] [<ffffffff81388513>] ret_from_intr+0x0/0xf
> [ 811.702999] [<ffffffff81027dfa>] cpu_idle+0x5a/0xb0
> [ 811.702999] [<ffffffff81382934>] start_secondary+0x211/0x254
> [ 811.702999] irq event stamp: 411
> [ 811.702999] hardirqs last enabled at (411): [<ffffffff81068432>] local_bh_enable_ip+0x82/0xe0
> [ 811.702999] hardirqs last disabled at (409): [<ffffffff8106860e>] __do_softirq+0xce/0x150
> [ 811.702999] softirqs last enabled at (410): [<ffffffff8106863e>] __do_softirq+0xfe/0x150
> [ 811.702999] softirqs last disabled at (391): [<ffffffff81029c0c>] call_softirq+0x1c/0x30
> [ 811.702999]
> [ 811.702999] other info that might help us debug this:
> [ 811.702999] 2 locks held by krfcommd/3892:
> [ 811.702999] #0: (rfcomm_mutex){+.+.+.}, at: [<ffffffffa0188744>] rfcomm_run+0x174/0xb20 [rfcomm]
> [ 811.702999] #1: (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa0186223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm]
> [ 811.702999]
> [ 811.702999] stack backtrace:
> [ 811.702999] Pid: 3892, comm: krfcommd Tainted: G W 2.6.35-rc1-01743-g41069ad-dirty #1
> [ 811.702999] Call Trace:
> [ 811.702999] [<ffffffff8108c541>] print_usage_bug+0x171/0x180
> [ 811.702999] [<ffffffff8108d323>] mark_lock+0x333/0x400
> [ 811.702999] [<ffffffff8108e02a>] __lock_acquire+0x63a/0x1560
> [ 811.702999] [<ffffffff8108e515>] ? __lock_acquire+0xb25/0x1560
> [ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
> [ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
> [ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffffa0186239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
> [ 811.702999] [<ffffffffa0186a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm]
> [ 811.702999] [<ffffffffa0187cab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
> [ 811.702999] [<ffffffff8138827b>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
> [ 811.702999] [<ffffffff8108d72d>] ? trace_hardirqs_on_caller+0x13d/0x180
> [ 811.702999] [<ffffffff8108d77d>] ? trace_hardirqs_on+0xd/0x10
> [ 811.702999] [<ffffffffa01887f1>] rfcomm_run+0x221/0xb20 [rfcomm]
> [ 811.702999] [<ffffffff81385667>] ? schedule+0x267/0x5d0
> [ 811.702999] [<ffffffffa01885d0>] ? rfcomm_run+0x0/0xb20 [rfcomm]
> [ 811.702999] [<ffffffff8107afae>] kthread+0x8e/0xa0
> [ 811.702999] [<ffffffff81029b14>] kernel_thread_helper+0x4/0x10
> [ 811.702999] [<ffffffff813885bc>] ? restore_args+0x0/0x30
> [ 811.702999] [<ffffffff8107af20>] ? kthread+0x0/0xa0
> [ 811.702999] [<ffffffff81029b10>] ? kernel_thread_helper+0x0/0x10
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/rfcomm/sock.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 44a6232..30cd80b 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -82,12 +82,14 @@ static void rfcomm_sk_data_ready(struct rfcomm_dlc *d, struct sk_buff *skb)
> static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
> {
> struct sock *sk = d->owner, *parent;
> + unsigned long flags;
> +
> if (!sk)
> return;
>
> BT_DBG("dlc %p state %ld err %d", d, d->state, err);
>
> - bh_lock_sock(sk);
> + spin_lock_irqsave(&sk->sk_lock.slock, flags);
>
> if (err)
> sk->sk_err = err;
> @@ -107,7 +109,7 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
> sk->sk_state_change(sk);
> }
>
> - bh_unlock_sock(sk);
> + spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
>
> if (parent && sock_flag(sk, SOCK_ZAPPED)) {
> /* We have to drop DLC lock here, otherwise
I am missing an explanation why you fixed it this way. And also why thi
sis the right way to fix it. Directly referencing sk->sk_lock seems
pretty much wrong to me.
Regards
Marcel
^ permalink raw reply
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