No notification when sliding audio volume, muting volume on ThinkPad X23, X24, X31, X32, X41, X60, T22, T40, T41, T42, T43, T43p, T60, R50e, R51, R52

thank you for your bug report, do you get other notification? is notification-daemon or notify-osd running?

Seb, I am receiving other notification (networkManager, hplip, etc...).
So maybe this bug need to be moved to notify-osd.
Thanks.

does the volume actually change when you use those keys? why should the bug be moved if other notifications are working?

Yes, the volume actually changes but there is no visual feedback.

Not a notify-osd bug: it doesn't receive anything on the bus. I've also tried with a previous kernel (2.6.28-11-generic
), but the bug still occurs.

At least I can confirm the bug on my T60p.

the issue seems to be a side effect of the fix for bug #355300, those laptops have hardware volume actions and the software ones have been stopped to avoid duplication

I can confirm the same bug on my R50e...

Confirmed on my T42 as well.

No more volume and LCD brightness on-screen-display on ThinkPad X32 as well. These buttons still work as expected though.

Confirmed that the problem impacts LCD brightness as well as volume control on a T42, even though LCD brightness use function keys (Fn+Home, Fn+End) rather than hardware buttons. Same issue with the mute button too.

Note: this problem just arised 20 days ago. Before that, the notification was acing perfectly.

First, please read my post on bug #355300 to know about the hardware volume control and digital volume knob details.

Let's start with a key fact: the thinkpad-acpi driver does NOT support any sort of OSD notification events for brightness and volume right now. All that was done for OSD was done by abusing the hotkey key-press events, and it should not be a surprise to anyone involved that it finally decided to break hideously. That's the nature of half-baked hacks.

That said, let's see what can be done to fix OSD both in the short term in Ubuntu and in the long term for everyone. Do notice that I *expect* Ubuntu to actively work with me to get the proper long-term fixes deployed this time around.

My best guess is that Ubuntu (just like Debian) switched away from procfs-based ACPI events to netlink-based ACPI events. Well, thinkpad-acpi does not, and has never issued keypress events over ACPI netlink. Those events belong to the input layer, so they were not ported to the new, clean netlink ABI when it was introduced in 2.6.23 or thereabouts, and they will _not_ be. That is not only the right thing to do, it also avoids a whole bunch of problems due to duplicated keypress events on the input device and also as an ACPI event.

