On Tue, 31 May 2016 08:29:20 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Why attach the hotspot to the plane? Wouldn't it make more sense to
> > > make it a framebuffer property?
> >
> > We don't have properties on the framebuffer. I guess you /could/ just add
> > it internally to struct drm_
On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann wrote:
>> but it also means that
>> atomic userspace can't use hotspots before we add properties to fbs. And
>> doing that is a bit tricky since drm_framebuffer objects are meant to be
>> invariant - this assumption is deeply in-grained into the code
Hi,
> > Why attach the hotspot to the plane? Wouldn't it make more sense to
> > make it a framebuffer property?
>
> We don't have properties on the framebuffer. I guess you /could/ just add
> it internally to struct drm_framebuffer, and not bother exposing to
> userspace. I guess that would be
On Mon, May 30, 2016 at 03:50:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane,
> > e.g. drm_plane_register_hotspot(). That should allocate the properties
> > (if they don't exist yet) and then attach those props to the cu
Hi,
> - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane,
> e.g. drm_plane_register_hotspot(). That should allocate the properties
> (if they don't exist yet) and then attach those props to the cursor. We
> don't want those props everywhere, but only on drivers that
On Fri, May 27, 2016 at 09:48:22AM +0200, Gerd Hoffmann wrote:
> > I guess I didn't do a good job at looking at your v2: Cursor is still
> > using legacy interfaces and not a proper plane. Would be awesome if
> > you could fix that up. Atomic drivers really shouldn't use the legacy
> > cursor inter
Hi,
> I guess I didn't do a good job at looking at your v2: Cursor is still
> using legacy interfaces and not a proper plane. Would be awesome if
> you could fix that up. Atomic drivers really shouldn't use the legacy
> cursor interfaces any more at all.
> -Daniel
Figured that one for the most
On 25 May 2016 at 17:40, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
>> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>>> > > Signed-off-by: Dave Airlie
>>> > > Signed-off-by: Gerd Hoffmann
>>> >
>>> > Standard request from my side for new drm d
On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>> > > Signed-off-by: Dave Airlie
>> > > Signed-off-by: Gerd Hoffmann
>> >
>> > Standard request from my side for new drm drivers (especially if they're
>> > this simple): Can y
On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Signed-off-by: Dave Airlie
> > > Signed-off-by: Gerd Hoffmann
> >
> > Standard request from my side for new drm drivers (especially if they're
> > this simple): Can you please update the drivers to latest drm interna
Hi,
> > Signed-off-by: Dave Airlie
> > Signed-off-by: Gerd Hoffmann
>
> Standard request from my side for new drm drivers (especially if they're
> this simple): Can you please update the drivers to latest drm internal
> interfaces, i.e. using universal planes and atomic?
Up'n'running. Incre
Hi,
> >
> > Completely different thing crossing my mind: I think we can make
> > virtio-vga fully compatible with stdvga. stdvga has two bars, memory
> > (#0) and mmio (#2). We can make the mmio bar larger and place all the
> > virtio regions there.
> >
>
> Full compatibility with some sta
On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > I don't know. This seems exactly like the kind of thing
> > we had in mind when we added the virtio pci capability.
> > For example, we have text in spec that requires drivers
> > to skip unknown capabilities.
> >
> > An
Hi,
> I don't know. This seems exactly like the kind of thing
> we had in mind when we added the virtio pci capability.
> For example, we have text in spec that requires drivers
> to skip unknown capabilities.
>
> And yes, if bios pokes at a specific bar then we do
> need to list this info in t
On Thu, Mar 26, 2015 at 12:38:43PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Absolutely, it's pretty common to mix regions in a BAR.
> > For example, we have virtio kick (ioeventfd backed,
> > handled in kernel) in same BAR as common and device
> > specific configuration.
>
> > We did the same th
Hi,
> Absolutely, it's pretty common to mix regions in a BAR.
> For example, we have virtio kick (ioeventfd backed,
> handled in kernel) in same BAR as common and device
> specific configuration.
> We did the same thing you are now doing with the
> virtio BAR, and now we have to maintain two co
On Thu, Mar 26, 2015 at 09:42:47AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > And is it possible to use offset within BAR and/or memory BARs?
> > If yes I'd strongly prefer this.
>
> What is the point? Do you want place virtio regions and vga framebuffer
> in the same pci bar? Why? virtio is mm
On Wed, Mar 25, 2015 at 03:53:09PM +0100, Gerd Hoffmann wrote:
> > > Signed-off-by: Dave Airlie
> > > Signed-off-by: Gerd Hoffmann
> >
> > Standard request from my side for new drm drivers (especially if they're
> > this simple): Can you please update the drivers to latest drm internal
> > inter
Hi,
> And is it possible to use offset within BAR and/or memory BARs?
> If yes I'd strongly prefer this.
What is the point? Do you want place virtio regions and vga framebuffer
in the same pci bar? Why? virtio is mmio and traps into qemu on
access, whereas the vga framebuffer is memory-backe
On Thu, Mar 26, 2015 at 08:12:39AM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> > On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > BTW can we teach virtio-gpu to look for framebuffer using
> > > > virtio pci cap
On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > BTW can we teach virtio-gpu to look for framebuffer using
> > > virtio pci caps?
> >
> > The virtio-gpu driver doesn't matter much here, it doesn't use
On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > BTW can we teach virtio-gpu to look for framebuffer using
> > virtio pci caps?
>
> The virtio-gpu driver doesn't matter much here, it doesn't use it
> anyway.
>
> > Or are there limitations such as only
> > using IO po
Hi,
> BTW can we teach virtio-gpu to look for framebuffer using
> virtio pci caps?
The virtio-gpu driver doesn't matter much here, it doesn't use it
anyway.
> Or are there limitations such as only
> using IO port BARs, or compatibility with
> BIOS code etc that limit us to specific BARs anywa
On Wed, Mar 25, 2015 at 03:52:01PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > diff --git a/drivers/virtio/virtio_pci_common.c
> > > b/drivers/virtio/virtio_pci_common.c
> > > index e894eb2..a3167fa 100644
> > > --- a/drivers/virtio/virtio_pci_common.c
> > > +++ b/drivers/virtio/virtio_pci_common
On Di, 2015-03-24 at 22:50 +, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> > +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> > +struct drm_framebuffer *fb,
> > +struct drm
> > Signed-off-by: Dave Airlie
> > Signed-off-by: Gerd Hoffmann
>
> Standard request from my side for new drm drivers (especially if they're
> this simple): Can you please update the drivers to latest drm internal
> interfaces, i.e. using universal planes and atomic?
Have a docs / sample code p
Hi,
> > diff --git a/drivers/virtio/virtio_pci_common.c
> > b/drivers/virtio/virtio_pci_common.c
> > index e894eb2..a3167fa 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_de
On 25 March 2015 at 08:50, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
>> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
>> +struct drm_framebuffer *fb,
>> +struct drm_pending_v
Hi,
On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +
Just a license nit.
On Tue, 2015-03-24 at 17:07 +0100, Gerd Hoffmann wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -0,0 +1,132 @@
> +/*
> + * 2011 Red Hat, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining
On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote:
> From: Dave Airlie
>
> This patch adds a kms driver for the virtio gpu. The xorg modesetting
> driver can handle the device just fine, the framebuffer for fbcon is
> there too.
>
> Qemu patches for the host side are under review cu
On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote:
> From: Dave Airlie
>
> This patch adds a kms driver for the virtio gpu. The xorg modesetting
> driver can handle the device just fine, the framebuffer for fbcon is
> there too.
>
> Qemu patches for the host side are under review cu
On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote:
> From: Dave Airlie
>
> This patch adds a kms driver for the virtio gpu. The xorg modesetting
> driver can handle the device just fine, the framebuffer for fbcon is
> there too.
>
> Qemu patches for the host side are under review cu
From: Dave Airlie
This patch adds a kms driver for the virtio gpu. The xorg modesetting
driver can handle the device just fine, the framebuffer for fbcon is
there too.
Qemu patches for the host side are under review currently.
The pci version of the device comes in two variants: with and witho
34 matches
Mail list logo
