Life has not been conducive to frivolities like trying new kernels, but I
finally gave 3.4-rc5 a go yesterday. I'm seeing some decidedly weird
keyboard behavior; it seems surprising that nobody else has complained.
I have a logitech Dinovo Edge bluetooth keyboard that I've used for
years. With 3.4 kernels, the keyboard generates no input until I've
banged on it for a couple of seconds. If I continually hit characters,
they make it through; as soon as I stop for even a brief period (even
somebody as verbose as me has to come up for air occasionally), it goes
back to sleep.
It's almost as if some sort of aggressive power management were knocking
things out at every chance. Wired USB keyboards do not show this
behavior. Neither does my bluetooth mouse (which is on a different
adapter).
3.3 works, 3.4-rc1 appears not to. This should be a straightforward
bisection and I'm happy to begin that process, but I thought I'd ask if
anybody had any ideas first...?
Thanks,
jon
On Tue, May 01, 2012 at 05:24:54PM -0600, Jonathan Corbet wrote:
> > In either case, does the
> > attached file help if dropped into /lib/udev/rules.d ?
>
> Nope, no joy there.
You tested after rebooting?
--
Matthew Garrett | [email protected]
On Tue, 1 May 2012 20:27:36 +0100
Matthew Garrett <[email protected]> wrote:
> What does removable in the parent device say?
"unknown".
> In either case, does the
> attached file help if dropped into /lib/udev/rules.d ?
Nope, no joy there.
Thanks,
jon
What does removable in the parent device say? In either case, does the
attached file help if dropped into /lib/udev/rules.d ?
--
Matthew Garrett | [email protected]
On Tue, May 01, 2012 at 12:39:23PM -0600, Jonathan Corbet wrote:
> On Tue, 1 May 2012 19:31:49 +0100
> Matthew Garrett <[email protected]> wrote:
>
> > > It's Rawhide, updated yesterday. "Removable" says "fixed".
> >
> > Ok, well that's the problem. udev is seeing "fixed" and enabling
> > autosuspend. Is this really bluetooth, or does it appear as a USB HID
> > device? Can you send lsusb -v?
>
> Whether it's really bluetooth has been an issue in the past... parts of
> the system have fought over it.
Ok, so what I'm assuming is happening here is that the device is plugged
into a port that's flagged "removable", but contains a built-in hub and
the receiver is attached to *that*. So this code really needs to look
back up the chain and see whether the parent port was removable or not.
I think the kernel is arguably ok here, and the udev rule needs fixing.
Let me talk to Kay.
--
Matthew Garrett | [email protected]
On Tue, 1 May 2012 19:31:49 +0100
Matthew Garrett <[email protected]> wrote:
> > It's Rawhide, updated yesterday. "Removable" says "fixed".
>
> Ok, well that's the problem. udev is seeing "fixed" and enabling
> autosuspend. Is this really bluetooth, or does it appear as a USB HID
> device? Can you send lsusb -v?
Whether it's really bluetooth has been an issue in the past... parts of
the system have fought over it.
lsusb says (on an older kernel where my keyboard works):
Bus 002 Device 003: ID 046d:0b04 Logitech, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0x0b04
bcdDevice 49.00
iManufacturer 1 Logitech
iProduct 2 Logitech BT Mini-Receiver
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x0004
Ganged power switching
Compound device
Ganged overcurrent protection
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 100 milli Ampere
DeviceRemovable 0x0c
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Port 3: 0000.0103 power enable connect
Device Status: 0x0000
(Bus Powered)
jon
On Tue, May 01, 2012 at 12:01:45PM -0600, Jonathan Corbet wrote:
> On Tue, 1 May 2012 18:19:01 +0100
> Matthew Garrett <[email protected]> wrote:
>
> > On its own, this should do precisely nothing.
>
> Nonetheless, at the previous patch
> (0846e7e9856c0928223447d9349a877202a63f24, usb: Add support for indicating
> whether a port is removable) things work. With this one, they don't.
The patch just exports an attribute, so it's something then acting on
that attribute...
> > What userspace are you
> > running, and what does the removable node in the sysfs entry for the
> > dongle's USB device say?
>
> It's Rawhide, updated yesterday. "Removable" says "fixed".
Ok, well that's the problem. udev is seeing "fixed" and enabling
autosuspend. Is this really bluetooth, or does it appear as a USB HID
device? Can you send lsusb -v?
--
Matthew Garrett | [email protected]
On Tue, 1 May 2012 18:19:01 +0100
Matthew Garrett <[email protected]> wrote:
> On its own, this should do precisely nothing.
Nonetheless, at the previous patch
(0846e7e9856c0928223447d9349a877202a63f24, usb: Add support for indicating
whether a port is removable) things work. With this one, they don't.
> What userspace are you
> running, and what does the removable node in the sysfs entry for the
> dongle's USB device say?
It's Rawhide, updated yesterday. "Removable" says "fixed".
FWIW, power/runtime_status reads "suspended" most of the time. By banging
on the keyboard I can get it to "active", but it goes back to "suspended"
even with continuous activity. Weirdly, the keyboard continues to work if
I keep hitting keys.
Thanks,
jon
On Tue, May 01, 2012 at 11:01:56AM -0600, Jonathan Corbet wrote:
> OK, git bisect has rendered its verdict:
>
> d35e70d50a0641ebc1502fd343bef9b4011ada27 is the first bad commit
> commit d35e70d50a0641ebc1502fd343bef9b4011ada27
> Author: Matthew Garrett <[email protected]>
> Date: Fri Feb 3 17:11:55 2012 -0500
>
> usb: Use hub port data to determine whether a port is removable
>
> Hubs have a flag to indicate whether a given port carries removable devices
> or not. This is not strictly accurate in that some built-in devices
> will be flagged as removable, but followup patches will make use of platform
> data to make this more reliable.
>
> Signed-off-by: Matthew Garrett <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ...and, indeed, things do seem to break right there.
>
> I assume there's something funky about the (oldish) USB bluetooth dongle
> that came with my keyboard that interacts badly with this patch. Matthew,
> is there anything I can do or tell you to help figure this one out?
On its own, this should do precisely nothing. What userspace are you
running, and what does the removable node in the sysfs entry for the
dongle's USB device say?
--
Matthew Garrett | [email protected]
On Tue, 1 May 2012 07:37:11 -0600
Jonathan Corbet <[email protected]> wrote:
> I have a logitech Dinovo Edge bluetooth keyboard that I've used for
> years. With 3.4 kernels, the keyboard generates no input until I've
> banged on it for a couple of seconds. If I continually hit characters,
> they make it through; as soon as I stop for even a brief period (even
> somebody as verbose as me has to come up for air occasionally), it goes
> back to sleep.
OK, git bisect has rendered its verdict:
d35e70d50a0641ebc1502fd343bef9b4011ada27 is the first bad commit
commit d35e70d50a0641ebc1502fd343bef9b4011ada27
Author: Matthew Garrett <[email protected]>
Date: Fri Feb 3 17:11:55 2012 -0500
usb: Use hub port data to determine whether a port is removable
Hubs have a flag to indicate whether a given port carries removable devices
or not. This is not strictly accurate in that some built-in devices
will be flagged as removable, but followup patches will make use of platform
data to make this more reliable.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
...and, indeed, things do seem to break right there.
I assume there's something funky about the (oldish) USB bluetooth dongle
that came with my keyboard that interacts badly with this patch. Matthew,
is there anything I can do or tell you to help figure this one out?
Thanks,
jon
Hi Jon,
* Jonathan Corbet <[email protected]> [2012-05-01 07:37:11 -0600]:
> Life has not been conducive to frivolities like trying new kernels, but I
> finally gave 3.4-rc5 a go yesterday. I'm seeing some decidedly weird
> keyboard behavior; it seems surprising that nobody else has complained.
>
> I have a logitech Dinovo Edge bluetooth keyboard that I've used for
> years. With 3.4 kernels, the keyboard generates no input until I've
> banged on it for a couple of seconds. If I continually hit characters,
> they make it through; as soon as I stop for even a brief period (even
> somebody as verbose as me has to come up for air occasionally), it goes
> back to sleep.
This looks weird, I suspect of something. Could you try running
'bluetoothd -nd -P mgmtops' and check if the problem still happens too
you?
Gustavo