So, all you need to do for a quick fix is to (assuming you don't want to just re-enable ACPI PROCFS events):

1. Hook the OSD snooper to the thinkpad-acpi input device, instead of to the ACPI event stream;

2. Make sure to not regress #355300:

     2a. DO NOT attach KEY_VOLUME_UP/DOWN/MUTE to the 0x14, 0x15 and 0x16 thinkpad-acpi keymap positions. Instead, attach some other useless and unhandled keycodes, maybe mark those as passive, and use those as OSD events for volume up/down/mute. You will have to fix HAL .fdi files to make sure of this.

     2b. After you reprogram the keymap as above, read the value of hotkey_recommended_mask, set the bits for volume, and write the result to hotkey_mask. Do not just override hotkey_mask with some random crap like 0xffffff. I provide "hotkey_recommended_mask" in the driver for a good reason.

3. Do the same steps (2a, 2b) for the brightness keys. This will future-proof the hideous hack somewhat, which is a good idea should it outlast its expected lifetime.

That should give you working OSD in the short term. DO NOT send the above hackery upstream. Please work with me on the stuff described below, instead.

Now, for the long term OSD fixing.

1. Volume notifications

The proper place to get OSD information for mixer-related things is ALSA. If OSD is working there, it will work for every mixer, on every hardware, and in a generic way to boot.

So, how to do proper OSD for volume on thinkpads? An ALSA mixer for the ThinkPad built-in volume control (which doesn't exist anymore in recent Lenovo firmware) is (finally!) the next thing on my TODO list.

The Lenovo models already have an ALSA mixer since they just have the master mixer, so "ALSA mixer OSD" will cover all ThinkPads when I deploy support for the IBM hardware mixer (also present on 1st-gen T60).

ALSA mixers are supposed to be capable of doing event generation for OSD, and if they're not doing it as well...

Fabio: notification were originally working because each time you pressed a key, it was handled both through hardware and software, which meant that it was as if you had pressed the key twice. To correct that problem, software handling of those keys was removed for the ThinkPads. However, because the notifications were handled by the software handler, a side effect of this was that notifications were lost. What really needs to be done is to enable notification on hardware events.

I'll mark the bug as confirmed as the thread above shows that a number of people have reported it. In terms of resolving it, I am happy to make code changes and test patches on my Jaunty install if that can help.

Repeating comment from duplicate bug #364442:

The problem is that on ThinkPads, these buttons *also* have an effect at the hardware level; we have previously been overriding the defaults of the thinkpad-acpi module to force these button presses to be exposed to userspace, but there is no way to disable the action in hardware, so we end up with double handling.

The short-term fix for this is to /not/ override the kernel module and expose these keypresses to userspace. This has the unfortunate side-effect of leaving us without OSD for these keys, but this is effectively because hal/gnome-settings-daemon are not equipped to deal with this kind of "notification-only" mixer event, and there are currently no standard linux input key events defined for this.

In the long term, we need a good way to expose these mixer changes to userspace, but reverting to the previous behavior isn't more correct than what we're currently doing.

Thanks Steve!

Steve,

it may be true that the software stack can't handle volume being done in hardware, but the software stack can, and has, correctly handled the LCD brightness for ages correctly.

For the panel there is an hal property (correctly set on my x31 for example):

  laptop_panel.brightness_in_hardware = true

This is used by gnome-power-manager to let it know that the hardware notifications are just notifications and not action requests.

Steve, Crispin,

From what you both say and from my (very flaky) understanding of the problem, what needs to be done is:

1. add support for hardware based notifications in OSD
1.1 implement such notifications for LCD brightness
2. add support for hardware based audio controls (volume up, down, mute) in hal/gnome-settings-daemon, in collaboration with Henrique
3. add support for other hardware events if possible (e.g. the bluetooth/wifi radio switch or the internal/external display switch)

At first sight, #1 looks like it's an all Ubuntu affair while #2 looks more complicated than that. So what is the next step to resolve this? Should we file individual, more detailed bugs for each of the different areas of work? And what can we, as users who have little understanding of the internals and varied technical skills, do to help?

Actually, what is needed is proper OSD based on passive notifications _FOR_ OSD (and NOT a hideous hack based on keypress notifications like what exists right now for thinkpad brightness OSD).

Don't make a mistake of believing that there exists OSD support in the current scenario. There is none. It is just a jury-rig.

OSD support means events engineered to work as OSD notifications, without any side-effects on the rest of the system, nor on the input layer, etc. It means a layered approach, where you have OSD event sources (HAL, applications) and sinks (an applet that display the on-screen notifications). This is how the rest of the notification system (e.g. used to notify of new mail) already works, so it is not anything new.

HAL should monitor the kernel interfaces (sysfs backlight, ALSA mixers, etc) and issue OSD events through DBUS. Applets would not get terribly confused doing both active and passive work (which they, invariably, screw up): they would just do OSD (which is always passive in any sane design).

Stuff like gnome.*mixer would only generate DBUS OSD notification events, and the on-screen-display functionality would be in a separate component. This gives you a choice of which active producers of OSD events you want, and of which OSD applet you want to display the events. It is also very cross-desktop-environment-friendly.

I already offered to help kernel-side to fix and/or extend the kernel interfaces lacking event-based triggers, so that polling is not required, and the offer stands. But there is no need to wait for anything kernel-side, polling-based solutions can be deployed _now_.

I strongly suggest we start walking that path, after the short-term fixes are in.

Under polling you mean a soft that continuously checks the hardware mixer levels and sends a message to osd-notify whenever it changes? I'm not a programmer, but I think this is not a difficult thing to code. I have an IBM T42, and experienced the above-mentioned problems myself when i updated, and I'm willing to offer my help in the development (either by providing logs, or testing applications, whatever needed).
I'm not familiar with the way osd-notify receives events (although I think/hope the developers adhered some standards), but my opinion is, if we could find a reliable event source for the polling (maybe a file in /proc or /sys, or at least a memory address) this poller application could be finished within minutes and the numerous Thinkpad owners would be happier than ever with Jaunty :)

Same on T22.

No notification when sliding audio volume, muting volume, +/- brightness not working on X60s.
Curiously the the battery report key does just what it should and with the new notification system. Neither xev nor Gnomes Keyboard Shortcuts catches the mute, volume +/- keys.

Thinkpad X60 Tablet same symptoms

Same problem on my thinkpad t42

Same here on my T42. I started to mess about with notify-osd, thought it wasn't installed, but I'm glad I now know its a known bug.

Any ideas when we can expect this to be resolved? I miss my OSD. :(

Apart from that Jaunty seems brilliant.

In the meantime you can use tpb instead of hotkey-setup.
It requires its own hacks (see https://bugs.launchpad.net/ubuntu/+source/tpb/+bug/158262 ), but will give on screen feedback.

a.tom made me to think if is posible to hack tpb.deb to use ubuntu OSD istead of tpb blue OSD??? maybe someone with coding skills

Confirmed bug on ThinkPad T60 -- please note, this did *NOT* happen when I was running 9.04 Beta and Release Candidates.

I first noticed this problem in the stable release of 9.04 Jaunty Jackalope

Also, I'd like to confirm this bug on my friend's ThinkPad SL300 same problem but worst, he cannot control the volume (or mute) using the buttons at all, nor can he control the brightness using the buttons, he has to use the Brightness and Volume control applets in GNOME.

Sorry for mis-information, but it is only the volume OSD that does not work for X60.
The brightness Fn keys work fine with the new notifcation manager, as does the wireless notifications.

@ Henrique de Moraes Holschuh :
Is there any easy way / tutorial on how to get your quick fix (from https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/357673/comments/12) working?

I can confirm that all my buttons work on the T42, but no osd for volume, Fn brightness or Fn keyboard light on/off.

Wireless notifications and other ones using notify-osd (e.g. Pidgin) work fine.

here is a workaround for those who are interested:

http://packages.ubuntu.com/intrepid/i386/hotkey-setup/download
downgrade to the version of hotkey-setup in intrepid repository

it fixed my ThinkPad T60

This workaround does the trick, but is unfortunately not the prettiest. The keys on the Thinkpads are controlling the hardware mixer (as Henrique & the others explained above) and with the old hotkey-setup, your volume buttons will control the hardware mixer and the software mixer together.
The suggested approach was to find a polling based solution, which is possible (at least for the volume) using a couple files in the /proc filesystem, that store the hardware mixer levels. I'll try hacking up a script for watching these values and sending a notification whenever they change (this way you don't have to control both mixers, and can have the functionality without the bloody hacks).

I've created a small script to handle hardware mixer and brightness changes on Thinkpads. If you start it (perhaps fork it to the background) and change hardware mixer or brightness levels, you should see a notification pop up with the appropriate value within 1 sec (yes, i know it's not immediate, it's on the todo list :)
I take no responsibility for the script, so please read it through before executing (it does not need root privileges btw), and please share comments and suggestions. Thanks

Zoltan

@Zoltan,

Nice little script: it works great on my T42, thanks! Just a small comment on it: it would be easier to read if you indented what's inside the 'while' loop.

instead of the sleep 1 loop (which may drain battery a bit from all the polling), maybe use:

while read file event
do
  case "$file" in
   */volume)
     # take volume actions here
     ;;
    */brightness)
     # take brightness actions here
     ;;
  esac
done < inotifywait -qm -e modify /proc/acpi/ibm/volume /proc/acpi/ibm/brightness

it'll need inotify-tools installed...

Sorry, last line should read:
done < <(inotifywait -qm -e modify /proc/acpi/ibm/volume /proc/acpi/ibm/brightness)

I altered Zoltan's script so that it could handle muting and unmuting, and also change the speaker icon depending on what the volume was set at. Ubuntu is displaying notifications for brightness changes on my T60 (don't ask me why), so I can't comment on how the brightness notifications in this script work with my changes (though I didn't touch that part at all, so they really should work just fine).

