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
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
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
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 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 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 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: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]
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, 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
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 Wed, 2 May 2012 22:50:34 +0100
Matthew Garrett <[email protected]> wrote:
> > > In either case, does the
> > > attached file help if dropped into /lib/udev/rules.d ?
> >
> > Nope, no joy there.
>
> You tested after rebooting?
Yes, of course. I'm running a kernel that actually talks to my keyboard
most of the time, I *have* to reboot to try a broken one.
Thanks,
jon
On Wed, May 02, 2012 at 04:04:37PM -0600, Jonathan Corbet wrote:
> On Wed, 2 May 2012 22:50:34 +0100
> Matthew Garrett <[email protected]> wrote:
>
> > > > In either case, does the
> > > > attached file help if dropped into /lib/udev/rules.d ?
> > >
> > > Nope, no joy there.
> >
> > You tested after rebooting?
>
> Yes, of course. I'm running a kernel that actually talks to my keyboard
> most of the time, I *have* to reboot to try a broken one.
Hm. Well, easiest thing to do would just to be to delete that for the
moment and make sure that things work again - beyond that it's me trying
to figure out how to write a udev file to do the right thing when I
don't have hardware that has this layout. I'll see if I can mock it up.
--
Matthew Garrett | [email protected]
On Wed, 2 May 2012 23:27:24 +0100
Matthew Garrett <[email protected]> wrote:
> Hm. Well, easiest thing to do would just to be to delete that for the
> moment and make sure that things work again - beyond that it's me trying
> to figure out how to write a udev file to do the right thing when I
> don't have hardware that has this layout. I'll see if I can mock it up.
I get the implied hint there ... :)
Every time I delve into udev I have to learn it all over again. I've just
done a bit of that. Looking at the 42-usb-hid-pm-rules file you sent me,
I see this at the end:
ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO "usb_hid_pm_end"
ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO "usb_hid_pm_end"
ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", ATTRS{removable}=="fixed", TEST=="../power/control", ATTR{../power/control}="auto"
LABEL="usb_hid_pm_end"
The two GOTO rules are the ones you've added over what Rawhide provided
me. By a laborious path I figured out that they were not working as
expected, while if I instead just commented out the final rule my keyboard
was happy again.
Then I looked closer and noticed that they read:
GOTO "usb_hid_pm_end"
GOTO considered harmful indeed, at least when it's written as above,
instead of:
GOTO="usb_hid_pm_end"
Once I dug up a couple of spare equals signs and stuffed them in there,
things worked. Sure was nice of udev to tell me about the problem...
Sorry it took me so long to figure that out, and thanks for the help. Can
you get the fixed rules into rawhide, or should I go bug somebody?
Thanks,
jon
On Thu, May 10, 2012 at 04:51:44PM -0600, Jonathan Corbet wrote:
> Sorry it took me so long to figure that out, and thanks for the help. Can
> you get the fixed rules into rawhide, or should I go bug somebody?
Doh. Wonderful, thanks - I'll get that pushed to Kay.
--
Matthew Garrett | [email protected]