----- Original Message ----- > > > Oh, I get you wrong. So you really think we can modify existing message > > formats based on caps? > > > That looks a bit confusing to me, and it is not clear how that should > > > work because message marshallers are auto-generated? > > > > I don't remember. In the case of clipboard selection, it was certainly > > easier since > > we don't use the marshaller atm. > > Perhaps have a second marshaller function version for this case would work? > > how does that work (can't see it)? > > Simply adding a new message solve the problem easily.
Yes, I think you should use a new message on input channel. In fact, your first protocol change made more sense for your needs, iirc. > > > >> that's irrelevant for the protocol change. You can also convert most > > >> XT scancode to utf... > > > > > > no, you can't do that (because you do not know the keymap)! > > > You can do it for US keymap - but most of us do not use that keymap. > > > > right, but it is assumed the server/vm have the keymap (or default). > > It can convert to utf. That's what happen if i open gedit and type a key. > > utf > > conversion is irrelevant to your change. It's just a keysym you want to > > send. > > What you do with it, the protocol doesn't care. > > Not everything is a VM (there is no server side keymap in spiceterm). But even *userspace* x11 or weston spice server handle keymaps. You could too, using xkb common. > > > The day the protocol send input strings, then it can be said it will be > > utf8 > > encoded. > > > > > > > I need utf8 and special/function keys. Using keysyms you get both. > > > > I got that. > > > > >> extension will not be relevant for typical client/vm usage (or even > > >> x11 & weston > > >> server) that Spice is targetting, and I think you could use that > > >> arbitrary utf8 string input approach instead. But I don't want to > > >> force you to do it. We can also accept extensions to the protocol that > > >> are not > > relevant for VM. > > > > > > Great! > > > > > >> > > > It is still not clear to me what patch do you prefer - vdagent > > >> > > > protocol extension or the input channel extension? > > >> > > > > >> > > In your case, a gdk_keyval message, the input channel. > > >> > > > >> > or better 'x11_keysym' message? > > >> > > >> You are using it with gdk constant in client and spiceterm, but gdk > > >> keysyms seems to be exact mapping of x11. So either we decide to > > >> follow x11 or gdk. I would tend to say Gdk, which is more > > >> cross-platform (even though it's in fact just x11 atm). > > > > > > But the gdk docs simply references to the x11 docs, so I guess x11 is the > > source. > > > The also mention that they keep that in sync with x11. > > > > yeah, and scratch what I said, X11 makes more sense has it is a protocol, > > regardless of the platform. > > > > So you have enough to update your patches? > > I still have no idea how to generate 2 marshallers for one protocol message? That might be a marshaller limitation. Anyway, since you could add a new message, you can skip that. _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