Thank you Zoltan for posting your script.

Thanks everybody for the contributions, it really was a morning surprise :) I'll try to combine Kees' cycle with dmandell's level checking in the evening, as i don't have my T42 with me currently. I've been also thinking how this could be developed to look like an official fix, do you have any ideas regarding that? I could create a .deb file that installs the script in /etc/init.d and starts it during boot, but before going that far we should see if the script works on other Thinkpads, shouldn't we? Also, what are your opinions about a shell script doing this job (that's the only "programming" language i have experience with)? Would an application written in Python or C work better?

Zlotan, I just tried Kees's suggestion but it looks like the files in /proc don't generate any event that can be captured with inotifywait. It works on standard files but not on the ones we're interested in. I suspect it's because /proc is pseudo-filesystem rather than a real one.

In the meantime, you'll find attached a small update on dmandell's script that shows different brightness icons depending on the brightness level.

This bug was fixed in the package linux - 2.6.32-19.28

---------------
linux (2.6.32-19.28) lucid; urgency=low

  [ Andy Whitcroft ]

  * [Config] enable various multitouch devices
    - LP: #541453

  [ Chase Douglas ]

  * (pre-stable): input: ALPS - Add signature for HP Pavilion dm3 laptops
    - LP: #545307
  * SAUCE: Disable function tracing after hitting __schedule_bug
  * SAUCE: Reduce ACPI resource conflict message to KERN_INFO, printf
    cleanup
    - LP: #440470

  [ Jesse Barnes ]

  * SAUCE: drm/i915: don't change DRM configuration when releasing load
    detect pipe
    - LP: #488328

  [ John Johansen ]

  * SAUCE: AppArmor: Remove null_profile's use of PFLAG_NO_LIST_REF
    - LP: #539437
  * SAUCE: AppArmor: Stop page allocation warnings that can occur on policy
    load
    - LP: #458299
  * SAUCE: AppArmor: Return string len rather than the allocation size
    - LP: #551844
  * SAUCE: AppArmor: Fix oops in profile verification if profile unpack
    fails.

  [ Luke Yelavich ]

  * [Config] Enable Nouveau DRM module on powerpc

  [ Stefan Bader ]

  * SAUCE: Pull in thinkpad-acpi from v2.6.34-rc1
    - LP: #357673
  * [Config] Enable thinkpad-acpi ALSA volume control
    - LP: #357673

  [ Steve Conklin ]

  * SAUCE: drm/i915: Disable FBC on 915GM and 945GM
    - LP: #492392, #539609

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) drm/i915: blacklist lid status: Sony VGN-BX196VP,
    Dell Inspiron 700m"
    - LP: #515246
  * (pre-stable) softlockup: Stop spurious softlockup messages due to
    overflow
    - LP: #551068
  * backlight: mbp_nvidia_bl - add five more MacBook variants
    - LP: #511965
  * drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay.
    - LP: #529130
  * drm/nouveau: Fix fbcon corruption with font width not divisible by 8
    - LP: #544739
  * (pre-stable) USB: fix usbfs regression
  * drm/radeon/bo: add some fallback placements for VRAM only objects.
    - LP: #507148
  * drm/radeon/kms: don't print error on -ERESTARTSYS.
    - LP: #507148
  * Input: add the ABS_MT_PRESSURE event
    - LP: #541453
  * HID: Support for 3M multitouch panel
    - LP: #541453
  * HID: make 3M PCT touchscreen driver standalone config option
    - LP: #541453
  * HID: add support for Stantum multitouch panel
    - LP: #541453
  * HID: make Stantum driver standalone config option
    - LP: #541453
  * HID: add support for Acer T230H multitouch
    - LP: #541453
  * HID: add support for Pixart Imaging Optical Touch Screen
    - LP: #541453
  * HID: fixed bug in single-touch emulation on the stantum panel
    - LP: #541453
  * HID: add pressure support for the Stantum multitouch panel
    - LP: #541453
  * HID: Support for MosArt multitouch panel
    - LP: #541453
  * HID: hid-ntrig add multi input quirk and clean up
    - LP: #541453
  * HID: n-trig: remove unnecessary tool switching
    - LP: #541453
  * HID: hid-ntrig: multitouch cleanup and fix
    - LP: #541453
  * HID: hid-ntrig: Single touch mode tap
    - LP: #541453
  * hid: ntrig touch events
    - LP: #541453
  * (pre-stable) x86-32, resume: do a global tlb flush in S4 resume
    - LP: #531309
  * drm/i915: Part of: Add initial bits for VGA mode...

