Using play/pause buttons in Chrome with GNOME 3

I wrote a post last summer about preventing Chrome from stealing the media buttons (like play, pause, previous track and next track) from OS X. Now that I’m using Linux regularly and I fell in love with Google Play Music All Access, I found that GNOME was stealing the media keys from Chrome.

The fix is quite simple. Press the SUPER key (Windows key or Mac Command key), type settings, and press enter. Click on Keyboard and then on the Shortcuts tab. You should now see something like this:

GNOME keyboard settings

Click on each entry that shows Disabled above. After clicking on the entry, press your backspace key to clear the shortcut. If you’re using a Mac keyboard, that’s your oddly-named delete key that sits right above the pipe/backslash key.

You should be set to go once they’re all cleared out. If you disabled the media keys in Chrome, go to this post and do all of the steps in reverse. ;)

Rotate GNOME 3’s wallpaper with systemd user units and timers

GNOME 3 has improved by leaps and bounds since its original release and it’s my daily driver window manager on my Linux laptop. Even with all of these improvements, there’s still no built-in way to rotate wallpaper (that I’ve found).

There are some extensions, like BackSlide, that enable background rotation on a time interval. Fedora 21 uses GNOME 3.14 and the current BackSlide version is incompatible. BackSlide’s interface is fairly useful but I wanted something different.

One of systemd’s handy features is the ability to set up systemd unit files on a per-user basis. Every user can create unit files in their home directory and tell systemd to begin using those.

Getting started

We first need a script that can rotate the background based on files in a particular directory. All of my wallpaper images are in ~/Pictures/wallpapers. I adjusted this script that I found on GitHub so that it searches through files in my wallpaper directory and picks one at random to use:

#!/bin/bash
 
walls_dir=$HOME/Pictures/Wallpapers
selection=$(find $walls_dir -type f -name "*.jpg" -o -name "*.png" | shuf -n1)
gsettings set org.gnome.desktop.background picture-uri "file://$selection"

I tossed this script into ~/bin/rotate_bg.sh and made it executable with chmod +x ~/bin/rotate_bg.sh. Before you go any further, run the script manually in a terminal to verify that your background rotates to another image.

Preparing the systemd service unit file

You’ll need to create a user-level systemd service file directory if it doesn’t exist already:

mkdir ~/.config/systemd/user/

Drop this file into ~/.config/systemd/user/gnome-background-change.service:

[Unit]
Description=Rotate GNOME background
 
