Firefox’s built-in search capabilities still use the unencrypted search, though. To remedy this I built an OpenSearch plug-in which makes Firefox use the HTTPS-based search:

Install Google Secure Search Plug-In

(Read more about Google’s SSL Search here)

||facebook.com$third-party
||facebook.net$domain=~facebook.com,third-party
||fbcdn.com$domain=~facebook.com,third-party
||fbcdn.net$domain=~facebook.com,third-party

Instead of adding the rules manually, you can subscribe to this Adblock Plus filter subscription: Facebook Connect Opt-Out.

• Build a udev rule to give the mouse device a static name: I’m using

  ACTION=="add", \
    KERNEL=="event*", \
    SUBSYSTEM=="input", \
    SYSFS{manufacturer}=="Logitech", \
    SYSFS{product}=="USB Receiver", \
    NAME="input/mx1000"

  in /etc/udev/rules.d/010_local.rules.
  After restarting udev and replugging the mouse, you should see a device named /dev/input/mx1000.

• /etc/X11/xorg.conf:

  Section "InputDevice"
   Identifier "MX1000"
   Driver     "evdev"
   Option     "CorePointer"
   Option     "Device"    "/dev/input/mx1000"
  EndSection

• ~/.xbindkeysrc:
  (You have to install xbindkeys and xvkbd for this; I’m starting xbindkeys in ~/.gnomerc)

  # Backward and Forward buttons
  "xvkbd -text "\[Alt_L]\[Left]""
    m:0x10 + b:8
  "xvkbd -text "\[Alt_L]\[Right]""
    m:0x10 + b:9
  
  # "Cruise Control" disabled:
  #"xvkbd -text "\[Page_Up]""
  #  m:0x10 + b:11
  #"xvkbd -text "\[Page_Down]""
  #  m:0x10 + b:12
  
  # "Cruise Control" enabled:
  # Work-around extra events
  "~/bin/click 4"
   m:0x10 + b:11
  "~/bin/click 5"
   m:0x10 + b:12
  
  # Application-Switch button
  # A-Tab doesn't work
  # Use it as another Forward for now
  "xvkbd -text "\[Alt_L]\[Right]""
    m:0x10 + b:10

  Using the Application-Switch button for switching windows in GNOME doesn’t work because it would require holding down the Alt key while pressing Tab several times, xvkbd can’t do that. I’m using the button as another Forward now, it’s easier to reach than the real Forward button.
  Defining actions for the Cruise Control buttons only makes sense when Cruise Control is disabled (you can disable it with lmctl or the Logitech Mouse Applet). If it is disabled, the buttons generate 11 and 12. When it is enabled, they generate a single button 11 or 12 event and then a series of button 4 or 5 events just like scrolling the wheel does.
  I have no idea why the mouse generates 11 or 12 before starting normal scrolling in Cruise Control mode. I’m mapping 11 and 12 to a little utility (click by Jeremy Nickurak) which replaces these bogus events with normal scroll events.

• At this point the Backward and Forward buttons should work in GNOME, KDE, and Mozilla-based browsers. Horizontal scrolling should work in GNOME and KDE.
  Mozilla-based browser like Firefox need two additional changes to get horizontal scrolling working with the tilt wheel: Open about:config and set

  mousewheel.horizscroll.withnokey.action = 0
  mousewheel.horizscroll.withnokey.sysnumlines = true

January 18th, 2006: The evdev driver in XOrg 6.9 is broken on big-endian machines like powerpc. Here’s a fix.

I’m not completely satisfied with the MX1000. It’s too heavy and a bit too small for my hands. The notable exception is the Forward button, it’s too far away from my thumb. I’ve had the last problem with the IntelliMouse Explorer too. I still have a few IntelliMouse Optical on other machines, I really like that mouse. Perfect Size, good wheel, easily reachable side buttons. The only drawback is the annoying big red light.

Anyhow, back to the MX1000. Only a few changes to my configuration for the IntelliMouse Explorer where needed to get it working. Here’s my new configuration:

• /etc/X11/XF86Config-4 or /etc/X11/xorg.conf:

  Section "InputDevice"
   Identifier "MX1000"
   Driver     "mouse"
   Option     "CorePointer"
   Option     "Protocol"        "evdev"
   Option     "Dev Name"        "Logitech USB Receiver"
   Option     "Buttons"         "12"
   Option     "ZAxisMapping"    "11 12 10 9"
   Option     "Resolution"      "800"
   Option     "Emulate3Buttons" "false"
  EndSection

