diff --git a/README.md b/README.md
index 0f533aa..e2c5c92 100644
--- a/README.md
+++ b/README.md
@@ -151,6 +151,39 @@ to this implementation. For example, a portal can set the client name
 using `libreis` based on the app-id. A client cannot override this name
 later.
 
+Differences between XTest vs libei
+----------------------------------
+
+**libei** functionality is a superset of XTest's input emulation which
+consists of a single request, `XTestFakeInput`. This request allows
+emulation of button, key and motion events, including X Input 1.x events
+(but not XI2). So **libei** can be a drop-in replacement since it supports
+the same functionality and more.
+
+However, XTest is an X protocol extension and users of XTest usually obtain
+more information out-of-band ("out-of-band" here means "not through XTest
+but instead other X protocol requests").
+
+One example is `xdotool` which does window focus and modifier mangling (see
+below). Window focus notification is not available to a pure **libei**
+client and would have to be obtained or handled on a separate channel, e.g.
+X or Wayland. Having said that, a Wayland client does not usually have acess
+to query or modifiy the window focus.
+
+Modifiers in `xdotool` are handled by obtaining the modifier mask from the X
+server, identifying any difference to the intended mask and emulating key
+events to change the modifier state to the intended one. For example, if
+capslock is on, xdotool would send a capslock key event first (thus
+disabling capslock) and then the actual key sequence. This is followed by
+another capslock key event to restore the modifier mask.
+
+This is not possible for a pure **libei** client as the modifier state is
+maintained by the windowing system (if any). A client can obtain the
+modifier state on Wayland on `wl_keyboard.enter` but when the client is
+in-focus, there is rarely a need to emulate events.
+
+Overall, it is best to think of **libei** devices as virtual equivalents to
+a hardware device.
 
 Open questions
 --------------