Re: [patch 0/2] vdagent KEYVAL extension

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry, I'll stop replying to each of you mails, because it becomes incoherent and hard to follow.

Either try to summarize and wait for reply, or let's discuss it on IRC.

----- Original Message -----
> 
> 
> ----- Original Message -----
> > > If you really want to send scancode, do it the same way as "Data
> > > key_scancode"
> > > for arbitrary sequence.
> > 
> > will try.
> > 
> > > Why did you drop the flags in the end?
> > 
> > The information can be generated on the server side, so there is no real
> > need
> > to send it over the wire.
> 
> Not all the flags you proposed.
> 
> >  
> > > > Another advantage is that a client could request scancode generation
> > > > at server side.
> > > > This is useful for the javascript/java client, because they do not
> > > > have access to scancodes.
> > > >
> > > > The server (qemu) can synthesize the scancode from the keysym (code
> > > > for that already exists in qemu for vnc).
> > > 
> > > I think I understand what you mean, even though I think it becomes weird
> > > server
> > > cases...
> > 
> > The point is that we already have the code in qemu, and there is not really
> > an other
> > solutions for the javascript client (or is there a better way to do it?).
> 
> I don't follow you.
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]