[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/bin/bash /home/[USERNAME]/bin/rotate_bg.sh
 
[Install]
WantedBy=basic.target

This unit file tells systemd that we have a oneshot script that will exit when it’s finished. In addition, we also give the environment details to systemd so that it’s aware of our existing X session.

Don’t enable or start the service file yet. We will let our timer handle that part.

Setting a timer

Systemd’s concept of timers is pretty detailed. You have plenty of control over how and when you want a particular service to run. We need a simple calendar-based timer (much like cron) that will start up our service from the previous step.

Drop this into ~/.config/systemd/user/gnome-background-change.timer:

[Unit]
Description=Rotate GNOME wallpaper timer
 
[Timer]
OnCalendar=*:0/5
Persistent=true
Unit=gnome-background-change.service
 
[Install]
WantedBy=gnome-background-change.service

We’re telling systemd that we want this timer to run every five minutes and we want to start our service unit file from the previous step. The Persistent line tells systemd that we want this unit file run if the last run was missed. For example, if you log in at 7:02AM, we don’t want to wait until 7:05AM to rotate the background. We can rotate it immediately after login.

If you’d like a different interval, be sure to review systemd’s time syntax for the OnCalendar line. It’s a little quirky if you’re used to working with crontabs but it’s very powerful once you understand it.

Now we can enable and start the timer:

systemctl --user enable gnome-background-change.timer
systemctl --user start gnome-background-change.timer

Checking our work

You can use systemctl to query the timer we just activated:

$ systemctl --user list-timers
NEXT                         LEFT          LAST                         PASSED  UNIT                          ACTIVATES
Wed 2015-02-11 08:15:00 CST  3min 53s left Wed 2015-02-11 08:10:49 CST  16s ago gnome-background-change.timer gnome-background-change.service

In my case, this shows that the background rotation service last ran 16 seconds ago. It will run again in just under four minutes. If you find that the service runs but your wallpaper doesn’t change, try running journalctl -xe to see if your service is throwing any errors.

Additional reading

This is just the tip of the iceberg of what systemd can do with user unit files and timers. the Arch Linux wiki has some awesome documentation about user unit files and timers. Check out the other timers that already exist on your system for more ideas.

Lessons learned from a kernel bisection

Git-Logo-1788CI’m far from being a kernel developer, but I found myself staring down a peculiar touchpad problem with my new Dell XPS 13. Before kernel 3.17, the touchpad showed up as a standard PS/2 mouse, which certainly wasn’t ideal. That robbed the pad of its multi-touch capabilities. Kernel 3.17 added the right support for the pad but freezes began to occur somewhere between 3.17 and 3.19.

Bisecting

It became apparent that bisecting the kernel would be required. If you’re not familiar with bisection, it’s a process than can help you narrow down where a particular piece of software picked up a bug. You tell git which revision you know is good and you also tell it which revision has a problem. Git will pick a revision right in the middle and let you re-test. If the test is good, you mark the revision as good and git scoots to the middle between the two known good revisions. The same thing happens if you mark the revision as a bad one.

You’ll eventually find yourself staring down fewer and fewer commits until you isolate the commit that is causing problems. From there, you’ll need to write a new patch to fix the bug or consider reverting the problematic patch entirely.

Lessons learned

Making mistakes during a kernel bisection are quite painful since the build times are fairly extensive. Kernel builds on my laptop took about a half hour and a 32-core Rackspace Cloud Server still took about 10 minutes to compile and package the kernel.

Come up with a solid test plan

Before you get started, define a good test plan so that you know what a good or bad revision should look like. In my case, the touchpad froze when I applied more than one finger to the touchpad or tried to do multi-finger taps and clicks. It’s even better if you can figure out a way to run a script to test the revision. If you can do that, git can automated the bisection for you and you’ll be done really quickly.

Build the project consistently

Ensure that you build the software project the same way each time. In my case, I was careful to use the same exact kernel config file and use the same script to build the kernel for each round of bisection. Introducing changes in the build routine could sway your results and cause you to mislabel a good or bad revision.

Write the upcoming revisions to a file

You can protect yourself from many mistakes by writing the list of revisions in your bisection to a file. That would allow you to come back to the bisection after a mistake and pick up where you left off. You could use something like this:

git bisect view --oneline > /tmp/bisect_revisions_to_test.txt

That file will help in case you accidentally run a git bisect reset or delete the repository. I cannot confirm or deny that anything like that happened during my work. :)

Using ZoneMinder with a Logitech C270 webcam

For those of you in the market for a cheap webcam for videoconferencing or home surveillance, the Logitech C270 is hard to beat at about $20-25 USD. It can record video at 1280×960 and it’s fairly good at low light levels. The white balance gets a bit off when it’s bright in the room but hey — this camera is cheap.

ZoneMinder can monitor multiple cameras connected via USB or network. Setting up the C270 with ZoneMinder is relatively straightforward. (Getting ZoneMinder installed and running is well outside the scope of this post.)

Adjust groups

If a user wants to access the webcam in Linux, they must be in the video group. On my system, ZoneMinder runs as the apache user. I needed to add the apache user to the video group:

usermod -G video apache

Configuring the C270

After clicking Add New Monitor, here’s the data for each tab:

General Tab:

  • Source Type: Local
  • Function: Modect

Source:

  • Device Path: /dev/video0
  • Capture Method: Video For Linux version2
  • Device Format: PAL
  • Capture Palette: YUYV
  • Capture Width: 1280
  • Capture Height: 960

The width and height settings are suggestions. You can crank them down to something like 640×480 if you’d like to save disk space or get a higher frame rate.

Once you save the configuration and the window disappears, you should see /dev/video0 (0) turn green in the ZoneMinder web interface. If it’s red, there may be a different permissions issue to solve or your ZoneMinder instance might be running as a different user than you expected. If the text is yellow/orange, go back and check your camera configuration settings in the ZoneMinder interface.

Linux support for the Dell XPS 13 9343 (2015 model)

Dell XPS 13 9343 (2015 model)UPDATES ARE AT THE BOTTOM: Scroll down to see the latest developments.


I’ve been looking for a good laptop to run Linux for a while now and my new Dell XPS 13 9343 has arrived. It was released at CES in 2015 and it received quite a lot of attention for packing a large amount of pixels into a very small laptop frame with excellent battery life. Ars Technica has a great overall review of the device.

Linux support has been historically good on the previous generation XPS 13’s and a blog post from Dell suggests that the latest revision will have good support as well. For a deep dive on the hardware inside the laptop, review this GitHub Gist.

