> > graphic_console_init(..., &state->heads[i]);
> >
> > so you can figure the head in the callbacks.
>
> What I had prototyped (I got impatient) was to add a helper:
> qemu_console_hw_opaque() to console.c so the HwOps could query the
> opaque pointer. I don't like it because it requires an
On 11/19/2013 1:57 AM, Gerd Hoffmann wrote:
Hi,
I think it would be better if the HwOps calls all took a QemuConsole
instead of the opaque structure. The hw implementations can dig their
opaque structure out from there.
QemuConsole is private to ui/console.c though (and I prefer to keep it
Hi,
> I think it would be better if the HwOps calls all took a QemuConsole
> instead of the opaque structure. The hw implementations can dig their
> opaque structure out from there.
QemuConsole is private to ui/console.c though (and I prefer to keep it
this way). So we need either a helper f
I've dug into this further, and basically gotten what I had before
working against the latest code. So now the ugly bits are making
themselves known.
In my existing patch set, dpy_refresh is called for each display,
however since hw_update takes an opaque pointer to the hw info
structure, it
On 11/06/2013 06:44 PM, Dave Airlie wrote:
On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann wrote:
Hi,
It currently just adds multiple DisplaySurfaces to the QemuConsole,
now Gerd said he thought I should be using multiple QemuConsoles but I
really didn't think this was a good idea,
Why?
It
On 11/7/2013 8:46 AM, Gerd Hoffmann wrote:
Hi,
As far as the EDID is concerned, there can only be one EDID for a
display+hw pair, or the guest won't know what to do. In my use-case, I
simply pass real EDIDs through, and create a full-screen window for each
real monitor.
Ok, makes sense.
I
Hi,
> As far as the EDID is concerned, there can only be one EDID for a
> display+hw pair, or the guest won't know what to do. In my use-case, I
> simply pass real EDIDs through, and create a full-screen window for each
> real monitor.
Ok, makes sense.
> If you wanted to have two UIs displa
On Do, 2013-11-07 at 09:44 +1000, Dave Airlie wrote:
> On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> It currently just adds multiple DisplaySurfaces to the QemuConsole,
> >> now Gerd said he thought I should be using multiple QemuConsoles but I
> >> really didn't think th
On 11/06/2013 05:55 AM, Gerd Hoffmann wrote:
Hi,
In QEMU 1.3, there was a DisplayState list. We used one DisplayState per
monitor. The DisplayChangeListener has a new hw_add_display vector, so
that when the UI requests a second monitor the new display gets attached
to the emulated hardware.
On 11/05/2013 08:46 PM, Dave Airlie wrote:
On Wed, Nov 6, 2013 at 6:42 AM, John Baboval wrote:
Hello,
I am currently the device model maintainer for XenClient Enterprise. As you
may or may not know, we maintain a patch queue on top of QEMU (currently
1.3) that adds functionality needed to supp
On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann wrote:
> Hi,
>
>> It currently just adds multiple DisplaySurfaces to the QemuConsole,
>> now Gerd said he thought I should be using multiple QemuConsoles but I
>> really didn't think this was a good idea,
>
> Why?
It's a fair question and I haven't
Hi,
> It currently just adds multiple DisplaySurfaces to the QemuConsole,
> now Gerd said he thought I should be using multiple QemuConsoles but I
> really didn't think this was a good idea,
Why?
cheers,
Gerd
Hi,
> In QEMU 1.3, there was a DisplayState list. We used one DisplayState per
> monitor. The DisplayChangeListener has a new hw_add_display vector, so
> that when the UI requests a second monitor the new display gets attached
> to the emulated hardware. (patch: add_display_ptr)
I don't thin
On Wed, Nov 6, 2013 at 6:42 AM, John Baboval wrote:
> Hello,
>
> I am currently the device model maintainer for XenClient Enterprise. As you
> may or may not know, we maintain a patch queue on top of QEMU (currently
> 1.3) that adds functionality needed to support XCE features.
>
> One of the majo
Hello,
I am currently the device model maintainer for XenClient Enterprise. As
you may or may not know, we maintain a patch queue on top of QEMU
(currently 1.3) that adds functionality needed to support XCE features.
One of the major things we add is robust multi-head support. This
includes
15 matches
Mail list logo
