diff --git a/HELP.md b/HELP.md
index 22f5cf2f..d5f53c3f 100644
--- a/HELP.md
+++ b/HELP.md
@@ -1,11 +1,16 @@
 # The problems with overwriting keys
 
-If you had one keyboard layout for your mouse that writes SHIFT keys on
-keycode 10, and one for your keyboard that is normal and writes 1/! on
-keycode 10, then you would not be able to write ! by pressing that mouse
-button and that keyboard button at the same time. Keycodes may not clash.
-
-**The first idea** was to write special keycodes known only to key-mapper
+**Initial target** You write a symbols file based on your specified mapping,
+and that's pretty much it. There were two mappings: The first one is in the
+keycodes file and contains "<10> = 10", which is super redundant but needed
+for xkb. The second one mapped "<10>" to characters, modifiers, etc. using
+symbol files in xkb. However, if you had one keyboard layout for your mouse
+that writes SHIFT keys on keycode 10, and one for your keyboard that is normal
+and writes 1/! on keycode 10, then you would not be able to write ! by
+pressing that mouse button and that keyboard button at the same time.
+Keycodes may not clash.
+
+**The second idea** was to write special keycodes known only to key-mapper
 (256 - 511) into the input device of your mouse in /dev/input, and map
 those to SHIFT and such, whenever a button is clicked. A mapping would have
 existed to prevent the original keycode 10 from writing a 1. But X/Linux seem
@@ -13,8 +18,8 @@ to ignore anything greater than 255 for regular keyboard events, or even
 crash in some cases. Mouse click buttons can use those high keycodes though,
 but they cannot be remapped, which I guess is another indicator of that.
 
-**The second idea** is to create a new input device that uses 8 - 255, just like
-other layouts, and key-mapper always tries to use the same keycodes for
+**The third idea** is to create a new input device that uses 8 - 255, just
+like other layouts, and key-mapper always tries to use the same keycodes for
 SHIFT as already used in the system default. The pipeline is like this:
 
 1. A human thumb presses an extra-button of the device "mouse"
@@ -30,9 +35,10 @@ SHIFT as already used in the system default. The pipeline is like this:
    mapping to print the overwritten key "1" into the session.
    
 But this is a rather complicated approach. The mapping of 10 -> 50 would
-have to be stored somewhere as well.
+have to be stored somewhere as well. It would make the mess of configuration
+files already needed for xkb even worse.
 
-**Third idea**: Based on the first idea, instead of using keycodes greater
+**Fourth idea**: Based on the first idea, instead of using keycodes greater
 than 255, use unused keycodes starting from 255, going down. Issues existed
 when two buttons with the same keycode are pressed at the same time,
 so the goal is to avoid such overlaps. For example, if keycode 10 should be
@@ -41,17 +47,21 @@ and a second keyboard, except if pressing key 10 triggers key-mapper to write
 key 253 into the /dev device, while mapping key 10 to nothing. Unfortunately
 linux just completely ignores some keycodes. 140 works, 145 won't, 150 works.
 
-So back to the second idea.
+**Fifth idea**: Instead of writing xkb symbol files, just disable all
+mouse buttons with a single symbol file. Key-mapper listens for key events
+in /dev and then writes the mapped keycode into /dev. For example, if 10
+should be mapped to Shift_L, xkb configs would disable key 10 and key-mapper
+would write 50 into /dev, which is Shift_L in xmodmaps output. This sounds
+incredibly simple and makes me throw away tons of code. Branches for all that
+stuff exist to archive it instead of loosing it forever.
 
-# The various mappings
 
-There are three mappings:
+# The various mappings
 
-The first one is in the keycodes file and contains "<10> = 10", which is
-super redundant but needed for xkb.
+There were two mappings: The first one is in the keycodes file and contains
+"<10> = 10", which is super redundant but needed for xkb. The second one
+mapped "<10>" to characters, modifiers, etc. using symbol files in xkb.
 
-The second one maps "<10>" to characters, modifiers, etc. using symbol files
-in xkb.
 
 The third mapping reads the input keycodes from your mouse (also known as
 system_keycode here) and writes a different one into /dev (also known as
diff --git a/keymapper/linux.py b/keymapper/linux.py
index e733ebf2..8e42305a 100644
--- a/keymapper/linux.py
+++ b/keymapper/linux.py
@@ -33,6 +33,9 @@ from keymapper.logger import logger
 from keymapper.mapping import custom_mapping, MAX_KEYCODE, MIN_KEYCODE
 
 
+DEVNODE = '/dev/keymapper'
+
+
 def can_grab(path):
     """Can input events from the device be read?
 
@@ -72,7 +75,7 @@ class KeycodeReader:
         loop = asyncio.new_event_loop()
         asyncio.set_event_loop(loop)
         device = evdev.InputDevice(path)
-        keymapper_device = evdev.UInput()
+        keymapper_device = evdev.UInput(devnode=DEVNODE)
 
         for event in device.read_loop():
             if event.type != evdev.ecodes.EV_KEY: