Weird bluetooth keyboard regression - just me?

Weird bluetooth keyboard regression - just me?

[Jonathan Corbet]

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

Re: Weird bluetooth keyboard regression - just me?

[Gustavo Padovan]

Hi Jon,

* Jonathan Corbet <corbet@lwn.net> [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

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Jonathan Corbet]

On Tue, 1 May 2012 07:37:11 -0600
Jonathan Corbet <corbet@lwn.net> 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 <mjg@redhat.com>
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 <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

...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

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Matthew Garrett]

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 <mjg@redhat.com>
> 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 <mjg@redhat.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ...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 | mjg59@srcf.ucam.org

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Jonathan Corbet]

On Tue, 1 May 2012 18:19:01 +0100
Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Matthew Garrett]

On Tue, May 01, 2012 at 12:01:45PM -0600, Jonathan Corbet wrote:
> On Tue, 1 May 2012 18:19:01 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> 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 | mjg59@srcf.ucam.org

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Jonathan Corbet]

On Tue, 1 May 2012 19:31:49 +0100
Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Matthew Garrett]

On Tue, May 01, 2012 at 12:39:23PM -0600, Jonathan Corbet wrote:
> On Tue, 1 May 2012 19:31:49 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> 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 | mjg59@srcf.ucam.org

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Matthew Garrett]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

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 | mjg59@srcf.ucam.org

[-- Attachment #2: 42-usb-hid-pm.rules --]
[-- Type: text/plain, Size: 2966 bytes --]

#
# Enable autosuspend for qemu emulated usb hid devices.
#
# Note that there are buggy qemu versions which advertise remote
# wakeup support but don't actually implement it correctly.  This
# is the reason why we need a match for the serial number here.
# The serial number "42" is used to tag the implementations where
# remote wakeup is working.
#

ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Mouse", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Tablet", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Keyboard", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"

#
# Enable autosuspend for KVM and iLO usb hid devices. These are
# effectively self-powered (despite what some claim in their USB
# profiles) and so it's safe to do so.
#

# AMI 046b:ff10
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="046b", ATTR{idProduct}=="ff10", TEST=="power/control", ATTR{power/control}="auto"

#
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
#
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", ATTR{bInterfaceClass}=="03", TEST=="../power/control", ATTR{../power/control}="auto"

# Dell DRAC 4
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="2500", TEST=="power/control", ATTR{power/control}="auto"

# Dell DRAC 5
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="0000", TEST=="power/control", ATTR{power/control}="auto"

# Hewlett Packard iLO
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="7029", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="1027", TEST=="power/control", ATTR{power/control}="auto"

# IBM remote access
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04b3", ATTR{idProduct}=="4001", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04b3", ATTR{idProduct}=="4002", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b3", ATTR{idProduct}=="4012", TEST=="power/control", ATTR{power/control}="auto"

# Raritan Computer, Inc KVM.
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", ATTR{idProduct}="0002", TEST=="power/control", ATTR{power/control}="auto"

# USB HID devices that are internal to the machine should also be safe to autosuspend

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"

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Jonathan Corbet]

On Tue, 1 May 2012 20:27:36 +0100
Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: [now bisected] Weird bluetooth keyboard regression - just me?

[Matthew Garrett]

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 | mjg59@srcf.ucam.org