| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Paravirt framebuffer backend tools [2/5]
> >> 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.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home