qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Steffen Görtz" <contrib@steffen-goertz.de>,
	qemu-devel@nongnu.org, "Jim Mussared" <jim@groklearning.com>,
	"Julia Suvorova" <jusual@mail.ru>,
	"Joel Stanley" <joel@jms.id.au>
Subject: Re: [Qemu-devel] [RFC] qapi: command category to stimulate high-level machine devices
Date: Thu, 7 Jun 2018 13:34:08 +0100	[thread overview]
Message-ID: <20180607123408.GH19032@stefanha-x1.localdomain> (raw)
In-Reply-To: <317e07c2-b1d8-b782-9a0b-88ece8600164@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

On Mon, Jun 04, 2018 at 05:14:25PM -0500, Eric Blake wrote:
> On 06/01/2018 10:16 PM, Steffen Görtz wrote:
> > From: Steffen Goertz <contrib@steffen-goertz.de>
> > 
> > Add a new category "stimulate" to host commands that
> > act upon high-level devices associated with machines/boards.
> > 
> > This is patch is part of an effort to add support for BBC:microbit
> > educational computer to QEMU.
> > 
> > The microbit board, as many other microcontroller boards,
> > contains typical trivial (digital) input and output options such as buttons and LEDs,
> > but also more sophiscated possibilities such as analog inputs and
> 
> s/sophiscated/sophisticated/
> 
> > complex dedicated sensor ICs that are connected to the microbit machine
> > by means of inter-ic bus (i2c).
> > These devices interact with peripheral devices of the microcontroller
> > in use, for example with the GPIO peripheral of the used NRF51.
> > 
> > One aim of our efforts is to create a user interface that models the
> > look and feel of the physical microbit board and lets the user interact
> > with its inputs and provide feedback on its outsputs.
> 
> s/outsputs/outputs/
> 
> > 
> > For this it is necessary to transmit user inputs such as the pressing of a
> > button to the machine.
> > In return, when the state of an output is changed on the machine, this
> > change needs to be reflected in the user interface.
> > 
> > At the moment, there are only a few QMP commands that provide user input to the
> > machine, eg. send-keys, input-button. These commands require very
> > high-level concepts, which are not really suitable for applications that
> > microcontrollers are typically used in in.
> > 
> > This RFC is meant to start a discussion on how to provide stimuli to
> > low-complex inputs and outputs typically found in embedded
> > microcontroller applications. To the best of my knowledge, there are
> > currently no examples of how to provide such stimuli to either SoC
> > device peripheral or machine level concepts like pushbuttons and LEDs.
> > 
> > To my understanding, the following concepts/apis are needed:
> > - QMP commands to send stimuli to machine level concepts like
> > pushbuttons
> > - Machine level devices that receive these stimuli and act as an adapter
> > to manipulate the associated SoC peripheral devices
> > - For outputs, machine level devices are needed that observe changes in
> > SoC peripherals and emit QMP events that clients can receive
> > 
> > This patch adds a new qmp command "buttons-set-state" to update the
> > push-down state of arbitrarily identified buttons (string identifier).
> 
> An arbitrary string has the most flexibility, but also the least
> discoverability.  Is there any way to enumerate which strings are valid,
> and/or make the button names an enum instead of an open-coded string?

The button names could defined by an enum.

Which button names are valid with a particular machine type can't be
expressed in the schema AFAIK.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

      reply	other threads:[~2018-06-07 12:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-02  3:16 [Qemu-devel] [RFC] qapi: command category to stimulate high-level machine devices Steffen Görtz
2018-06-02  7:26 ` no-reply
2018-06-02  7:30 ` no-reply
2018-06-02  7:35 ` no-reply
2018-06-04 22:14 ` Eric Blake
2018-06-07 12:34   ` Stefan Hajnoczi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180607123408.GH19032@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=contrib@steffen-goertz.de \
    --cc=eblake@redhat.com \
    --cc=jim@groklearning.com \
    --cc=joel@jms.id.au \
    --cc=jusual@mail.ru \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).