* [PATCH 1/1] Enable xy scrolling for Apple Magic Mouse
From: Ed Tomlinson @ 2010-02-14 22:24 UTC (permalink / raw)
To: Jiri Kosina
Cc: Michael Poole, linux-input, Marcel Holtmann, linux-bluetooth,
linux-kernel
In-Reply-To: <alpine.LNX.2.00.1002101456490.30967@pobox.suse.cz>
Hi,
Here is a patch that enables xy scrolling with the magic mouse. I have also
changed the accelleration logic to work better with xy scrolling.
Comments
Ed Tomlinson
---
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index b20484a..3075d78 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -59,7 +59,7 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state fie
* @delta_time: 18-bit difference between the two most recent touch
* reports from the mouse.
* @ntouches: Number of touches in most recent touch report.
- * @scroll_accel: Number of consecutive scroll motions.
+ * @scroll_accely: Number of consecutive scroll motions.
* @scroll_jiffies: Time of last scroll motion.
* @touches: Most recent data for a touch, indexed by tracking ID.
* @tracking_ids: Mapping of current touch input data to @touches.
@@ -71,11 +71,13 @@ struct magicmouse_sc {
int last_timestamp;
int delta_time;
int ntouches;
- int scroll_accel;
+ int scroll_accely;
+ int scroll_accelx;
unsigned long scroll_jiffies;
struct {
short x;
+ short scroll_x;
short y;
short scroll_y;
u8 size;
@@ -139,8 +141,10 @@ static void magicmouse_emit_buttons(struct magicmouse_sc *msc, int state)
input_report_key(msc->input, BTN_LEFT, state & 1);
input_report_key(msc->input, BTN_RIGHT, state & 2);
- if (state != last_state)
- msc->scroll_accel = 0;
+ if (state != last_state) {
+ msc->scroll_accely = 0;
+ msc->scroll_accelx = 0;
+ }
}
static void magicmouse_emit_touch(struct magicmouse_sc *msc, int raw_id, u8 *tdata)
@@ -159,34 +163,46 @@ static void magicmouse_emit_touch(struct magicmouse_sc *msc, int raw_id, u8 *tda
msc->touches[id].size = misc & 63;
/* If requested, emulate a scroll wheel by detecting small
- * vertical touch motions along the middle of the mouse.
+ * touch motions on the mouse.
*/
if (emulate_scroll_wheel &&
- middle_button_start < x && x < middle_button_stop) {
+ msc->ntouches == 1) {
static const int accel_profile[] = {
- 256, 228, 192, 160, 128, 96, 64, 32,
+ 192, 160, 128, 96, 64, 48, 32, 24,
};
unsigned long now = jiffies;
- int step = msc->touches[id].scroll_y - y;
+ int stepx, stepy;
/* Reset acceleration after half a second. */
- if (time_after(now, msc->scroll_jiffies + HZ / 2))
- msc->scroll_accel = 0;
+ if (time_after(now, msc->scroll_jiffies + HZ / 2)) {
+ msc->scroll_accely = 0;
+ msc->scroll_accelx = 0;
+ }
- /* Calculate and apply the scroll motion. */
switch (tdata[7] & TOUCH_STATE_MASK) {
case TOUCH_STATE_START:
msc->touches[id].scroll_y = y;
- msc->scroll_accel = min_t(int, msc->scroll_accel + 1,
- ARRAY_SIZE(accel_profile) - 1);
+ msc->touches[id].scroll_x = x;
break;
case TOUCH_STATE_DRAG:
- step = step / accel_profile[msc->scroll_accel];
- if (step != 0) {
+ /* Calculate and apply the scroll motion. */
+ stepy = (msc->touches[id].scroll_y - y)/accel_profile[msc->scroll_accely];
+ stepx = (msc->touches[id].scroll_x - x)/accel_profile[msc->scroll_accelx];
+
+ /* tell input about any motions */
+ if (stepy != 0) {
msc->touches[id].scroll_y = y;
- msc->scroll_jiffies = now;
- input_report_rel(input, REL_WHEEL, step);
+ input_report_rel(input, REL_WHEEL, stepy);
+ msc->scroll_accely = min_t(int, msc->scroll_accely + 1,
+ ARRAY_SIZE(accel_profile) - 1);
}
+ if (stepx != 0) {
+ msc->touches[id].scroll_x = x;
+ input_report_rel(input, REL_HWHEEL, stepx);
+ msc->scroll_accelx = min_t(int, msc->scroll_accelx + 1,
+ ARRAY_SIZE(accel_profile) - 1);
+ }
+ msc->scroll_jiffies = now;
break;
}
}
@@ -300,8 +316,10 @@ static void magicmouse_setup_input(struct input_dev *input, struct hid_device *h
__set_bit(EV_REL, input->evbit);
__set_bit(REL_X, input->relbit);
__set_bit(REL_Y, input->relbit);
- if (emulate_scroll_wheel)
+ if (emulate_scroll_wheel) {
__set_bit(REL_WHEEL, input->relbit);
+ __set_bit(REL_HWHEEL, input->relbit);
+ }
if (report_touches) {
__set_bit(EV_ABS, input->evbit);
^ permalink raw reply related
* Re: [PATCH 0/2] Provide a driver for the Apple Magic Mouse - opps
From: Ed Tomlinson @ 2010-02-14 14:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Michael Poole, linux-input, Marcel Holtmann,
linux-bluetooth, linux-kernel
In-Reply-To: <20100214080344.GA4423@core.coreip.homeip.net>
On Sunday 14 February 2010 03:03:44 Dmitry Torokhov wrote:
> On Sat, Feb 13, 2010 at 02:29:29PM -0500, Ed Tomlinson wrote:
> > On Wednesday 10 February 2010 08:57:37 Jiri Kosina wrote:
> > > On Tue, 9 Feb 2010, Michael Poole wrote:
> > >
> > > > I think this patch is ready for real review. The Magic Mouse requires
> > > > that a driver send an unlock Report(Feature) command, similar to the
> > > > Wacom wireless tablet and Sixaxis controller quirks. This turns on an
> > > > Input Report that isn't published in the input Report descriptor that
> > > > contains touch data (and usually overrides the normal motion and click
> > > > Report).
> > > >
> > > > Because the mouse has only one switch and no scroll wheel, the driver
> > > > (under control of parameters) emulates a middle button and scroll wheel.
> > > > User space could also ignore and/or re-synthesize those events based on
> > > > the reported events.
> > > >
> > > > The first patch exports hid_register_report() so the driver can turn on
> > > > the multitouch report. The second patch adds the device ID and the
> > > > driver. Some user-space tools to talk to the mouse directly (that is,
> > > > when it is not associated with the host's HIDP stack) are at
> > > > http://github.com/entrope/linux-magicmouse .
> > >
> > > I have applied the driver into apple_magic_mouse branch and merged this
> > > branch into for-next, so it should appear in the upcoming linux-next.
> >
>
> > This driver (or the hid changes) can triggers an opps. What I did was
> > start X. Turn on the magic mouse. It connected on input7&8. Then I
> > powered it off and on. This time it conneced on input9&10. Then I
> > exited X and got the opps. Note my X does not hotplug the magic
> > mouse. I've also included a trace of the udev events that generated
> > the log below (if there was a remove after X stopped it would not be
> > included). To my eyes it looks like we leak an input device (there is
> > not a remove event for input8).
> >
>
> Indeed, we seem to be missing call to input_unregister_device() in
> magicmouse_remove().
How does this look? With this udevadm shows input8 being removed and
there is no more opps.
----
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index f94b3e4..71a8669 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -429,8 +429,11 @@ static int magicmouse_probe(struct hid_device *hdev,
static void magicmouse_remove(struct hid_device *hdev)
{
+ struct magicmouse_sc *msc;
+ msc = hid_get_drvdata(hdev);
+ input_unregister_device(msc->input);
hid_hw_stop(hdev);
- kfree(hid_get_drvdata(hdev));
+ kfree(msc);
}
static const struct hid_device_id magic_mice[] = {
----
Thanks
Ed
^ permalink raw reply related
* [PATCH 2/2] Add hack to allow compilation with old bluez lib
From: Stefan Seyfried @ 2010-02-14 11:33 UTC (permalink / raw)
To: BlueZ development; +Cc: Marcel Holtmann, Stefan Seyfried
In-Reply-To: <1266147212-32461-2-git-send-email-stefan.seyfried@googlemail.com>
From: Stefan Seyfried <seife@sphairon.com>
---
parser/hci.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index e4fc473..33c3640 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -41,6 +41,12 @@
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
+/* ugly hack, as hci.h changed incompatibly with bluez 4.61 */
+#ifndef OCF_READ_INQ_RESPONSE_TX_POWER_LEVEL
+#define OCF_READ_INQ_RESPONSE_TX_POWER_LEVEL OCF_READ_INQUIRY_TRANSMIT_POWER_LEVEL
+#define read_inq_response_tx_power_level_rp read_inquiry_transmit_power_level_rp
+#endif
+
#include "parser.h"
static uint16_t manufacturer = DEFAULT_COMPID;
--
1.6.6.1
^ permalink raw reply related
* [PATCH 1/2] Fix compilation with bluez 4.61's changed hci.h
From: Stefan Seyfried @ 2010-02-14 11:33 UTC (permalink / raw)
To: BlueZ development; +Cc: Marcel Holtmann, Stefan Seyfried
In-Reply-To: <1266147212-32461-1-git-send-email-stefan.seyfried@googlemail.com>
From: Stefan Seyfried <seife@sphairon.com>
---
parser/hci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index f1507fc..e4fc473 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -1973,7 +1973,7 @@ static inline void read_ext_inquiry_response_dump(int level, struct frame *frm)
static inline void read_inquiry_transmit_power_level_dump(int level, struct frame *frm)
{
- read_inquiry_transmit_power_level_rp *rp = frm->ptr;
+ read_inq_response_tx_power_level_rp *rp = frm->ptr;
p_indent(level, frm);
printf("status 0x%2.2x level %d\n", rp->status, rp->level);
@@ -2325,7 +2325,7 @@ static inline void cmd_complete_dump(int level, struct frame *frm)
case OCF_READ_EXT_INQUIRY_RESPONSE:
read_ext_inquiry_response_dump(level, frm);
return;
- case OCF_READ_INQUIRY_TRANSMIT_POWER_LEVEL:
+ case OCF_READ_INQ_RESPONSE_TX_POWER_LEVEL:
read_inquiry_transmit_power_level_dump(level, frm);
return;
case OCF_READ_DEFAULT_ERROR_DATA_REPORTING:
--
1.6.6.1
^ permalink raw reply related
* [PATCH 0/2] Fix hcidump compilation with bluez-4.61+
From: Stefan Seyfried @ 2010-02-14 11:33 UTC (permalink / raw)
To: BlueZ development; +Cc: Marcel Holtmann
Bluez 4.61 broke compilation of hcidump.
The first patch fixes this for bluez 4.61, the second patch implements an
(admittedly ugly) hack to also allow to compile hcidump with older bluez
versions.
^ permalink raw reply
* Re: [PATCH 0/2] Provide a driver for the Apple Magic Mouse - opps
From: Dmitry Torokhov @ 2010-02-14 8:03 UTC (permalink / raw)
To: Ed Tomlinson
Cc: Jiri Kosina, Michael Poole, linux-input, Marcel Holtmann,
linux-bluetooth, linux-kernel
In-Reply-To: <201002131429.29671.edt@aei.ca>
On Sat, Feb 13, 2010 at 02:29:29PM -0500, Ed Tomlinson wrote:
> On Wednesday 10 February 2010 08:57:37 Jiri Kosina wrote:
> > On Tue, 9 Feb 2010, Michael Poole wrote:
> >
> > > I think this patch is ready for real review. The Magic Mouse requires
> > > that a driver send an unlock Report(Feature) command, similar to the
> > > Wacom wireless tablet and Sixaxis controller quirks. This turns on an
> > > Input Report that isn't published in the input Report descriptor that
> > > contains touch data (and usually overrides the normal motion and click
> > > Report).
> > >
> > > Because the mouse has only one switch and no scroll wheel, the driver
> > > (under control of parameters) emulates a middle button and scroll wheel.
> > > User space could also ignore and/or re-synthesize those events based on
> > > the reported events.
> > >
> > > The first patch exports hid_register_report() so the driver can turn on
> > > the multitouch report. The second patch adds the device ID and the
> > > driver. Some user-space tools to talk to the mouse directly (that is,
> > > when it is not associated with the host's HIDP stack) are at
> > > http://github.com/entrope/linux-magicmouse .
> >
> > I have applied the driver into apple_magic_mouse branch and merged this
> > branch into for-next, so it should appear in the upcoming linux-next.
>
> This driver (or the hid changes) can triggers an opps. What I did was
> start X. Turn on the magic mouse. It connected on input7&8. Then I
> powered it off and on. This time it conneced on input9&10. Then I
> exited X and got the opps. Note my X does not hotplug the magic
> mouse. I've also included a trace of the udev events that generated
> the log below (if there was a remove after X stopped it would not be
> included). To my eyes it looks like we leak an input device (there is
> not a remove event for input8).
>
Indeed, we seem to be missing call to input_unregister_device() in
magicmouse_remove().
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/2] Provide a driver for the Apple Magic Mouse - opps
From: Ed Tomlinson @ 2010-02-13 19:29 UTC (permalink / raw)
To: Jiri Kosina
Cc: Michael Poole, linux-input, Marcel Holtmann, linux-bluetooth,
linux-kernel
In-Reply-To: <alpine.LNX.2.00.1002101456490.30967@pobox.suse.cz>
On Wednesday 10 February 2010 08:57:37 Jiri Kosina wrote:
> On Tue, 9 Feb 2010, Michael Poole wrote:
>
> > I think this patch is ready for real review. The Magic Mouse requires
> > that a driver send an unlock Report(Feature) command, similar to the
> > Wacom wireless tablet and Sixaxis controller quirks. This turns on an
> > Input Report that isn't published in the input Report descriptor that
> > contains touch data (and usually overrides the normal motion and click
> > Report).
> >
> > Because the mouse has only one switch and no scroll wheel, the driver
> > (under control of parameters) emulates a middle button and scroll wheel.
> > User space could also ignore and/or re-synthesize those events based on
> > the reported events.
> >
> > The first patch exports hid_register_report() so the driver can turn on
> > the multitouch report. The second patch adds the device ID and the
> > driver. Some user-space tools to talk to the mouse directly (that is,
> > when it is not associated with the host's HIDP stack) are at
> > http://github.com/entrope/linux-magicmouse .
>
> I have applied the driver into apple_magic_mouse branch and merged this
> branch into for-next, so it should appear in the upcoming linux-next.
This driver (or the hid changes) can triggers an opps. What I did was start X. Turn on the magic mouse. It connected on input7&8.
Then I powered it off and on. This time it conneced on input9&10. Then I exited X and got the opps. Note my X does not hotplug
the magic mouse. I've also included a trace of the udev events that generated the log below (if there was a remove after X stopped
it would not be included). To my eyes it looks like we leak an input device (there is not a remove event for input8).
[ 5955.908380] input: Apple Wireless Mouse as /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7
[ 5955.921165] magicmouse 0005:05AC:030D.0004: input,hidraw3: BLUETOOTH HID v0.84 Mouse [Apple Wireless Mouse] on 00:0A:3A:55:07:5A
[ 5955.934120] input: Apple Wireless Mouse as /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8
[ 6180.899332] input: Apple Wireless Mouse as /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input9
[ 6180.911914] magicmouse 0005:05AC:030D.0005: input,hidraw3: BLUETOOTH HID v0.84 Mouse [Apple Wireless Mouse] on 00:0A:3A:55:07:5A
[ 6180.923988] input: Apple Wireless Mouse as /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input10
[ 6391.991295] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 6391.995818] IP: [<ffffffffa05a604f>] magicmouse_input_open+0x1f/0x30 [hid_magicmouse]
[ 6392.009801] PGD 16c3b6067 PUD 16b139067 PMD 0
[ 6392.009801] Oops: 0000 [#1] PREEMPT SMP
[ 6392.009801] last sysfs file: /sys/devices/pci0000:00/0000:00:18.3/temp1_input
[ 6392.009801] CPU 1
[ 6392.009801] Pid: 2763, comm: gpm Not tainted 2.6.33-rc8-crc #106 M3A78-T/System Product Name
[ 6392.064520] RIP: 0010:[<ffffffffa05a604f>] [<ffffffffa05a604f>] magicmouse_input_open+0x1f/0x30 [hid_magicmouse]
[ 6392.064520] RSP: 0018:ffff88016c2ddba8 EFLAGS: 00010282
[ 6392.064520] RAX: ffff88016dd90000 RBX: ffff88016bc9b000 RCX: 0000000000000001
[ 6392.107009] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88016dd90000
[ 6392.107009] RBP: ffff88016c2ddba8 R08: 2222222222222222 R09: 2222222222222222
[ 6392.107009] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880133b5a810
[ 6392.107009] R13: ffff88016bc9b820 R14: ffff88016dd60150 R15: ffff88016dd600a8
[ 6392.107009] FS: 00007f5ee305b700(0000) GS:ffff880028280000(0000) knlGS:0000000000000000
[ 6392.107009] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6392.107009] CR2: 0000000000000010 CR3: 000000016c3b7000 CR4: 00000000000006e0
[ 6392.107009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6392.107009] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6392.107009] Process gpm (pid: 2763, threadinfo ffff88016c2dc000, task ffff88016dde0000)
[ 6392.107009] Stack:
[ 6392.107009] ffff88016c2ddbe8 ffffffff814010e9 ffff88016dd60150 ffff88016dd600a8
[ 6392.107009] <0> ffff88016c2ddbe8 ffff880133b5a800 ffff880133b5a8d8 0000000000000000
[ 6392.107009] <0> ffff88016c2ddc18 ffffffff81404236 ffff88016c2ddc18 ffff880133b5a800
[ 6392.107009] Call Trace:
[ 6392.107009] [<ffffffff814010e9>] input_open_device+0x89/0xb0
[ 6392.107009] [<ffffffff81404236>] mousedev_open_device+0x76/0x100
[ 6392.107009] [<ffffffff814042a9>] mousedev_open_device+0xe9/0x100
[ 6392.107009] [<ffffffff8140523f>] mousedev_open+0x19f/0x260
[ 6392.107009] [<ffffffff814bc243>] ? _lock_kernel+0x143/0x1e0
[ 6392.107009] [<ffffffff81402ba7>] input_open_file+0x227/0x410
[ 6392.107009] [<ffffffff814bf981>] ? sub_preempt_count+0x51/0x60
[ 6392.107009] [<ffffffff8112384d>] chrdev_open+0x17d/0x320
[ 6392.107009] [<ffffffff814bbb7c>] ? _raw_spin_unlock+0x5c/0x70
[ 6392.107009] [<ffffffff8111d358>] __dentry_open+0x1a8/0x400
[ 6392.107009] [<ffffffff811236d0>] ? chrdev_open+0x0/0x320
[ 6392.107009] [<ffffffff8111d6b4>] nameidata_to_filp+0x54/0x70
[ 6392.107009] [<ffffffff8112e7f1>] do_filp_open+0x841/0xc00
[ 6392.107009] [<ffffffff814bf981>] ? sub_preempt_count+0x51/0x60
[ 6392.107009] [<ffffffff814bbb7c>] ? _raw_spin_unlock+0x5c/0x70
[ 6392.107009] [<ffffffff81002b0c>] ? sysret_check+0x27/0x62
[ 6392.107009] [<ffffffff8111e954>] do_sys_open+0xa4/0x180
[ 6392.107009] [<ffffffff8111ea70>] sys_open+0x20/0x30
[ 6392.107009] [<ffffffff81002adb>] system_call_fastpath+0x16/0x1b
[ 6392.107009] Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 48 81 c7 a0 08 00 00 e8 3b f0 de e0 48 8b 90 38 1b 00 00 48 89 c7 <ff> 52 10 c9 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5
[ 6392.107009] RIP [<ffffffffa05a604f>] magicmouse_input_open+0x1f/0x30 [hid_magicmouse]
[ 6392.107009] RSP <ffff88016c2ddba8>
[ 6392.107009] CR2: 0000000000000010
[ 6392.107321] ---[ end trace c83e80c68826df09 ]---
grover ~ # udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1266085238.085802] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41 (bluetooth)
UDEV [1266085238.113475] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41 (bluetooth)
KERNEL[1266085238.412016] add /module/hidp (module)
UDEV [1266085238.412247] add /module/hidp (module)
KERNEL[1266085238.418193] add /bus/hid/drivers/generic-bluetooth (drivers)
UDEV [1266085238.418365] add /bus/hid/drivers/generic-bluetooth (drivers)
KERNEL[1266085238.418507] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004 (hid)
KERNEL[1266085238.460711] add /module/hid_magicmouse (module)
UDEV [1266085238.460906] add /module/hid_magicmouse (module)
KERNEL[1266085238.460977] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7 (input)
UDEV [1266085238.462772] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7 (input)
KERNEL[1266085238.473232] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/mouse1 (input)
KERNEL[1266085238.473323] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/event7 (input)
KERNEL[1266085238.473662] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004/hidraw/hidraw3 (hidraw)
UDEV [1266085238.479691] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/event7 (input)
KERNEL[1266085238.486090] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8 (input)
UDEV [1266085238.488291] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/mouse1 (input)
UDEV [1266085238.493195] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8 (input)
KERNEL[1266085238.498954] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8/mouse2 (input)
KERNEL[1266085238.499066] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8/event8 (input)
KERNEL[1266085238.499154] add /bus/hid/drivers/magicmouse (drivers)
UDEV [1266085238.499624] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004 (hid)
UDEV [1266085238.501108] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004/hidraw/hidraw3 (hidraw)
UDEV [1266085238.501311] add /bus/hid/drivers/magicmouse (drivers)
UDEV [1266085238.509221] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8/event8 (input)
UDEV [1266085238.511459] add /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input8/mouse2 (input)
KERNEL[1266085311.467279] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/mouse1 (input)
UDEV [1266085311.468189] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/mouse1 (input)
KERNEL[1266085311.471961] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/event7 (input)
UDEV [1266085311.472632] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7/event7 (input)
KERNEL[1266085311.475921] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7 (input)
KERNEL[1266085311.475985] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004/hidraw/hidraw3 (hidraw)
KERNEL[1266085311.476153] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004 (hid)
KERNEL[1266085311.476214] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41 (bluetooth)
UDEV [1266085311.476397] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/input7 (input)
UDEV [1266085311.476734] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004/hidraw/hidraw3 (hidraw)
UDEV [1266085311.477000] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41/0005:05AC:030D.0004 (hid)
UDEV [1266085311.503056] remove /devices/pci0000:00/0000:00:13.2/usb7/7-4/7-4.4/7-4.4:1.0/bluetooth/hci0/hci0:41 (bluetooth)
Ideas?
Ed Tomlinson
^ permalink raw reply
* compat-wireless updated for 2.6.33-rc8, 2.6.32.8 and next-20100212
From: Luis R. Rodriguez @ 2010-02-13 2:10 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel
The bleeding edge compat-wireless updates were stuck due to a
bluetooth hunk failing on net/bluetooth/hidp/core.c, that should be
fixed now, at least it compiles for me down to 2.6.27. I also hadn't
updated a 2.6.33-rcx releases in a while, as well as 2.6.32.y release.
This should all now be in synch with upstream. I never got reports
about MQ support on older kernels so I just threw in the code, issues
can be dealt with once actually found.
ath3k went in on 2.6.33-rc8 so we enable it now. Atheros Ethernet
AR8152/AR8152 support was submitted upstream for atl1c but it hasn't
been merged yet so likely it won't get into 2.6.33, but once its
merged for 2.6.34 I will just throw in the patch as an extra onto the
compat-wireless-2.6.33 releases.
Worth noting also is if you have any specific patch which did *not* go
into a stable release due to size but yet considered relatively
important and if it is merged upstream please send a note to
linux-wireless about it and we can consider enabling it if it is not
insane. This applies to new drivers as well. I will likely an an
extra/ dir. The only requirement is you *must* have the patch merged
upstream on one of the trees, either wireless-testing,
bluetooth-testing, or net-next-2.6. Reasoning for enabling patches
like these is as I have seen, even as hard we try we somehow can't get
rid of a small delta between what we feel needs to be supported and
what is on stable. My main concern over accepting patches like these
is creating a fork but forks can be avoided if we have a requirement
of first requiring the patch on a development tree.
Please report any issues found:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
Stable releases:
=========
2.6.32.8:
sha1sum 694b453db50cd22798b754d022aca1e5ba45c8f1
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.8.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/ChangeLog-2.6.32.8-wireless
2.6.33-rc8:
sha1sum 4811f419acb1d9d12e5262bffc4892da71134510
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.33/compat-wireless-2.6.33-rc8.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.33/ChangeLog-2.6.33-rc8-wireless
Bleeding edge release based on linux-next:
==========================
http://wireless.kernel.org/en/users/Download
http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2
Luis
^ permalink raw reply
* [PATCH] Punch a hole for HandsfreeAgent in dbus policy
From: Denis Kenzior @ 2010-02-13 2:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Denis Kenzior
In-Reply-To: <1266026813-29676-1-git-send-email-denis.kenzior@intel.com>
---
src/bluetooth.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/bluetooth.conf b/src/bluetooth.conf
index 315009c..56e7a83 100644
--- a/src/bluetooth.conf
+++ b/src/bluetooth.conf
@@ -11,6 +11,7 @@
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.Agent"/>
+ <allow send_interface="org.bluez.HandsfreeAgent"/>
</policy>
<policy at_console="true">
--
1.6.4.4
^ permalink raw reply related
* [PATCH] Punch a hole for HandsfreeAgent in dbus policy
From: Denis Kenzior @ 2010-02-13 2:06 UTC (permalink / raw)
To: linux-bluetooth
This is required for HFP support.
^ permalink raw reply
* Re: Coordinating development for Bluetooth 3.0 between 802.11 and BT trees
From: Marcel Holtmann @ 2010-02-13 0:09 UTC (permalink / raw)
To: John W. Linville
Cc: Luis R. Rodriguez, linux-wireless, linux-bluetooth, Dan Tian,
Kevin Hayes
In-Reply-To: <20100212183309.GB4983@tuxdriver.com>
Hi John,
> > Wanted to get your feedback on what you think would be the best
> > approach to take for focus on development for Bluetooth 3.0 support.
> > Hoping there is a better solution than using linux-next.
>
> I'm sure Marcel and Johannes are way ahead of us on this. :-)
>
> I think you covered the basics, but you did leave-out the possibility
> of using net-next-2.6 for bleeding-edge development of bluetooth 3.
> Since both Marcel and I feed Dave's tree and Dave endeavours to
> keep the history of that tree stable then this would seem like your
> best bet.
if we reach the point where any kind of coordination is needed between
your and my tree, I would just merge into wireless-next-2.6 tree instead
of net-next-2.6. That should solve most issues around this anyway. And
in case it doesn't we will always need manual interaction on one side.
So I wouldn't try to overthink this right now.
The only tricky part I see is wireless-testing since bluetooth-testing
is not immutable right now. And I don't have any intention to make it
that way.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] Deprecate the ListAdapters() method on Manager
From: Marcel Holtmann @ 2010-02-12 19:47 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1265998592-7249-2-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
> doc/manager-api.txt | 6 ++++--
> src/manager.c | 3 ++-
> 2 files changed, 6 insertions(+), 3 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] Add {deprecated} annotation to ListDevices()
From: Marcel Holtmann @ 2010-02-12 19:46 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1265998592-7249-1-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
> ---
> doc/adapter-api.txt | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: Coordinating development for Bluetooth 3.0 between 802.11 and BT trees
From: Marcel Holtmann @ 2010-02-12 19:16 UTC (permalink / raw)
To: John W. Linville
Cc: Luis R. Rodriguez, linux-wireless, linux-bluetooth, Dan Tian,
Kevin Hayes
In-Reply-To: <20100212183309.GB4983@tuxdriver.com>
Hi John,
> In any case, I was under the impression that at least the initial
> parts of the 802.11 AMP implementation could happen independently
> from any bluetooth stack changes...?
yes, we should be able to test the AMP pieces without a Bluetooth stack
implementing the AMP manager. Especially since there will be FullMAC
WiFi devices that implement the AMP inside firmware.
Regards
Marcel
^ permalink raw reply
* Re: Coordinating development for Bluetooth 3.0 between 802.11 and BT trees
From: David Vrabel @ 2010-02-12 18:48 UTC (permalink / raw)
To: John W. Linville
Cc: Luis R. Rodriguez, Marcel Holtmann, linux-wireless,
linux-bluetooth, Dan Tian, Kevin Hayes
In-Reply-To: <20100212183309.GB4983@tuxdriver.com>
John W. Linville wrote:
>
> In any case, I was under the impression that at least the initial
> parts of the 802.11 AMP implementation could happen independently
> from any bluetooth stack changes...?
You should be able to do (almost) all of the AMP PAL development and
testing without a Bluetooth stack.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply
* Re: Coordinating development for Bluetooth 3.0 between 802.11 and BT trees
From: John W. Linville @ 2010-02-12 18:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, linux-wireless, linux-bluetooth, Dan Tian,
Kevin Hayes
In-Reply-To: <43e72e891002111210l55d6a802pc5a1384e3535c845@mail.gmail.com>
On Thu, Feb 11, 2010 at 12:10:24PM -0800, Luis R. Rodriguez wrote:
> we are reviewing possibilities of working on Bluetooth 3.0. With
> Bluetooth 3.0 you essentially will switch to transmitting large data
> over your 802.11 device instead of the BT device. One of the first
> questions we need to address first is how we would go about
> coordinating development between wireless-testing and
> bluetooth-testing. First I'll note that I know squat of bluetooth so
> bare with me if I'm not being 100% accurate here. From what I gather
> on the mac80211 side the biggest piece will be the PAL implementation
> which should translate HCI commands to respective 802.11 frames where
> needed. It seems this would likely be the first thing tackled. Prior
> to working on 802.11 though we realize that at some point we'll need
> to synchronize the 802.11 and Bluetooth trees though so work done on
> wireless-testing for a PAL is reasonable but then the
> bluetooth-testing won't have the respective updates.
>
> Using linux-next is one possibility but using linux-next proves a pain
> due to the fact that every single update on breaks updates, so the
> only way to update is:
>
> git fetch
> git reset --hard origin
>
> Wanted to get your feedback on what you think would be the best
> approach to take for focus on development for Bluetooth 3.0 support.
> Hoping there is a better solution than using linux-next.
I'm sure Marcel and Johannes are way ahead of us on this. :-)
I think you covered the basics, but you did leave-out the possibility
of using net-next-2.6 for bleeding-edge development of bluetooth 3.
Since both Marcel and I feed Dave's tree and Dave endeavours to
keep the history of that tree stable then this would seem like your
best bet.
In any case, I was under the impression that at least the initial
parts of the 802.11 AMP implementation could happen independently
from any bluetooth stack changes...?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 2/2] Deprecate the ListAdapters() method on Manager
From: Gustavo F. Padovan @ 2010-02-12 18:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1265998592-7249-1-git-send-email-padovan@profusion.mobi>
---
doc/manager-api.txt | 6 ++++--
src/manager.c | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 256a782..d2c1caf 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -37,9 +37,11 @@ Methods dict GetProperties()
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.NoSuchAdapter
- array{object} ListAdapters()
+ array{object} ListAdapters() {deprecated}
- Returns list of adapter object paths under /org/bluez
+ Returns list of adapter object paths under /org/bluez.
+ This method is deprecated, instead use the Adapters
+ Property to get the list of adapter object paths.
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.Failed
diff --git a/src/manager.c b/src/manager.c
index 3331dcb..da7b91f 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -229,7 +229,8 @@ static GDBusMethodTable manager_methods[] = {
{ "GetProperties", "", "a{sv}",get_properties },
{ "DefaultAdapter", "", "o", default_adapter },
{ "FindAdapter", "s", "o", find_adapter },
- { "ListAdapters", "", "ao", list_adapters },
+ { "ListAdapters", "", "ao", list_adapters,
+ G_DBUS_METHOD_FLAG_DEPRECATED},
{ }
};
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/2] Add {deprecated} annotation to ListDevices()
From: Gustavo F. Padovan @ 2010-02-12 18:16 UTC (permalink / raw)
To: linux-bluetooth
---
doc/adapter-api.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 213bc02..48cab40 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -80,9 +80,11 @@ Methods dict GetProperties()
Possible Errors: org.bluez.Error.DoesNotExist
org.bluez.Error.InvalidArguments
- array{object} ListDevices()
+ array{object} ListDevices() {deprecated}
Returns list of device object paths.
+ This method is deprecated, instead use the Devices
+ Property to get the list of devices object paths.
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.Failed
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH] g_dbus_remove_watch function
From: Marcel Holtmann @ 2010-02-12 17:57 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <f9d4bd31002111306h143c82den71b0e89c41c98463@mail.gmail.com>
Hi Claudio,
> this patch removes an unnecessary argument(D-Bus connection) of
> g_dbus_remove_watch.
I would prefer if we keep it. In theory we can open watches on per
connection basis. And keep the watch id based on this connection.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] eSCO fallback to SCO on Error: Connection Failed to Complete
From: Marcel Holtmann @ 2010-02-12 17:56 UTC (permalink / raw)
To: smcoe1; +Cc: Nick Pelly, linux-bluetooth
In-Reply-To: <9c9ad6a31002120806m381e6548xacf28c5ba9b079de@mail.gmail.com>
Hi Stephen,
> Thanks, I guess I wasn't really paying attention, it was a late nite.
>
> Signed-off-by: Stephen Coe <smcoe1@gmail.com>
> ---
> net/bluetooth/hci_event.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 592da5c..6c57fc7 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1698,6 +1698,7 @@ static inline void
> hci_sync_conn_complete_evt(struct hci_dev *hdev, struct sk_bu
> hci_conn_add_sysfs(conn);
> break;
>
> + case 0x11: /* Unsupported Feature or Parameter Value */
> case 0x1c: /* SCO interval rejected */
> case 0x1a: /* Unsupported Remote Feature */
> case 0x1f: /* Unspecified error */
I need a proper patch with the hcidump and the name of the device that
causes this issue. See how Nick has done it lately.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] eSCO fallback to SCO on Error: Connection Failed to Complete
From: smcoe1 @ 2010-02-12 16:06 UTC (permalink / raw)
To: Nick Pelly; +Cc: linux-bluetooth
In-Reply-To: <35c90d961002111320n3e5626d6oca767c7facccc356@mail.gmail.com>
Nick,
Thanks, I guess I wasn't really paying attention, it was a late nite.
Signed-off-by: Stephen Coe <smcoe1@gmail.com>
---
net/bluetooth/hci_event.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 592da5c..6c57fc7 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1698,6 +1698,7 @@ static inline void
hci_sync_conn_complete_evt(struct hci_dev *hdev, struct sk_bu
hci_conn_add_sysfs(conn);
break;
+ case 0x11: /* Unsupported Feature or Parameter Value */
case 0x1c: /* SCO interval rejected */
case 0x1a: /* Unsupported Remote Feature */
case 0x1f: /* Unspecified error */
^ permalink raw reply related
* Re: Apple Bluetooth devices: Battery level?
From: Bastien Nocera @ 2010-02-12 15:41 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-bluetooth, linux-input
In-Reply-To: <alpine.LNX.2.00.0906161156470.7457@wotan.suse.de>
On Tue, 2009-06-16 at 11:59 +0200, Jiri Kosina wrote:
> On Sat, 13 Jun 2009, Iain Hibbert wrote:
>
> > Sorry, I posted a parsed version of the report descriptor previously
> > though I failed to cross post:
> >
> > Collection page=Generic_Desktop usage=Mouse
> > Input id=2 size=1 count=1 page=Button usage=Button_1 Variable, logical range 0..1
> > Input id=2 size=1 count=1 page=Button usage=Button_2 Variable, logical range 0..1
> > Input id=2 size=1 count=1 page=Button usage=Button_3 Variable, logical range 0..1
> > Input id=2 size=1 count=1 page=Button usage=Button_4 Variable, logical range 0..1
> > Input id=2 size=4 count=1 page=0x0000 usage=0x0000 Const Variable, logical range 0..1
> > Collection page=Generic_Desktop usage=Pointer
> > Input id=2 size=8 count=1 page=Generic_Desktop usage=X Variable Relative, logical range -127..127
> > Input id=2 size=8 count=1 page=Generic_Desktop usage=Y Variable Relative, logical range -127..127
> > Input id=2 size=8 count=1 page=Consumer usage=AC_Pan Variable Relative, logical range -127..127
> > Input id=2 size=8 count=1 page=Generic_Desktop usage=Wheel Variable Relative, logical range -127..127
> > End collection
> > Input id=2 size=8 count=1 page=0x00ff usage=0x00c0 Variable, logical range -127..127
> > Feature id=71 size=8 count=1 page=Device_Controls usage=Battery_Strength Variable NoPref Volatile, logical range 0..100
> > End collection
> > As you can see, there is a Feature report relating to the Battery
> > Strength, but I do not know what to do with that. I suppose that it is
> > to be polled in order to return a percentage value..
>
> Yes, it has to be polled. But at least the initial value should be
> retrieved during the very initialization of the device -- both USB and
> Bluetooth implementations this in usbhid_init_reports()/hidp_start() --
> they query INPUT and FEATURE reports during device initialization.
Any hints/example code on how to do that? Or is this something you'd
want to work on?
Cheers
^ permalink raw reply
* Re: [PATCH] Fix segmentation fault when headset disconnects during authorization
From: Johan Hedberg @ 2010-02-12 1:38 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <f9d4bd31002101510y1435f74ev886d7993959990ff@mail.gmail.com>
Hi Claudio,
On Wed, Feb 10, 2010, Claudio Takahasi wrote:
> This patch fix a segmentation fault when the headset disconnected
> during authorization, see gdb backtrace:
> http://pastebin.com/m1529c2dc
Thanks. Strange that we didn't notice this earlier. It's been pushed
upstream now though.
> Can someone fix avctp now? For this case, answering "yes" in agent
> avctp connection will be left open:
>
> bluetoothd[5406]: Headset disconnected during authorization
> bluetoothd[5406]: State changed
> /org/bluez/5406/hci0/dev_00_15_A0_0F_76_CF: HEADSET_STATE_CONNECTING
> -> HEADSET_STATE_DISCONNECTED
> bluetoothd[5406]: AVCTP: connected to 00:15:A0:0F:76:CF
> bluetoothd[5406]: Can't open input device: No such file or directory (2)
> bluetoothd[5406]: AVRCP: failed to init uinput for 00:15:A0:0F:76:CF
> bluetoothd[5406]: AVCTP Connected
I'll be offline for the next 5 days so someone else will need to look at
this one.
Johan
^ permalink raw reply
* Re: [PATCHes] More osso-gwobex cleanups
From: Johan Hedberg @ 2010-02-12 1:36 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1265808777.2383.8684.camel@localhost.localdomain>
Hi Bastien,
On Wed, Feb 10, 2010, Bastien Nocera wrote:
> Let me know what you think.
All patches looked good and they've been pushed upstream. Thanks!
Johan
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth:L2CAP check FEAT success
From: Nick Pelly @ 2010-02-12 0:50 UTC (permalink / raw)
To: Liejun Tao; +Cc: Marcel Holtmann, Bluettooth Linux
In-Reply-To: <8a7a8d7b1002091852p4b76917fnd43c2346943caa6a@mail.gmail.com>
On Tue, Feb 9, 2010 at 6:52 PM, Liejun Tao <liejuntao001@gmail.com> wrote:
> ping
>
> On Wed, Feb 3, 2010 at 12:13 PM, Liejun Tao <liejuntao001@gmail.com> wrot=
e:
>> Hi Marcel,
>>
>>> Hi Liejun,
>>>
>>> I might have an idea what is going here. Can you send me the whole
>>> hcidump -X -V from the Create Connection to the Connection Refused
>>> without having it mangled via your mailer.
>>>
>>> Regards
>>>
>>> Marcel
>>
>> In my source, function l2cap_security_cfm & l2cap_information_rsp is
>> almost same as 2.6.33-rc6.
>>
>> Ed's log looks almost same as mine.
>> There migh be minor vairaty like
>>
>> 1.sometimes after Info Req: type 2, there is a Info Req: type 3.
>>
>> HCI sniffer - Bluetooth packet analyzer ver 1.42
>>
>> device: hci0 snap_len: 1028 filter: 0xffffffff
>>
>> 2010-02-03 18:03:47.446807 < HCI Command: Create Connection
>> (0x01|0x0005) plen 13
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA ptype 0xcc18 rswitch 0x01 clkoffset 0x00=
00
>>
>> =E1 =E1Packet type: DM1 DM3 DM5 DH1 DH3 DH5
>>
>> 2010-02-03 18:03:47.455749 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Create Connection (0x01|0x0005) status 0x00 ncmd 1
>>
>> 2010-02-03 18:03:47.993408 > HCI Event: Link Key Request (0x17) plen 6
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA
>>
>> 2010-02-03 18:03:47.997131 < HCI Command: Link Key Request Reply
>> (0x01|0x000b) plen 22
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA key 09F010B636EBEC8A3E0E81BBD7AE1CAA
>>
>> 2010-02-03 18:03:47.997802 > HCI Event: Command Complete (0x0e) plen 10
>>
>> =E1 =E1Link Key Request Reply (0x01|0x000b) ncmd 1
>>
>> =E1 =E1status 0x00 bdaddr 00:24:9F:AC:1E:EA
>>
>> 2010-02-03 18:03:48.014465 > HCI Event: Connect Complete (0x03) plen 11
>>
>> =E1 =E1status 0x00 handle 1 bdaddr 00:24:9F:AC:1E:EA type ACL encrypt 0x=
00
>>
>> 2010-02-03 18:03:48.014678 < HCI Command: Read Remote Supported
>> Features (0x01|0x001b) plen 2
>>
>> =E1 =E1handle 1
>>
>> 2010-02-03 18:03:48.015563 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
>>
>> 2010-02-03 18:03:48.022430 < HCI Command: Remote Name Request
>> (0x01|0x0019) plen 10
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA mode 2 clkoffset 0x0000
>>
>> 2010-02-03 18:03:48.023437 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
>>
>> 2010-02-03 18:03:48.024230 > HCI Event: Max Slots Change (0x1b) plen 3
>>
>> =E1 =E1handle 1 slots 5
>>
>> 2010-02-03 18:03:48.028198 > HCI Event: Read Remote Supported Features
>> (0x0b) plen 11
>>
>> =E1 =E1status 0x00 handle 1
>>
>> =E1 =E1Features: 0xbf 0xfe 0x8f 0xfe 0x98 0x19 0x00 0x80
>>
>> 2010-02-03 18:03:48.028320 < ACL data: handle 1 flags 0x02 dlen 10
>>
>> =E1 =E1L2CAP(s): Info req: type 2
>>
>> 2010-02-03 18:03:48.031616 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 18:03:48.039977 > HCI Event: Remote Name Req Complete (0x07) =
plen 255
>>
>> =E1 =E1status 0x00 bdaddr 00:24:9F:AC:1E:EA name 'BlackBerry 8900'
>>
>> 2010-02-03 18:03:48.042755 > ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Info rsp: type 2 result 1
>>
>> =E1 =E1 =E1Not supported
>>
>> 2010-02-03 18:03:48.042846 < ACL data: handle 1 flags 0x02 dlen 10
>>
>> =E1 =E1L2CAP(s): Info req: type 3
>>
>> 2010-02-03 18:03:48.045226 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 18:03:48.090545 > HCI Event: Encrypt Change (0x08) plen 4
>>
>> =E1 =E1status 0x00 handle 1 encrypt 0x01
>>
>> 2010-02-03 18:03:48.090728 < ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Connect req: psm 3 scid 0x0040
>>
>> 2010-02-03 18:03:48.094024 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 18:03:48.094146 > ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Info rsp: type 3 result 1
>>
>> =E1 =E1 =E1Not supported
>>
>> 2010-02-03 18:03:48.094238 < ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Connect req: psm 3 scid 0x0040
>>
>> 2010-02-03 18:03:48.096618 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 18:03:48.104003 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
>>
>> =E1 =E1 =E1Connection successful
>>
>> 2010-02-03 18:03:48.104095 < ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
>>
>> =E1 =E1 =E1MTU 1013
>>
>> 2010-02-03 18:03:48.104125 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
>>
>> =E1 =E1 =E1MTU 1024
>>
>> 2010-02-03 18:03:48.104156 < ACL data: handle 1 flags 0x02 dlen 18
>>
>> =E1 =E1L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
>>
>> =E1 =E1 =E1MTU 1024
>>
>> 2010-02-03 18:03:48.104339 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 4 status 0
>>
>> =E1 =E1 =E1Connection refused - no resources available
>>
>> 2010-02-03 18:03:48.107696 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 2
>>
>> 2010-02-03 18:03:48.115264 > ACL data: handle 1 flags 0x02 dlen 14
>>
>> =E1 =E1L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
>>
>> =E1 =E1 =E1Success
>>
>> 2010-02-03 18:03:48.115386 > ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
>>
>> 2010-02-03 18:03:50.101531 < HCI Command: Disconnect (0x01|0x0006) plen =
3
>>
>> =E1 =E1handle 1 reason 0x13
>>
>> =E1 =E1Reason: Remote User Terminated Connection
>>
>> 2010-02-03 18:03:50.102508 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Disconnect (0x01|0x0006) status 0x00 ncmd 1
>>
>> 2010-02-03 18:03:50.105438 > HCI Event: Disconn Complete (0x05) plen 4
>>
>> =E1 =E1status 0x00 handle 1 reason 0x16
>>
>> =E1 =E1Reason: Connection Terminated by Local Host
>>
>>
>> 2. sometimes Encrypt Change is before Info Req: type 2
>>
>> HCI sniffer - Bluetooth packet analyzer ver 1.42
>>
>> 2010-02-03 17:58:29.214416 < HCI Command: Create Connection
>> (0x01|0x0005) plen 13
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA ptype 0xcc18 rswitch 0x01 clkoffset 0x00=
00
>>
>> =E1 =E1Packet type: DM1 DM3 DM5 DH1 DH3 DH5
>>
>> 2010-02-03 17:58:29.234832 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Create Connection (0x01|0x0005) status 0x00 ncmd 1
>>
>> 2010-02-03 17:58:30.559875 > HCI Event: Link Key Request (0x17) plen 6
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA
>>
>> 2010-02-03 17:58:30.563995 < HCI Command: Link Key Request Reply
>> (0x01|0x000b) plen 22
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA key 09F010B636EBEC8A3E0E81BBD7AE1CAA
>>
>> 2010-02-03 17:58:30.564819 > HCI Event: Command Complete (0x0e) plen 10
>>
>> =E1 =E1Link Key Request Reply (0x01|0x000b) ncmd 1
>>
>> =E1 =E1status 0x00 bdaddr 00:24:9F:AC:1E:EA
>>
>> 2010-02-03 17:58:30.580596 > HCI Event: Connect Complete (0x03) plen 11
>>
>> =E1 =E1status 0x00 handle 1 bdaddr 00:24:9F:AC:1E:EA type ACL encrypt 0x=
00
>>
>> 2010-02-03 17:58:30.580779 < HCI Command: Read Remote Supported
>> Features (0x01|0x001b) plen 2
>>
>> =E1 =E1handle 1
>>
>> 2010-02-03 17:58:30.581634 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
>>
>> 2010-02-03 17:58:30.587951 > HCI Event: Max Slots Change (0x1b) plen 3
>>
>> =E1 =E1handle 1 slots 5
>>
>> 2010-02-03 17:58:30.590515 > HCI Event: Read Remote Supported Features
>> (0x0b) plen 11
>>
>> =E1 =E1status 0x00 handle 1
>>
>> =E1 =E1Features: 0xbf 0xfe 0x8f 0xfe 0x98 0x19 0x00 0x80
>>
>> 2010-02-03 17:58:30.590667 < ACL data: handle 1 flags 0x02 dlen 10
>>
>> =E1 =E1L2CAP(s): Info req: type 2
>>
>> 2010-02-03 17:58:30.593902 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 17:58:30.600280 < HCI Command: Remote Name Request
>> (0x01|0x0019) plen 10
>>
>> =E1 =E1bdaddr 00:24:9F:AC:1E:EA mode 2 clkoffset 0x0000
>>
>> 2010-02-03 17:58:30.600799 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
>>
>> 2010-02-03 17:58:30.615020 > HCI Event: Remote Name Req Complete (0x07) =
plen 255
>>
>> =E1 =E1status 0x00 bdaddr 00:24:9F:AC:1E:EA name 'BlackBerry 8900'
>>
>> 2010-02-03 17:58:30.639282 > HCI Event: Encrypt Change (0x08) plen 4
>>
>> =E1 =E1status 0x00 handle 1 encrypt 0x01
>>
>> 2010-02-03 17:58:30.639434 < ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Connect req: psm 3 scid 0x0040
>>
>> 2010-02-03 17:58:30.642669 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 17:58:30.642822 > ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Info rsp: type 2 result 1
>>
>> =E1 =E1 =E1Not supported
>>
>> 2010-02-03 17:58:30.642883 < ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Connect req: psm 3 scid 0x0040
>>
>> 2010-02-03 17:58:30.645141 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 1
>>
>> 2010-02-03 17:58:30.652862 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
>>
>> =E1 =E1 =E1Connection successful
>>
>> 2010-02-03 17:58:30.652862 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
>>
>> =E1 =E1 =E1MTU 1024
>>
>> 2010-02-03 17:58:30.652984 > ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0040 result 4 status 0
>>
>> =E1 =E1 =E1Connection refused - no resources available
>>
>> 2010-02-03 17:58:30.653137 < ACL data: handle 1 flags 0x02 dlen 16
>>
>> =E1 =E1L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
>>
>> =E1 =E1 =E1MTU 1013
>>
>> 2010-02-03 17:58:30.653198 < ACL data: handle 1 flags 0x02 dlen 18
>>
>> =E1 =E1L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
>>
>> =E1 =E1 =E1MTU 1024
>>
>> 2010-02-03 17:58:30.657653 > HCI Event: Number of Completed Packets
>> (0x13) plen 5
>>
>> =E1 =E1handle 1 packets 2
>>
>> 2010-02-03 17:58:30.665191 > ACL data: handle 1 flags 0x02 dlen 14
>>
>> =E1 =E1L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
>>
>> =E1 =E1 =E1Success
>>
>> 2010-02-03 17:58:30.665283 > ACL data: handle 1 flags 0x02 dlen 12
>>
>> =E1 =E1L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
>>
>> 2010-02-03 17:58:32.648467 < HCI Command: Disconnect (0x01|0x0006) plen =
3
>>
>> =E1 =E1handle 1 reason 0x13
>>
>> =E1 =E1Reason: Remote User Terminated Connection
>>
>> 2010-02-03 17:58:32.649322 > HCI Event: Command Status (0x0f) plen 4
>>
>> =E1 =E1Disconnect (0x01|0x0006) status 0x00 ncmd 1
>>
>> 2010-02-03 17:58:32.652984 > HCI Event: Disconn Complete (0x05) plen 4
>>
>> =E1 =E1status 0x00 handle 1 reason 0x16
>>
>> =E1 =E1Reason: Connection Terminated by Local Host
>>
Hi Marcel,
You said you had some idea what was going on here. Do you have a
better approach in mind to fix this?
Nick
^ 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