Bluetooth - MSMouse5000(bt) - 13.1KDE4.12 Suspend anomaly

English Hardware
1

I recently upgraded my HPDV7T(integrated bluetooth) from 12.3 using DVD upgrade.
With updates and switch to KDE upstream repos complete, system is running well but with limited use so far.

One anomaly I am living with while I figure it out - connection to my MS Bluetooth Mouse 5000 does not restore after a Suspend to RAM.
I normally run with the Synaptics pad disabled, to avoid thumb-draging-wierdness using keyboard, alas it does come back from Suspend in the disabled state, so I am sort of stuck.

Workaround solution is to kill KDM (alt-ctl-backspace-backspace), then log back in and reconnect to the mouse.
Restarting KDE enables the Synaptics pad by default.
So far, I have found that I need to restart the Bluetooth Service

sudo service bluetooth restart

Then I use the SystemSettings-Bluetooth dialog to reconnect the mouse, then disable the Synaptics and I am back in business.

After updates, I have installed

 **zypper if bluedevil**
Loading repository data...
Reading installed packages...


Information for package bluedevil:
----------------------------------
Repository: KDE:Extra
Name: bluedevil
Version: 2.0~rc1-16.2
Arch: x86_64
Vendor: obs://build.opensuse.org/KDE
Installed: Yes
Status: up-to-date
Installed Size: 1.0 MiB
Summary: Bluetooth Manager for KDE
Description: 
Bluetooth daemon for KDE, handling connections.

**zypper if bluez**
Loading repository data...
Reading installed packages...


Information for package bluez:
------------------------------
Repository: openSUSE-13.1-Update
Name: bluez
Version: 5.8-3.5.1
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 3.0 MiB
Summary: Bluetooth Stack for Linux
Description: 
The Bluetooth stack for Linux.

When running 12.3, I did not experience this issue, but understand that the new Bluedevil is still work-in-progress.
Reviewing /var/log/pm-suspend.log, I need no special treatment yet for the bluetooth service, perhaps that is coming.
A quick look at another system finds a hook/49bluetooth, which is probably what needs to be ported to the new Bluedevil.

Summary - So far, with these updates, 13.1 behaving very well for me, with this workaround for Bluetooth Mouse.

2

I checked my 12.3 system that behaves well in this area - it appears that pm-utils on 13.1 does not have proper hooks yet for bluetooth, probably because bluetooth was not working at the time.

3

I have been hacking about with this issue, anyone wanting to try same can do this.
The pm-suspend hook from 12.3 is shown here

carl@PVE-LinuxSRV5:~> cat /usr/lib/pm-utils/sleep.d/49bluetooth
#!/bin/sh
# IBM specific hack to disable/enable bluetooth.
# TODO: Doesn't the working USB suspend/resume functionality
#       make this code more or less obsolete?

. "${PM_FUNCTIONS}"

 -f /proc/acpi/ibm/bluetooth ] || exit $NA

suspend_bluetooth()
{
        if grep -q enabled /proc/acpi/ibm/bluetooth; then
                savestate ibm_bluetooth enable
                echo disable > /proc/acpi/ibm/bluetooth
        else
                savestate ibm_bluetooth disable
        fi
}

resume_bluetooth()
{
        state_exists ibm_bluetooth || return
        restorestate ibm_bluetooth > /proc/acpi/ibm/bluetooth
}

case "$1" in
        hibernate|suspend)
                suspend_bluetooth
                ;;
        thaw|resume)
                resume_bluetooth
                ;;
        *) exit $NA
                ;;
esac

I copied the contents to my 13.1 system (as root), into a new file /etc/pm/sleep.d/49bluetooth_hack.
Permissions should be **-rwxr-xr-x 1 root root **

/etc/pm/sleep.d is where local “tweaks” to pm-utils are supposed to be implemented.

I tried a sleep-wakeup cycle and it worked for me; YRMV.

Keep an eye out for future updates to pm-utilities; they may come up with a different solution that might conflict.

4

On 2013-12-28 02:06, cmcgrath5035 wrote:
> Keep an eye out for future updates to pm-utilities; they may come up
> with a different solution that might conflict.

They may disappear completely, and soon (13.2). There is no maintainer.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

5

Where did you read that?

pm-utils is part of freedesktop.org and currently supported AFAIU.

pm-utils

6

On 2013-12-28 04:36, deano ferrari wrote:

> Where did you read that?
>
> pm-utils is part of freedesktop.org and currently supported AFAIU.

No openSUSE maintainer. They asked for one, or it will be dropped from the distro. Factory mail list.

http://lists.opensuse.org/opensuse-factory/2013-11/msg00911.html
Re: [opensuse-factory] Your thoughts on dropping pm-utils
Hi,
I maintain pm-utils, and I want to drop them soon, because systemd can
handle (sort of) suspend and hibernation and also becouse their
upstream is dead and I’m not able to (and don’t want to) fix all the
bugs all by myself.
There is some information and an initial discussion on the topic here:
https://bugzilla.novell.com/show_bug.cgi?id=790157

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

7

Okay, thanks for that. I was completely unaware, although it looks like systemd can take over without issue. Upower no longer requires pm-utils anyway. The only real issue is making sure that any required quirks are migrated accordingly. Important that any suspend/resume issues are reported.

A similar discussion has been had with Arch Linux

https://bugs.archlinux.org/task/31349

8

On 2013-12-28 21:56, deano ferrari wrote:
>
> Okay, thanks for that. I was completely unaware, although it looks like
> systemd can take over without issue. Upower no longer requires pm-utils
> anyway. The only real issue is making sure that any required quirks are
> migrated accordingly. Important that any suspend/resume issues are
> reported.