• /etc/X11/Xmodmap:

  ! MX1000
  pointer = 1 2 3 8 9 10 11 12 6 7 4 5

  This gets the buttons in right order: Scrolling the wheel generates 4 and 5, tilting the wheel 6 and 7.

• ~/.xbindkeysrc:
  (You have to install xbindkeys and xvkbd for this; I’m starting xbindkeys in ~/.gnomerc)

  # Backward and Forward buttons
  "xvkbd -text "\[Alt_L]\[Left]""
    m:0x10 + b:8
  "xvkbd -text "\[Alt_L]\[Right]""
    m:0x10 + b:9
  
  # "Cruise Control" disabled:
  #"xvkbd -text "\[Page_Up]""
  #  m:0x10 + b:11
  #"xvkbd -text "\[Page_Down]""
  #  m:0x10 + b:12
  
  # "Cruise Control" enabled:
  # Only use this if you have problems with Mozilla
  #"NoCommand"
  #  m:0x10 + b:11
  #"NoCommand"
  #  m:0x10 + b:12
  
  # Application-Switch button
  # A-Tab doesn't work
  # Use it as another Forward for now
  "xvkbd -text "\[Alt_L]\[Right]""
    m:0x10 + b:10

  Using the Application-Switch button for switching windows in GNOME doesn’t work because it would require holding down the Alt key while pressing Tab several times, xvkbd can’t do that. I’m using the button as another Forward now, it’s easier to reach than the real Forward button.
  Defining actions for the Cruise Control buttons only makes sense when Cruise Control is disabled (you can disable it with the Logitech Mouse Applet). If it is disabled, the buttons generate 11 and 12. When it is enabled, they generate a single button 11 or 12 event and then a series of button 4 or 5 events just like scrolling the wheel does.
  I have no idea why the mouse generates 11 or 12 before starting normal scrolling in Cruise Control mode. I’m mapping 11 and 12 to “NoCommand”, this eliminates the ButtonPress but not the ButtonRelease event. This seems to eliminate the negative effects of the extra button events in Mozilla. (Mozilla interprets the 11 and 12 events as normal left clicks, Firefox doesn’t have this issue. So if you’re using Firefox or if you don’t see the left-click problem with your Mozilla build, then don’t bind 11 and 12 to anything.)

• At this point the Backward and Forward buttons should work in GNOME, KDE, and Mozilla-based browsers. Horizontal scrolling should work in GNOME and KDE.
  Mozilla-based browser like Firefox need two additional changes to get horizontal scrolling working with the tilt wheel: Open about:config and set

  mousewheel.horizscroll.withnokey.action = 0
  mousewheel.horizscroll.withnokey.sysnumlines = true

April 5th, 2005: Update: Don’t bind 11/12 to anything in Cruise Control mode by default (only needed if there are problems with Mozilla). Fixed the "Cruise Control" comments in ~/.xbindkeysrc.

January 15th, 2006: Xorg 6.9 and later come with a different evdev driver. I’ve made an updated version of this guide now.

• Mouse section from /etc/X11/XF86Config-4:

  Section "InputDevice"
    Identifier "Configured Mouse"
    Driver     "mouse"
    Option     "CorePointer"
    Option     "Protocol"        "evdev"
    Option     "Dev Name"        "*Microsoft IntelliMouse*"
    Option     "Buttons"         "9"
    Option     "ZAxisMapping"    "8 9 6 7"
    Option     "Emulate3Buttons" "false"
  EndSection

• To get the buttons in the correct order for X11, change /etc/X11/Xmodmap to:

  pointer = 1 2 3 8 9 7 6 4 5

  Now horizontal scrolling should work with GNOME!

• In Mozilla-based browsers however, tilting the wheel moves back- or forward in the history now. To fix this open about:config and set mousewheel.horizscroll.withnokey.action to 0.
  Unfortunately Mozilla and GNOME seem to have different interpretations of left and right; set mousewheel.horizscroll.withnokey.sysnumlines to true to fix that.
• To get the sides buttons going back- and forward in history again, install xbindkeys and xvkbd. Bind the buttons to Alt-Left and Alt-Right in ~/.xbindkeysrc:

  "xvkbd -text "\[Alt_L]\[Left]""
    m:0x10 + b:8
  "xvkbd -text "\[Alt_L]\[Right]""
    m:0x10 + b:9

  and run xbindkeys in ~/.gnomerc

January 15th, 2006: Xorg 6.9 and later come with a different evdev driver. I’ve made a new guide now. The new guide talks about the Logitech MX1000 but it’s quite easy to adapt the configuartion for other mice.