[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1103141135170.3382@kaball-desktop>
Date: Mon, 14 Mar 2011 11:39:15 +0000
From: Stefano Stabellini <stefano.stabellini@...citrix.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
Olaf Hering <olaf@...fle.de>
Subject: Re: [PATCH] input/xen-fbfront: advertise either absolute or relative
coordinates
On Sun, 13 Mar 2011, Dmitry Torokhov wrote:
> Hi Stefano,
>
> On Fri, Mar 11, 2011 at 11:30:10AM +0000, Stefano Stabellini wrote:
> > From: Olaf Hering <olaf@...fle.de>
> >
> > A virtualized display device is usually viewed with the vncviewer
> > application, either by 'xm vnc domU' or with vncviewer localhost:port.
> > vncviewer and the RFB protocol provides absolute coordinates to the
> > virtual display. These coordinates are either passed through to a PV
> > guest or converted to relative coordinates for a HVM guest.
> >
> > A PV guest receives these coordinates and passes them to the kernels
> > evdev driver. There it can be picked up by applications such as the
> > xorg-input drivers. Using absolute coordinates avoids issues such as
> > guest mouse pointer not tracking host mouse pointer due to wrong mouse
> > acceleration settings in the guests X display.
> >
> > Advertise either absolute or relative coordinates to the input system
> > and the evdev driver, depending on what dom0 provides. The xorg-input
> > driver prefers relative coordinates even if a devices provides both.
>
> So if I am reading this correctly the original version handled changes
> in backend capabilities and could switch between delivering either
> relative or absolute coordinates. The new version selects the
> capabilities at boot time and sticks with them. Was it really the
> intended behavior?
Yes, as Olaf said, we prefer absolute coordinates so we want to make
sure absolute coordinates are the ones that are used if both are
available.
> BTW, drivers/input is intended for core input and handlers stuff with
> drivers suppsed to be in drivers/input/<type>. Would you mind if I moved
> this driver to drivers/input/misc?
I am OK with it.
Konrad, any comments on this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists