Re: [PATCH] Paravirt framebuffer backend tools [2/5]

[Steven Smith <sos22-xen@srcf.ucam.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2861 bytes --]

> >> How to best map buttons from VNC and SDL to input beyond the first
> >> three?  If we can find a workable answer for that, providing for more
> >> buttons should be trivial.
> > *shrug* We might as well just send input layer codes across the ring
> > buffer and do the translation in the backend.  That makes the Linux
> > frontend easier and doesn't make other operating systems any harder.
> > If we later find that some other operating system supports buttons
> > which the input layer doesn't then we can figure out what to do with
> > them then; provided we make the frontend discard buttons it doesn't
> > understand it should be trivial to do this in a backwards compatible
> > way.
> The input layer treats mouse buttons just like keys.  If we use its
> button encoding, we can just as well use XENKBD_TYPE_KEY and drop
> XENKBD_TYPE_BUTTON.  Any objections?
Choosing the correct encoding for key events is (as we've so recently
demonstrated) non-trivial, so I think I'd like to avoid tying it too
closely to the encoding for mouse events, if it's all the same to you.

> >> >> +
> >> >> +	event.type = XENFB_TYPE_SET_EVENTS;
> >> >> +	event.set_events.flags = XENFB_FLAG_UPDATE;
> >> >> +	if (xenfb_fb_event(xenfb, &event))
> >> >> +		goto error;
> >> > Would it make sense to negotiate this via xenbus at connection setup
> >> > time?  It's not like it's likely to change during the life of the
> >> > buffer.
> >> Can you point to an example of such a negotiation between a frontend
> >> and a backend via xenbus?
> > The netif feature flags are probably the most obvious example.  For
> > instance, to turn on copy rx mode, you first have the backend put
> > feature-rx-copy=1 in its xenstore area, and then when the frontend
> > connects it notices this and puts request-rx-copy=1 in its area.  The
> > backend reads this out as part of connection setup, and rx copy mode
> > is turned on.
> >
> > The equivalent in this case would be for the backend to set
> > request-update=1 in its area when it starts, and then for the frontend
> > to set provides-update=1 if appropriate.
> I'll look into this when/if I find the time.
Thanks.

> > Of course, this sort of thing only works well for flags which don't
> > change while the buffer is live.  I'd certainly expect
> > XENFB_FLAG_UPDATE to fit into that category, but perhaps you have some
> > future plans which wouldn't work well with this?
> I can't guarantee we won't need a mechanism to switch things during
> operation at some time, but neither can I guarantee that
> XENFB_TYPE_SET_EVENTS as it is now will do for that then.
> 
> Instead of attempting to cover all possible future cases of option
> negotiation / mode switching, let's just provide for what we need now
> in a simple and reasonably general way.
Good plan.

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel