On Fri, May 25, 2012 at 09:23:13AM +0200, Alexander Larsson wrote:
> On Mon, 2012-05-07 at 09:28 +0300, Alon Levy wrote:
> > Hi,
> >
> > Currently we support multiple monitors by having:
> > single pci = single display channel = single client window
> >
> > The RANDR architecture doesn't len
On Mon, 2012-05-07 at 09:28 +0300, Alon Levy wrote:
> Hi,
>
> Currently we support multiple monitors by having:
> single pci = single display channel = single client window
>
> The RANDR architecture doesn't lend itself to this, but on the other hand it
> makes it very easy to have an alter
On Mon, May 07, 2012 at 03:31:23PM -0600, Noel Van Hook wrote:
> How far away is a multi-head solution, do you think?
> It sounds like most of the work is in the client and the X driver?
> Noel
>
I guess a month of real life I hope.
> On Mon, May 7, 2012 at 12:28 AM, Alon Levy wrote:
> > Hi,
>
On Tue, May 08, 2012 at 10:30:17AM +0300, Yonit Halperin wrote:
> On 05/07/2012 09:28 AM, Alon Levy wrote:
> >Hi,
> >
> > Currently we support multiple monitors by having:
> > single pci = single display channel = single client window
> >
> > The RANDR architecture doesn't lend itself to this,
On 05/07/2012 09:28 AM, Alon Levy wrote:
Hi,
Currently we support multiple monitors by having:
single pci = single display channel = single client window
The RANDR architecture doesn't lend itself to this, but on the other hand it
makes it very easy to have an alternative scheme:
si
How far away is a multi-head solution, do you think?
It sounds like most of the work is in the client and the X driver?
Noel
On Mon, May 7, 2012 at 12:28 AM, Alon Levy wrote:
> Hi,
>
> Currently we support multiple monitors by having:
> single pci = single display channel = single client window
Hi,
>> Are we going to have one more input/cursor channel per head? Probably
>> not, but it would be nice to specify. I guess the coordinate will need
>> to be adjusted to the respective heads. (ie some messages will be
>> relative to heads, other to primary surface: INPUTS_MOUSE_POSITION vs
>>
On Mon, May 07, 2012 at 02:16:09PM +0200, Marc-André Lureau wrote:
> On Mon, May 7, 2012 at 8:28 AM, Alon Levy wrote:
> > RANDR introduces a concept of a CRTC and an OUTPUT. The CRTC scansout a
> > portion of the framebuffer onto one or more OUTPUTs. I propose having a
> > 1:1 CRTC:OUTPUT corre
On Mon, May 7, 2012 at 8:28 AM, Alon Levy wrote:
> RANDR introduces a concept of a CRTC and an OUTPUT. The CRTC scansout a
> portion of the framebuffer onto one or more OUTPUTs. I propose having a 1:1
> CRTC:OUTPUT correspondence and introducing two new commands, one on PCI and
> one for the p
On Mon, May 07, 2012 at 01:57:37PM +0200, Gerd Hoffmann wrote:
> On 05/07/12 12:28, Alon Levy wrote:
> > On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>> But there is no concept of an additional surface in the guest driver.
> >>> RANDR 1.2 (and I think the same f
On 05/07/12 12:28, Alon Levy wrote:
> On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>>> But there is no concept of an additional surface in the guest driver.
>>> RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per
>>> CRTC pixmaps) has a single screen
On Mon, May 07, 2012 at 01:36:03PM +0300, Alon Levy wrote:
> On Mon, May 07, 2012 at 01:28:58PM +0300, Alon Levy wrote:
> > On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > But there is no concept of an additional surface in the guest driver.
> > > > RANDR 1
On Mon, May 07, 2012 at 01:28:58PM +0300, Alon Levy wrote:
> On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > But there is no concept of an additional surface in the guest driver.
> > > RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per
> > > CR
On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > But there is no concept of an additional surface in the guest driver.
> > RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per
> > CRTC pixmaps) has a single screen wide pixmap. A screen is one per X
> >
Hi,
> But there is no concept of an additional surface in the guest driver.
> RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per
> CRTC pixmaps) has a single screen wide pixmap. A screen is one per X
> server, so there is just one even if you have multiple heads. And the
> CRT
On Mon, May 07, 2012 at 09:03:02AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > 1. Guest enables a new monitor:
> > 2. Guest pushes QXLHead command to command ring
> > 3. Server sends SpiceHead message on the ring's display channel.
> > 4. Client creates a window out of [x, y, width, height] scan
Hi,
On 05/07/2012 09:03 AM, Gerd Hoffmann wrote:
Hi,
1. Guest enables a new monitor:
2. Guest pushes QXLHead command to command ring
3. Server sends SpiceHead message on the ring's display channel.
4. Client creates a window out of [x, y, width, height] scanning out of the
primary
Hi,
> 1. Guest enables a new monitor:
> 2. Guest pushes QXLHead command to command ring
> 3. Server sends SpiceHead message on the ring's display channel.
> 4. Client creates a window out of [x, y, width, height] scanning out of the
> primary surface (there is one associated primary with th
Hi,
Currently we support multiple monitors by having:
single pci = single display channel = single client window
The RANDR architecture doesn't lend itself to this, but on the other hand it
makes it very easy to have an alternative scheme:
single pci = single display channel = multiple cl
Hi,
Currently we support multiple monitors by having:
single pci = single display channel = single client window
The RANDR architecture doesn't lend itself to this, but on the other hand it
makes it very easy to have an alternative scheme:
single pci = single display channel = multiple cl
20 matches
Mail list logo
