Wow, this makes me happy!
edit: If you have an XPS 13 of the current-gen Haswell variety - or an XPS 12, or possibly other similar Dell systems - you aren't affected by this issue. You may also have trackpad weirdness on such systems, but it's not this bug, it's a different one. If you have the Haswell XPS 13, try blacklisting the i2c-hid module.
tl;dr version: if you have a Dell XPS 13 of the last-gen Ivy Bridge (not current-gen Haswell) variety, or other system with a 'CyPS/2 Cypress Trackpad' clickpad, and you have trouble trying to middle-click or use custom synaptics configurations or even with normal clicks with the new synaptics 1.8 code, stick something like this as
Section "InputClass" Identifier "Disable clickpad for touchpad" MatchDriver "synaptics" Option "ClickPad" "no" EndSection
and you should be happy: everything should work properly with synaptics 1.8, and middle-click emulation (by pressing left and right softbuttons together) should work!
I spent the last couple of days tracking down a frustrating problem with the trackpad on my laptop, with the extremely kind and patient assistance of the awesome Peter Hutterer. The debugging was tedious and annoying, but once we figured out what was going on, it was sure worth it.
I've hated the trackpad on the system since I bought it, mainly because I've never been able to get a middle click working at all. With clickpads - trackpads with no physical buttons, where you can click the pad itself - you're supposed to be able to get a middle-click by doing a three-finger click, or you can configure various other things (like a particular corner of the pad or something) to do it. But none of those seemed to work right for me.
I was managing to live with that, but with the recent changes to the 'synaptics' X driver (leading up to the release of 1.8), things seemed to get a lot more broken. Clicking at the bottom left of the pad didn't always seem to generate a left click, and with some builds, right clicks weren't working at all. It was pretty frustrating.
In the end, in debugging the new issue, we figured out the underlying cause and it turns out to have been causing the older issues too. This particular hardware is smarter than your average clickpad: its firmware tries to do a lot of the typical clickpad tricks which other clickpads leave to the OS driver.
Apparently most clickpads are pretty dumb devices: they just track the number of fingers, finger location and pressure across the whole pad, and send out an event when you click the pad. It's up to the OS driver to implement stuff like 'make it a right click if the click was in the bottom-right hand corner of the pad', 'make it a middle click if it was a three finger click', etc etc.
However, it turns out that the firmware on this clickpad does rather more. First, it implements its own soft button area - let's call it a 'firmware button area' - at the bottom of the pad, which behaves rather differently from the rest of the pad. If you click in the bottom right it actually sends out a right click event (other clickpads don't differentiate, they leave it to the driver to do the clever stuff). If you make initial finger contact within this area, the driver doesn't register the 'tap' or pressure or even the finger location at all until you move the finger around a bit (outside this 'firmware button area', it starts tracking those things immediately). The firmware also implements 'click with multiple fingers sends a right click event'. Again, other clickpads don't do that.
So ultimately all the bugs turned out to essentially be symptoms of the same underlying problem: the pad's firmware and the synaptics driver were kind of fighting each other. Synaptics 'knows' this pad is a clickpad, so it tries to do all the clickpad 'clever stuff' - but the firmware is already doing it too. Their implementations of button emulation were clashing, causing the problem with left clicks not working. Trying to configure a multi-finger click as a middle click didn't work because the firmware already detects multi-finger clicks and sends a right-click event, which synaptics doesn't expect. And so on.
Ultimately, the solution turned out to be simple: just tell synaptics not to treat the pad as a clickpad at all, and rely on the firmware implementation. That way they're not fighting. You lose all the flexibility/configurability of synaptics' behaviour - you can't use all the neat synaptics config options relating to clickpads - but at least the basic stuff works.
And most awesomely (for me), with synaptics not treating the pad as a clickpad, middle-button emulation works! If I click the left and right 'buttons' implemented by the firmware together, I get a middle click. This makes me very happy.
So yeah, if you have a similar 'smart' clickpad (my system is the previous generation of Dell XPS 13 developer edition, I'd guess other XPS 13s have the same hardware but can't be sure, and I expect there are other laptops with the same pads in them out there), try the xorg config snippet at the top of this post. It might make you happy.
Peter will probably implement a quirk for my pad in future synaptics releases. If you have a different pad that behaves similarly, it might be good to file a bug at Freedesktop to get a quirk added for that, too.