On 11/26/2013 11:29 PM, Dave Airlie wrote:
On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann 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)
Hi,
> 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.
>
> I suppose spice must do something like this already, maybe they can
> tell
On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann 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.
>> > The
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
Hi,
> > With absolute pointer events the whole thing becomes a bit more tricky
> > as we have to map input from multiple displays (QemuConsoles) to a
> > single absolute pointing device (usb tablet). This is what Dave wants
> > the screen layout for. I still think the input layer is the place
On Thu, Nov 21, 2013 at 1:14 AM, Gerd Hoffmann wrote:
> On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote:
>> On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
>> >Hi,
>> >
>> >> I think you are only considering output here, for input we definitely
>> >> need some idea of screen layout, and this
On 11/20/2013 10:14 AM, Gerd Hoffmann wrote:
On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote:
On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
Hi,
I think you are only considering output here, for input we definitely
need some idea of screen layout, and this needs to be stored
somewhere.
On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote:
> On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
> >Hi,
> >
> >> I think you are only considering output here, for input we definitely
> >> need some idea of screen layout, and this needs to be stored
> >> somewhere.
> > Oh yea, input. That n
On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
Hi,
I think you are only considering output here, for input we definitely
need some idea of screen layout, and this needs to be stored
somewhere.
Oh yea, input. That needs quite some work for multihead / multiseat.
I think we should *not* try t
Hi,
> I think you are only considering output here, for input we definitely
> need some idea of screen layout, and this needs to be stored
> somewhere.
Oh yea, input. That needs quite some work for multihead / multiseat.
I think we should *not* try to hack that into the ui. We should extend
On Wed, Nov 20, 2013 at 3:17 PM, Dave Airlie wrote:
>>> Have a look the virtio-gpu branch in my repo (don't look at the
>>> history, its ugly, just the final state), you'll see code in sdl2.c to
>>> do input translation from window coordinates to the overall screen
>>> space. So we need at least t
>> Have a look the virtio-gpu branch in my repo (don't look at the
>> history, its ugly, just the final state), you'll see code in sdl2.c to
>> do input translation from window coordinates to the overall screen
>> space. So we need at least the x,y offset in the ui code, and I think
>> we need to c
On Nov 19, 2013, at 9:59 PM, Dave Airlie wrote:
> On Tue, Nov 19, 2013 at 6:11 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> So I felt I had a choice here for sharing a single output surface
>>> amongst outputs:
>>>
>>> a) have multiple QemuConsole reference multiple DisplaySurface wihch
>>> refer
On Tue, Nov 19, 2013 at 6:11 PM, Gerd Hoffmann wrote:
> Hi,
>
>> So I felt I had a choice here for sharing a single output surface
>> amongst outputs:
>>
>> a) have multiple QemuConsole reference multiple DisplaySurface wihch
>> reference a single pixman image,
>
> This one.
>
>> In either case
Hi,
> So I felt I had a choice here for sharing a single output surface
> amongst outputs:
>
> a) have multiple QemuConsole reference multiple DisplaySurface wihch
> reference a single pixman image,
This one.
> In either case we need to store, width/height of the console and x/y
> offset into
So I've started banging my head against using QemuConsole as the
container for a single output, and have been left with the usual 10
ways to design things, but since I don't want to spend ages
implementing one way just to be told its unacceptable it would be good
to get some more up front design in
16 matches
Mail list logo