[ThinkPad T420] Wireless hotkey does not turn BlueTooth back on

Bug #773558 reported by Jeff Lane 
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
High
Unassigned
Natty
Invalid
Undecided
Unassigned

Bug Description

On the T420, the wireless key, when used, turns off both wi-fi and bluetooth. However, when used again, it turns wireless back on, but does not turn bluetooth back on.

According to Enablement test results, the key passed testing.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: linux-image-2.6.38-8-generic-pae 2.6.38-8.42
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic-pae 2.6.38.2
Uname: Linux 2.6.38-8-generic-pae i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 3612 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xf3920000 irq 45'
   Mixer name : 'Conexant CX20590'
   Components : 'HDA:14f1506e,17aa21ce,00100000'
   Controls : 8
   Simple ctrls : 5
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw unknown'
   Mixer name : 'ThinkPad EC (unknown)'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Fri Apr 29 15:25:34 2011
HibernationDevice: RESUME=UUID=55b24bde-8249-4ba9-bee2-77646a35c657
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110427.1)
Lsusb:
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 4177Q3U
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-generic-pae root=UUID=7f6b34c5-7740-4d45-bb7c-6e06615cfc59 ro quiet splash initcall_debug vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-2.6.38-8-generic-pae N/A
 linux-backports-modules-2.6.38-8-generic-pae N/A
 linux-firmware 1.52
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/17/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 83ET45WW (1.15 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4177Q3U
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr83ET45WW(1.15):bd02/17/2011:svnLENOVO:pn4177Q3U:pvrThinkPadT420:rvnLENOVO:rn4177Q3U:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4177Q3U
dmi.product.version: ThinkPad T420
dmi.sys.vendor: LENOVO

Revision history for this message
Jeff Lane  (bladernr) wrote :
Jeff Lane  (bladernr)
summary: - Wireless key does not turn BlueTooth back on on ThinkPad T420
+ [ThinkPad T420] Wireless hotkey does not turn BlueTooth back on
Revision history for this message
Ara Pulido (ara) wrote :

Chris, can you please take a look to this one?

Changed in linux (Ubuntu):
assignee: nobody → Chris Van Hoof (vanhoof)
Revision history for this message
Ara Pulido (ara) wrote :

Chris, can you have a look to this one, please?

Changed in linux (Ubuntu):
importance: Undecided → High
Revision history for this message
Jeff Lane  (bladernr) wrote :

New information. After talking to Marc L about this when he saw it earlier, I have confirmed the behaviour he noticed.

Sequence Wireless Bluetooth
       0 ON ON
       1 OFF OFF
       2 ON OFF
       3 OFF ON
       4 ON OFF

So, assuming that 0 is the beginning state where both wifi and bluetooth are on, it takes 4 presses of the wireless key to get both things back on. Between Marc and I, we have confirmed this on two thinkpads, so it's probably safe to assume that this behaviour affects most of the thinkpads...

Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris Van Hoof (vanhoof) wrote :

Jeff -- Based on your most recent update does this still need to be opened as a bug?

Changed in linux (Ubuntu):
assignee: Chris Van Hoof (vanhoof) → nobody
assignee: nobody → Jeff Lane (bladernr)
Revision history for this message
Jeff Lane  (bladernr) wrote :

nah... we can probably close this (and similar on other thinkpads assuming we confirm the behaviour on them. It's not a bug, it's a "feature" :/

Revision history for this message
Manoj Iyer (manjo) wrote :
Revision history for this message
nick rundy (nrundy) wrote :

Is there anyway for the Wireless Hotkey to remember the previous state?

For example, if I have bluetooth turned off and wireless turned on when I hit the hotkey (in effect turning off just wireless), is there anyway that when I next hit the hotkey then only Wireless would turn on?

I rarely use bluetooth. I regularly hit the hotkey to turn on and off wireless though. I don't want bluetooth turning on and off with Wireless because I never use Bluetooth.

Revision history for this message
Jeff Lane  (bladernr) wrote :

Chris, I'm dumping this on you :) I think we can just close this as it appears to be a "feature" rather than a bug. Confusing by design, I'd say...

In any case, I thought I'd leave the final call to you as to whether you want to close this or not.

Changed in linux (Ubuntu):
assignee: Jeff Lane (bladernr) → Chris Van Hoof (vanhoof)
Revision history for this message
Chris Van Hoof (vanhoof) wrote :

Closing this bug as invalid as it does look like we're in line with the intended behaviour. There are methods outlined in the link provided in Comment #7 which will alter this behaviour if it is not preferred.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
assignee: Chris Van Hoof (vanhoof) → nobody
Changed in linux (Ubuntu Natty):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.