From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Smith Subject: Re: [PATCH] Paravirt framebuffer backend tools [2/5] Date: Sat, 7 Oct 2006 10:42:56 +0100 Message-ID: <20061007094256.GA2028@cam.ac.uk> References: <20060904090150.GC4812@cam.ac.uk> <87y7s168k2.fsf@pike.pond.sub.org> <20061002090145.GA3576@cam.ac.uk> <87y7rwyy6q.fsf@pike.pond.sub.org> <20061005183346.GB4998@cam.ac.uk> <87bqopwn5c.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0950199721==" Return-path: In-Reply-To: <87bqopwn5c.fsf@pike.pond.sub.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Markus Armbruster Cc: aliguori , Jeremy Katz , xen-devel , sos22@srcf.ucam.org List-Id: xen-devel@lists.xenproject.org --===============0950199721== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >> 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 =3D XENFB_TYPE_SET_EVENTS; > >> >> + event.set_events.flags =3D 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=3D1 in its xenstore area, and then when the frontend > > connects it notices this and puts request-rx-copy=3D1 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=3D1 in its area when it starts, and then for the frontend > > to set provides-update=3D1 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. >=20 > 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. --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFJ3agO4S8/gLNrjcRAjKOAKCCDKXlJz8KWehJ9MujGdxd49f+oQCfdbdN dKijl5+aI6FJacX8yNZvCY0= =2DGP -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============0950199721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0950199721==--