qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Laurent Vivier <laurent@vivier.eu>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC,Draft] ui: add an embedded Barrier client
Date: Wed, 28 Aug 2019 11:07:53 +0200	[thread overview]
Message-ID: <20190828090753.ho2stm7ppzej4zcb@sirius.home.kraxel.org> (raw)
In-Reply-To: <79ea4476-f2ae-4b6f-1f65-48de3b0ffebd@vivier.eu>

  Hi,

> >> +        p = write_short(ib, p, 1920); /* width */
> >> +        p = write_short(ib, p, 1080); /* height */
> > 
> > Hmm.
> > 
> > This is the screen size I guess?  Which you don't know ...
> > What this is used for?
> > Should we maybe use INPUT_EVENT_ABS_MAX here?
> > 
> 
> Yes, it's screen size but we can't use INPUT_EVENT_ABS_MAX.
> 
> In fact Barrier can manage more than 2 displays:
> 
>    0            x1           x2           x3
> 
> 0  +------------+------------+------------+---
>    |            |            |            |
>    |  localhost |    VM-1    |   VM-2     |
>    |            |            |            |
> y1 +------------+------------+------------+---
>    |            |            |            |
>    | remotehost |            |            |
>    |            |            |            |
> y2 +------------+------------+------------+---
>    |            |            |            |
> 
> So Barrier will send events to localhost while x(mouse) is between 0 and
> x1, to VM-1 while it is between x1 and x2, and to VM-2 between x2 and
> x3. So we need to know the size of the display to have x2.

Ok, I see.

> Normally when the barrier client runs into an OS it intercepts the
> screen resizing information and send them to the server. In our case we
> cannot (for instance if we use a vfio display)

Yes, for the vfio case we can't (unless it is a vgpu).

Otherwise looking up the DisplaySurface (via QemuConsole) and checking
the size should work.  Not a priority given that vfio is probably the
most interesting use case.

How does barrier send input events to physical machines btw?

> but I plan to add
> properties to the input-barrier object to provide the information at
> least statically.

Makes sense.

> The barrier server runs only on the machine with the mouse and the
> keyboard. Other machines have normally the barrier client daemon to
> inject the mouse and keyboard events in the OS.

Ok.

> I will try to add a keyboard remapping as we have with VNC because it
> doesn't work well with my french keyboard (AZERTY). Or perhaps I can use
> the "button" id instead of the keyid but I don't now how to map the
> value to a qcode.

Depends on how the button id is defined.  If it is one of the usual
keycodes it should be easy and should work better than reverse mapping.

cheers,
  Gerd



  reply	other threads:[~2019-08-28  9:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 19:25 [Qemu-devel] [RFC,Draft] ui: add an embedded Barrier client Laurent Vivier
2019-08-28  6:11 ` Gerd Hoffmann
2019-08-28  8:13   ` Laurent Vivier
2019-08-28  9:07     ` Gerd Hoffmann [this message]
2019-08-28 20:58       ` Laurent Vivier

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=20190828090753.ho2stm7ppzej4zcb@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=berrange@redhat.com \
    --cc=laurent@vivier.eu \
    --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).