A bit of background: X started out with a single mouse and a single keyboard. The XINPUT extension (which is now in the second major versions) made this a lot more flexible. It kept the original single mouse and single keyboard as "core pointer" and "core keyboard", but allowed additional "masters" like the core pair, and turned all devices into slaves which can be attached to masters. X applications can also query XINPUT events directly, but very few applications actually do that; most applications just react to "core" events.

By default (at least on my system), all evdev devices are attached to the "core" master, either as keyboard or mouse. Apparently this didn't work on your system. You can see the current mapping with `xinput --list`, and regardless of the mapping, you can check with `xinput --test-xi2 <device id>` if some device actually produces output.

For completeness, if you need to debug events on a lower level (before X processes them), then `evtest` can help to see what goes on at the kernel input layer.

So if you can see mouse events with `xinput --test-xi2 <razor id>`, and for some reason your "Razer keyboard mouse" is not usable because it's not attached to the core pointer, then you can deattach it if necesary with `xinput --float <razor id>` and attach it to the core pointer with `xinput --reattach <razor id> <core pointer id'.

If something else is going on (I don't know what, so far you didn't provide any additional information), e.g. if you are getting keyboard events on the "Razer keyboard mouse", then it'll get more complicated.

And even if your udev and/or xorg.conf is messed up, it should be possible to get everything into a working state with command line tools (unless there is something more fundamentally wrong, like no mouse events). Once you have accomplished this, you can look at the configuration files to make it permanent.