From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mjea3-0001qh-3X for qemu-devel@nongnu.org; Fri, 04 Sep 2009 15:36:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjeZx-0001qH-EQ for qemu-devel@nongnu.org; Fri, 04 Sep 2009 15:36:17 -0400 Received: from [199.232.76.173] (port=53591 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjeZx-0001qE-AF for qemu-devel@nongnu.org; Fri, 04 Sep 2009 15:36:13 -0400 Received: from smtp-out.google.com ([216.239.45.13]:33901) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MjeZw-0008F5-LU for qemu-devel@nongnu.org; Fri, 04 Sep 2009 15:36:13 -0400 Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id n84Ja8sj028388 for ; Fri, 4 Sep 2009 12:36:08 -0700 Received: from bwz12 (bwz12.prod.google.com [10.188.26.12]) by spaceape7.eur.corp.google.com with ESMTP id n84Ja55w020692 for ; Fri, 4 Sep 2009 12:36:06 -0700 Received: by bwz12 with SMTP id 12so863222bwz.20 for ; Fri, 04 Sep 2009 12:36:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1600c7720909040258i2fa51f31g72dafb308ef90c25@mail.gmail.com> References: <1600c7720909020555i3a16970eq35e753b33ebf3f78@mail.gmail.com> <60cad3f0909021632n6e7528cam479720b74bb61c67@mail.gmail.com> <1600c7720909040258i2fa51f31g72dafb308ef90c25@mail.gmail.com> Date: Fri, 4 Sep 2009 12:36:05 -0700 Message-ID: <60cad3f0909041236hd0463d3hfc28f4b2c32275a1@mail.gmail.com> Subject: Re: [Qemu-devel] How does QEMU kernel receive any input events from host OS From: David Turner Content-Type: multipart/alternative; boundary=0016e65aedd86f75e70472c59cfa List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amey Moghe Cc: qemu-devel --0016e65aedd86f75e70472c59cfa Content-Type: text/plain; charset=ISO-8859-1 I think you are confused about what clients/servers are in VNC. On Fri, Sep 4, 2009 at 2:58 AM, Amey Moghe wrote: > Hello, > > Thanks for the details.I understood how any input event is processed. > But if I pressed a key in guest OS environment You never "press a key in a guest OS environment", the guest doesn't have access to a real keyboard. > then how does client > i.e. guest OS ( with reference to VNC server ) come to know that it > has to send key_event to VNC server? The guest OS is not a VNC client at all. The qemu program implements a VNC server, that can be accessed from VNC clients running on the host, or even from different machines, but that is totally oblivious to the guest OS. A VNC Client is a standalone application, which generally converts user input into RFB protocol messages, which are then sent to the VNC server (running in QEMU), which translates them into emulated hardware i/o. The guest OS doesn't know if the user is really using a VNC client, the qemu SDL frontend, or anything else, it just believes there was some hardware activity. > Does client through qemu, > recognise it either from X server running on host OS (e.g. linux ) or > directly from host OS's kernel ? > > I don't really understand this question, but if you want to know how a typical VNC client translates a real user event into a VNC message sent to the server, you should read the RFB protocol specification. Try http://en.wikipedia.org/wiki/RFB_protocolfor a start. > > Thanks, > Amey. > > On 9/3/09, David Turner wrote: > > the QEMU frontend (e.g. the VNC server or the SDL window) is in charge of > > translating user events > > into emulated hardware ones. Most generally, this will mean emulating a > > keyboard or mouse IRQ > > and the associated i/o protocol. Exact details depend on which hardware > you > > want to emulate. > > > > For example, when emulating a PC with PS/2 keyboard and mouse, the code > in > > hw/ps2.c will be used. > > > > Here's a concrete example: > > > > - The VNC server receives packets from the client (see > > protocol_client_msg in vnc.c). > > Some of them correspond to keyboard events (processed in key_event() > in > > the same file), > > which end up calling kbd_put_keycode() after translating the VNC > > keycode/state into > > a different key scancode. > > > > > > - kbd_put_keycode() is defined in vl.c and calls the hardware-specific > > keycode translator. > > > > > > - For PC emulation, this happens to be ps2_put_keycode() defined in > > hw/ps2.c, and > > registered at startup by ps2_kbd_init() in the same file. It probably > is > > a different function > > for different emulated hardware. > > > > > > - The implementation of ps2_put_keycode() will end up enqueue-ing a > > keycode into > > a queue then raising an IRQ. > > > > - The guest kernel responds to the IRQ by running its keyboard driver > > code, the latter > > will try to read data from the PS/2 queue > > > > > > The SDL front-end receives user events differently, but still ends up > > calling kbd_put_keycode(). > > Same thing happens for mouse events, and about anything that needs to > > emulate hardware > > (e.g. serial/usb/bluetooth/etc...) but implementations and specifics may > > differ. > > > > Hope this helps > > > > On Wed, Sep 2, 2009 at 5:55 AM, Amey Moghe wrote: > > > >> Hello all, > >> > >> I am new to QEMU.While reading about qemu , I came across one statement: > >> "QEMU does not depend on the presence of graphical output methods on the > >> host system. Instead, it allows one to access the screen of the guest OS > >> via > >> VNC. It can also use an emulated serial line, without any screen, with > >> applicable operating systems." on following link : > >> > >> http://en.wikipedia.org/wiki/QEMU > >> > >> So please can anybodys tell me how does qemu use VNC server for > receiving > >> events and if yes then how does it receive events from host OS? Or is > >> there > >> any other way with which QEMU receives input events from host OS? > > > > > --0016e65aedd86f75e70472c59cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think you are confused about what clients/servers are in VNC.

On Fri, Sep 4, 2009 at 2:58 AM, Amey Moghe <amey1288@gmail.com&g= t; wrote:
Hello,

Thanks for the details.I understood how any input event is processed.
But if I pressed a key in guest OS environment

You nev= er "press a key in a guest OS environment", the guest doesn't= have access
to a real keyboard.
=A0
then how does client
i.e. guest OS ( with reference to VNC server ) =A0 come to know that it
has to send key_event to VNC server?

The guest OS is n= ot a VNC client at all. The qemu program implements a VNC server,
that c= an be accessed from VNC clients running on the host, or even from different= machines,
but that is totally oblivious to the guest OS.

A VNC Client is a sta= ndalone application, which generally converts user input into RFB
protoc= ol messages, which are then sent to the VNC server (running in QEMU), which= translates
them into emulated hardware i/o. The guest OS doesn't know if the user = is really using a
VNC client, the qemu SDL frontend, or anything else, i= t just believes there was some hardware
activity.
=A0
Does client through qemu,
recognise it either from X server running on host OS (e.g. linux ) or
directly from host OS's kernel ?


I don't really understand this question, but = if you want to know how a typical VNC client
translates a real user even= t into a VNC message sent to the server, you should read the
RFB protoco= l specification. Try = http://en.wikipedia.org/wiki/RFB_protocol for a start.
=A0

Thanks,
Amey.

On 9/3/09, David Turner <digit@googl= e.com> wrote:
> the QEMU frontend (e.g. the VNC server or the SDL window) is in charge= of
> translating user events
> into emulated hardware ones. Most generally, this will mean emulating = a
> keyboard or mouse IRQ
> and the associated i/o protocol. Exact details depend on which hardwar= e you
> want to emulate.
>
> For example, when emulating a PC with PS/2 keyboard and mouse, the cod= e in
> hw/ps2.c will be used.
>
> Here's a concrete example:
>
> =A0 =A0- The VNC server receives packets from the client (see
> =A0 =A0protocol_client_msg in vnc.c).
> =A0 =A0Some of them correspond to keyboard events (processed in key_ev= ent() in
> =A0 =A0the same file),
> =A0 =A0which end up calling kbd_put_keycode() after translating the VN= C
> =A0 =A0keycode/state into
> =A0 =A0a different key scancode.
>
>
> =A0 =A0- kbd_put_keycode() is defined in vl.c and calls the hardware-s= pecific
> =A0 =A0keycode translator.
>
>
> =A0 =A0- For PC emulation, this happens to be ps2_put_keycode() define= d in
> =A0 =A0hw/ps2.c, and
> =A0 =A0registered at startup by ps2_kbd_init() in the same file. It pr= obably is
> =A0 =A0a different function
> =A0 =A0for different emulated hardware.
>
>
> =A0 =A0- The implementation of ps2_put_keycode() will end up enqueue-i= ng a
> =A0 =A0keycode into
> =A0 =A0a queue then raising an IRQ.
>
> =A0 =A0- The guest kernel responds to the IRQ by running its keyboard = driver
> =A0 =A0code, the latter
> =A0 =A0will try to read data from the PS/2 queue
>
>
> The SDL front-end receives user events differently, but still ends up<= br> > calling kbd_put_keycode().
> Same thing happens for mouse events, and about anything that needs to<= br> > emulate hardware
> (e.g. serial/usb/bluetooth/etc...) but implementations and specifics m= ay
> differ.
>
> Hope this helps
>
> On Wed, Sep 2, 2009 at 5:55 AM, Amey Moghe <amey1288@gmail.com> wrote:
>
>> Hello all,
>>
>> I am new to QEMU.While reading about qemu , I came across one stat= ement:
>> "QEMU does not depend on the presence of graphical output met= hods on the
>> host system. Instead, it allows one to access the screen of the gu= est OS
>> via
>> VNC. It can also use an emulated serial line, without any screen, = with
>> applicable operating systems." on following link :
>>
>> ht= tp://en.wikipedia.org/wiki/QEMU
>>
>> So please can anybodys tell me how does qemu use VNC server for re= ceiving
>> events and if yes then how does it receive events from host OS? Or= is
>> there
>> any other way with which QEMU receives input events from host OS?<= br> >



--0016e65aedd86f75e70472c59cfa--