I’m not sure about “no issues”… :-?

> A similar discussion has been had with Arch Linux
>
> https://bugs.archlinux.org/task/31349

Oh.

I guess that we have to remove pm-utils, and then test hibernation and suspend. If there are any
issues, we have to report them on bugzillas, so that they are solved. And this has to be done by
every individual here.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

9

I guess that we have to remove pm-utils, and then test hibernation and suspend. If there are any
issues, we have to report them on bugzillas, so that they are solved. And this has to be done by
every individual here.
Interesting future ahead of us, I guess.

Do i surmise from this that the best way to test is to uninstall pm-utilities and evaluate?

Assuming that not all is “better”, I’ll be then reinstalling pm-utilities.

I see this in the Description for Upower in YAST

UPower is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus. Some operations (such as suspending the system) are restricted using PolicyKit.

Does one need to muck about with PolicyKit for Upower to perform suspending tasks?

10

On 2013-12-28 23:56, cmcgrath5035 wrote:
>
>> I guess that we have to remove pm-utils, and then test hibernation and suspend. If there are any
>> issues, we have to report them on bugzillas, so that they are solved.
>> And this has to be done by every individual here.Interesting future ahead of us, I guess.
>
> Do i surmise from this that the best way to test is to uninstall
> pm-utilities and evaluate?

Yes.

> Assuming that not all is “better”, I’ll be then reinstalling
> pm-utilities.

Yes, that’s the worst that can happen.

> I see this in the Description for Upower in YAST
>> UPower is an abstraction for enumerating power devices, listening to
>> device events and querying history and statistics. Any application or
>> service on the system can access the org.freedesktop.UPower service via
>> the system message bus. Some operations (such as suspending the system)
>> are restricted using PolicyKit.
>>
>>
>
> Does one need to muck about with PolicyKit for Upower to perform
> suspending tasks?

Dunno…

In my 13.1, XFCE, when I try to hibernate as user the system refuses. It asks for root’s password
because it says that there are more users logged in (true, there is an opened console). I’m told
that this is enforced with policykit and it is intentional. However, this is not consistent with not
requiring root’s password for poweroff or reset.

I have a bugzilla opened against this issue.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

11

The polkit authorization for hibernation (via upower) is governed by org.freedesktop.upower.suspend

For reference, I have

pkaction --verbose --action-id org.freedesktop.upower.suspend
org.freedesktop.upower.suspend:
  description:       Suspend the system
  message:           Authentication is required to suspend the system
  vendor:            The UPower Project
  vendor_url:        http://upower.freedesktop.org/
  icon:              system-suspend
  implicit any:      no
  implicit inactive: no
  implicit active:   yes
12

I removed pm-utils and proceeded to suspend successfully using KDE menu, and then s2ram methods. So, with this Compaq 6710b laptop (Intel graphics), I appear to be okay.

13

I just removed pm-utilities with YAST
As expected, the hack I had copied into /etc/pm/sleep.d was left in place, all the other pm-utilities files and folders were removed.

I find that my HPDV7T (i7, integrated intel graphics with add-on nvidia) Sleeps and restores OK using all three of these initiation methods:

  • KDE-Launcher
  • Logout/Lock/Sleep Widget
  • Hot Key sequence which I have locally set-up

My uncalibrated impression is that Sleep state and Resume state are achieved much faster than when using the pm-utilities method.
I did not have to authenticate the sleep request(enter root password, etc).
Wired and wireless connects reestablish automatically upon resume.
I have not reinstalled bumblebee nor setup the nvidia yet, so can’t comment about that performance.

I have 2 residual issues, which existed with pm-utilities, that have work-arounds

  1. Bluetooth mouse - I found with more testing that the pm-utilities bluetooth hack I posted above was intermittent. Sometimes the bluetooth wizard would crash on resume as it was re-connecting to the mouse, but it would auto restart and I could/can reconnect by pressing the “discover me” button on the mouse. Works same using this Upower method, I still suspect the bluetooth wizard has an issue. The Synaptics pad status (enabled/disabled) upon resume is same as when sleep executed.
  2. NFS client connections are not restored upon resume. I had same issue under pm-utilities, was just starting to chase that. The workaround for this is to execute sudo mount -a
    in a Konsole.

My summary - After removing pm-utilities, sleep/resume works same under Upower, perhaps a bit faster.
I guess the future is already here!

14

i have this problem with a fresh install of suse 13.1.

so with or without pm-utils, there is a problem with bluetooth and suspend… no real solution actually?

15

There are bug reports open for that. In particular, I want to draw your attention to

https://bugzilla.redhat.com/show_bug.cgi?id=988481

Reading comment #24 onwards, it appears that a kernel patch has been submitted upstream, and so should be fixed from kernel 3.12.2 onwards. You might want to consider upgrading the kernel accordingly.

16

Thanks, Deano, for the bug info.
As an experiment, I tried the “solution” in Comment 34, but on my kernel 3.11.6-4 system it did not work.

I guess we have a hint as to how to implement quirks with Upower - scripts in /user/lib/systemd/system-sleep/

I’ll consider moving to kernel 3.12 in the future, for now I am getting pretty good at recovering the mouse; I only do it once a day.

17

ok so it seem to be fixed in 3.12.2 and 3.11.10 (maybe this one will be available officialy for 13.1?)

18

I just switched my 13.1 laptop to kernel 3.11.10-7 from the KernelRepo using YAST.

All seems well in the early going, AND my Bluetooth Mouse recovers properly after Upower suspend-recover cycle.

Thanks for the good dialog and helpful hints

19

That’s encouraging to know.