After wiping Windows 8.1 off the laptop, I started with the Fedora 21 installation. If you want to run Linux on one of these laptops, here’s what you need to know:

The good

All of the most basic devices work just fine. The display, storage, and peripheral connections (USB, SD card slot, mini DisplayPort) all work out of the box in Linux 3.18.5 with Fedora 21. The display looks great with GNOME 3’s default HiDPI settings and it’s very readable with the default font sizes without HiDPI (although this is a bit subjective).

The webcam works without any additional configuration the video quality is excellent.

The wireless card in the laptop I received is a BCM4352:

02:00.0 Network controller: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter (rev 03)

It’s possible to get this card working with the b43 kernel modules but I’ve had better luck with the binary blob STA drivers from Broadcom. There are plenty of guides out there to help you install the kernel module for your Fedora kernel. I’ve had great network performance with the binary driver.

Some users are seeing Intel wireless cards in their Dell XPS 13’s, especially in Europe. Opening the laptop for service isn’t terribly difficult and you could replace the bluetooth/wireless card with a different one.

PRO TIP: If you’re seeing errors in your journald logs about NetworkManager being unable to scan for access points, be sure to hit the wireless switch key on your keyboard (Fn-F12) to enable the card. This had me stumped for about 45 minutes. There’s an option in the BIOS to disable the switch and let the OS control the wireless card.

The special keyboard buttons (volume up/down, brightness up/down) all work flawlessly.

The bad

The touchpad and keyboard are on the I2C bus and this creates some problems. Many users have reported that keys on the keyboard seem to repeat themselves while you’re typing and the touchpad has an issue where X stops receiving input from it. However, when the touchpad seems to freeze, the kernel still sees data coming from the device (verified with evtest and evemu-record).

There are some open bugs and discussion about the touchpad issues:

You can connect up a mouse and keyboard to the laptop and work around those issues. However, dragging around some big peripherals with such a small laptop isn’t a great long-term solution. Some users suggested blacklisting the i2c_hid module so that the touchpad shows up as a plain PS/2 touchpad but I’m still seeing freezes even after making that change.

If you’re having one of those “touchpad on the I2C bus?” moments like I had, read Synaptics’ brief page about Intertouch. Using the I2C bus saves power, reduces USB port consumption, and allows for more powerful multi-touch gestures.

Oddly enough, the touchscreen is an ELAN Touchscreen and it runs over USB. It suffers from the same freezes that the touchpad does.

The ugly

Sound is a big problem. The microphone, speakers and headphone port don’t work under 3.18.5 and 3.19.0-rc7. The audio device is a ALC3263 from RealTek and it should use the same module as the RT286. However, the probing still fails and the module can’t be used. The module code seems to be correct but the probing still fails.

There’s an open bug on Launchpad about the problem:

I connected up an old Syba USB audio device to the USB port and was able to get sound immediately. This is also a horrible workaround.

What now?

From what I gather, Dell is extremely eager to make Linux work on the new XPS 13 and we should see some movement on these bugs soon. I’m still doing a bunch of testing on my own with kernel 3.19 and I’ll be keeping this page updated as news becomes available.

If you know much about the I2C bus or about the sound devices in this laptop and you have some time available to help, just let me know where to send the beer. ;)

Latest updates

2015-02-03

Added Red Hat bug link for sound issues.

2015-02-05

The touchpad bug has been reduced to a kernel issue. Recordings from evemu-record look fine when they’re played back in X. Users reported in Launchpad and in the Red Hat bug that kernel 3.16 works perfectly but 3.17 doesn’t. A kernel bisection will most likely be required to find the patch that broke the touchpad.

Many users find that adding acpi.os="!Windows 2013" to the kernel boot line will bring the audio card online after 1-3 reboots. Apparently there is some level of state information stored in memory that requires a few reboots to clear it. I haven’t verified this yet.

2015-02-06

Kernel bisect for the touchpad issue is underway. Every 3.16.x kernel I built would keep the trackpad in PS/2 mode and that’s not helpful at all. There’s no multi-finger taps/clicks/gestures. 3.17.0 works perfectly, however. My gut says something broke down between 3.17.0 and 3.18.0 but it might actually be closer to 3.17.4 since Fedora 21’s initial kernel is 3.17.4 (and the touchpad doesn’t work well with it).

A post was made on Barton’s Blog yesterday about Dell being aware of the Linux issues. (Thanks to Chris’ comment below!)

