Development/Impress Remote Protocol

    From The Document Foundation Wiki


    This page (may) contain content that is old and/or out of date.
    If you have experience in this area, please review this page for accuracy.
    Reason: WARNING: this page contains outdated information. For the latest documentation on the Impress Remote procotol please check sd/IMPRESS_REMOTE in the source tree. (

    Version #1

    Communication is over a UTF-8 encoded character stream (using RTL_TEXTENCODING_UTF8 in the LibreOffice portion).



    More TCP-specific details on setup and initial handshake to be written, but the actual message protocol is the same as for Bluetooth.

    TCP port for a socket is 1599.


    Bluetooth communication is over RFCOMM. For discovery use the "standard UUID for the Serial Port Profile" i.e. the 16-bit SerialPort UUID 0x1101, or if necessary inserted into the Bluetooth BASE_UUID: 00001101-0000-1000-8000-00805F9B34FB. See

    Message format

    A message consists of one or more lines. The first line is the message description, further lines can add any necessary data. An empty line concludes the message. I.e. MESSAGE\n\n or MESSAGE\nDATA\nDATA2...\n\n.

    You must keep reading a message until an empty line (i.e. double new-line) is reached to allow for future protocol extension.


    Once connected the server sends LO_SERVER_SERVER_PAIRED (i.e. LO_SERVER_SERVER_PAIRED\n\n is sent over the stream).

    Subsequently the server will send either slideshow_started if a slideshow is running, or slideshow_finished if no slideshow is running (see below for details of).

    The current server implementation then proceeds to send all slide notes and previews to the client. This should be changed to prevent memory issues, and a preview request mechanism implemented.


    Nested lists represent commands parameters.

    Client → Server

    The client should not assume that the state of the server has changed when a command has been sent. All changes will be signalled back to the client. This is to allow for cases such as multiple clients requesting different changes, etc.

    • transition_next
    • transition_previous
    • goto_slide
    1. slide number
    • presentation_start
    • presentation_stop
    • presentation_blank_screen
    • presentation_resume (resumes after a presentation_blank_screen)

    Server → Client

    • slideshow_finished (also transmitted if no slideshow running when started)
    • slideshow_started (also transmitted if a slideshow is running on startup)
    1. number of slides
    2. current slide number
    • slide_notes
    1. slide number
    2. the notes as a HTML document, and may also include \n newlines, i.e. the client should keep reading until a blank line is reached
    • slide_updated (slide on server has changed)
    1. current slide number
    • slide_preview
    1. slide number
    2. a Base64 encoded PNG image

    Client’s Workflow

    1. Connect to a server via socket.
    3. If there will be the message from server LO_SERVER_VALIDATING_PIN\n\n it is necessary to display PIN to a user so one can enter it at the server.
    4. Wait for the message from the server LO_SERVER_PAIRED\n\n.
    5. Send commands and receive responses.

    Version #2

    New features

    • Pointer.
    • Downloading presentation file.


    Proposal by Artur Dryomov

    • Add the protocol’s versioning to avoid compatibility issues.
      • A client should implement a single protocol version, the server should support all versions with deprecation of old versions after some time period.
      • The versioning should be implemented via handshakes because there are no URLs or whatever used by clients — just commands. The required protocol version can be requested by client so server will know how to operate with each client.
      • The first protocol version has no versioning so I suggest to use the first protocol version by default.
    • Remove sending all previews and notes to client after starting a slideshow to avoid possible huge memory usage on clients. Optimize commands and their responses.
    • Use serialization (JSON or XML — probably XML is better for LO infrastructure).

    A very simple request can be something like this.

       "action": "pair",
       "client": {
         "name": "Fancy Phone Model",
         "pin": 1234

    Or like this.

       "action": "pointer",
       "coordinates": {
         "x": 100,
         "y": 200