From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYViD-0003A1-Qc for qemu-devel@nongnu.org; Fri, 11 Apr 2014 03:17:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYVi7-00038V-Mi for qemu-devel@nongnu.org; Fri, 11 Apr 2014 03:17:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYVi7-00038Q-FH for qemu-devel@nongnu.org; Fri, 11 Apr 2014 03:17:15 -0400 Message-ID: <1397200629.22291.21.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Fri, 11 Apr 2014 09:17:09 +0200 In-Reply-To: <20140410145603.GA21110@redhat.com> References: <1397120874-17166-1-git-send-email-kraxel@redhat.com> <1397120874-17166-6-git-send-email-kraxel@redhat.com> <20140410110621.GD19546@redhat.com> <1397132537.16790.116.camel@nilsson.home.kraxel.org> <20140410145603.GA21110@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, Anthony Liguori Hi, > > It's not different from other input devices. No buffer space -> drop > > event. What else do you think should happen? We could signal "you lost > > events" to the guest, but I suspect that buys us nothing. Other input > > devices don't have that capability, so guests are likely not prepared to > > handle the situation. > > For assigned device input events, how about we don't read events off the > input device file if there's nowhere to put them? That'll just offload the problem to the kernel. > For things like sync that qemu generates, I suspect it's a good idea > to buffer them in QEMU otherwise guest will get out of sync, right? Grouping things makes sense indeed. Mouse movements for example are reported as three events: one for the x axis, one for the y axis, and the sync. We should report either all three or none of them to the guest to avoid confusion. I'll think about how to do that best. > I'm also pretty sure whoever's running the hypervisor does not > want to see the fprintf. I'll drop it. Or maybe better make it a tracepoint. cheers, Gerd