Deskflow 1.22.0.197
Keyboard and mouse sharing utility
Loading...
Searching...
No Matches
Keyboard Messages
Protocol Message Definitions » Data Messages

Keyboard input event messages. More...

Collaboration diagram for Keyboard Messages:

Variables

const char *const kMsgDKeyDownLang
 Key press with language code (v1.8+)
const char *const kMsgDKeyDown
 Key press event.
const char *const kMsgDKeyDown1_0
 Key press event (legacy v1.0)
const char *const kMsgDKeyRepeat
 Key auto-repeat event.
const char *const kMsgDKeyRepeat1_0
 Key auto-repeat event (legacy v1.0)
const char *const kMsgDKeyUp
 Key release event.
const char *const kMsgDKeyUp1_0
 Key release event (legacy v1.0)

Detailed Description

Keyboard input event messages.

Variable Documentation

◆ kMsgDKeyDown

const char* const kMsgDKeyDown
extern

Key press event.

Message Code: "DKDN" Direction: Primary → Secondary Format: "DKDN%2i%2i%2i" Parameters:

  • $1: KeyID (2 bytes) - Virtual key identifier, often called a "keysym" on Linux/X11. This is platform-dependent and corresponds to values like XK_a on X11/Linux, ‘'a’ on macOS, and 'A' on Windows.
  • $2: KeyModifierMask (2 bytes) - Active modifier keys
  • $3`: KeyButton (2 bytes) - Physical key code, often called a "keycode" or "scancode". This is the raw, platform-dependent scan code of the key pressed.

Example:

'a' key (KeyID 0x61), no modifiers, physical key (KeyButton 0x1E)

"DKDN\x00\x61\x00\x00\x00\x1E"

Key Mapping Strategy: The KeyButton parameter is crucial for proper key release handling. The secondary screen should:

  1. Map the KeyID to its local virtual key
  2. Remember the association between KeyButton and the local physical key
  3. Use KeyButton (not KeyID) to identify which key to release

This is necessary because:

  • Dead keys can change the KeyID between press and release
  • Different keyboard layouts may produce different KeyIDs
  • Modifier keys released before the main key can alter KeyID
See also
kMsgDKeyUp, kMsgDKeyDownLang
Since
Protocol version 1.1

◆ kMsgDKeyDown1_0

const char* const kMsgDKeyDown1_0
extern

Key press event (legacy v1.0)

Message Code: "DKDN" Direction: Primary → Secondary Format: "DKDN%2i%2i" Parameters:

Legacy version without KeyButton parameter. Used only when communicating with protocol version 1.0 clients.

Deprecated
Use kMsgDKeyDown for protocol version 1.1+
See also
kMsgDKeyDown
Since
Protocol version 1.0

◆ kMsgDKeyDownLang

const char* const kMsgDKeyDownLang
extern

Key press with language code (v1.8+)

Message Code: "DKDL" Direction: Primary → Secondary Format: "DKDL%2i%2i%2i%s" Parameters:

  • $1: KeyID (2 bytes) - Virtual key identifier, often called a "keysym" on Linux/X11. This is platform-dependent and corresponds to values like XK_a on X11/Linux, ‘'a’ on macOS, and 'A' on Windows.
  • $2: KeyModifierMask (2 bytes) - Active modifier keys
  • $3: KeyButton (2 bytes) - Physical key code, often called a "keycode" or "scancode". This is the raw, platform-dependent scan code of the key pressed.
  • $4`: Language code (string) - Keyboard language identifier

Example:

'a' key (KeyID 0x61), no modifiers, physical key (KeyButton 0x1E), English

"DKDL\x00\x61\x00\x00\x00\x1E\x00\x00\x00\x02en"

Enhanced version of kMsgDKeyDown that includes language information to help clients handle unknown language characters correctly.

See also
kMsgDKeyDown
Since
Protocol version 1.8

◆ kMsgDKeyRepeat

const char* const kMsgDKeyRepeat
extern

Key auto-repeat event.

Message Code: "DKRP" Direction: Primary → Secondary Format: "DKRP%2i%2i%2i%2i%s" Parameters:

  • $1: KeyID (2 bytes) - Virtual key identifier, often called a "keysym" on Linux/X11. This is platform-dependent and corresponds to values like XK_a on X11/Linux, ‘'a’ on macOS, and 'A' on Windows.
  • $2: KeyModifierMask (2 bytes) - Active modifier keys
  • $3: Repeat count (2 bytes) - Number of repeats
  • $4: KeyButton (2 bytes) - Physical key code, often called a "keycode" or "scancode". This is the raw, platform-dependent scan code of the key pressed.
  • $5`: Language code (string) - Keyboard language identifier

Example:

'a' key repeating 3 times, English layout

"DKRP\x00\x61\x00\x00\x00\x03\x00\x1E\x00\x00\x00\x02en"

Sent when a key is held down and auto-repeating. The repeat count indicates how many repeat events occurred since the last message.

See also
kMsgDKeyDown
Since
Protocol version 1.1

◆ kMsgDKeyRepeat1_0

const char* const kMsgDKeyRepeat1_0
extern

Key auto-repeat event (legacy v1.0)

Message Code: "DKRP" Direction: Primary → Secondary Format: "DKRP%2i%2i%2i" Parameters:

  • $1: KeyID (2 bytes) - Virtual key identifier
  • $2: KeyModifierMask (2 bytes) - Active modifier keys
  • $3: Repeat count (2 bytes) - Number of repeats

Legacy version without KeyButton and language parameters.

Deprecated
Use kMsgDKeyRepeat for protocol version 1.1+
See also
kMsgDKeyRepeat
Since
Protocol version 1.0

◆ kMsgDKeyUp

const char* const kMsgDKeyUp
extern

Key release event.

Message Code: "DKUP" Direction: Primary → Secondary Format: "DKUP%2i%2i%2i" Parameters:

  • $1: KeyID (2 bytes) - Virtual key identifier, often called a "keysym" on Linux/X11. This is platform-dependent and corresponds to values like XK_a on X11/Linux, ‘'a’ on macOS, and 'A' on Windows.
  • $2: KeyModifierMask (2 bytes) - Active modifier keys
  • $3`: KeyButton (2 bytes) - Physical key code, often called a "keycode" or "scancode". This is the raw, platform-dependent scan code of the key pressed.

Example:

Release 'a' key, physical key 0x1E

"DKUP\x00\x61\x00\x00\x00\x1E"

Important: The secondary screen should use KeyButton (not KeyID) to determine which physical key to release. This ensures correct behavior with dead keys and layout differences.

See also
kMsgDKeyDown
Since
Protocol version 1.1

◆ kMsgDKeyUp1_0

const char* const kMsgDKeyUp1_0
extern

Key release event (legacy v1.0)

Message Code: "DKUP" Direction: Primary → Secondary Format: "DKUP%2i%2i" Parameters:

Legacy version without KeyButton parameter.

Deprecated
Use kMsgDKeyUp for protocol version 1.1+
See also
kMsgDKeyUp
Since
Protocol version 1.0