Re: [Qemu-devel] console muti-head some more design input

[John Baboval]

On 11/26/2013 11:29 PM, Dave Airlie wrote:
> On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann <address@hidden> wrote:
> >    Hi,
> >
> > > > While thinking about this:  A completely different approach to tackle
> > > > this would be to implement touchscreen emulation.  So we don't have a
> > > > single usb-tablet, but multiple (one per display) touch input devices.
> > > > Then we can simply route absolute input events from this display as-is
> > > > to that touch device and be done with it.  No need to deal with
> > > > coordinate transformations in qemu, the guest will deal with it.
> > > This is a nice dream, except you'll find the guest won't deal with it
> > > very well, and you'll have all kinds of guest scenarios to link up
> > > that touchscreen a talks to monitor a etc.
> > Ok, scratch the idea then.
> >
> > I don't have personal experience with this,
> > no touch capable displays here.
> Hmm I think we get to unscratch this idea,
>
> After looking into this a bit more I think we probably do need
> something outside the gpu to handle this.
>
> The problem is that there are two scenarios for a GPU multi-head,
>
> a) one resource - two outputs, the second output has an offset to
> scanout into the resource
> b) two resources - two outputs, both outputs have a 0,0 into their
> respective resources.
>
> So the GPU doesn't have this information in all cases on what the
> input device configuration should be,
> Neither do we have anyway in the guests to specify this relationship
> at the driver level.

There is a third, likely option:

 c) one resource - two outputs, the second output's scanout offset 
isn't the same as the logical offset from the perspective of the input 
device

There are two possible solutions to this, both of which I have added 
interfaces for. (I really should hurry up and send out patches....)

The individual logical display offsets can be provided by the UI, and 
pushed into the guest, or the guest driver can push the offsets down.  
So if the UI provides absolute coordinates normalized to the individual 
displays, and the offsets are stored in the QemuConsole, then the input 
layer can do the math as Gerd suggested. It just requires one additional 
coordinate set transformation.

In XenClient, we use both interfaces, so the user can set the display 
offsets from wherever they care to. The in-guest side is relatively easy 
to implement in Linux guests that run X. It's more complicated in 
Windows, since the display driver isn't actually told about the offsets, 
so there needs to be an additional user-level service running to inform 
it of changes.

> So I think we probably do need treat multi-head windows as separate
> input devices, and/or have
> an agent in the guest to do the right thing by configuring multiple
> input devices to map to multiple outputs.
This is essentially correct, except that only the UI needs to treat it 
as separate input devices. The rest of the stack should be OK as one 
input device.

> I suppose spice must do something like this already, maybe they can
> tell me more.
>
> Dave.