IMO this is not "Fix Released" -- as in, there is still no notification when one presses those buttons. So far ALSA is told about those buttons, but the information is not passed on to the desktop.

Martin -

I made a wild guess regarding the package, but wanted to get this on your radar. Please reassign, retarget, etc... as needed.

I'm not sure what component is responsible for this, but I know it's not acpid. ;)

The kernel is now exporting a special read-only alsa mixer for the in-firmware mixer. Whatever processes input events and translates them to mixer changes and OSD notifications needs to do the same thing here by *reading* changes on this mixer and generating the OSD notifications. Maybe this is g-s-d?

Unfortunately the patched kernel doesn't seem to make volume notification work.

Further more as brightness was mentioned in the initial bug message, I have to add that adjusting this stopped working since the kernel upgrade from 2.6.32-18 (from Beta 1) to the latest update with the patched 2.6.32-19. Booting into -18 and brightness control (via the powerdevil in kubuntu) works fine, booting back on -19 and it's not working.

This looks pretty bad to me, as profiles can't adjust the brightness, which means that battery would last substantially shorter.

I assume this new mixer already appears in pulseaudio? Do you see it in the volume properties? I guess it can't hurt to attach the output of "pactl" on such a system.

Right now, g-s-d only listens for keypress events, it will need completely new code to connect to pulse and listen to mixer events. This is not something we can or should force into lucid two weeks before final freeze, so I'm closing the lucid task.

