HOWTO: MX5000 Bluetooth Keyboard and MX1000 Laser Mouse Combo in Hardy

[fsm]

Does anyone have a problem with the event # changing on reboots?

I am trying to debug a similar setup (non-bluetooth mouse, but same technique works). I used this in my xorg.conf:

Option "Device" "/dev/input/event6"

Problem is when I boot, I sometimes the mouse handler is on event6, sometimes event7 (swaps with something else). Similarly, my video devices (webcam and tuner) also swap positions.

Is there a way to force my devices to always be on the same event handler, or bind them to some other constant device?

[puffyzacd]

Is there a way to force my devices to always be on the same event handler, or bind them to some other constant device?

This is the purpose of the udev rule that I described in an earlier post (on page 1 of this thread). It maps the mouse to the device /dev/input/mx1000

Hopefully this helps!

[puffyzacd]

I've got this same problem (at least with the mouse, not sure why your keyboard would stop working). I think it's because when the mouse goes to sleep (to save batteries) the evdev driver is unloaded. Try looking at /var/log/Xorg.0.log to see if there's anything about evdev being unloaded.

Unfortunately, I have no idea how to fix this problem... anyone else?

I've noticed this same problem, although for me it is most notable during startup. If I'm not moving the mouse while X is starting up, it won't find the mouse and so it unloads evdev (I can verify this in the /var/log/Xorg.0.log file). My mouse works after, but I lose some of my buttons.

I have no idea how to approach this problem, definitely out of my league...

[puffyzacd]

I've got this same problem (at least with the mouse, not sure why your keyboard would stop working). I think it's because when the mouse goes to sleep (to save batteries) the evdev driver is unloaded. Try looking at /var/log/Xorg.0.log to see if there's anything about evdev being unloaded.

Unfortunately, I have no idea how to fix this problem... anyone else?

I don't know if anyone is still reading this thread, but I think I've found a solution to this problem.

Apparently the problem is that xserver-xorg doesn't support hotplugging of devices, so the evdev driver is either loaded when X starts, or not loaded at all. If a device is "unplugged" (or in this case goes to sleep), even when it is reconnected the evdev driver is not reloaded.

Well it turns out the devs are working on supporting this hotplugging behavior, maybe for Hardy+1, but the adventurous can enable it now by following the steps laid out in this post.

So, I changed my xorg.conf mouse section to

Section "InputDevice"
	Identifier	"Logitech MX1000"
	Driver		"mouse"
	Option		"Protocol"	"auto"
	Option		"Device"	"/dev/input/mice"
	Option 		"RelHWHEELMapTo"	"Buttons 7 6"
EndSection

And added the following into /etc/hal/fdi/policy/10-x11-input.fdi

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_driver" type="string">mouse</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Now all my buttons work every time, even when booting up or coming back to the computer after several hours.

Also, this approach makes the udev rule unneccessary since it takes care of loading evdev for the proper device for us! Anyway, hope someone else who stumbles across this might find it useful.

[Curtisc]

puffyzcad, that's amazing, I'd given up on that problem! I found that the fdi stuff also works when added to /etc/hal/fdi/policy/preferences.fdi in case you want to have everything in one file. Thanks a lot, I'll update the first post in case any looks.

[Curtisc]

puffyzcad (or anyone else that's reading this):
I found a bit of a problem with that fdi policy. Apparently the BT receiver reports itself as having mouse capabilities, so I was getting all kinds of crazy input (single click was acting as double, everything moving at twice the speed, etc). So, here's my new fdi policy:

  <device>
    <match key="info.product" string="Logitech MX1000 mouse">
	  <merge key="input.device.set" type="string">/dev/input/mx1000</merge>
      <merge key="input.x11_driver" type="string">mouse</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>
  </device>

As you can see, I also changed the device from /dev/input/mouse to /dev/input/mx1000, so that needs to be changed in xorg.conf. I don't even know if this is necessary, but I figured I'd give it its own special device instead of using the generic "mice" device.

Now the last thing to solve is the bluetooth connection problem...

[Kiwi-Hawk]

Hi

Been fighting with this for a bit,..

I can see keyboard but no mouse and when I select connect I get

------------------------------------------------------
Couldn't display "obex://[00:07:61:98:ec:0c]/"

error: host down
Please select another viewer and try again
-------------------------------------------------

The other day it was Mouse that showed and not the Keyboard

--------------------------------------------------
Couldn't display "obex://[00:07:61:98:c1:a2]/"

error: host down
Please select another viewer and try again
----------------------------------------------

am I right in thinking these are mac address's if so I'm still not close
to getting it going,.. strangely enough I looked at Mythbuntu and it worked fine there, anbody knw what the difference is in under garage?

Cheers
Kiwi-Hawk

[Kiwi-Hawk]

Hi

Second message same as first,..

I have followed the howto's and put the text in policy also

and it has made no difference at all


------------------------------------------------------
Couldn't display "obex://[00:07:61:98:ec:0c]/"

error: host down
Please select another viewer and try again
-------------------------------------------------

--------------------------------------------------
Couldn't display "obex://[00:07:61:98:c1:a2]/"

error: host down
Please select another viewer and try again
----------------------------------------------

Is all I get


Cheers
Kiwi-Hawk

[EnlistedSquire]

Hi,

I used this How To to set up my stand alone, RF (not bluetooth) MX1000 after updgrading to Hardy and apart from the previously mentioned problem of the event number changing from time to time it worked fine.

However, I came back to my PC after a few days of not using it earlier this week and it's gone totally to pot. I can no longer get the horizontal scrolling to work - the left and right mouse wheel buttons don't give a button number in xev and they seem to have picked up the same output as the volume + and - on my keyboard (which have been working fine from day one).

The cruise buttons now give the same button number as scrolling the mouse wheel up and down (buttons 4 and 5) when they were previously different as I had the cruise buttons assigned to Page Up and Page Down. I tried install lomoco and disabling SmartScroll and the cruise buttons no longer get a button assignment in xev either. This is what xev gives for my crusie button with SmartScroll disabled:

MotionNotify event, serial 31, synthetic NO, window 0x3400001,
    root 0x1a6, subw 0x3400002, time 867717, (64,36), root:(1775,221),
    state 0x10, is_hint 0, same_screen YES

Here is what my previously working xorg.conf looks like:

Section "InputDevice"
	Identifier	"Logitech MX1000"
	Driver		"evdev"
	Option		"Device"	"/dev/input/event2" 
	# If your event handler is something other than event8, 
	# change it to the appropriate value
	Option 		"RelHWHEELMapTo"	"Buttons 7 6"
EndSection

Can anyone offer an idea as to what's gone wrong and how to fix it? I've tried powering everything off to give the mouse a hard-reset and started these instructions totally from scratch from a default xorg.conf.

I had a go using BtnX but couldn't get the horizontal mouse wheel action to work (I assume because it's not compatible with evdev so I was using the standard mouse driver).

Thanks.

[EnlistedSquire]

Bump, I could really do with some help here. I've been experimenting with xmodmap with no joy either. My button assignments seem to change every few boots with out me doing anything. What could be causing that?

Thanks.