After about 35 kernel builds during the most frustrating git bisect of my life, I found the problematic patch. The Red Hat bug is updated now and I’m hoping that someone with a detailed knowledge of this part of the kernel can make sense of it:

From d1c7e29e8d276c669e8790bb8be9f505ddc48888 Mon Sep 17 00:00:00 2001
From: Gwendal Grignou <gwendal@chromium.org>
Date: Thu, 11 Dec 2014 16:02:45 -0800
Subject: HID: i2c-hid: prevent buffer overflow in early IRQ
 
Before ->start() is called, bufsize size is set to HID_MIN_BUFFER_SIZE,
64 bytes. While processing the IRQ, we were asking to receive up to
wMaxInputLength bytes, which can be bigger than 64 bytes.
 
Later, when ->start is run, a proper bufsize will be calculated.
 
Given wMaxInputLength is said to be unreliable in other part of the
code, set to receive only what we can even if it results in truncated
reports.
 
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
 
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 747d544..9c014803b4 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -369,7 +369,7 @@ static int i2c_hid_hwreset(struct i2c_client *client)
 static void i2c_hid_get_input(struct i2c_hid *ihid)
 {
 	int ret, ret_size;
-	int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
+	int size = ihid->bufsize;
 
 	ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
 	if (ret != size) {

I reverted the patch in Linux 3.19-rc7 and built the kernel. The touchpad works flawlessly. However, simply reverting the patch probably isn’t the best idea long term. ;)

2015-02-07

The audio patch mentioned in the Launchpad bug report didn’t work for me on Linux 3.19-rc7.

2015-02-10

Progress is still being made on the touchpad in the Red Hat bug ticket. If you can live with the pad working as PS/2, you can get sound by adding acpi_osi="!Windows 2013" to your kernel command line. Once you do that, you’ll need to:

  1. Do a warm reboot
  2. Wait for the OS to boot, then do a full poweroff
  3. Boot the laptop, then do a full poweroff
  4. Sound should now be working

If sound still isn’t working, you may need to install pavucontrol, the PulseAudio volume controller, and disable the HDMI sound output that is built into the Broadwell chip.

This obviously isn’t a long-term solution, but it’s a fair workaround.

2015-02-11

There is now a patch that you can apply to 3.18 or 3.19 kernels that eliminates the trackpad freeze:

From 2a2aa272447d0ad4340c73db91bd8e995f6a0c3f Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Tue, 10 Feb 2015 12:40:13 -0500
Subject: [PATCH] HID: multitouch: force release of touches when i2c
 communication is not reliable
 
The Dell XPS 13 9343 (2015) shows that from time to time, i2c_hid misses
some reports from the touchpad. This can lead to a freeze of the cursor
in user space when the missing report contains a touch release information.
 
Win 8 devices should have a contact count reliable, to we can safely
release all touches that has not been seen in the current report.
 
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/hid/hid-multitouch.c | 8 ++++++++
 1 file changed, 8 insertions(+)
 
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index f65e78b..48b051e 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1021,6 +1021,14 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
 	if (id->vendor == HID_ANY_ID && id->product == HID_ANY_ID)
 		td->serial_maybe = true;
 
+	if ((id->group == HID_GROUP_MULTITOUCH_WIN_8) && (hdev->bus == BUS_I2C))
+		/*
+		 * Some i2c sensors are not completely reliable with the i2c
+		 * communication. Force release of unseen touches in a report
+		 * to prevent bad behavior from user space.
+		 */
+		td->mtclass.quirks |= MT_QUIRK_NOT_SEEN_MEANS_UP;
+
 	ret = hid_parse(hdev);
 	if (ret != 0)
 		return ret;

I’ve tested it against 3.19-rc7 as well as Fedora’s 3.18.5. However, tapping still doesn’t work yet with more than one finger. The touchpad jumps around a bit when you apply two fingers to it.

2015-02-12

Rene commented below that he found a post in alsa devel with a patch for the “Dell Dino” that looks like it might help with the i2c audio issues. Another kernel maintainer replied and asked for some of the code to be rewritten to make it easier to handle audio quirks. UPDATE: Audio patch didn’t work.

We’ve created an IRC channel on Freenode: #xps13.

There’s an interesting kernel patch mentioning “Dell Dino” that is line for inclusion in 3.20-rc1. Someone in IRC found “Dell Dino” mentioned on a Dell business purchase page. The board name from dmidecode in the patch is 0144P8 but that doesn’t match other known board names. My i5-5200U with touch is 0TM99H while a user with a non-touch i5 has a board name of OTRX4F. Other i5 touch models have the same board name as mine. All BIOS revisions found so far are A00 (the latest on Dell’s site).

A probe for the rt286 module looks like it starts to happen and then it fails (skip to line 795):

[    4.141189] rt286 i2c-INT343A:00: probe
[    4.141245] i2c i2c-8: master_xfer[0] W, addr=0x1c, len=4
[    4.141246] i2c i2c-8: master_xfer[1] R, addr=0x1c, len=4
[    4.141249] i2c_designware INT3432:00: i2c_dw_xfer: msgs: 2
[    4.141389] i2c_designware INT3432:00: Standard-mode HCNT:LCNT = 432:507
[    4.141391] i2c_designware INT3432:00: Fast-mode HCNT:LCNT = 72:160
[    4.141662] i2c_designware INT3432:00: i2c_dw_isr:  Synopsys DesignWare I2C adapter enabled= 0x1 stat=0x10
[    4.141670] i2c_designware INT3433:00: i2c_dw_isr:  Synopsys DesignWare I2C adapter enabled= 0x1 stat=0x0
[    4.141695] i2c_designware INT3432:00: i2c_dw_isr:  Synopsys DesignWare I2C adapter enabled= 0x1 stat=0x750
[    4.141703] i2c_designware INT3433:00: i2c_dw_isr:  Synopsys DesignWare I2C adapter enabled= 0x1 stat=0x0
[    4.141965] i2c_designware INT3432:00: i2c_dw_handle_tx_abort: slave address not acknowledged (7bit mode)
[    4.141968] rt286 i2c-INT343A:00: Device with ID register 0 is not rt286
[    4.160506] i2c-core: driver [rt286] registered

2015-02-16
I received an email from a Realtek developer about the sound card in the XPS:

I see “rt286 i2c-INT343A:00: Device with ID register 0 is not rt286″ in the log. It means there are something wrong when the driver is trying to read the device id of codec. I believe that is due to I2C read/write issue. ALC3263 is a dual mode (I2S and HDA) codec. And BIOS will decide which mode according to OS type. So, if you want to use i2s mode, you need to configure your BIOS to set ALC3263 to I2S mode.

After poring through the DSDT and other ACPI tables over the weekend (and building way too many kernels with overriden DSDT’s), it sounds like a BIOS update may be required for the sound card to function properly. The sound devices specified in the DSDT that are on the i2c bus are only activated after a BUNCH of checks succeed. One of them is the check of OSYS, the system’s operating system. Setting acpi_osi="Windows 2013" does flip OSYS to 0x07DD, but that’s only part of the fix. There are other variables checked, like CODS (that shows up very often) that are instantiated early in the DSDT but I can’t find them ever being set to a value anywhere in the DSDT code. These variables equal zero by default and that disables critical parts of the sound device.

My take: This laptop is going to need a BIOS update of some sort before we can get sound working properly in Linux with an i2c touchpad. If someone is more skilled with DSDT’s than I am, I’ll be glad to share all of my work that I’ve tried so far. As for now, I’m going to be waiting eagerly for some type of firmware update from Dell.

2015-02-17
There’s some progress on the sound card in Linux! After building the latest commits from linux.git’s master branch, my XPS started showing a device called “broadwell-rt286″ in pavucontrol. It showed up as a normal audio device but it had no output support, only input. I tried to enable the microphone but I couldn’t record any sound.

I found a kernel bug from a ThinkPad Helix 2 user with a very similar hardware setup. Their rt286 device is on the I2S bus with a Haswell SoC. Their fix was to copy over the latest firmware binaries from linux-firmware.git and reboot. I did the same and an output device suddenly showed up in pavucontrol after a reboot.

When I played sounds via aplay, canberra-gtk-play, and rhythmbox, I could see the signal level fluctuating in pavucontrol on the broadwell-rt286 device. However, I couldn’t hear the sound through the speakers. I connected headphones and I couldn’t hear any sound there either.

There’s now a kernel bug ticket open for the sound issue.

Stay tuned for a BIOS update with a potential keyboard repeat fix. It’s already been talked about in IRC as a potential A01 release sssssssssssoon:

someone asked about the fix for the repeating keypresses. yes, it was traced back to the source and will be fixed on all affected Dell platforms soon
I just saw that the one for 9343 was promoted to our factories so should be up on support.dell.com any day now as BIOS A01

You can get notifications about driver releases for the XPS on Dell’s site.