On Fri, Apr 20, 2012 at 01:59:05AM +0200, Marc-André Lureau wrote:
Hi
Now that I implemented it a bit more correctly, using a timer, and
splitting the in two patches, I realize that it doesn't work with
windows. Windows expect to receive several key press events
apparently. Hans, the hack
On 04/19/2012 02:58 PM, Marc-André Lureau wrote:
On Thu, Apr 19, 2012 at 9:30 AM, Yonit Halperinyhalp...@redhat.com wrote:
The latency factor is in my TODO (see cover letter).
I use ioctl(socket, TIOCOUTQ) in order to find how many bytes are pending in
the tcp snd buffer, in addition to the
Hi
On Sun, Apr 22, 2012 at 9:40 AM, Alon Levy al...@redhat.com wrote:
On Fri, Apr 20, 2012 at 01:59:05AM +0200, Marc-André Lureau wrote:
So it seems like we should keep sending repeat key press in fact. And
it's probably better to rely on client-side repeat, since letting the
server handling
On Sun, Apr 22, 2012 at 10:39 AM, Yonit Halperin yhalp...@redhat.com wrote:
A top with N bytes sent
This is the simpler mechanism I have in mind: the client receives a
start mark knowing N bytes are following that were sent directly (in
burst). Once the N bytes are received the client can
On Sun, Apr 22, 2012 at 03:16:20PM +0200, Marc-André Lureau wrote:
Hi
On Sun, Apr 22, 2012 at 9:40 AM, Alon Levy al...@redhat.com wrote:
On Fri, Apr 20, 2012 at 01:59:05AM +0200, Marc-André Lureau wrote:
So it seems like we should keep sending repeat key press in fact. And
it's probably
On 04/22/2012 04:23 PM, Marc-André Lureau wrote:
On Sun, Apr 22, 2012 at 10:39 AM, Yonit Halperinyhalp...@redhat.com wrote:
A top with N bytes sent
This is the simpler mechanism I have in mind: the client receives a
start mark knowing N bytes are following that were sent directly (in