When I tested the new thinkpad driver, it didn't appear in pulseaudio. As far I as could tell, PulseAudio didn't like loading a alsa module for a card with no pcm input/output.

On Tue, Apr 06, 2010 at 01:09:37PM -0000, Martin Pitt wrote:
> I assume this new mixer already appears in pulseaudio? Do you see it in
> the volume properties? I guess it can't hurt to attach the output of
> "pactl" on such a system.

> Right now, g-s-d only listens for keypress events, it will need
> completely new code to connect to pulse and listen to mixer events. This
> is not something we can or should force into lucid two weeks before
> final freeze, so I'm closing the lucid task.

No, it doesn't show up in pulseaudio. It's a mixer device with no
associated input/output, so I don't think it should go through PA here - the
mixer device exists *only* to provide notifications of volume changes.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On a T60, I now see "ThinkPad Console Audio Control", which responds to the volume buttons. As expected, no OSD notification though.

This issue is still active on Maverick, fully up-to-date, kernel 2.6.35-2, on a Thinkpad R50e.

Problem still exists in 10.10 alpha3 on an IBM X31.

I have Kubuntu Lucid with all updates. The problem still exists on my T40.

The status of this bug is fix-released in the kernel. So either the kernel fix does not work or there is another Kubuntu-specific component involved, which is not yet listed under affected compontents.

Just to clarify after such a lengthy discussion:

> The problem still exists on my T40.

The problem means: No notification when changing the volume or muting/unmuting using hardware keys. But the volume changes like expected.

This has worked in Ubuntu Intrepid at least.

@Uwe: as mentioned by Henrique in comment #112, the fix is in version 2.6.33 of the kernel hence why the bug is fix-released in the kernel. However, Ubuntu Lucid runs on version 2.6.32 of the kernel and therefore the fix is not in Lucid. It should make it into Maverick though, as Maverick should run on kernel 2.6.35 IIRC.

@Bruno (and Uwe)

I do NOT agree with you, as volume control DO NOT cooperate with the KDE/Gnome volume control applet (and neither with the OSD indicator) on Lucid with a 2.6.33 kernel (found in ubuntu mainline kernels) - BTW same for .34 and .35.
NEITHER does it work in Maverick beta 1+2+3, even if the keyboard bottoms is able to adjust the volume here too (like Uwe describes). I've done extensive tests on more of the reported boxes (from the bug-headline), and every test on new installations - apart from the kernel of course.

The only thing that makes this (and on some boxes the also the broken brightness control and OSD) work, is adding:
cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
to /etc/rc.local
And even though a big WARNING has been given by someone (was it Henrique), this just works every time and even in Karmic.

