Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1618590 > unrolled thread
| Started by | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| First post | 2017-04-07 10:40 +0200 |
| Last post | 2017-04-10 08:10 +0200 |
| Articles | 20 — 5 participants |
Back to article view | Back to linux.kernel
[For Linux 0/4] PV protocol headers for Linux Kernel Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 10:40 +0200
[For Linux 3/4] xen/sndif: add sound-device ABI Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 10:40 +0200
Re: [Xen-devel] [For Linux 3/4] xen/sndif: add sound-device ABI Juergen Gross <jgross@suse.com> - 2017-04-07 13:40 +0200
[For Linux 1/4] xen/kbdif: update protocol description Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 10:40 +0200
Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description Juergen Gross <jgross@suse.com> - 2017-04-07 13:40 +0200
Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2017-04-07 14:50 +0200
Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 15:00 +0200
[For Linux 2/4] xen/kbdif: add multi-touch support Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 10:40 +0200
Re: [Xen-devel] [For Linux 2/4] xen/kbdif: add multi-touch support Juergen Gross <jgross@suse.com> - 2017-04-07 13:40 +0200
Re: [For Linux 0/4] PV protocol headers for Linux Kernel Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 10:50 +0200
Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display Juergen Gross <jgross@suse.com> - 2017-04-07 13:40 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Julien Grall <julien.grall@arm.com> - 2017-04-07 16:00 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 16:10 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Stefano Stabellini <sstabellini@kernel.org> - 2017-04-07 18:40 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 19:50 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Stefano Stabellini <sstabellini@kernel.org> - 2017-04-07 20:00 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-07 20:00 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Oleksandr Andrushchenko <andr2000@gmail.com> - 2017-04-10 08:10 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Juergen Gross <jgross@suse.com> - 2017-04-10 08:10 +0200
Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display Juergen Gross <jgross@suse.com> - 2017-04-10 08:10 +0200
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 10:40 +0200 |
| Subject | [For Linux 0/4] PV protocol headers for Linux Kernel |
| Message-ID | <ttxAZ-4Hw-7@gated-at.bofh.it> |
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Hi, all! This patch series adds/updates para-virtual device protocols for Linux Kernel (headers): o kbdif (multitouch support added) o sndif - sound (new) o displif - display (new) No changes, but Linux Kernel coding style applied. Thank you, Oleksandr Oleksandr Andrushchenko (4): xen/kbdif: update protocol description xen/kbdif: add multi-touch support xen/sndif: add sound-device ABI xen/displif: add ABI for para-virtual display include/xen/interface/io/displif.h | 864 +++++++++++++++++++++++++++++++++++++ include/xen/interface/io/kbdif.h | 468 ++++++++++++++++++-- include/xen/interface/io/sndif.h | 803 ++++++++++++++++++++++++++++++++++ 3 files changed, 2108 insertions(+), 27 deletions(-) create mode 100644 include/xen/interface/io/displif.h create mode 100644 include/xen/interface/io/sndif.h -- 2.7.4
[toc] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 10:40 +0200 |
| Subject | [For Linux 3/4] xen/sndif: add sound-device ABI |
| Message-ID | <ttxAZ-4Hw-5@gated-at.bofh.it> |
| In reply to | #1618590 |
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case backend can expose more sound
cards and PCM devices/streams than the underlying HW physically
has by employing SW mixers, configuring virtual sound streams,
channels etc. Thus, allowing fine tunned configurations per
frontend.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
---
include/xen/interface/io/sndif.h | 803 +++++++++++++++++++++++++++++++++++++++
1 file changed, 803 insertions(+)
create mode 100644 include/xen/interface/io/sndif.h
diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
new file mode 100644
index 000000000000..ea9b81024cd9
--- /dev/null
+++ b/include/xen/interface/io/sndif.h
@@ -0,0 +1,803 @@
+/******************************************************************************
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ * Copyright (C) 2016-2017 EPAM Systems Inc.
+ *
+ * Authors: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
+ * Oleksandr Grytsov <oleksandr_grytsov@epam.com>
+ * Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
+ * Iurii Konovalenko <iurii.konovalenko@globallogic.com>
+ */
+
+#ifndef __XEN_PUBLIC_IO_SNDIF_H__
+#define __XEN_PUBLIC_IO_SNDIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ ******************************************************************************
+ * Feature and Parameter Negotiation
+ ******************************************************************************
+ *
+ * Front->back notifications: when enqueuing a new request, sending a
+ * notification can be made conditional on xensnd_req (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Backends must set
+ * xensnd_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
+ *
+ * Back->front notifications: when enqueuing a new response, sending a
+ * notification can be made conditional on xensnd_resp (i.e., the generic
+ * hold-off mechanism provided by the ring macros). Frontends must set
+ * xensnd_resp appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
+ *
+ * The two halves of a para-virtual sound card driver utilize nodes within
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of XenStore, following the XenBus convention.
+ *
+ * All data in XenStore is stored as strings. Nodes specifying numeric
+ * values are encoded in decimal. Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ ******************************************************************************
+ * Example configuration
+ ******************************************************************************
+ *
+ * Note: depending on the use-case backend can expose more sound cards and
+ * PCM devices/streams than the underlying HW physically has by employing
+ * SW mixers, configuring virtual sound streams, channels etc.
+ *
+ * This is an example of backend and frontend configuration:
+ *
+ *--------------------------------- Backend -----------------------------------
+ *
+ * /local/domain/0/backend/vsnd/1/0/frontend-id = "1"
+ * /local/domain/0/backend/vsnd/1/0/frontend = "/local/domain/1/device/vsnd/0"
+ * /local/domain/0/backend/vsnd/1/0/state = "4"
+ * /local/domain/0/backend/vsnd/1/0/versions = "1,2"
+ *
+ *--------------------------------- Frontend ----------------------------------
+ *
+ * /local/domain/1/device/vsnd/0/backend-id = "0"
+ * /local/domain/1/device/vsnd/0/backend = "/local/domain/0/backend/vsnd/1/0"
+ * /local/domain/1/device/vsnd/0/state = "4"
+ * /local/domain/1/device/vsnd/0/version = "1"
+ *
+ *----------------------------- Card configuration ----------------------------
+ *
+ * /local/domain/1/device/vsnd/0/short-name = "Card short name"
+ * /local/domain/1/device/vsnd/0/long-name = "Card long name"
+ * /local/domain/1/device/vsnd/0/sample-rates = "8000,32000,44100,48000,96000"
+ * /local/domain/1/device/vsnd/0/sample-formats = "s8,u8,s16_le,s16_be"
+ * /local/domain/1/device/vsnd/0/buffer-size = "262144"
+ *
+ *------------------------------- PCM device 0 --------------------------------
+ *
+ * /local/domain/1/device/vsnd/0/0/name = "General analog"
+ * /local/domain/1/device/vsnd/0/0/channels-max = "5"
+ *
+ *----------------------------- Stream 0, playback ----------------------------
+ *
+ * /local/domain/1/device/vsnd/0/0/0/type = "p"
+ * /local/domain/1/device/vsnd/0/0/0/sample-formats = "s8,u8"
+ * /local/domain/1/device/vsnd/0/0/0/unique-id = "0"
+ *
+ * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386"
+ * /local/domain/1/device/vsnd/0/0/0/event-channel = "15"
+ *
+ *------------------------------ Stream 1, capture ----------------------------
+ *
+ * /local/domain/1/device/vsnd/0/0/1/type = "c"
+ * /local/domain/1/device/vsnd/0/0/1/channels-max = "2"
+ * /local/domain/1/device/vsnd/0/0/1/unique-id = "1"
+ *
+ * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384"
+ * /local/domain/1/device/vsnd/0/0/1/event-channel = "13"
+ *
+ *------------------------------- PCM device 1 --------------------------------
+ *
+ * /local/domain/1/device/vsnd/0/1/name = "HDMI-0"
+ * /local/domain/1/device/vsnd/0/1/sample-rates = "8000,32000,44100"
+ *
+ *------------------------------ Stream 0, capture ----------------------------
+ *
+ * /local/domain/1/device/vsnd/0/1/0/type = "c"
+ * /local/domain/1/device/vsnd/0/1/0/unique-id = "2"
+ *
+ * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387"
+ * /local/domain/1/device/vsnd/0/1/0/event-channel = "151"
+ *
+ *------------------------------- PCM device 2 --------------------------------
+ *
+ * /local/domain/1/device/vsnd/0/2/name = "SPDIF"
+ *
+ *----------------------------- Stream 0, playback ----------------------------
+ *
+ * /local/domain/1/device/vsnd/0/2/0/type = "p"
+ * /local/domain/1/device/vsnd/0/2/0/unique-id = "3"
+ *
+ * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389"
+ * /local/domain/1/device/vsnd/0/2/0/event-channel = "152"
+ *
+ ******************************************************************************
+ * Backend XenBus Nodes
+ ******************************************************************************
+ *
+ *----------------------------- Protocol version ------------------------------
+ *
+ * versions
+ * Values: <string>
+ *
+ * List of XENSND_LIST_SEPARATOR separated protocol versions supported
+ * by the backend. For example "1,2,3".
+ *
+ ******************************************************************************
+ * Frontend XenBus Nodes
+ ******************************************************************************
+ *
+ *-------------------------------- Addressing ---------------------------------
+ *
+ * dom-id
+ * Values: <uint16_t>
+ *
+ * Domain identifier.
+ *
+ * dev-id
+ * Values: <uint16_t>
+ *
+ * Device identifier.
+ *
+ * pcm-dev-idx
+ * Values: <uint8_t>
+ *
+ * Zero based contigous index of the PCM device.
+ *
+ * stream-idx
+ * Values: <uint8_t>
+ *
+ * Zero based contigous index of the stream of the PCM device.
+ *
+ * The following pattern is used for addressing:
+ * /local/domain/<dom-id>/device/vsnd/<dev-id>/<pcm-dev-idx>/<stream-idx>/...
+ *
+ *----------------------------- Protocol version ------------------------------
+ *
+ * version
+ * Values: <string>
+ *
+ * Protocol version, chosen among the ones supported by the backend.
+ *
+ *------------------------------- PCM settings --------------------------------
+ *
+ * Every virtualized sound frontend has a set of PCM devices and streams, each
+ * could be individually configured. Part of the PCM configuration can be
+ * defined at higher level of the hierarchy and be fully or partially re-used
+ * by the underlying layers. These configuration values are:
+ * o number of channels (min/max)
+ * o supported sample rates
+ * o supported sample formats.
+ * E.g. one can define these values for the whole card, device or stream.
+ * Every underlying layer in turn can re-define some or all of them to better
+ * fit its needs. For example, card may define number of channels to be
+ * in [1; 8] range, and some particular stream may be limited to [1; 2] only.
+ * The rule is that the underlying layer must be a subset of the upper layer
+ * range.
+ *
+ * channels-min
+ * Values: <uint8_t>
+ *
+ * The minimum amount of channels that is supported, [1; channels-max].
+ * Optional, if not set or omitted a value of 1 is used.
+ *
+ * channels-max
+ * Values: <uint8_t>
+ *
+ * The maximum amount of channels that is supported.
+ * Must be at least <channels-min>.
+ *
+ * sample-rates
+ * Values: <list of uint32_t>
+ *
+ * List of supported sample rates separated by XENSND_LIST_SEPARATOR.
+ * Sample rates are expressed as a list of decimal values w/o any
+ * ordering requirement.
+ *
+ * sample-formats
+ * Values: <list of XENSND_PCM_FORMAT_XXX_STR>
+ *
+ * List of supported sample formats separated by XENSND_LIST_SEPARATOR.
+ * Items must not exceed XENSND_SAMPLE_FORMAT_MAX_LEN length.
+ *
+ * buffer-size
+ * Values: <uint32_t>
+ *
+ * The maximum size in octets of the buffer to allocate per stream.
+ *
+ *----------------------- Virtual sound card settings -------------------------
+ * short-name
+ * Values: <char[32]>
+ *
+ * Short name of the virtual sound card. Optional.
+ *
+ * long-name
+ * Values: <char[80]>
+ *
+ * Long name of the virtual sound card. Optional.
+ *
+ *----------------------------- Device settings -------------------------------
+ * name
+ * Values: <char[80]>
+ *
+ * Name of the sound device within the virtual sound card. Optional.
+ *
+ *----------------------------- Stream settings -------------------------------
+ *
+ * type
+ * Values: "p", "c"
+ *
+ * Stream type: "p" - playback stream, "c" - capture stream
+ *
+ * If both capture and playback are needed then two streams need to be
+ * defined under the same device.
+ *
+ * unique-id
+ * Values: <uint32_t>
+ *
+ * After stream initialization it is assigned a unique ID (within the front
+ * driver), so every stream of the frontend can be identified by the
+ * backend by this ID. This is not equal to stream-idx as the later is
+ * zero based within the device, but this index is contigous within the
+ * driver.
+ *
+ *-------------------- Stream Request Transport Parameters --------------------
+ *
+ * event-channel
+ * Values: <uint32_t>
+ *
+ * The identifier of the Xen event channel used to signal activity
+ * in the ring buffer.
+ *
+ * ring-ref
+ * Values: <uint32_t>
+ *
+ * The Xen grant reference granting permission for the backend to map
+ * a sole page in a single page sized ring buffer.
+ *
+ ******************************************************************************
+ * STATE DIAGRAMS
+ ******************************************************************************
+ *
+ * Tool stack creates front and back state nodes with initial state
+ * XenbusStateInitialising.
+ * Tool stack creates and sets up frontend sound configuration nodes per domain.
+ *
+ * Front Back
+ * ================================= =====================================
+ * XenbusStateInitialising XenbusStateInitialising
+ * o Query backend device identification
+ * data.
+ * o Open and validate backend device.
+ * |
+ * |
+ * V
+ * XenbusStateInitWait
+ *
+ * o Query frontend configuration
+ * o Allocate and initialize
+ * event channels per configured
+ * playback/capture stream.
+ * o Publish transport parameters
+ * that will be in effect during
+ * this connection.
+ * |
+ * |
+ * V
+ * XenbusStateInitialised
+ *
+ * o Query frontend transport parameters.
+ * o Connect to the event channels.
+ * |
+ * |
+ * V
+ * XenbusStateConnected
+ *
+ * o Create and initialize OS
+ * virtual sound device instances
+ * as per configuration.
+ * |
+ * |
+ * V
+ * XenbusStateConnected
+ *
+ * XenbusStateUnknown
+ * XenbusStateClosed
+ * XenbusStateClosing
+ * o Remove virtual sound device
+ * o Remove event channels
+ * |
+ * |
+ * V
+ * XenbusStateClosed
+ *
+ *------------------------------- Recovery flow -------------------------------
+ *
+ * In case of frontend unrecoverable errors backend handles that as
+ * if frontend goes into the XenbusStateClosed state.
+ *
+ * In case of backend unrecoverable errors frontend tries removing
+ * the virtualized device. If this is possible at the moment of error,
+ * then frontend goes into the XenbusStateInitialising state and is ready for
+ * new connection with backend. If the virtualized device is still in use and
+ * cannot be removed, then frontend goes into the XenbusStateReconfiguring state
+ * until either the virtualized device removed or backend initiates a new
+ * connection. On the virtualized device removal frontend goes into the
+ * XenbusStateInitialising state.
+ *
+ * Note on XenbusStateReconfiguring state of the frontend: if backend has
+ * unrecoverable errors then frontend cannot send requests to the backend
+ * and thus cannot provide functionality of the virtualized device anymore.
+ * After backend is back to normal the virtualized device may still hold some
+ * state: configuration in use, allocated buffers, client application state etc.
+ * So, in most cases, this will require frontend to implement complex recovery
+ * reconnect logic. Instead, by going into XenbusStateReconfiguring state,
+ * frontend will make sure no new clients of the virtualized device are
+ * accepted, allow existing client(s) to exit gracefully by signaling error
+ * state etc.
+ * Once all the clients are gone frontend can reinitialize the virtualized
+ * device and get into XenbusStateInitialising state again signaling the
+ * backend that a new connection can be made.
+ *
+ * There are multiple conditions possible under which frontend will go from
+ * XenbusStateReconfiguring into XenbusStateInitialising, some of them are OS
+ * specific. For example:
+ * 1. The underlying OS framework may provide callbacks to signal that the last
+ * client of the virtualized device has gone and the device can be removed
+ * 2. Frontend can schedule a deferred work (timer/tasklet/workqueue)
+ * to periodically check if this is the right time to re-try removal of
+ * the virtualized device.
+ * 3. By any other means.
+ *
+ ******************************************************************************
+ * PCM FORMATS
+ ******************************************************************************
+ *
+ * XENSND_PCM_FORMAT_<format>[_<endian>]
+ *
+ * format: <S/U/F><bits> or <name>
+ * S - signed, U - unsigned, F - float
+ * bits - 8, 16, 24, 32
+ * name - MU_LAW, GSM, etc.
+ *
+ * endian: <LE/BE>, may be absent
+ * LE - Little endian, BE - Big endian
+ */
+#define XENSND_PCM_FORMAT_S8 0
+#define XENSND_PCM_FORMAT_U8 1
+#define XENSND_PCM_FORMAT_S16_LE 2
+#define XENSND_PCM_FORMAT_S16_BE 3
+#define XENSND_PCM_FORMAT_U16_LE 4
+#define XENSND_PCM_FORMAT_U16_BE 5
+#define XENSND_PCM_FORMAT_S24_LE 6
+#define XENSND_PCM_FORMAT_S24_BE 7
+#define XENSND_PCM_FORMAT_U24_LE 8
+#define XENSND_PCM_FORMAT_U24_BE 9
+#define XENSND_PCM_FORMAT_S32_LE 10
+#define XENSND_PCM_FORMAT_S32_BE 11
+#define XENSND_PCM_FORMAT_U32_LE 12
+#define XENSND_PCM_FORMAT_U32_BE 13
+#define XENSND_PCM_FORMAT_F32_LE 14 /* 4-byte float, IEEE-754 32-bit, */
+#define XENSND_PCM_FORMAT_F32_BE 15 /* range -1.0 to 1.0 */
+#define XENSND_PCM_FORMAT_F64_LE 16 /* 8-byte float, IEEE-754 64-bit, */
+#define XENSND_PCM_FORMAT_F64_BE 17 /* range -1.0 to 1.0 */
+#define XENSND_PCM_FORMAT_IEC958_SUBFRAME_LE 18
+#define XENSND_PCM_FORMAT_IEC958_SUBFRAME_BE 19
+#define XENSND_PCM_FORMAT_MU_LAW 20
+#define XENSND_PCM_FORMAT_A_LAW 21
+#define XENSND_PCM_FORMAT_IMA_ADPCM 22
+#define XENSND_PCM_FORMAT_MPEG 23
+#define XENSND_PCM_FORMAT_GSM 24
+
+/*
+ ******************************************************************************
+ * REQUEST CODES
+ ******************************************************************************
+ */
+#define XENSND_OP_OPEN 0
+#define XENSND_OP_CLOSE 1
+#define XENSND_OP_READ 2
+#define XENSND_OP_WRITE 3
+#define XENSND_OP_SET_VOLUME 4
+#define XENSND_OP_GET_VOLUME 5
+#define XENSND_OP_MUTE 6
+#define XENSND_OP_UNMUTE 7
+
+/*
+ ******************************************************************************
+ * XENSTORE FIELD AND PATH NAME STRINGS, HELPERS
+ ******************************************************************************
+ */
+#define XENSND_DRIVER_NAME "vsnd"
+
+#define XENSND_LIST_SEPARATOR ","
+/* Field names */
+#define XENSND_FIELD_BE_VERSIONS "versions"
+#define XENSND_FIELD_FE_VERSION "version"
+#define XENSND_FIELD_VCARD_SHORT_NAME "short-name"
+#define XENSND_FIELD_VCARD_LONG_NAME "long-name"
+#define XENSND_FIELD_RING_REF "ring-ref"
+#define XENSND_FIELD_EVT_CHNL "event-channel"
+#define XENSND_FIELD_DEVICE_NAME "name"
+#define XENSND_FIELD_TYPE "type"
+#define XENSND_FIELD_STREAM_UNIQUE_ID "unique-id"
+#define XENSND_FIELD_CHANNELS_MIN "channels-min"
+#define XENSND_FIELD_CHANNELS_MAX "channels-max"
+#define XENSND_FIELD_SAMPLE_RATES "sample-rates"
+#define XENSND_FIELD_SAMPLE_FORMATS "sample-formats"
+#define XENSND_FIELD_BUFFER_SIZE "buffer-size"
+
+/* Stream type field values. */
+#define XENSND_STREAM_TYPE_PLAYBACK "p"
+#define XENSND_STREAM_TYPE_CAPTURE "c"
+/* Sample rate max string length */
+#define XENSND_SAMPLE_RATE_MAX_LEN 11
+/* Sample format field values */
+#define XENSND_SAMPLE_FORMAT_MAX_LEN 24
+
+#define XENSND_PCM_FORMAT_S8_STR "s8"
+#define XENSND_PCM_FORMAT_U8_STR "u8"
+#define XENSND_PCM_FORMAT_S16_LE_STR "s16_le"
+#define XENSND_PCM_FORMAT_S16_BE_STR "s16_be"
+#define XENSND_PCM_FORMAT_U16_LE_STR "u16_le"
+#define XENSND_PCM_FORMAT_U16_BE_STR "u16_be"
+#define XENSND_PCM_FORMAT_S24_LE_STR "s24_le"
+#define XENSND_PCM_FORMAT_S24_BE_STR "s24_be"
+#define XENSND_PCM_FORMAT_U24_LE_STR "u24_le"
+#define XENSND_PCM_FORMAT_U24_BE_STR "u24_be"
+#define XENSND_PCM_FORMAT_S32_LE_STR "s32_le"
+#define XENSND_PCM_FORMAT_S32_BE_STR "s32_be"
+#define XENSND_PCM_FORMAT_U32_LE_STR "u32_le"
+#define XENSND_PCM_FORMAT_U32_BE_STR "u32_be"
+#define XENSND_PCM_FORMAT_F32_LE_STR "float_le"
+#define XENSND_PCM_FORMAT_F32_BE_STR "float_be"
+#define XENSND_PCM_FORMAT_F64_LE_STR "float64_le"
+#define XENSND_PCM_FORMAT_F64_BE_STR "float64_be"
+#define XENSND_PCM_FORMAT_IEC958_SUBFRAME_LE_STR "iec958_subframe_le"
+#define XENSND_PCM_FORMAT_IEC958_SUBFRAME_BE_STR "iec958_subframe_be"
+#define XENSND_PCM_FORMAT_MU_LAW_STR "mu_law"
+#define XENSND_PCM_FORMAT_A_LAW_STR "a_law"
+#define XENSND_PCM_FORMAT_IMA_ADPCM_STR "ima_adpcm"
+#define XENSND_PCM_FORMAT_MPEG_STR "mpeg"
+#define XENSND_PCM_FORMAT_GSM_STR "gsm"
+
+
+/*
+ ******************************************************************************
+ * STATUS RETURN CODES
+ ******************************************************************************
+ *
+ * Status return code is zero on success and -XEN_EXX on failure.
+ *
+ ******************************************************************************
+ * Assumptions
+ ******************************************************************************
+ * o usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a PV driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ * o all references in this document to page sizes must be treated
+ * as pages of size XEN_PAGE_SIZE unless otherwise noted.
+ *
+ ******************************************************************************
+ * Description of the protocol between frontend and backend driver
+ ******************************************************************************
+ *
+ * The two halves of a Para-virtual sound driver communicate with
+ * each other using shared pages and event channels.
+ * Shared page contains a ring with request/response packets.
+ *
+ * Packets, used for input/output operations, e.g. read/write, set/get volume,
+ * etc., provide offset/length fields in order to allow asynchronous protocol
+ * operation with buffer space sharing: part of the buffer allocated at
+ * XENSND_OP_OPEN can be used for audio samples and part, for example,
+ * for volume control.
+ *
+ * All reserved fields in the structures below must be 0.
+ *
+ *---------------------------------- Requests ---------------------------------
+ *
+ * All request packets have the same length (32 octets)
+ * All request packets have common header:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | operation | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * id - uint16_t, private guest value, echoed in response
+ * operation - uint8_t, operation code, XENSND_OP_???
+ *
+ * For all packets which use offset and length:
+ * offset - uint32_t, read or write data offset within the shared buffer,
+ * passed with XENSND_OP_OPEN request, octets,
+ * [0; XENSND_OP_OPEN.buffer_sz - 1].
+ * length - uint32_t, read or write data length, octets
+ *
+ * Request open - open a PCM stream for playback or capture:
+ *
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | XENSND_OP_OPEN | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | pcm_rate | 12
+ * +----------------+----------------+----------------+----------------+
+ * | pcm_format | pcm_channels | reserved | 16
+ * +----------------+----------------+----------------+----------------+
+ * | buffer_sz | 20
+ * +----------------+----------------+----------------+----------------+
+ * | gref_directory | 24
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 28
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * pcm_rate - uint32_t, stream data rate, Hz
+ * pcm_format - uint8_t, XENSND_PCM_FORMAT_XXX value
+ * pcm_channels - uint8_t, number of channels of this stream,
+ * [channels-min; channels-max]
+ * buffer_sz - uint32_t, buffer size to be allocated, octets
+ * gref_directory - grant_ref_t, a reference to the first shared page
+ * describing shared buffer references. At least one page exists. If shared
+ * buffer size (buffer_sz) exceeds what can be addressed by this single page,
+ * then reference to the next page must be supplied (see gref_dir_next_page
+ * below)
+ */
+
+struct xensnd_open_req {
+ uint32_t pcm_rate;
+ uint8_t pcm_format;
+ uint8_t pcm_channels;
+ uint16_t reserved;
+ uint32_t buffer_sz;
+ grant_ref_t gref_directory;
+};
+
+/*
+ * Shared page for XENSND_OP_OPEN buffer descriptor (gref_directory in the
+ * request) employs a list of pages, describing all pages of the shared data
+ * buffer:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | gref_dir_next_page | 4
+ * +----------------+----------------+----------------+----------------+
+ * | gref[0] | 8
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | gref[i] | i*4+8
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | gref[N - 1] | N*4+8
+ * +----------------+----------------+----------------+----------------+
+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page describing
+ * page directory. Must be 0 if there are no more pages in the list.
+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ * allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ * num_grefs_total = (XENSND_OP_OPEN.buffer_sz + XEN_PAGE_SIZE - 1) /
+ * XEN_PAGE_SIZE
+ */
+
+struct xensnd_page_directory {
+ grant_ref_t gref_dir_next_page;
+ grant_ref_t gref[1]; /* Variable length */
+};
+
+/*
+ * Request close - close an opened pcm stream:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | XENSND_OP_CLOSE| reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * Request read/write - used for read (for capture) or write (for playback):
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | operation | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | offset | 12
+ * +----------------+----------------+----------------+----------------+
+ * | length | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * operation - XENSND_OP_READ for read or XENSND_OP_WRITE for write
+ */
+
+struct xensnd_rw_req {
+ uint32_t offset;
+ uint32_t length;
+};
+
+/*
+ * Request set/get volume - set/get channels' volume of the stream given:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | operation | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | offset | 12
+ * +----------------+----------------+----------------+----------------+
+ * | length | 16
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * operation - XENSND_OP_SET_VOLUME for volume set
+ * or XENSND_OP_GET_VOLUME for volume get
+ * Buffer passed with XENSND_OP_OPEN is used to exchange volume
+ * values:
+ *
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | channel[0] | 4
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | channel[i] | i*4
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | channel[N - 1] | (N-1)*4
+ * +----------------+----------------+----------------+----------------+
+ *
+ * N = XENSND_OP_OPEN.pcm_channels
+ * i - uint8_t, index of a channel
+ * channel[i] - sint32_t, volume of i-th channel
+ * Volume is expressed as a signed value in steps of 0.001 dB,
+ * while 0 being 0 dB.
+ *
+ * Request mute/unmute - mute/unmute stream:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | operation | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | offset | 12
+ * +----------------+----------------+----------------+----------------+
+ * | length | 16
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * operation - XENSND_OP_MUTE for mute or XENSND_OP_UNMUTE for unmute
+ * Buffer passed with XENSND_OP_OPEN is used to exchange mute/unmute
+ * values:
+ *
+ * 0 octet
+ * +----------------+----------------+----------------+----------------+
+ * | channel[0] | 4
+ * +----------------+----------------+----------------+----------------+
+ * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | channel[i] | i*4
+ * +----------------+----------------+----------------+----------------+
+ * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | channel[N - 1] | (N-1)*4
+ * +----------------+----------------+----------------+----------------+
+ *
+ * N = XENSND_OP_OPEN.pcm_channels
+ * i - uint8_t, index of a channel
+ * channel[i] - uint8_t, non-zero if i-th channel needs to be muted/unmuted
+ *
+ *------------------------------------ N.B. -----------------------------------
+ *
+ * The 'struct xensnd_rw_req' is also used for XENSND_OP_SET_VOLUME,
+ * XENSND_OP_GET_VOLUME, XENSND_OP_MUTE, XENSND_OP_UNMUTE.
+ */
+
+/*
+ *---------------------------------- Responses --------------------------------
+ *
+ * All response packets have the same length (32 octets)
+ *
+ * Response for all requests:
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | id | operation | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | status | 8
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 12
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 32
+ * +----------------+----------------+----------------+----------------+
+ *
+ * id - uint16_t, copied from the request
+ * operation - uint8_t, XENSND_OP_* - copied from request
+ * status - int32_t, response status, zero on success and -XEN_EXX on failure
+ */
+
+struct xensnd_req {
+ uint16_t id;
+ uint8_t operation;
+ uint8_t reserved[5];
+ union {
+ struct xensnd_open_req open;
+ struct xensnd_rw_req rw;
+ uint8_t reserved[24];
+ } op;
+};
+
+struct xensnd_resp {
+ uint16_t id;
+ uint8_t operation;
+ uint8_t reserved;
+ int32_t status;
+ uint8_t reserved1[24];
+};
+
+DEFINE_RING_TYPES(xen_sndif, struct xensnd_req, struct xensnd_resp);
+
+#endif /* __XEN_PUBLIC_IO_SNDIF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-07 13:40 +0200 |
| Subject | Re: [Xen-devel] [For Linux 3/4] xen/sndif: add sound-device ABI |
| Message-ID | <ttApc-6sd-17@gated-at.bofh.it> |
| In reply to | #1618591 |
On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Add ABI for the two halves of a para-virtualized > sound driver to communicate with each other. > > The ABI allows implementing audio playback and capture as > well as volume control and possibility to mute/unmute > audio sources. > > Note: depending on the use-case backend can expose more sound > cards and PCM devices/streams than the underlying HW physically > has by employing SW mixers, configuring virtual sound streams, > channels etc. Thus, allowing fine tunned configurations per > frontend. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com> > Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com> > Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com> Acked-by: Juergen Gross <jgross@suse.com> Juergen
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 10:40 +0200 |
| Subject | [For Linux 1/4] xen/kbdif: update protocol description |
| Message-ID | <ttxB0-4Hw-19@gated-at.bofh.it> |
| In reply to | #1618590 |
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
The patch clarifies the protocol that is used by the PV keyboard
drivers.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
include/xen/interface/io/kbdif.h | 258 +++++++++++++++++++++++++++++++++++----
1 file changed, 231 insertions(+), 27 deletions(-)
diff --git a/include/xen/interface/io/kbdif.h b/include/xen/interface/io/kbdif.h
index 8066c7849fbe..e83eaddb20dc 100644
--- a/include/xen/interface/io/kbdif.h
+++ b/include/xen/interface/io/kbdif.h
@@ -26,43 +26,223 @@
#ifndef __XEN_PUBLIC_IO_KBDIF_H__
#define __XEN_PUBLIC_IO_KBDIF_H__
-/* In events (backend -> frontend) */
+/*
+ *****************************************************************************
+ * Feature and Parameter Negotiation
+ *****************************************************************************
+ *
+ * The two halves of a para-virtual driver utilize nodes within
+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of XenStore, following XenBus convention.
+ *
+ * All data in XenStore is stored as strings. Nodes specifying numeric
+ * values are encoded in decimal. Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ *****************************************************************************
+ * Backend XenBus Nodes
+ *****************************************************************************
+ *
+ *---------------------------- Features supported ----------------------------
+ *
+ * Capable backend advertises supported features by publishing
+ * corresponding entries in XenStore and puts 1 as the value of the entry.
+ * If a feature is not supported then 0 must be set or feature entry omitted.
+ *
+ * feature-abs-pointer
+ * Values: <uint>
+ *
+ * Backends, which support reporting of absolute coordinates for pointer
+ * device should set this to 1.
+ *
+ *------------------------- Pointer Device Parameters ------------------------
+ *
+ * width
+ * Values: <uint>
+ *
+ * Maximum X coordinate (width) to be used by the frontend
+ * while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * height
+ * Values: <uint>
+ *
+ * Maximum Y coordinate (height) to be used by the frontend
+ * while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ *****************************************************************************
+ * Frontend XenBus Nodes
+ *****************************************************************************
+ *
+ *------------------------------ Feature request -----------------------------
+ *
+ * Capable frontend requests features from backend via setting corresponding
+ * entries to 1 in XenStore. Requests for features not advertised as supported
+ * by the backend have no effect.
+ *
+ * request-abs-pointer
+ * Values: <uint>
+ *
+ * Request backend to report absolute pointer coordinates
+ * (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
+ *
+ *----------------------- Request Transport Parameters -----------------------
+ *
+ * event-channel
+ * Values: <uint>
+ *
+ * The identifier of the Xen event channel used to signal activity
+ * in the ring buffer.
+ *
+ * page-gref
+ * Values: <uint>
+ *
+ * The Xen grant reference granting permission for the backend to map
+ * a sole page in a single page sized event ring buffer.
+ *
+ * page-ref
+ * Values: <uint>
+ *
+ * OBSOLETE, not recommended for use.
+ * PFN of the shared page.
+ */
/*
- * Frontends should ignore unknown in events.
+ * EVENT CODES.
+ */
+
+#define XENKBD_TYPE_MOTION 1
+#define XENKBD_TYPE_RESERVED 2
+#define XENKBD_TYPE_KEY 3
+#define XENKBD_TYPE_POS 4
+
+/*
+ * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
*/
-/* Pointer movement event */
-#define XENKBD_TYPE_MOTION 1
-/* Event type 2 currently not used */
-/* Key event (includes pointer buttons) */
-#define XENKBD_TYPE_KEY 3
+#define XENKBD_DRIVER_NAME "vkbd"
+
+#define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
+#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
+#define XENKBD_FIELD_RING_GREF "page-gref"
+#define XENKBD_FIELD_EVT_CHANNEL "event-channel"
+#define XENKBD_FIELD_WIDTH "width"
+#define XENKBD_FIELD_HEIGHT "height"
+
+/* OBSOLETE, not recommended for use */
+#define XENKBD_FIELD_RING_REF "page-ref"
+
/*
- * Pointer position event
- * Capable backend sets feature-abs-pointer in xenstore.
- * Frontend requests ot instead of XENKBD_TYPE_MOTION by setting
- * request-abs-update in xenstore.
+ *****************************************************************************
+ * Description of the protocol between frontend and backend driver.
+ *****************************************************************************
+ *
+ * The two halves of a Para-virtual driver communicate with
+ * each other using a shared page and an event channel.
+ * Shared page contains a ring with event structures.
+ *
+ * All reserved fields in the structures below must be 0.
+ *
+ *****************************************************************************
+ * Backend to frontend events
+ *****************************************************************************
+ *
+ * Frontends should ignore unknown in events.
+ * All event packets have the same length (40 octets)
+ * All event packets have common header:
+ *
+ * 0 octet
+ * +-----------------+
+ * | type |
+ * +-----------------+
+ * type - uint8_t, event code, XENKBD_TYPE_???
+ *
+ *
+ * Pointer relative movement event
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MOTION | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | rel_x | 8
+ * +----------------+----------------+----------------+----------------+
+ * | rel_y | 12
+ * +----------------+----------------+----------------+----------------+
+ * | rel_z | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * rel_x - int32_t, relative X motion
+ * rel_y - int32_t, relative Y motion
+ * rel_z - int32_t, relative Z motion (wheel)
*/
-#define XENKBD_TYPE_POS 4
struct xenkbd_motion {
- uint8_t type; /* XENKBD_TYPE_MOTION */
- int32_t rel_x; /* relative X motion */
- int32_t rel_y; /* relative Y motion */
- int32_t rel_z; /* relative Z motion (wheel) */
+ uint8_t type;
+ int32_t rel_x;
+ int32_t rel_y;
+ int32_t rel_z;
};
+/*
+ * Key event (includes pointer buttons)
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_KEY | pressed | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | keycode | 8
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 12
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * pressed - uint8_t, 1 if pressed; 0 otherwise
+ * keycode - uint32_t, KEY_* from linux/input.h
+ */
+
struct xenkbd_key {
- uint8_t type; /* XENKBD_TYPE_KEY */
- uint8_t pressed; /* 1 if pressed; 0 otherwise */
- uint32_t keycode; /* KEY_* from linux/input.h */
+ uint8_t type;
+ uint8_t pressed;
+ uint32_t keycode;
};
+/*
+ * Pointer absolute position event
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_POS | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | abs_x | 8
+ * +----------------+----------------+----------------+----------------+
+ * | abs_y | 12
+ * +----------------+----------------+----------------+----------------+
+ * | rel_z | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * abs_x - int32_t, absolute X position (in FB pixels)
+ * abs_y - int32_t, absolute Y position (in FB pixels)
+ * rel_z - int32_t, relative Z motion (wheel)
+ */
+
struct xenkbd_position {
- uint8_t type; /* XENKBD_TYPE_POS */
- int32_t abs_x; /* absolute X position (in FB pixels) */
- int32_t abs_y; /* absolute Y position (in FB pixels) */
- int32_t rel_z; /* relative Z motion (wheel) */
+ uint8_t type;
+ int32_t abs_x;
+ int32_t abs_y;
+ int32_t rel_z;
};
#define XENKBD_IN_EVENT_SIZE 40
@@ -75,12 +255,22 @@ union xenkbd_in_event {
char pad[XENKBD_IN_EVENT_SIZE];
};
-/* Out events (frontend -> backend) */
-
/*
+ *****************************************************************************
+ * Frontend to backend events
+ *****************************************************************************
+ *
* Out events may be sent only when requested by backend, and receipt
* of an unknown out event is an error.
* No out events currently defined.
+
+ * All event packets have the same length (40 octets)
+ * All event packets have common header:
+ * 0 octet
+ * +-----------------+
+ * | type |
+ * +-----------------+
+ * type - uint8_t, event code
*/
#define XENKBD_OUT_EVENT_SIZE 40
@@ -90,7 +280,11 @@ union xenkbd_out_event {
char pad[XENKBD_OUT_EVENT_SIZE];
};
-/* shared page */
+/*
+ *****************************************************************************
+ * Shared page
+ *****************************************************************************
+ */
#define XENKBD_IN_RING_SIZE 2048
#define XENKBD_IN_RING_LEN (XENKBD_IN_RING_SIZE / XENKBD_IN_EVENT_SIZE)
@@ -113,4 +307,14 @@ struct xenkbd_page {
uint32_t out_cons, out_prod;
};
-#endif
+#endif /* __XEN_PUBLIC_IO_KBDIF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-07 13:40 +0200 |
| Subject | Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description |
| Message-ID | <ttApc-6sd-23@gated-at.bofh.it> |
| In reply to | #1618595 |
On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > The patch clarifies the protocol that is used by the PV keyboard > drivers. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: Juergen Gross <jgross@suse.com> I don't think its appropriate to keep the R-b:'s from the Xen commits for the Linux kernel. I can remove them when committing in case no V2 will be necessary. Added Boris. Juergen
[toc] | [prev] | [next] | [standalone]
| From | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> |
|---|---|
| Date | 2017-04-07 14:50 +0200 |
| Subject | Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description |
| Message-ID | <ttBuW-78a-35@gated-at.bofh.it> |
| In reply to | #1618701 |
On Fri, Apr 07, 2017 at 01:29:27PM +0200, Juergen Gross wrote: > On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > > > The patch clarifies the protocol that is used by the PV keyboard > > drivers. > > > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Acked-by: Juergen Gross <jgross@suse.com> > > I don't think its appropriate to keep the R-b:'s from the Xen > commits for the Linux kernel. <nods> > > I can remove them when committing in case no V2 will be necessary. Thank you! Oleksandr, thank you for doing this! > > Added Boris. > > > Juergen > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 15:00 +0200 |
| Subject | Re: [Xen-devel] [For Linux 1/4] xen/kbdif: update protocol description |
| Message-ID | <ttBED-7cJ-35@gated-at.bofh.it> |
| In reply to | #1618751 |
On 04/07/2017 03:45 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 07, 2017 at 01:29:27PM +0200, Juergen Gross wrote: >> On 07/04/17 10:30, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >>> >>> The patch clarifies the protocol that is used by the PV keyboard >>> drivers. >>> >>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> >>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> Acked-by: Juergen Gross <jgross@suse.com> >> >> I don't think its appropriate to keep the R-b:'s from the Xen >> commits for the Linux kernel. > <nods> > >> I can remove them when committing in case no V2 will be necessary. Please, do me a favor > Thank you! > > Oleksandr, thank you for doing this! My pleasure >> Added Boris. >> >> >> Juergen >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel Thank you, Oleksandr
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 10:40 +0200 |
| Subject | [For Linux 2/4] xen/kbdif: add multi-touch support |
| Message-ID | <ttxB0-4Hw-31@gated-at.bofh.it> |
| In reply to | #1618590 |
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
include/xen/interface/io/kbdif.h | 210 +++++++++++++++++++++++++++++++++++++++
1 file changed, 210 insertions(+)
diff --git a/include/xen/interface/io/kbdif.h b/include/xen/interface/io/kbdif.h
index e83eaddb20dc..41124f69aa59 100644
--- a/include/xen/interface/io/kbdif.h
+++ b/include/xen/interface/io/kbdif.h
@@ -57,6 +57,12 @@
* Backends, which support reporting of absolute coordinates for pointer
* device should set this to 1.
*
+ * feature-multi-touch
+ * Values: <uint>
+ *
+ * Backends, which support reporting of multi-touch events
+ * should set this to 1.
+ *
*------------------------- Pointer Device Parameters ------------------------
*
* width
@@ -87,6 +93,11 @@
* Request backend to report absolute pointer coordinates
* (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
*
+ * request-multi-touch
+ * Values: <uint>
+ *
+ * Request backend to report multi-touch events.
+ *
*----------------------- Request Transport Parameters -----------------------
*
* event-channel
@@ -106,6 +117,25 @@
*
* OBSOLETE, not recommended for use.
* PFN of the shared page.
+ *
+ *----------------------- Multi-touch Device Parameters -----------------------
+ *
+ * multi-touch-num-contacts
+ * Values: <uint>
+ *
+ * Number of simultaneous touches reported.
+ *
+ * multi-touch-width
+ * Values: <uint>
+ *
+ * Width of the touch area to be used by the frontend
+ * while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * multi-touch-height
+ * Values: <uint>
+ *
+ * Height of the touch area to be used by the frontend
+ * while reporting input events, pixels, [0; UINT32_MAX].
*/
/*
@@ -116,6 +146,16 @@
#define XENKBD_TYPE_RESERVED 2
#define XENKBD_TYPE_KEY 3
#define XENKBD_TYPE_POS 4
+#define XENKBD_TYPE_MTOUCH 5
+
+/* Multi-touch event sub-codes */
+
+#define XENKBD_MT_EV_DOWN 0
+#define XENKBD_MT_EV_UP 1
+#define XENKBD_MT_EV_MOTION 2
+#define XENKBD_MT_EV_SYN 3
+#define XENKBD_MT_EV_SHAPE 4
+#define XENKBD_MT_EV_ORIENT 5
/*
* CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
@@ -124,11 +164,16 @@
#define XENKBD_DRIVER_NAME "vkbd"
#define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
+#define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
+#define XENKBD_FIELD_REQ_MTOUCH "request-multi-touch"
#define XENKBD_FIELD_RING_GREF "page-gref"
#define XENKBD_FIELD_EVT_CHANNEL "event-channel"
#define XENKBD_FIELD_WIDTH "width"
#define XENKBD_FIELD_HEIGHT "height"
+#define XENKBD_FIELD_MT_WIDTH "multi-touch-width"
+#define XENKBD_FIELD_MT_HEIGHT "multi-touch-height"
+#define XENKBD_FIELD_MT_NUM_CONTACTS "multi-touch-num-contacts"
/* OBSOLETE, not recommended for use */
#define XENKBD_FIELD_RING_REF "page-ref"
@@ -245,6 +290,170 @@ struct xenkbd_position {
int32_t rel_z;
};
+/*
+ * Multi-touch event and its sub-types
+ *
+ * All multi-touch event packets have common header:
+ *
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | event_type | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ *
+ * event_type - unt8_t, multi-touch event sub-type, XENKBD_MT_EV_???
+ * contact_id - unt8_t, ID of the contact
+ *
+ * Touch interactions can consist of one or more contacts.
+ * For each contact, a series of events is generated, starting
+ * with a down event, followed by zero or more motion events,
+ * and ending with an up event. Events relating to the same
+ * contact point can be identified by the ID of the sequence: contact ID.
+ * Contact ID may be reused after XENKBD_MT_EV_UP event and
+ * is in the [0; XENKBD_FIELD_NUM_CONTACTS - 1] range.
+ *
+ * For further information please refer to documentation on Wayland [1],
+ * Linux [2] and Windows [3] multi-touch support.
+ *
+ * [1] https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml
+ * [2] https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt
+ * [3] https://msdn.microsoft.com/en-us/library/jj151564(v=vs.85).aspx
+ *
+ *
+ * Multi-touch down event - sent when a new touch is made: touch is assigned
+ * a unique contact ID, sent with this and consequent events related
+ * to this touch.
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_DOWN | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | abs_x | 12
+ * +----------------+----------------+----------------+----------------+
+ * | abs_y | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * abs_x - int32_t, absolute X position, in pixels
+ * abs_y - int32_t, absolute Y position, in pixels
+ *
+ * Multi-touch contact release event
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_UP | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * Multi-touch motion event
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_MOTION | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | abs_x | 12
+ * +----------------+----------------+----------------+----------------+
+ * | abs_y | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * abs_x - int32_t, absolute X position, in pixels,
+ * abs_y - int32_t, absolute Y position, in pixels,
+ *
+ * Multi-touch input synchronization event - shows end of a set of events
+ * which logically belong together.
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_SYN | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * Multi-touch shape event - touch point's shape has changed its shape.
+ * Shape is approximated by an ellipse through the major and minor axis
+ * lengths: major is the longer diameter of the ellipse and minor is the
+ * shorter one. Center of the ellipse is reported via
+ * XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION events.
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_SHAPE | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | major | 12
+ * +----------------+----------------+----------------+----------------+
+ * | minor | 16
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 20
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * major - unt32_t, length of the major axis, pixels
+ * minor - unt32_t, length of the minor axis, pixels
+ *
+ * Multi-touch orientation event - touch point's shape has changed
+ * its orientation: calculated as a clockwise angle between the major axis
+ * of the ellipse and positive Y axis in degrees, [-180; +180].
+ * 0 1 2 3 octet
+ * +----------------+----------------+----------------+----------------+
+ * | _TYPE_MTOUCH | _MT_EV_ORIENT | contact_id | reserved | 4
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 8
+ * +----------------+----------------+----------------+----------------+
+ * | orientation | reserved | 12
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 16
+ * +----------------+----------------+----------------+----------------+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +----------------+----------------+----------------+----------------+
+ * | reserved | 40
+ * +----------------+----------------+----------------+----------------+
+ *
+ * orientation - int16_t, clockwise angle of the major axis
+ */
+
+struct xenkbd_mtouch {
+ uint8_t type; /* XENKBD_TYPE_MTOUCH */
+ uint8_t event_type; /* XENKBD_MT_EV_??? */
+ uint8_t contact_id;
+ uint8_t reserved[5]; /* reserved for the future use */
+ union {
+ struct {
+ int32_t abs_x; /* absolute X position, pixels */
+ int32_t abs_y; /* absolute Y position, pixels */
+ } pos;
+ struct {
+ uint32_t major; /* length of the major axis, pixels */
+ uint32_t minor; /* length of the minor axis, pixels */
+ } shape;
+ int16_t orientation; /* clockwise angle of the major axis */
+ } u;
+};
+
#define XENKBD_IN_EVENT_SIZE 40
union xenkbd_in_event {
@@ -252,6 +461,7 @@ union xenkbd_in_event {
struct xenkbd_motion motion;
struct xenkbd_key key;
struct xenkbd_position pos;
+ struct xenkbd_mtouch mtouch;
char pad[XENKBD_IN_EVENT_SIZE];
};
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-07 13:40 +0200 |
| Subject | Re: [Xen-devel] [For Linux 2/4] xen/kbdif: add multi-touch support |
| Message-ID | <ttApb-6sd-9@gated-at.bofh.it> |
| In reply to | #1618598 |
On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Multi-touch fields re-use the page that is used by the other features > which means that you can interleave multi-touch, motion, and key > events. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: Juergen Gross <jgross@suse.com> Juergen
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 10:50 +0200 |
| Message-ID | <ttxKF-4On-1@gated-at.bofh.it> |
| In reply to | #1618590 |
+Juergen On 04/07/2017 11:30 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Hi, all! > > This patch series adds/updates para-virtual device > protocols for Linux Kernel (headers): > o kbdif (multitouch support added) > o sndif - sound (new) > o displif - display (new) > > No changes, but Linux Kernel coding style applied. > > Thank you, > Oleksandr > > Oleksandr Andrushchenko (4): > xen/kbdif: update protocol description > xen/kbdif: add multi-touch support > xen/sndif: add sound-device ABI > xen/displif: add ABI for para-virtual display > > include/xen/interface/io/displif.h | 864 +++++++++++++++++++++++++++++++++++++ > include/xen/interface/io/kbdif.h | 468 ++++++++++++++++++-- > include/xen/interface/io/sndif.h | 803 ++++++++++++++++++++++++++++++++++ > 3 files changed, 2108 insertions(+), 27 deletions(-) > create mode 100644 include/xen/interface/io/displif.h > create mode 100644 include/xen/interface/io/sndif.h >
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-07 13:40 +0200 |
| Subject | Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttApb-6sd-11@gated-at.bofh.it> |
| In reply to | #1618590 |
On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > This is the ABI for the two halves of a para-virtualized > display driver. > > This protocol aims to provide a unified protocol which fits more > sophisticated use-cases than a framebuffer device can handle. At the > moment basic functionality is supported with the intention to extend: > o multiple dynamically allocated/destroyed framebuffers > o buffers of arbitrary sizes > o better configuration options including multiple display support > > Note: existing fbif can be used together with displif running at the > same time, e.g. on Linux one provides framebuffer and another DRM/KMS > > Future extensions to the existing protocol may include: > o allow display/connector cloning > o allow allocating objects other than display buffers > o add planes/overlays support > o support scaling > o support rotation > > Note, that this protocol doesn't use ring macros for > bi-directional exchange (PV calls/9pfs) bacause: > o it statically defines the use of a single page > for the ring buffer > o it uses direct memory access to ring's contents > w/o memory copying > o re-uses the same idea that kbdif/fbif use > which for this use-case seems to be appropriate > > ================================================== > Rationale for introducing this protocol instead of > using the existing fbif: > ================================================== > > 1. In/out event sizes > o fbif - 40 octets > o displif - 40 octets > This is only the initial version of the displif protocol > which means that there could be requests which will not fit > (WRT introducing some GPU related functionality > later on). In that case we cannot alter fbif sizes as we need to > be backward compatible an will be forced to handle those > apart of fbif. > > 2. Shared page > Displif doesn't use anything like struct xenfb_page, but > DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct > xendispl_resp) which is a better and more common way. > Output events use a shared page which only has in_cons and in_prod > and all the rest is used for incoming events. Here struct xenfb_page > could probably be used as is despite the fact that it only has a half > of a page for incoming events which is only 50 events. (consider > something like 60Hz display) > > 3. Amount of changes. > fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE > events, so it looks like it is easier to get fb support into displif > than vice versa. displif at the moment has 6 requests and 1 event, > multiple connector support, etc. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: Juergen Gross <jgross@suse.com> Juergen
[toc] | [prev] | [next] | [standalone]
| From | Julien Grall <julien.grall@arm.com> |
|---|---|
| Date | 2017-04-07 16:00 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttCAF-7Q8-7@gated-at.bofh.it> |
| In reply to | #1618590 |
Hi Oleksandr,
On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
> +/*
> + ******************************************************************************
> + * Back to front events delivery
> + ******************************************************************************
> + * In order to deliver asynchronous events from back to front a shared page is
> + * allocated by front and its granted reference propagated to back via
> + * XenStore entries (evt-ring-ref/evt-event-channel).
> + * This page has a common header used by both front and back to synchronize
> + * access and control event's ring buffer, while back being a producer of the
> + * events and front being a consumer. The rest of the page after the header
> + * is used for event packets.
> + *
> + * Upon reception of an event(s) front may confirm its reception
> + * for either each event, group of events or none.
> + */
> +
> +struct xendispl_event_page {
> + uint32_t in_cons;
> + uint32_t in_prod;
> + uint8_t reserved[56];
> +};
> +
> +#define XENDISPL_EVENT_PAGE_SIZE 4096
This will be always the size of a grant (e.g xen page size), right? If
so, I would prefer if you use XEN_PAGE_SIZE to so we can easily update
Linux in the case Xen is using a different page size.
Note that the Front-end, Backend and Xen may use different page size, so
your drivers would need to cope with that. The current approach is to
always use the page granularity of Xen.
> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE - XENDISPL_IN_RING_OFFS)
> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct xendispl_evt))
> +#define XENDISPL_IN_RING(page) \
> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
> +#define XENDISPL_IN_RING_REF(page, idx) \
> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
> +
> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
>
Cheers,
--
Julien Grall
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 16:10 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttCKm-8a9-23@gated-at.bofh.it> |
| In reply to | #1618814 |
Hi, Julien!
On 04/07/2017 04:50 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>> +/*
>> +
>> ******************************************************************************
>> + * Back to front events delivery
>> +
>> ******************************************************************************
>> + * In order to deliver asynchronous events from back to front a
>> shared page is
>> + * allocated by front and its granted reference propagated to back via
>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>> + * This page has a common header used by both front and back to
>> synchronize
>> + * access and control event's ring buffer, while back being a
>> producer of the
>> + * events and front being a consumer. The rest of the page after the
>> header
>> + * is used for event packets.
>> + *
>> + * Upon reception of an event(s) front may confirm its reception
>> + * for either each event, group of events or none.
>> + */
>> +
>> +struct xendispl_event_page {
>> + uint32_t in_cons;
>> + uint32_t in_prod;
>> + uint8_t reserved[56];
>> +};
>> +
>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>
> This will be always the size of a grant (e.g xen page size), right? If
> so, I would prefer if you use XEN_PAGE_SIZE to so we can easily update
> Linux in the case Xen is using a different page size.
>
> Note that the Front-end, Backend and Xen may use different page size,
> so your drivers would need to cope with that. The current approach is
> to always use the page granularity of Xen.
>
Will the following satisfy the requirement?
#define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>> XENDISPL_IN_RING_OFFS)
>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>> xendispl_evt))
>> +#define XENDISPL_IN_RING(page) \
>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>> +#define XENDISPL_IN_RING_REF(page, idx) \
>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>> +
>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * tab-width: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>>
>
> Cheers,
>
Thank you,
Oleksandr
[toc] | [prev] | [next] | [standalone]
| From | Stefano Stabellini <sstabellini@kernel.org> |
|---|---|
| Date | 2017-04-07 18:40 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttF5v-1hT-1@gated-at.bofh.it> |
| In reply to | #1618821 |
On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
> Hi, Julien!
>
> On 04/07/2017 04:50 PM, Julien Grall wrote:
> > Hi Oleksandr,
> >
> > On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
> > > +/*
> > > +
> > > ******************************************************************************
> > > + * Back to front events delivery
> > > +
> > > ******************************************************************************
> > > + * In order to deliver asynchronous events from back to front a shared
> > > page is
> > > + * allocated by front and its granted reference propagated to back via
> > > + * XenStore entries (evt-ring-ref/evt-event-channel).
> > > + * This page has a common header used by both front and back to
> > > synchronize
> > > + * access and control event's ring buffer, while back being a producer of
> > > the
> > > + * events and front being a consumer. The rest of the page after the
> > > header
> > > + * is used for event packets.
> > > + *
> > > + * Upon reception of an event(s) front may confirm its reception
> > > + * for either each event, group of events or none.
> > > + */
> > > +
> > > +struct xendispl_event_page {
> > > + uint32_t in_cons;
> > > + uint32_t in_prod;
> > > + uint8_t reserved[56];
> > > +};
> > > +
> > > +#define XENDISPL_EVENT_PAGE_SIZE 4096
> >
> > This will be always the size of a grant (e.g xen page size), right? If so, I
> > would prefer if you use XEN_PAGE_SIZE to so we can easily update Linux in
> > the case Xen is using a different page size.
> >
> > Note that the Front-end, Backend and Xen may use different page size, so
> > your drivers would need to cope with that. The current approach is to always
> > use the page granularity of Xen.
> >
> Will the following satisfy the requirement?
> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
It is already defined in include/xen/page.h
> > > +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
> > > +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
> > > XENDISPL_IN_RING_OFFS)
> > > +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
> > > xendispl_evt))
> > > +#define XENDISPL_IN_RING(page) \
> > > + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
> > > +#define XENDISPL_IN_RING_REF(page, idx) \
> > > + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
> > > +
> > > +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
> > > +
> > > +/*
> > > + * Local variables:
> > > + * mode: C
> > > + * c-file-style: "BSD"
> > > + * c-basic-offset: 4
> > > + * tab-width: 4
> > > + * indent-tabs-mode: nil
> > > + * End:
> > > + */
> > >
> >
> > Cheers,
> >
> Thank you,
> Oleksandr
>
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 19:50 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttGbg-21h-5@gated-at.bofh.it> |
| In reply to | #1618954 |
On 04/07/2017 07:36 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 04/07/2017 04:50 PM, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>>>> +/*
>>>> +
>>>> ******************************************************************************
>>>> + * Back to front events delivery
>>>> +
>>>> ******************************************************************************
>>>> + * In order to deliver asynchronous events from back to front a shared
>>>> page is
>>>> + * allocated by front and its granted reference propagated to back via
>>>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>>>> + * This page has a common header used by both front and back to
>>>> synchronize
>>>> + * access and control event's ring buffer, while back being a producer of
>>>> the
>>>> + * events and front being a consumer. The rest of the page after the
>>>> header
>>>> + * is used for event packets.
>>>> + *
>>>> + * Upon reception of an event(s) front may confirm its reception
>>>> + * for either each event, group of events or none.
>>>> + */
>>>> +
>>>> +struct xendispl_event_page {
>>>> + uint32_t in_cons;
>>>> + uint32_t in_prod;
>>>> + uint8_t reserved[56];
>>>> +};
>>>> +
>>>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>>> This will be always the size of a grant (e.g xen page size), right? If so, I
>>> would prefer if you use XEN_PAGE_SIZE to so we can easily update Linux in
>>> the case Xen is using a different page size.
>>>
>>> Note that the Front-end, Backend and Xen may use different page size, so
>>> your drivers would need to cope with that. The current approach is to always
>>> use the page granularity of Xen.
>>>
>> Will the following satisfy the requirement?
>> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
> It is already defined in include/xen/page.h
Thank you, Stefano, but I meant if the change below
will fit the requirement, e.g. what Julien means is:
-#define XENDISPL_EVENT_PAGE_SIZE 4096
+#define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
Julien, does this change work for you?
>
>>>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>>>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>>>> XENDISPL_IN_RING_OFFS)
>>>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>>>> xendispl_evt))
>>>> +#define XENDISPL_IN_RING(page) \
>>>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>>>> +#define XENDISPL_IN_RING_REF(page, idx) \
>>>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>>>> +
>>>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>>>> +
>>>> +/*
>>>> + * Local variables:
>>>> + * mode: C
>>>> + * c-file-style: "BSD"
>>>> + * c-basic-offset: 4
>>>> + * tab-width: 4
>>>> + * indent-tabs-mode: nil
>>>> + * End:
>>>> + */
>>>>
>>> Cheers,
>>>
>> Thank you,
>> Oleksandr
>>
Thank you,
Oleksandr
[toc] | [prev] | [next] | [standalone]
| From | Stefano Stabellini <sstabellini@kernel.org> |
|---|---|
| Date | 2017-04-07 20:00 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttGkV-28n-5@gated-at.bofh.it> |
| In reply to | #1619000 |
On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
> On 04/07/2017 07:36 PM, Stefano Stabellini wrote:
> > On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
> > > Hi, Julien!
> > >
> > > On 04/07/2017 04:50 PM, Julien Grall wrote:
> > > > Hi Oleksandr,
> > > >
> > > > On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
> > > > > +/*
> > > > > +
> > > > > ******************************************************************************
> > > > > + * Back to front events delivery
> > > > > +
> > > > > ******************************************************************************
> > > > > + * In order to deliver asynchronous events from back to front a
> > > > > shared
> > > > > page is
> > > > > + * allocated by front and its granted reference propagated to back
> > > > > via
> > > > > + * XenStore entries (evt-ring-ref/evt-event-channel).
> > > > > + * This page has a common header used by both front and back to
> > > > > synchronize
> > > > > + * access and control event's ring buffer, while back being a
> > > > > producer of
> > > > > the
> > > > > + * events and front being a consumer. The rest of the page after the
> > > > > header
> > > > > + * is used for event packets.
> > > > > + *
> > > > > + * Upon reception of an event(s) front may confirm its reception
> > > > > + * for either each event, group of events or none.
> > > > > + */
> > > > > +
> > > > > +struct xendispl_event_page {
> > > > > + uint32_t in_cons;
> > > > > + uint32_t in_prod;
> > > > > + uint8_t reserved[56];
> > > > > +};
> > > > > +
> > > > > +#define XENDISPL_EVENT_PAGE_SIZE 4096
> > > > This will be always the size of a grant (e.g xen page size), right? If
> > > > so, I
> > > > would prefer if you use XEN_PAGE_SIZE to so we can easily update Linux
> > > > in
> > > > the case Xen is using a different page size.
> > > >
> > > > Note that the Front-end, Backend and Xen may use different page size, so
> > > > your drivers would need to cope with that. The current approach is to
> > > > always
> > > > use the page granularity of Xen.
> > > >
> > > Will the following satisfy the requirement?
> > > #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
> > It is already defined in include/xen/page.h
> Thank you, Stefano, but I meant if the change below
> will fit the requirement, e.g. what Julien means is:
> -#define XENDISPL_EVENT_PAGE_SIZE 4096
> +#define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
> Julien, does this change work for you?
Sure, I think that would be OK. Also using XEN_PAGE_SIZE directly would
be OK.
> > > > > +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
> > > > > +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
> > > > > XENDISPL_IN_RING_OFFS)
> > > > > +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
> > > > > xendispl_evt))
> > > > > +#define XENDISPL_IN_RING(page) \
> > > > > + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
> > > > > +#define XENDISPL_IN_RING_REF(page, idx) \
> > > > > + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
> > > > > +
> > > > > +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
> > > > > +
> > > > > +/*
> > > > > + * Local variables:
> > > > > + * mode: C
> > > > > + * c-file-style: "BSD"
> > > > > + * c-basic-offset: 4
> > > > > + * tab-width: 4
> > > > > + * indent-tabs-mode: nil
> > > > > + * End:
> > > > > + */
> > > > >
> > > > Cheers,
> > > >
> > > Thank you,
> > > Oleksandr
> > >
> Thank you,
> Oleksandr
>
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-07 20:00 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <ttGkV-28n-3@gated-at.bofh.it> |
| In reply to | #1619008 |
On 04/07/2017 08:50 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
>> On 04/07/2017 07:36 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
>>>> Hi, Julien!
>>>>
>>>> On 04/07/2017 04:50 PM, Julien Grall wrote:
>>>>> Hi Oleksandr,
>>>>>
>>>>> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>>>>>> +/*
>>>>>> +
>>>>>> ******************************************************************************
>>>>>> + * Back to front events delivery
>>>>>> +
>>>>>> ******************************************************************************
>>>>>> + * In order to deliver asynchronous events from back to front a
>>>>>> shared
>>>>>> page is
>>>>>> + * allocated by front and its granted reference propagated to back
>>>>>> via
>>>>>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>>>>>> + * This page has a common header used by both front and back to
>>>>>> synchronize
>>>>>> + * access and control event's ring buffer, while back being a
>>>>>> producer of
>>>>>> the
>>>>>> + * events and front being a consumer. The rest of the page after the
>>>>>> header
>>>>>> + * is used for event packets.
>>>>>> + *
>>>>>> + * Upon reception of an event(s) front may confirm its reception
>>>>>> + * for either each event, group of events or none.
>>>>>> + */
>>>>>> +
>>>>>> +struct xendispl_event_page {
>>>>>> + uint32_t in_cons;
>>>>>> + uint32_t in_prod;
>>>>>> + uint8_t reserved[56];
>>>>>> +};
>>>>>> +
>>>>>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>>>>> This will be always the size of a grant (e.g xen page size), right? If
>>>>> so, I
>>>>> would prefer if you use XEN_PAGE_SIZE to so we can easily update Linux
>>>>> in
>>>>> the case Xen is using a different page size.
>>>>>
>>>>> Note that the Front-end, Backend and Xen may use different page size, so
>>>>> your drivers would need to cope with that. The current approach is to
>>>>> always
>>>>> use the page granularity of Xen.
>>>>>
>>>> Will the following satisfy the requirement?
>>>> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>>> It is already defined in include/xen/page.h
>> Thank you, Stefano, but I meant if the change below
>> will fit the requirement, e.g. what Julien means is:
>> -#define XENDISPL_EVENT_PAGE_SIZE 4096
>> +#define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>> Julien, does this change work for you?
> Sure, I think that would be OK. Also using XEN_PAGE_SIZE directly would
> be OK.
>
Great, thanks
>>>>>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>>>>>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>>>>>> XENDISPL_IN_RING_OFFS)
>>>>>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>>>>>> xendispl_evt))
>>>>>> +#define XENDISPL_IN_RING(page) \
>>>>>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>>>>>> +#define XENDISPL_IN_RING_REF(page, idx) \
>>>>>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>>>>>> +
>>>>>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>>>>>> +
>>>>>> +/*
>>>>>> + * Local variables:
>>>>>> + * mode: C
>>>>>> + * c-file-style: "BSD"
>>>>>> + * c-basic-offset: 4
>>>>>> + * tab-width: 4
>>>>>> + * indent-tabs-mode: nil
>>>>>> + * End:
>>>>>> + */
>>>>>>
>>>>> Cheers,
>>>>>
>>>> Thank you,
>>>> Oleksandr
>>>>
>> Thank you,
>> Oleksandr
>>
[toc] | [prev] | [next] | [standalone]
| From | Oleksandr Andrushchenko <andr2000@gmail.com> |
|---|---|
| Date | 2017-04-10 08:10 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <tuAGt-5oC-11@gated-at.bofh.it> |
| In reply to | #1618821 |
On 04/10/2017 09:03 AM, Juergen Gross wrote:
> On 07/04/17 16:02, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 04/07/2017 04:50 PM, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>>>> +/*
>>>> +
>>>> ******************************************************************************
>>>>
>>>> + * Back to front events delivery
>>>> +
>>>> ******************************************************************************
>>>>
>>>> + * In order to deliver asynchronous events from back to front a
>>>> shared page is
>>>> + * allocated by front and its granted reference propagated to back via
>>>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>>>> + * This page has a common header used by both front and back to
>>>> synchronize
>>>> + * access and control event's ring buffer, while back being a
>>>> producer of the
>>>> + * events and front being a consumer. The rest of the page after the
>>>> header
>>>> + * is used for event packets.
>>>> + *
>>>> + * Upon reception of an event(s) front may confirm its reception
>>>> + * for either each event, group of events or none.
>>>> + */
>>>> +
>>>> +struct xendispl_event_page {
>>>> + uint32_t in_cons;
>>>> + uint32_t in_prod;
>>>> + uint8_t reserved[56];
>>>> +};
>>>> +
>>>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>>> This will be always the size of a grant (e.g xen page size), right? If
>>> so, I would prefer if you use XEN_PAGE_SIZE to so we can easily update
>>> Linux in the case Xen is using a different page size.
>>>
>>> Note that the Front-end, Backend and Xen may use different page size,
>>> so your drivers would need to cope with that. The current approach is
>>> to always use the page granularity of Xen.
>>>
>> Will the following satisfy the requirement?
>> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>>
>>>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>>>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>>>> XENDISPL_IN_RING_OFFS)
>>>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>>>> xendispl_evt))
>>>> +#define XENDISPL_IN_RING(page) \
>>>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>>>> +#define XENDISPL_IN_RING_REF(page, idx) \
>>>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>>>> +
>>>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>>>> +
>>>> +/*
>>>> + * Local variables:
>>>> + * mode: C
>>>> + * c-file-style: "BSD"
>>>> + * c-basic-offset: 4
>>>> + * tab-width: 4
>>>> + * indent-tabs-mode: nil
>>>> + * End:
>>>> + */
> I believe you'll send V2 due to the XEN_PAGE_SIZE usage?
yes
>
> Can you then please remove the editor mode settings block in each
> header, too? Those are disliked in the Linux tree.
sure, I will
>
>
> Juergen
Do you mind if I keep your acks for V2 with these changes?
Thank you,
Oleksandr
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-10 08:10 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <tuAGt-5oC-13@gated-at.bofh.it> |
| In reply to | #1619643 |
On 10/04/17 08:06, Oleksandr Andrushchenko wrote:
> On 04/10/2017 09:03 AM, Juergen Gross wrote:
>> On 07/04/17 16:02, Oleksandr Andrushchenko wrote:
>>> Hi, Julien!
>>>
>>> On 04/07/2017 04:50 PM, Julien Grall wrote:
>>>> Hi Oleksandr,
>>>>
>>>> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>>>>> +/*
>>>>> +
>>>>> ******************************************************************************
>>>>>
>>>>>
>>>>> + * Back to front events delivery
>>>>> +
>>>>> ******************************************************************************
>>>>>
>>>>>
>>>>> + * In order to deliver asynchronous events from back to front a
>>>>> shared page is
>>>>> + * allocated by front and its granted reference propagated to back
>>>>> via
>>>>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>>>>> + * This page has a common header used by both front and back to
>>>>> synchronize
>>>>> + * access and control event's ring buffer, while back being a
>>>>> producer of the
>>>>> + * events and front being a consumer. The rest of the page after the
>>>>> header
>>>>> + * is used for event packets.
>>>>> + *
>>>>> + * Upon reception of an event(s) front may confirm its reception
>>>>> + * for either each event, group of events or none.
>>>>> + */
>>>>> +
>>>>> +struct xendispl_event_page {
>>>>> + uint32_t in_cons;
>>>>> + uint32_t in_prod;
>>>>> + uint8_t reserved[56];
>>>>> +};
>>>>> +
>>>>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>>>> This will be always the size of a grant (e.g xen page size), right? If
>>>> so, I would prefer if you use XEN_PAGE_SIZE to so we can easily update
>>>> Linux in the case Xen is using a different page size.
>>>>
>>>> Note that the Front-end, Backend and Xen may use different page size,
>>>> so your drivers would need to cope with that. The current approach is
>>>> to always use the page granularity of Xen.
>>>>
>>> Will the following satisfy the requirement?
>>> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>>>
>>>>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>>>>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>>>>> XENDISPL_IN_RING_OFFS)
>>>>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>>>>> xendispl_evt))
>>>>> +#define XENDISPL_IN_RING(page) \
>>>>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>>>>> +#define XENDISPL_IN_RING_REF(page, idx) \
>>>>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>>>>> +
>>>>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>>>>> +
>>>>> +/*
>>>>> + * Local variables:
>>>>> + * mode: C
>>>>> + * c-file-style: "BSD"
>>>>> + * c-basic-offset: 4
>>>>> + * tab-width: 4
>>>>> + * indent-tabs-mode: nil
>>>>> + * End:
>>>>> + */
>> I believe you'll send V2 due to the XEN_PAGE_SIZE usage?
> yes
>>
>> Can you then please remove the editor mode settings block in each
>> header, too? Those are disliked in the Linux tree.
> sure, I will
>>
>>
>> Juergen
> Do you mind if I keep your acks for V2 with these changes?
You can keep them, of course.
Juergen
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-04-10 08:10 +0200 |
| Subject | Re: [For Linux 4/4] xen/displif: add ABI for para-virtual display |
| Message-ID | <tuAGt-5oC-7@gated-at.bofh.it> |
| In reply to | #1618821 |
On 07/04/17 16:02, Oleksandr Andrushchenko wrote:
> Hi, Julien!
>
> On 04/07/2017 04:50 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
>>> +/*
>>> +
>>> ******************************************************************************
>>>
>>> + * Back to front events delivery
>>> +
>>> ******************************************************************************
>>>
>>> + * In order to deliver asynchronous events from back to front a
>>> shared page is
>>> + * allocated by front and its granted reference propagated to back via
>>> + * XenStore entries (evt-ring-ref/evt-event-channel).
>>> + * This page has a common header used by both front and back to
>>> synchronize
>>> + * access and control event's ring buffer, while back being a
>>> producer of the
>>> + * events and front being a consumer. The rest of the page after the
>>> header
>>> + * is used for event packets.
>>> + *
>>> + * Upon reception of an event(s) front may confirm its reception
>>> + * for either each event, group of events or none.
>>> + */
>>> +
>>> +struct xendispl_event_page {
>>> + uint32_t in_cons;
>>> + uint32_t in_prod;
>>> + uint8_t reserved[56];
>>> +};
>>> +
>>> +#define XENDISPL_EVENT_PAGE_SIZE 4096
>>
>> This will be always the size of a grant (e.g xen page size), right? If
>> so, I would prefer if you use XEN_PAGE_SIZE to so we can easily update
>> Linux in the case Xen is using a different page size.
>>
>> Note that the Front-end, Backend and Xen may use different page size,
>> so your drivers would need to cope with that. The current approach is
>> to always use the page granularity of Xen.
>>
> Will the following satisfy the requirement?
> #define XENDISPL_EVENT_PAGE_SIZE XEN_PAGE_SIZE
>
>>> +#define XENDISPL_IN_RING_OFFS (sizeof(struct xendispl_event_page))
>>> +#define XENDISPL_IN_RING_SIZE (XENDISPL_EVENT_PAGE_SIZE -
>>> XENDISPL_IN_RING_OFFS)
>>> +#define XENDISPL_IN_RING_LEN (XENDISPL_IN_RING_SIZE / sizeof(struct
>>> xendispl_evt))
>>> +#define XENDISPL_IN_RING(page) \
>>> + ((struct xendispl_evt *)((char *)(page) + XENDISPL_IN_RING_OFFS))
>>> +#define XENDISPL_IN_RING_REF(page, idx) \
>>> + (XENDISPL_IN_RING((page))[(idx) % XENDISPL_IN_RING_LEN])
>>> +
>>> +#endif /* __XEN_PUBLIC_IO_DISPLIF_H__ */
>>> +
>>> +/*
>>> + * Local variables:
>>> + * mode: C
>>> + * c-file-style: "BSD"
>>> + * c-basic-offset: 4
>>> + * tab-width: 4
>>> + * indent-tabs-mode: nil
>>> + * End:
>>> + */
I believe you'll send V2 due to the XEN_PAGE_SIZE usage?
Can you then please remove the editor mode settings block in each
header, too? Those are disliked in the Linux tree.
Juergen
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web