From what I understand from comment #112, only an alsa mixer was put in place in .33 kernel, which does not mean that KDE/Gnome uses this mixer - at least it seem that no buntu release does yet.

So of course it would be pretty great if it could be fixed before Maverick is released.

Regarding comment #170 I'm not sure if it's clear, that the brightness bug only applies to the default ubuntu kernels in Karmic and Lucid, not any of the mainline kernels used, nor is it present in the .35 kernel in Maverick beta jet (that is, mainline kernels don't need the workaround for brightness to work only for volume control and OSD).

Problem still exists in 10.10 beta on an IBM X31.

I can confirm the problem exists in 10.10 beta. I'm using a T60 and the volume up, down, and mute buttons do not produce any type of OSD. The brightness OSD works, but the bar it draws on screen doesn't always go to 0%, nor does it always go to 100%. It seems to get stuck around 20% and 80%.

Bug is affecting my T41 since Interpid. Currently running Lucid.

Christiansen workound works fine with 10.04 and 10.10 on my T60. Thanks!

But what does not work is the function of the mute-button itself. I can mute and when I press the mute-button again it wont unmute. I then have to press one of the lower- or higher-volume-buttons to get sound working again.

is there any fix for that?

@Simon Pfeifer

There is no fix for that and there never will be because that is intended and is hardware coded (as in; not in the software/driver). Imagine if you are playing music very loud and you quickly need to mute? What are you going to do? Push the Mute button once? Probably not... Most people would push it repeatedly. No? :)

@Julius Thor

Unmuting via the mute button does work on my T61

@Forlong

Also normal. The T61 is different. :)

On Thu, 17 Feb 2011, Forlong wrote:
> Unmuting via the mute button does work on my T61

Yes, it was dumbed down.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I dunno but I'm getting bit of a snotty vibe from you guys.
I agree it makes more sense that the mute button does just that: mute, not unmute. But there's obviously a demand for the way the T61 behaves.
There's no one and only way to go as you make it sound (which was the original reason I responded even though the T61 is not affected by this bug). IMHO it's all about choice (but sadly, that seems not be an option here anyway).

@Forlong

We're not being snotty and it's the functionality of the T60 is not up to the Ubuntu developers. It's Lenovo that made the T60 function as it does (Mute button only mutes) and that's done in the hardware mixer. However in the T61's case it's done in software and that's what Henrique meant with the "Yes, it was dumbed down." comment.

Can someone please confirm if this is still an issue on natty?

> Can someone please confirm if this is still an issue on natty?

Yes (T30). I can see the read-only mixer ("ThinkPad Console Audio Control") in alsamixer, but the volume applet uses the software mixer only, and shows no notifications when volume / mute buttons are pressed.

Confirmed on natty on a T60p.

confirmed - natty - X60s

Confirmed on Ubuntu 11.04 on a G40.

confirmed, ubuntu 11.04 on a thinkpad T30.
the hack in comment #170 works for both audio and brightness.

I see this problem in 11.10 on Thinkpad X60.

When i open alsamixer and switch to "Thinkpad Console Audio Control" sound card it can see that the buttons work.

using a Thinkpad T400 and 11.10 i have this issue. all was fine until one of the last updates (installed locally in the last 6 days (contained a kernel update as well)). can not say more as i only know it worked 6 days ago and now no longer works.

no OSD on volume events (up, down, un/mute) on Thinkpad X61S. otherwise volume buttons function as expected.

eh, sorry... the system is pretty basic lubuntu x86 11.04.

Happens on Thinkpad t42 with Ubuntu 12.04.03.

With alsamixer -> 'F6' -> "29 ThinkPad Console Audio Control" I can see current level of hardware mixer and that hotkeys are working (I can also hear they really affcets volume level). But there are no on-screen-notification.

Same with brightness.

Still an issue in 13.10. Nothing happened when I hit the volume/mute buttons on my T60p. Christiansen's workaround in comment #170 worked great though.

Still an issue in 14.04.
Tried this on a X60 with Ubuntu 14.04 and Linux Mint 17.

Complementing #194:
Still an issue in 14.04
Tried this on a T60 with Linux Mint 17 (Rebeca) and elementaryOS Freya (based on Ubuntu 14.04)

Workaround mentioned on #170 still working