Re: [Spice-devel] [PATCH] drm/qxl: drop prime import/export callbacks
On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
>
> On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> >
> > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > userspace.
It's been pointed out to me that disables DRI3 for these devices, I'm
not sure that is the solution we actually wanted.
any ideas?
Dave.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Dave Airlie
> > ---
> > drivers/gpu/drm/qxl/qxl_drv.c | 4
> > drivers/gpu/drm/qxl/qxl_prime.c | 14 --
> > 2 files changed, 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index 13c8a662f9..ccb090f3ab 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -250,14 +250,10 @@ static struct drm_driver qxl_driver = {
> > #if defined(CONFIG_DEBUG_FS)
> > .debugfs_init = qxl_debugfs_init,
> > #endif
> > - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > .gem_prime_export = drm_gem_prime_export,
> > .gem_prime_import = drm_gem_prime_import,
> > .gem_prime_pin = qxl_gem_prime_pin,
> > .gem_prime_unpin = qxl_gem_prime_unpin,
> > - .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
> > - .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
> > .gem_prime_vmap = qxl_gem_prime_vmap,
> > .gem_prime_vunmap = qxl_gem_prime_vunmap,
> > .gem_prime_mmap = qxl_gem_prime_mmap,
> > diff --git a/drivers/gpu/drm/qxl/qxl_prime.c
> > b/drivers/gpu/drm/qxl/qxl_prime.c
> > index a55dece118..df65d3c1a7 100644
> > --- a/drivers/gpu/drm/qxl/qxl_prime.c
> > +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> > @@ -38,20 +38,6 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
> > WARN_ONCE(1, "not implemented");
> > }
> >
> > -struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
> > -{
> > - WARN_ONCE(1, "not implemented");
> > - return ERR_PTR(-ENOSYS);
> > -}
> > -
> > -struct drm_gem_object *qxl_gem_prime_import_sg_table(
> > - struct drm_device *dev, struct dma_buf_attachment *attach,
> > - struct sg_table *table)
> > -{
> > - WARN_ONCE(1, "not implemented");
> > - return ERR_PTR(-ENOSYS);
> > -}
> > -
> > void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
> > {
> > WARN_ONCE(1, "not implemented");
> > --
> > 2.9.3
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] drm/qxl: Fix build errors
On Tue, 18 Aug 2020 at 15:32, Gerd Hoffmann wrote: > > Hi, > > > I guess things are never quite so easy :-). It looks like Daniel's > > patch is in drm-misc-fixes and Sidong's patch is in drm-misc-next. On > > their own they're fine, but once they are merged in drm-tip the build > > error shows up. > > Ah, ok. I've already wondered how that got past my build testing. > This explains it. > > thanks for looking into it, I've fixed this in drm-tip with a fixup. In future when we find these silent conflicts, can someone please https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html follow those instructions to fix it up. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC EXP] remote Virgl support
On 29 June 2016 at 00:46, Frediano Ziglio wrote: > This patch is really hacky and mainly intended to try to use the > current spice-protocol to make Virgl remote. > It does in a fast (as code lines) way: > - extract the images from scanouts; > - fed these images to normal flow (using display_channel_process_draw) > so making possible to check streaming flow or just image compression > using Qemu parameters (or some other hacks is not very recent). > > First problem: it works only on Intel i915 family. > I tried to use DRM directly finding many post where mmap were used. > This was a big mistake. Current cards use some internal memory > arrangement for textures or the texture memory could be in an area > not mmap-able. Using DRM you can allocate a buffer (PBO) mmap-able > but however there is no portable (among card types) way to copy the > texture on this buffer. At the end I think would be much better to use > EGL like Qemu does so will work on any card, probably faster. Yes you want to use EGL here, I think we could probably put more code in qemu to help with this case. At one point I had remote spice working, but it was due to having the qemu code sync'ing the GL rendered output to the qemu/spice framebuffer using a callback into the renderer which essentially did a readpixels. It was very hacky, https://cgit.freedesktop.org/~airlied/qemu/log/?h=virtio-gpu-3d-old-hacks has some remnants of it, look for dpy_needs_gl_surface_sync. You'd probably want to talk to Gerd to find the nice/proper way to do things, but it most definitely involves egl, and most likely readpixels into a PBO. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8
On 4 November 2016 at 20:41, Christophe Fergeau wrote: > On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote: >> > Or maybe other parts of the >> > kernel/userspace rely on this rounding down. >> >> This is where I suspect we could run in trouble. Odd resolutions simply >> don't happen on physical hardware, all usual resolutions are a multiple >> of 8, most of them are even a multiple of 16. >> >> Various image/video formats use 16x16 blocks. >> The qemu vnc server operates on 16x16 blocks too (and we had bugs in the >> past with odd resolutions). >> >> Also scanlines and cachelines align nicely if you don't use odd >> resolutions. >> >> > I unfortunately don't know >> > :( >> >> I don't have definitive answers too, just a gut feeling that this might >> cause trouble. > > I think this might be fine actually, there is already one such > resolution in the kernel, which is 1366x768 (1366 is only a multiple of > 2). There is already a bit of a hack to handle it anyway, see > fixup_mode_1366x768() in drm_edid.c. > >> >> Maybe we should add a module option for this? So there is an easy >> (as-in: doesn't require a kernel rebuild) way out in case it causes >> trouble in certain setups? > > This seems a bit overkill to me, but I can look into it if needed. I think we should try it an see, if we see problems you could enforce the framebuffer would have a stride aligned to whatever value, and just the view into the framebuffer could be whatever. The CVT stuff is just due to how hw is programmed and monitors are described. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] drm/qxl: drop prime import/export callbacks
On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
>
> Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> userspace.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 4
> drivers/gpu/drm/qxl/qxl_prime.c | 14 --
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 13c8a662f9..ccb090f3ab 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -250,14 +250,10 @@ static struct drm_driver qxl_driver = {
> #if defined(CONFIG_DEBUG_FS)
> .debugfs_init = qxl_debugfs_init,
> #endif
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = drm_gem_prime_export,
> .gem_prime_import = drm_gem_prime_import,
> .gem_prime_pin = qxl_gem_prime_pin,
> .gem_prime_unpin = qxl_gem_prime_unpin,
> - .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
> - .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
> .gem_prime_vmap = qxl_gem_prime_vmap,
> .gem_prime_vunmap = qxl_gem_prime_vunmap,
> .gem_prime_mmap = qxl_gem_prime_mmap,
> diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
> index a55dece118..df65d3c1a7 100644
> --- a/drivers/gpu/drm/qxl/qxl_prime.c
> +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> @@ -38,20 +38,6 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
> WARN_ONCE(1, "not implemented");
> }
>
> -struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
> -{
> - WARN_ONCE(1, "not implemented");
> - return ERR_PTR(-ENOSYS);
> -}
> -
> -struct drm_gem_object *qxl_gem_prime_import_sg_table(
> - struct drm_device *dev, struct dma_buf_attachment *attach,
> - struct sg_table *table)
> -{
> - WARN_ONCE(1, "not implemented");
> - return ERR_PTR(-ENOSYS);
> -}
> -
> void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
> {
> WARN_ONCE(1, "not implemented");
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] qxl and page flip
On 4 October 2017 at 21:38, Gerd Hoffmann wrote: > Hi, > >> > So, the options I see are: >> > >> > (1) Declare qxl deprecated, promote virtio-vga instead. >> > >> > (2) Pimp the qxl hardware, add page-flip support. Requires >> > changes >> > in spice-server (due to lazy rendering), qemu qxl emulation >> > and >> > guest kernel driver. Should be transparent to spice-client >> > and >> > guest userspace (aka xorg qxl driver). > >> I don't think that supporting page flipping in QXL would be hard. > > Yes, it shouldn't be difficult. > > But still requires new versions on both guest and host side. > And these new versions will have virtio-vga support too. > > Also note that wayland will not use any qxl 2d accel operations. Same > is true for any opengl compositors like gnome-shell when running on > xorg. So performance-wise it should not make a big difference whenever > you are using qxl or virtio-vga (without virgl), it's all llvmpipe > software opengl rendering in both cases. > > So, is it worth updating qxl? > Or should we focus on virtio-vga instead? I think we should try and refocus on virtio-vga for Linux guests, I don't think we currently gain anything majorly useful from qxl acceleration under composited environments, though if we did plumb through more things maybe we could get the video encoding youtube use case working better again. The other option is we revert atomic modesetting from upstream qxl until the hw is upgraded to it, and we use the atomic path only on the newer hardware. I'd really like to see some commitment to fixing qxl if we do decide to do that. Dave. > >> Would just requires to support calling create surface having a >> surface and detecting that only the pointer changes. > > Either that, or an explicit QXL_SURF_FLAG_PAGEFLIP instead of the > detection. > > But when touching the qxl virtual virtual hardware anyway we might > consider to deprecate the concept of a "primary surface" altogether and > just allow mapping normal surfaces to output heads instead. Which > would be alot closer to how physical hardware works today and should be > more future-proof. Of course that would be a bigger change and > probably requires spice-protocol changes too. > > cheers, > Gerd > > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] qxl and page flip
On 12 October 2017 at 19:16, Gerd Hoffmann wrote: > On Fri, 2017-10-06 at 12:40 +0200, Gerd Hoffmann wrote: >> Hi, >> >> > Would not actually be possible to detect a destroy + create >> > commands and avoid having to change any version/driver? >> >> Well, that would be option (3) of the original mail: Make the spice >> client hide this. Basically not go into "no display" mode instantly >> after destroy-surface, but wait a bit to see whenever it is followed >> by >> a create-surface command. > > Ping. What do you think? We are fixing it host side, I still think we need hack the guest until it knows the host has the workaround, Daniel Vetter suggested we take a different path for atomic page flip, and put back the copy mechanism until we can support atomic modesetting properly, which might be simpler than reverting all the qxl atomic work. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] drm/qxl: workaround broken qxl hw primary setting.
From: Dave Airlie
QXL hw can't change primary surfaces easily, the server sends a msg
and the client flickers a lo when it does. The old pre-atomic
page flip code endeavoured to workaround this with a copy operation.
This worked by another accident of how the qxl virtual gpu is designed,
it does lazy operation evaluation on the host, so this operation
wouldn't generally trash the memory, and result in correct display.
This tries to work out when the commit is likely just a pageflip
and avoid touching the primary surface, this might go wrong at
some point but I believe it's the same level as wrong as the old code
base.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index afbf50d..3b702d1 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -502,6 +502,7 @@ static void qxl_primary_atomic_update(struct drm_plane
*plane,
struct qxl_framebuffer *qfb_old;
struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
struct qxl_bo *bo_old;
+ bool update_primary = true;
struct drm_clip_rect norect = {
.x1 = 0,
.y1 = 0,
@@ -519,15 +520,31 @@ static void qxl_primary_atomic_update(struct drm_plane
*plane,
if (bo == bo_old)
return;
+ if (bo && bo_old &&
+ plane->state->crtc == old_state->crtc &&
+ plane->state->crtc_w == old_state->crtc_w &&
+ plane->state->crtc_h == old_state->crtc_h &&
+ plane->state->src_x == old_state->src_x &&
+ plane->state->src_y == old_state->src_y &&
+ plane->state->src_w == old_state->src_w &&
+ plane->state->src_h == old_state->src_h &&
+ plane->state->rotation == old_state->rotation &&
+ plane->state->zpos == old_state->zpos)
+ /* this is likely a pageflip */
+ update_primary = false;
+
if (bo_old && bo_old->is_primary) {
- qxl_io_destroy_primary(qdev);
+ if (update_primary)
+ qxl_io_destroy_primary(qdev);
bo_old->is_primary = false;
}
if (!bo->is_primary) {
- qxl_io_create_primary(qdev, 0, bo);
+ if (update_primary)
+ qxl_io_create_primary(qdev, 0, bo);
bo->is_primary = true;
}
+
qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, &norect, 1, 1);
}
--
2.9.5
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [rfc] suggested offset properties + qxl support
There was some discussion on spice irc channel somewhere last week about how best to take note of the x/y offsets that were suggested by the hosts into the guests, so that the guest can configured the monitors in the same layout as they are on the host side. I think initially the kernel needs to just propogate the values to userspace, so I've created two properties. The X server and desktop environments should start to use these properties to set things correctly. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 2/2] drm/qxl: use suggested x/y offset properties to pass guest prefs
From: Dave Airlie
This passes the guest preferences for a where to place the
outputs through to userspace. Userspace would need to be updated
to take note of this information, X server and GNOME.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 0d13962..2b90b53 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -100,14 +100,37 @@ static int
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
return 0;
}
+static void qxl_update_offset_props(struct qxl_device *qdev)
+{
+ struct drm_device *dev = qdev->ddev;
+ struct drm_connector *connector;
+ struct qxl_output *output;
+ struct qxl_head *head;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ output = drm_connector_to_qxl_output(connector);
+
+ head = &qdev->client_monitors_config->heads[output->index];
+
+ drm_object_property_set_value(&connector->base,
+ dev->mode_config.suggested_x_property, head->x);
+ drm_object_property_set_value(&connector->base,
+ dev->mode_config.suggested_y_property, head->y);
+ }
+}
+
void qxl_display_read_client_monitors_config(struct qxl_device *qdev)
{
+ struct drm_device *dev = qdev->ddev;
while (qxl_display_copy_rom_client_monitors_config(qdev)) {
qxl_io_log(qdev, "failed crc check for client_monitors_config,"
" retrying\n");
}
+ drm_modeset_lock_all(dev);
+ qxl_update_offset_props(qdev);
+ drm_modeset_unlock_all(dev);
if (!drm_helper_hpd_irq_event(qdev->ddev)) {
/* notify that the monitor configuration changed, to
adjust at the arbitrary resolution */
@@ -951,6 +974,10 @@ static int qdev_output_init(struct drm_device *dev, int
num_output)
drm_object_attach_property(&connector->base,
qdev->hotplug_mode_update_property, 0);
+ drm_object_attach_property(&connector->base,
+ dev->mode_config.suggested_x_property, 0);
+ drm_object_attach_property(&connector->base,
+ dev->mode_config.suggested_y_property, 0);
drm_connector_register(connector);
return 0;
}
@@ -1064,6 +1091,7 @@ int qxl_modeset_init(struct qxl_device *qdev)
qdev->ddev->mode_config.fb_base = qdev->vram_base;
+ drm_mode_create_suggested_offset_properties(qdev->ddev);
qxl_mode_create_hotplug_mode_update_property(qdev);
for (i = 0 ; i < qxl_num_crtc; ++i) {
--
1.9.3
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/2] drm: add properties for suggested x/y offset for connectors.
From: Dave Airlie
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 17 -
drivers/gpu/drm/drm_crtc.c | 24
include/drm/drm_crtc.h | 5 +
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index be35bc3..a434040 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2507,7 +2507,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions
- DRM
+ DRM
Generic
“EDID”
BLOB | IMMUTABLE
@@ -2638,6 +2638,21 @@ void intel_crt_init(struct drm_device *dev)
TBD
+ Virtual GPU
+ “suggested X”
+ RANGE
+ Min=0, Max=0x
+ Connector
+ property to suggest an X offset for a connector
+
+
+ “suggested Y”
+ RANGE
+ Min=0, Max=0x
+ Connector
+ property to suggest an Y offset for a connector
+
+
Optional
“scaling mode”
ENUM
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..15679a7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1535,6 +1535,30 @@ int drm_mode_create_dirty_info_property(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
+/**
+ * drm_mode_create_suggested_offset_properties - create suggests offset
properties
+ * @dev: DRM device
+ *
+ * Create the the suggested x/y offset property for connectors.
+ */
+int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
+{
+ if (dev->mode_config.suggested_x_property &&
dev->mode_config.suggested_y_property)
+ return 0;
+
+ dev->mode_config.suggested_x_property =
+ drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested_x", 0, 0x);
+
+ dev->mode_config.suggested_y_property =
+ drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested_y", 0, 0x);
+
+ if (dev->mode_config.suggested_x_property == NULL ||
+ dev->mode_config.suggested_y_property == NULL)
+ return -ENOMEM;
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
+
static int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group
*group)
{
uint32_t total_objects = 0;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..01da16a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -851,6 +851,10 @@ struct drm_mode_config {
struct drm_property *aspect_ratio_property;
struct drm_property *dirty_info_property;
+ /* properties for virtual machine layout */
+ struct drm_property *suggested_x_property;
+ struct drm_property *suggested_y_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
@@ -1046,6 +1050,7 @@ extern int drm_mode_create_tv_properties(struct
drm_device *dev, int num_formats
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
+extern int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
extern int drm_mode_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
--
1.9.3
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH xf86-qxl] Remove image cache
On 29 January 2015 at 23:16, Marc-André Lureau
wrote:
> I forgot that line:
>
> --- a/src/qxl_driver.c
> +++ b/src/qxl_driver.c
> @@ -854,7 +854,6 @@ qxl_enter_vt (VT_FUNC_ARGS_DECL)
> if (qxl->mem)
> {
> qxl_mem_free_all (qxl->mem);
> - qxl_drop_image_cache (qxl);
>
> On Thu, Jan 29, 2015 at 2:14 PM, Marc-André Lureau
> wrote:
>> While looking for leaks, I realized that the image cache looks
>> quite suspicious.
>>
>> Not only it leaks when qxl_drop_image_cache() is called,
>> since all the allocated image_info_t references are lost.
>> But it is also useless...
>>
>> (note: this won't help all the bug reports about vram memory "leak", or
>> rather "failed allocation", since it's a different memory area)
Yes please,
Reviewed-by: Dave Airlie
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/11] Miscellaneous stability patches
> I was using a different repository with only QXL driver. I tested and all > patches apply and compile perfectly even with Linus master branch. Lets only post patches people can apply, it makes it harder to figure out stuff. I'll take a look at the patches, but it would be good to get them resent base on drm-next. also indicating in each patch what is a right now fix and what isn't. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 01/11] Do not cause spice-server to clean our objects
On 27 May 2015 at 20:03, Frediano Ziglio wrote: > If objects are moved back from system memory to VRAM (and spice id > created again) memory is already initialized so we need to set flag > to not clear memory. > If you don't do it after a while using desktop many images turns to > black or transparents. Good point, Reviewed-by: Dave Airlie > > Signed-off-by: Frediano Ziglio > --- > qxl/qxl_cmd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/qxl/qxl_cmd.c b/qxl/qxl_cmd.c > index bd5404e..85ed5dc 100644 > --- a/qxl/qxl_cmd.c > +++ b/qxl/qxl_cmd.c > @@ -502,6 +502,7 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev, > > cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release); > cmd->type = QXL_SURFACE_CMD_CREATE; > + cmd->flags = QXL_SURF_FLAG_KEEP_DATA; > cmd->u.surface_create.format = surf->surf.format; > cmd->u.surface_create.width = surf->surf.width; > cmd->u.surface_create.height = surf->surf.height; > -- > 2.1.0 > > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 02/11] Do not leak memory if qxl_release_list_add fails
On 27 May 2015 at 20:03, Frediano Ziglio wrote: > If the function fails reference counter to the object is not decremented > causing leaks. > This is hard to spot as it happens only on very low memory situations. > > Signed-off-by: Frediano Ziglio Looks good, Reviewed-by: Dave Airlie Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 03/11] Fix print statement not using uninitialized variable
On 27 May 2015 at 20:03, Frediano Ziglio wrote: > reloc_info[i] is not still initialized in the print statement. > > Signed-off-by: Frediano Ziglio Reviewed-by: Dave Airlie ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 04/11] Avoid double free on error
On 27 May 2015 at 20:03, Frediano Ziglio wrote: > Is we are not able to get source bo object from handle we free > destination bo object and call cleanup code however destination > object was already inserted in reloc_info array (num_relocs was > already incremented) so on cleanup we free destination again. > > Signed-off-by: Frediano Ziglio Reviewed-by: Dave Airlie ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 05/11] Handle all errors in qxl_surface_evict
On 27 May 2015 at 20:04, Frediano Ziglio wrote: > Only EBUSY error was handled. This could cause code to believe > reserve was successful while it failed. > > Signed-off-by: Frediano Ziglio This has been there since I wrote qxl, so I expect I had some reason for it, but I can't remember it now.. Most likely is something had the bo reserved already and we reentered from somewhere we shouldn't but I think a lot of the horrible code went away. so because I can't justify the hack, Reviewed-by: Dave Airlie Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 06/11] Fix return for qxl_release_alloc
On 27 May 2015 at 20:04, Frediano Ziglio wrote:
> This function return handle to allocated release object which is an int.
Reviewed-by: Dave Airlie
>
> Signed-off-by: Frediano Ziglio
> ---
> qxl/qxl_release.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qxl/qxl_release.c b/qxl/qxl_release.c
> index d9b2568..6fd8e50 100644
> --- a/qxl/qxl_release.c
> +++ b/qxl/qxl_release.c
> @@ -122,7 +122,7 @@ static const struct fence_ops qxl_fence_ops = {
> .wait = qxl_fence_wait,
> };
>
> -static uint64_t
> +static int
> qxl_release_alloc(struct qxl_device *qdev, int type,
> struct qxl_release **ret)
> {
> --
> 2.1.0
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 07/11] Handle correctly failures in qxl_alloc_relase_reserved
On 27 May 2015 at 20:04, Frediano Ziglio wrote: > Free resources correctly if function fails > > Signed-off-by: Frediano Ziglio Reviewed-by: Dave Airlie ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 08/11] Remove format string errors
On 27 May 2015 at 20:04, Frediano Ziglio wrote:
> Enable format string checks for qxl_io_log and remove resulting warnings
> which could lead to memory errors on different platform or just printing
> wrong information.
>
> Signed-off-by: Frediano Ziglio
Reviewed-by: Dave Airlie
> ---
> qxl/qxl_cmd.c | 2 +-
> qxl/qxl_display.c | 2 +-
> qxl/qxl_drv.h | 2 +-
> qxl/qxl_release.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
> index b18f84c..edc1eec 100644
> --- a/qxl/qxl_cmd.c
> +++ b/qxl/qxl_cmd.c
> @@ -248,7 +248,7 @@ int qxl_garbage_collect(struct qxl_device *qdev)
> }
> }
>
> - QXL_INFO(qdev, "%s: %lld\n", __func__, i);
> + QXL_INFO(qdev, "%s: %d\n", __func__, i);
>
> return i;
> }
> diff --git a/qxl/qxl_display.c b/qxl/qxl_display.c
> index 4a0a8b2..a8dbb3e 100644
> --- a/qxl/qxl_display.c
> +++ b/qxl/qxl_display.c
> @@ -67,7 +67,7 @@ static int
> qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
> crc = crc32(0, (const uint8_t *)&qdev->rom->client_monitors_config,
> sizeof(qdev->rom->client_monitors_config));
> if (crc != qdev->rom->client_monitors_config_crc) {
> - qxl_io_log(qdev, "crc mismatch: have %X (%d) != %X\n", crc,
> + qxl_io_log(qdev, "crc mismatch: have %X (%zd) != %X\n", crc,
>sizeof(qdev->rom->client_monitors_config),
>qdev->rom->client_monitors_config_crc);
> return 1;
> diff --git a/qxl/qxl_drv.h b/qxl/qxl_drv.h
> index 6745c44..62ef8be 100644
> --- a/qxl/qxl_drv.h
> +++ b/qxl/qxl_drv.h
> @@ -328,7 +328,7 @@ struct qxl_device {
> };
>
> /* forward declaration for QXL_INFO_IO */
> -void qxl_io_log(struct qxl_device *qdev, const char *fmt, ...);
> +__printf(2,3) void qxl_io_log(struct qxl_device *qdev, const char *fmt, ...);
>
> extern const struct drm_ioctl_desc qxl_ioctls[];
> extern int qxl_max_ioctl;
> diff --git a/qxl/qxl_release.c b/qxl/qxl_release.c
> index 00604ed..b66ec33 100644
> --- a/qxl/qxl_release.c
> +++ b/qxl/qxl_release.c
> @@ -153,7 +153,7 @@ qxl_release_alloc(struct qxl_device *qdev, int type,
> return handle;
> }
> *ret = release;
> - QXL_INFO(qdev, "allocated release %lld\n", handle);
> + QXL_INFO(qdev, "allocated release %d\n", handle);
> release->id = handle;
> return handle;
> }
> --
> 2.1.0
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 10/11] Simplify cleaning qxl processing command
On 27 May 2015 at 20:04, Frediano Ziglio wrote:
> In qxlhw_handle_to_bo we incremented counters twice, one time for release
> object
> and one for reloc_info.
> In the main function however reloc_info references was drop much earlier than
> release so keeping the pointer only on release is safe and make cleaning
> process easier.
Seems fine,
Reviewed-by: Dave Airlie
>
> Signed-off-by: Frediano Ziglio
> ---
> qxl/qxl_ioctl.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/qxl/qxl_ioctl.c b/qxl/qxl_ioctl.c
> index 85b3808..bb326ff 100644
> --- a/qxl/qxl_ioctl.c
> +++ b/qxl/qxl_ioctl.c
> @@ -122,10 +122,9 @@ static struct qxl_bo *qxlhw_handle_to_bo(struct
> qxl_device *qdev,
> qobj = gem_to_qxl_bo(gobj);
>
> ret = qxl_release_list_add(release, qobj);
> - if (ret) {
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_unreference_unlocked(gobj);
> + if (ret)
> return NULL;
> - }
>
> return qobj;
> }
> @@ -145,7 +144,7 @@ static int qxl_process_single_command(struct qxl_device
> *qdev,
> struct qxl_release *release;
> struct qxl_bo *cmd_bo;
> void *fb_cmd;
> - int i, j, ret, num_relocs;
> + int i, ret, num_relocs;
> int unwritten;
>
> switch (cmd->type) {
> @@ -269,12 +268,6 @@ static int qxl_process_single_command(struct qxl_device
> *qdev,
> qxl_release_fence_buffer_objects(release);
>
> out_free_bos:
> - for (j = 0; j < num_relocs; j++) {
> - if (reloc_info[j].dst_bo != cmd_bo)
> -
> drm_gem_object_unreference_unlocked(&reloc_info[j].dst_bo->gem_base);
> - if (reloc_info[j].src_bo && reloc_info[j].src_bo != cmd_bo)
> -
> drm_gem_object_unreference_unlocked(&reloc_info[j].src_bo->gem_base);
> - }
> out_free_release:
> if (ret)
> qxl_release_free(qdev, release);
> --
> 2.1.0
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 09/11] Move main reference counter to GEM object instead of TTM ones
On 27 May 2015 at 20:04, Frediano Ziglio wrote: > qxl_bo structure has two reference counters, one in the GEM object and > another in the TTM object. The GEM object keep a counter to the TTM object > so when GEM counter reached zero the TTM counter (using qxl_bo_unref) was > decremented. The qxl object is fully freed (both GEM and TTM part are cleaned) > when the TTM counter reach zero. > One issue was that surface idr structure has no owning on qxl_bo objects > however > it contains a pointer to qxl_bo object. This caused some nasty race condition > for instance qxl_bo object was reaped even after counter was already zero. > This patch fix these races moving main counter (the one used by > qxl_bo_(un)ref) > to GEM object which cleanup routine (qxl_gem_object_free) remove the idr > pointer > (using qxl_surface_evict) when the counters are still valid. Uggh, but yes, not sure I like this fix for the problem, but if it works, Reviewed-by: Dave Airlie ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 11/11] Propagate correctly errors from qxlhw_handle_to_bo
On 27 May 2015 at 20:04, Frediano Ziglio wrote:
> This function could return a NULL pointer in case of handle not
> present and in case of out of memory conditions however caller
> function always returned EINVAL error hiding a possible ENOMEM.
> This patch change the function to return the error instead to
> be able to propagate the error instead of assuming EINVAL.
>
> Signed-off-by: Frediano Ziglio
Reviewed-by: Dave Airlie
> ---
> qxl/qxl_ioctl.c | 33 ++---
> 1 file changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/qxl/qxl_ioctl.c b/qxl/qxl_ioctl.c
> index bb326ff..37f1faf 100644
> --- a/qxl/qxl_ioctl.c
> +++ b/qxl/qxl_ioctl.c
> @@ -107,9 +107,9 @@ apply_surf_reloc(struct qxl_device *qdev, struct
> qxl_reloc_info *info)
> }
>
> /* return holding the reference to this object */
> -static struct qxl_bo *qxlhw_handle_to_bo(struct qxl_device *qdev,
> -struct drm_file *file_priv, uint64_t
> handle,
> -struct qxl_release *release)
> +static int qxlhw_handle_to_bo(struct qxl_device *qdev,
> + struct drm_file *file_priv, uint64_t handle,
> + struct qxl_release *release, struct qxl_bo
> **qbo_p)
> {
> struct drm_gem_object *gobj;
> struct qxl_bo *qobj;
> @@ -117,16 +117,17 @@ static struct qxl_bo *qxlhw_handle_to_bo(struct
> qxl_device *qdev,
>
> gobj = drm_gem_object_lookup(qdev->ddev, file_priv, handle);
> if (!gobj)
> - return NULL;
> + return -EINVAL;
>
> qobj = gem_to_qxl_bo(gobj);
>
> ret = qxl_release_list_add(release, qobj);
> drm_gem_object_unreference_unlocked(gobj);
> if (ret)
> - return NULL;
> + return ret;
>
> - return qobj;
> + *qbo_p = qobj;
> + return 0;
> }
>
> /*
> @@ -219,13 +220,10 @@ static int qxl_process_single_command(struct qxl_device
> *qdev,
> reloc_info[i].type = reloc.reloc_type;
>
> if (reloc.dst_handle) {
> - reloc_info[i].dst_bo = qxlhw_handle_to_bo(qdev,
> file_priv,
> -
> reloc.dst_handle, release);
> - if (!reloc_info[i].dst_bo) {
> - ret = -EINVAL;
> - reloc_info[i].src_bo = NULL;
> + ret = qxlhw_handle_to_bo(qdev, file_priv,
> reloc.dst_handle, release,
> +&reloc_info[i].dst_bo);
> + if (ret)
> goto out_free_bos;
> - }
> reloc_info[i].dst_offset = reloc.dst_offset;
> } else {
> reloc_info[i].dst_bo = cmd_bo;
> @@ -234,14 +232,11 @@ static int qxl_process_single_command(struct qxl_device
> *qdev,
> num_relocs++;
>
> /* reserve and validate the reloc dst bo */
> - if (reloc.reloc_type == QXL_RELOC_TYPE_BO || reloc.src_handle
> > 0) {
> - reloc_info[i].src_bo =
> - qxlhw_handle_to_bo(qdev, file_priv,
> - reloc.src_handle, release);
> - if (!reloc_info[i].src_bo) {
> - ret = -EINVAL;
> + if (reloc.reloc_type == QXL_RELOC_TYPE_BO ||
> reloc.src_handle) {
> + ret = qxlhw_handle_to_bo(qdev, file_priv,
> reloc.src_handle, release,
> +&reloc_info[i].src_bo);
> + if (ret)
> goto out_free_bos;
> - }
> reloc_info[i].src_offset = reloc.src_offset;
> } else {
> reloc_info[i].src_bo = NULL;
> --
> 2.1.0
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Do not loop on ERESTARTSYS using interruptible waits
On 19 May 2015 at 19:54, Frediano Ziglio wrote:
> This problem happens using KMS surfaces and QXL driver.
> To easy reproduce use KDE Plasma (which use surfaces a lot) and assure
> you are using KMS surfaces (QXL driver on Fedora/RedHat has a patch to
> stop using them). Open some complex application like LibreOffice and
> after a while your machine get stuck using 100% CPU on Xorg.
> The problem occurs as creating new surfaces not interruptible wait
> are used however instead of returning ERESTARTSYS back to userspace
> you try to loop but wait routines always keep returning ERESTARTSYS
> once the signal is marked.
> On out of memory conditions TTM module try to move objects to system
> memory and QXL assure surface is updated before the move.
> The fix handle differently this case using no interruptible wait so
> wait functions will wait instead of returning ERESTARTSYS.
> Note the when the loop occurs driver will send a lot of update requests
> causing more CPU usage on Qemu side too.
I actually don't think we should be enabling surfaces upstream, I
don't mind fixing
the kernel driver to not be crap, but I really don't think surfaces
really help the
SPICE protocol.
I should h ave pushed the disable surface in all cases upstream, feel free to do
so, they were a bad experiment, and nobody ever showed they were faster, or
at least when they hit eviction paths they didn't plummet down the
side of a massive
cliff.
The reason this loops in -ERESTARTSYS is that the hw craps itself if you try
and redo an operation, so you can't go back out to userspace and re-enter the
kernel, just one of many bad design points in the QXL hw.
you should probably drop wait_for_io_cmd completely.
Dave.
>
> Signed-off-by: Frediano Ziglio
> ---
> qxl/qxl_cmd.c | 12 +++-
> qxl/qxl_drv.h | 2 +-
> qxl/qxl_ioctl.c | 2 +-
> 3 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drivers/gpu/drm/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
> index 9782364..bd5404e 100644
> --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> @@ -317,14 +317,11 @@ static void wait_for_io_cmd(struct qxl_device *qdev,
> uint8_t val, long port)
> {
> int ret;
>
> -restart:
> ret = wait_for_io_cmd_user(qdev, val, port, false);
> - if (ret == -ERESTARTSYS)
> - goto restart;
> }
>
> int qxl_io_update_area(struct qxl_ddevice *qdev, struct qxl_bo *surf,
> - const struct qxl_rect *area)
> + const struct qxl_rect *area, bool intr)
> {
> int surface_id;
> uint32_t surface_width, surface_height;
> @@ -350,7 +347,7 @@ int qxl_io_update_area(struct qxl_device *qdev, struct
> qxl_bo *surf,
> mutex_lock(&qdev->update_area_mutex);
> qdev->ram_header->update_area = *area;
> qdev->ram_header->update_surface = surface_id;
> - ret = wait_for_io_cmd_user(qdev, 0, QXL_IO_UPDATE_AREA_ASYNC, true);
> + ret = wait_for_io_cmd_user(qdev, 0, QXL_IO_UPDATE_AREA_ASYNC, intr);
> mutex_unlock(&qdev->update_area_mutex);
> return ret;
> }
> @@ -588,10 +585,7 @@ int qxl_update_surface(struct qxl_device *qdev, struct
> qxl_bo *surf)
> rect.right = surf->surf.width;
> rect.top = 0;
> rect.bottom = surf->surf.height;
> -retry:
> - ret = qxl_io_update_area(qdev, surf, &rect);
> - if (ret == -ERESTARTSYS)
> - goto retry;
> + ret = qxl_io_update_area(qdev, surf, &rect, false);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/drivers/gpu/drm/qxl/qxl_drv.h b/qxl/qxl_drv.h
> index 7c6cafe..6745c44 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -462,7 +462,7 @@ void qxl_io_memslot_add(struct qxl_device *qdev, uint8_t
> id);
> void qxl_io_notify_oom(struct qxl_device *qdev);
>
> int qxl_io_update_area(struct qxl_device *qdev, struct qxl_bo *surf,
> - const struct qxl_rect *area);
> + const struct qxl_rect *area, bool intr);
>
> void qxl_io_reset(struct qxl_device *qdev);
> void qxl_io_monitors_config(struct qxl_device *qdev);
> diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/qxl/qxl_ioctl.c
> index b110883..afd7297 100644
> --- a/drivers/gpu/drm/qxl/qxl_ioctl.c
> +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
> @@ -348,7 +348,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev,
> void *data,
> goto out2;
> if (!qobj->surface_id)
> DRM_ERROR("got update area for surface with no id %d\n",
> update_area->handle);
> - ret = qxl_io_update_area(qdev, qobj, &area);
> + ret = qxl_io_update_area(qdev, qobj, &area, true);
>
> out2:
> qxl_bo_unreserve(qobj);
> --
> 2.1.0
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
__
Re: [Spice-devel] Improving spice-server code base
> Here is an alternative suggestion for branching: > Branch 0.12 will keep the current code and will be updated > mostly with bugfixes. > Branch master will hold the new code (version 0.13 while its > experimental and version 0.14 when it becomes stable again) > > This is also consistent with "older" branches (0.4 0.6 0.8 0.10) > > With this approach master will become unstable/experimental > for the (hopefully) short term. Yeah I think doing development in master is far better way, esp as it follow how most other projects work. I'd also encourage early commits of this sort of change rather than queuing up a lot of things. (not that I interact with spice repo much :-) Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] autoconf for slirp
this is quick and dirty, and not completely tested yet, but it makes
my life a little bit easier, since I
don't install stuff in /usr ever.
Dave.
From 1d0ed0d05742917bb1f665578f2cc0d6e8d64c8e Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Fri, 26 Mar 2010 17:57:22 +1000
Subject: [PATCH] slirp: auto/libtool support.
this just does a basic conversion to using autotools + libtool
---
Makefile | 91 --
Makefile.am | 28 ++
configure.ac | 27 +
slirp.pc | 11 ---
slirp.pc.in | 11 +++
5 files changed, 66 insertions(+), 102 deletions(-)
delete mode 100644 Makefile
create mode 100644 Makefile.am
create mode 100644 configure.ac
delete mode 100644 slirp.pc
create mode 100644 slirp.pc.in
diff --git a/Makefile b/Makefile
deleted file mode 100644
index 929af78..000
--- a/Makefile
+++ /dev/null
@@ -1,91 +0,0 @@
-CC = gcc
-
-CFLAGS = -fvisibility=hidden -fPIC -DPIC -Wall -Wno-sign-compare -Werror -fno-strict-overflow
-LDFLAGS = -fPIC
-TARGET = RELEASE
-
-ifeq ($(TARGET),DEBUG)
- CFLAGS += -g -O0
- TARGETNAME = debug
-else ifeq ($(TARGET),RELEASE)
- CFLAGS += -g -O3
- TARGETNAME = release
-else
- TARGETNAME = $(error Invalid TARGET. Use DEBUG or RELEASE)
-endif
-
-HEADERNAME = net_slirp.h
-LIBNAME = libslirp.so
-PCNAME = slirp.pc
-
-BIN = $(addprefix $(TARGETNAME)/, libslirp.so)
-
-INCLUDEDIR = /usr/include/libslirp
-LIBDIR = /usr/lib64
-PKGCONFIGDIR = /usr/lib64/pkgconfig
-
-SRCS =\
- bootp.c\
- cksum.c\
- debug.c\
- if.c\
- ip_icmp.c\
- ip_input.c\
- ip_output.c\
- mbuf.c\
- misc.c\
- sbuf.c\
- net_slirp.c\
- tcp_input.c\
- tcp_output.c\
- tcp_subr.c\
- tcp_timer.c\
- udp.c\
-socket.c\
-$(NULL)
-
-TMP = $(SRCS:.c=.o)
-OBJ = $(addprefix $(TARGETNAME)/, $(TMP))
-
-STATIC_LIBS =
-DYNAMIC_LIBS =
-
-LIBS = -Wl,-Bstatic $(addprefix -l, $(STATIC_LIBS)) -Wl,-Bdynamic $(addprefix -l, $(DYNAMIC_LIBS))
-
-all : $(BIN) link
-
-$(BIN) : $(TARGETNAME) $(OBJ)
- $(CC) -shared $(LDFLAGS) -o $(BIN) $(OBJ) $(LIBS)
-
-link : $(BIN)
- rm -f $(LIBNAME)
- ln -s $(BIN)
-
-MAKEDEPEND = $(CC) -M $(CFLAGS) -o $(addprefix $(TARGETNAME)/,.$*.dep.tmp) $<
-
-$(addprefix $(TARGETNAME)/, %.o) : %.c Makefile
- @$(MAKEDEPEND) && \
- cp $(addprefix $(TARGETNAME)/, .$*.dep.tmp) $(addprefix $(TARGETNAME)/, .$*.dep) && \
- sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \
- -e '/^$$/ d' -e 's/$$/ :/' < $(addprefix $(TARGETNAME)/,.$*.dep.tmp) >> $(addprefix $(TARGETNAME)/,.$*.dep) && \
- sed -i '1 s/^\(.\)/$(TARGETNAME)\/\1/' $(addprefix $(TARGETNAME)/, .$*.dep) && \
- rm -f $(addprefix $(TARGETNAME)/,.$*.dep.tmp)
- $(CC) $(CFLAGS) -c -o $@ $<
-
-clean:
- @rm -f $(TARGETNAME)/*.o $(TARGETNAME)/.*.dep $(TARGETNAME)/.*.dep.tmp $(BIN)
-
-$(TARGETNAME):
- @mkdir -p $(TARGETNAME)
-
--include $(patsubst %.c, $(TARGETNAME)/.%.dep, $(SRCS))
-
-install:
- mkdir -p $(DESTDIR)/$(INCLUDEDIR)
- cp $(LIBNAME) $(DESTDIR)/$(LIBDIR)
- cp $(HEADERNAME) $(DESTDIR)/$(INCLUDEDIR)
- cp $(PCNAME) $(DESTDIR)/$(PKGCONFIGDIR)
-uninstall:
- rm -f $(DESTDIR)/$(LIBDIR)/$(LIBNAME)
- rm -f $(DESTDIR)/$(INCLUDEDIR)/$(HEADERNAME)
- rm -f $(DESTDIR)/$(PKGCONFIGDIR)/$(PCNAME)
diff --git a/Makefile.am b/Makefile.am
new file mode 100644
index 000..688d149
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,28 @@
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = slirp.pc
+
+lib_LTLIBRARIES = libslirp.la
+
+libslirpinclude_HEADERS = net_slirp.h
+libslirpincludedir = $(includedir)
+
+libslirp_la_SOURCES= bootp.c \
+cksum.c\
+debug.c\
+if.c\
+ip_icmp.c\
+ip_input.c\
+ip_output.c\
+mbuf.c\
+misc.c\
+sbuf.c\
+net_slirp.c\
+tcp_input.c\
+tcp_output.c\
+tcp_subr.c\
+tcp_timer.c\
+udp.c\
+socket.c \
+ net_slirp.h
+
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..961df0b
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,27 @@
+AC_PREREQ([2.57])
+
+AC_INIT([libslirp],
+ 0.0.1,
+ [],
+ libslirp)
+dnl
+dnl This is the package version number, not the shared library
+dnl version. This same version number must appear in Xfont.h
+dnl Yes, it is a pain to synchronize version numbers. Unfortunately, it's
+dnl not possible to extract the version number here from Xfont.h
+dnl
+AM_INIT_AUTOMAKE([foreign dist-bzip2])
+AM_CONFIG_HEADER(config.h)
+
+# Check for progs
+AC_PROG_CC
+AC_PROG_LIBTOOL
+dnl If the first PKG_CHECK_MODULES appears inside a conditional, pkg-config
+dnl must first be located explicitly.
+PKG_PROG_PKG_CONFIG
+
+# Look for headers
+
+AC_OUTPUT([Makefile
+ slirp.pc])
+
diff --git a/slirp.pc b/slirp.pc
deleted file mode 100644
index d463103..000
--- a/slirp.pc
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=/usr/local
-exec_prefix=${prefix}
-libdir=/usr/lib64
-includedir=/usr/include
Re: [Spice-devel] spice performance
On Mon, Jun 7, 2010 at 2:21 AM, brian wrote: > >> That's the right device. Each PCI device has a vendor number, this shows >> you "Red Hat, Inc." since the device is developed by Red Hat. > > Good, well then the emulated hardware is correct, so why is the driver not > loaded? I followed the instructions here: > http://www.cs.rug.nl/~jurjen/ApprenticesNotes/ch28s06.html > > Step 6 says: "wget > http://xorg.freedesktop.org/releases/individual/driver/xf86-video-qxl-0.0.12.tar.gz > tar zxf xf86-video-qxl-0.0.12.tar.gz > cd xf86-video-qxl-0.0.12 > sudo apt-get install -y xorg-dev > sudo apt-get remove -s xserver-xorg-video-ati xserver-xorg-video-chips > xserver-xorg-video-cirrus xserver-xorg-video-i128 xserver-xorg-video-intel > xserver-xorg-video-mach64 xserver-xorg-video-mga > xserver-xorg-video-neomagic xserver-xorg-video-nv > xserver-xorg-video-openchrome xserver-xorg-video-r128 > xserver-xorg-video-radeon xserver-xorg-video-rendition > xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage > xserver-xorg-video-siliconmotion xserver-xorg-video-sis > xserver-xorg-video-sisusb xserver-xorg-video-tdfx > xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l > xserver-xorg-video-vesa xserver-xorg-video-vmware > xserver-xorg-video-voodoo > sudo apt-get remove nvidia-173-modaliases nvidia-185-kernel-source > nvidia-185-libvdpau nvidia-185-modaliases nvidia-96-modaliases > nvidia-common nvidia-glx-185 nvidia-settings > ./configure --libdir=/usr/lib64 --prefix=/usr > make > sudo make install" > > There were no obvious errors during the install, yet the drivers have not > been loaded. I'm at a loss for where to begin trying to troubleshoot. > Any ideas? Is there an additional step required to force Ubuntu to use > the new drivers? you most likely need an xorg.conf with qxl driver specified in it. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice performance
On Tue, Jun 8, 2010 at 12:16 PM, Brian Milliron wrote: > Thanks to everyone who helped with this issue. Turns out I was missing > a step of editing the xorg.conf file which I did manage to do.. only to > have the new driver promptly segfault on me. The folks over at xorg > pointed out it looks like a bug in qxl, and it appears to have been > reported here once already, ref: > http://www.mail-archive.com/spice-space-de...@lists.sourceforge.net/msg00166.html > > So I went ahead and submitted a bug report over at bugs.freedesktop.org > which I am assuming is the correct place to go. > https://bugs.freedesktop.org/show_bug.cgi?id=28432 > > So my question now is whether qxl works on any linux distro or only > windows? If the only way to get this working is to switch distros, I > might consider that, but if the only way is to switch to windows, I > think I'll have to find something else. > I've got an F12 working, I'm sure F13 should work as well, but it might be some spice/qxl version interaction that is stopping it working for you, I haven't been tracking the qxl interface development. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 18 guest's GUI is slow. Due to 3D driver?
On Sat, Jan 26, 2013 at 12:05 PM, Jeremy White wrote: > >>> Have we really looked into this? I feel like we're all just throwing >>> our hands up in horror without seeing if there is anything we can do. >> >> Be my guest. I'm not a programmer. >> >> I can tell you that I'm not aware of anyone doing accelerated 3D stuff in >> a remoting protocol. Perhaps PC-over-IP (VMware View) does?!? >> >> 3D is listed as a future feature. :) >> http://www.spice-space.org/features.html > > > Right; I think the issue is that what we have right now is unbearably bad; > and I think that's a bug. > I suspect that 'bearably bad' is within our reach. Doing it well, now > that's a feature... The full screens are probably due to the compositor doing a page flip, but I guess that is due to some short-cut path missing that would cause it to use a sub buffer copy. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] xorg driver cleanups
On Tue, Feb 26, 2013 at 3:48 AM, Alon Levy wrote: >> On 02/24/2013 11:31 PM, airl...@gmail.com wrote: >> > Hi, >> > >> > these patches just move code around in the X.org driver so it looks >> > more >> > like something that can be maintained, I'm going to start adding >> > KMS support >> > to it soon and i'd like to get stuff split out a bit better with an >> > eye towards >> > that. >> >> Yay! >> >> > >> > I had to rebase these and I think I got caught all the recent >> > changes but who >> > knows. X at least starts fine afterwards. >> >> Starts here for me, and my simplest smoke tests function. >> >> But git-am does complain bitterly about added whitespace... Well the whitespace is possibly already there and I'm just moving it around! > I guess I was also ignoring the small problems, that and that the first patch > says moving but only contains the addition, the removal happens in the next > patch. Oh that seems like bad split I'll fix it. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] xorg driver cleanups
> > Well the whitespace is possibly already there and I'm just moving it around! yeah its all cut-n-paste whitespace damage, so the current tree is hardly in a good place, I've cleaned up some of it in the moving code around. >> I guess I was also ignoring the small problems, that and that the first >> patch says moving but only contains the addition, the removal happens in the >> next patch. > > Oh that seems like bad split I'll fix it. Okay that one is a mistake, I've fixed that, Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] qxl X.org driver bo abstraction for user mode setting
Hi, Okay this is the next chunk of prep for getting KMS into the driver, the first 8 patches are just preparation work and moving stuff around, along with a couple of minor fixes. The big guy on the end adds the BO abstraction layer, and makes all the code use it, it doesn't contain any kms code, it prepares the way for it. I've probably broken xspice with this lot! Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/9] qxl: split surface struct out into its own header file.
This is just ground work for kms addition.
Signed-off-by: Dave Airlie
---
src/Makefile.am | 2 ++
src/qxl_surface.c | 48 +---
src/qxl_surface.h | 52
3 files changed, 55 insertions(+), 47 deletions(-)
create mode 100644 src/qxl_surface.h
diff --git a/src/Makefile.am b/src/Makefile.am
index b8d0d3e..82ed0cc 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -41,6 +41,7 @@ qxl_drv_la_SOURCES = \
qxl_driver.c\
qxl_image.c \
qxl_surface.c \
+ qxl_surface.h \
qxl_ring.c \
qxl_mem.c \
mspace.c\
@@ -85,6 +86,7 @@ spiceqxl_drv_la_SOURCES = \
qxl_driver.c\
qxl_image.c \
qxl_surface.c \
+ qxl_surface.h \
qxl_ring.c \
qxl_mem.c \
mspace.c\
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index 3da9079..84f221b 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -48,7 +48,7 @@
#endif
#include "qxl.h"
-
+#include "qxl_surface.h"
#ifdef DEBUG_SURFACE_LIFECYCLE
#include
@@ -57,52 +57,6 @@ static FILE* surface_log;
typedef struct evacuated_surface_t evacuated_surface_t;
-struct qxl_surface_t
-{
-surface_cache_t*cache;
-
-uint32_t id;
-
-pixman_image_t * dev_image;
-pixman_image_t * host_image;
-
-uxa_access_t access_type;
-RegionRec access_region;
-
-void * address;
-void * end;
-
-qxl_surface_t *next;
-qxl_surface_t *prev; /* Only used in the 'live'
-* chain in the surface cache
-*/
-
-intin_use;
-intbpp;/* bpp of the pixmap */
-intref_count;
-
-PixmapPtr pixmap;
-
-struct evacuated_surface_t *evacuated;
-
-union
-{
- qxl_surface_t *copy_src;
- Pixel solid_pixel;
-
- struct
- {
- int op;
- PicturePtr src_picture;
- PicturePtr mask_picture;
- PicturePtr dest_picture;
- qxl_surface_t *src;
- qxl_surface_t *mask;
- qxl_surface_t *dest;
- } composite;
-} u;
-};
-
struct evacuated_surface_t
{
pixman_image_t *image;
diff --git a/src/qxl_surface.h b/src/qxl_surface.h
new file mode 100644
index 000..450a563
--- /dev/null
+++ b/src/qxl_surface.h
@@ -0,0 +1,52 @@
+#ifndef QXL_SURFACE_H
+#define QXL_SURFACE_H
+
+struct evacuated_surface_t;
+
+struct qxl_surface_t
+{
+surface_cache_t*cache;
+
+uint32_t id;
+
+pixman_image_t * dev_image;
+pixman_image_t * host_image;
+
+uxa_access_t access_type;
+RegionRec access_region;
+
+void * address;
+void * end;
+
+qxl_surface_t *next;
+qxl_surface_t *prev; /* Only used in the 'live'
+* chain in the surface cache
+*/
+
+intin_use;
+intbpp;/* bpp of the pixmap */
+intref_count;
+
+PixmapPtr pixmap;
+
+struct evacuated_surface_t *evacuated;
+
+union
+{
+ qxl_surface_t *copy_src;
+ Pixel solid_pixel;
+
+ struct
+ {
+ int op;
+ PicturePtr src_picture;
+ PicturePtr mask_picture;
+ PicturePtr dest_picture;
+ qxl_surface_t *src;
+ qxl_surface_t *mask;
+ qxl_surface_t *dest;
+ } composite;
+} u;
+};
+
+#endif
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 2/9] qxl: pass qxl instead of surface cache to some functions
This is more preparation work for adding bo abstraction layer.
Signed-off-by: Dave Airlie
---
src/qxl.h | 4 ++--
src/qxl_driver.c | 2 +-
src/qxl_surface.c | 13 +++--
src/qxl_uxa.c | 2 +-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/qxl.h b/src/qxl.h
index 941a2ad..2d1840a 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -346,10 +346,10 @@ int qxl_ring_cons(struct qxl_ring
*ring);
* Surface
*/
surface_cache_t * qxl_surface_cache_create (qxl_screen_t *qxl);
-qxl_surface_t *qxl_surface_cache_create_primary (surface_cache_t
*qxl,
+qxl_surface_t *qxl_surface_cache_create_primary (qxl_screen_t *qxl,
struct QXLMode *mode);
void * qxl_surface_get_host_bits(qxl_surface_t *surface);
-qxl_surface_t *qxl_surface_create (surface_cache_t *qxl,
+qxl_surface_t *qxl_surface_create (qxl_screen_t *qxl,
int width,
int height,
int bpp);
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index e488020..9a8de82 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -484,7 +484,7 @@ qxl_create_primary(qxl_screen_t *qxl)
pm->y_mili = 0; // TODO
pm->orientation = 0; // ? supported by us for single head usage? more TODO
-return qxl_surface_cache_create_primary (qxl->surface_cache,
&qxl->primary_mode);
+return qxl_surface_cache_create_primary (qxl, &qxl->primary_mode);
}
static Bool
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index 84f221b..d95054b 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -315,17 +315,17 @@ qxl_surface_recycle (surface_cache_t *cache, uint32_t id)
* will be the containing virtual size.
*/
qxl_surface_t *
-qxl_surface_cache_create_primary (surface_cache_t *cache,
+qxl_surface_cache_create_primary (qxl_screen_t *qxl,
struct QXLMode*mode)
{
struct QXLRam *ram_header =
- (void *)((unsigned long)cache->qxl->ram +
cache->qxl->rom->ram_header_offset);
+ (void *)((unsigned long)qxl->ram + qxl->rom->ram_header_offset);
struct QXLSurfaceCreate *create = &(ram_header->create_surface);
pixman_format_code_t format;
uint8_t *dev_addr;
pixman_image_t *dev_image, *host_image;
qxl_surface_t *surface;
-qxl_screen_t *qxl = cache->qxl;
+surface_cache_t *cache = qxl->surface_cache;
if (mode->bits == 16)
{
@@ -656,14 +656,15 @@ retry:
}
qxl_surface_t *
-qxl_surface_create (surface_cache_t *cache,
+qxl_surface_create (qxl_screen_t *qxl,
int width,
int height,
int bpp)
{
qxl_surface_t *surface;
+surface_cache_t *cache = qxl->surface_cache;
-if (!cache->qxl->enable_surfaces)
+if (!qxl->enable_surfaces)
return NULL;
if ((bpp & 3) != 0)
@@ -1208,7 +1209,7 @@ qxl_surface_cache_replace_all (surface_cache_t *cache,
void *data)
int height = pixman_image_get_height (ev->image);
qxl_surface_t *surface;
- surface = qxl_surface_create (cache, width, height, ev->bpp);
+ surface = qxl_surface_create (cache->qxl, width, height, ev->bpp);
assert (surface->host_image);
assert (surface->dev_image);
diff --git a/src/qxl_uxa.c b/src/qxl_uxa.c
index e81df4f..fd70488 100644
--- a/src/qxl_uxa.c
+++ b/src/qxl_uxa.c
@@ -358,7 +358,7 @@ qxl_create_pixmap (ScreenPtr screen, int w, int h, int
depth, unsigned usage)
goto fallback;
}
-surface = qxl_surface_create (qxl->surface_cache, w, h, depth);
+surface = qxl_surface_create (qxl, w, h, depth);
if (surface)
{
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 3/9] qxl_surface: move to using struct to avoid ordering issues with typedef.
Signed-off-by: Dave Airlie
---
src/qxl_surface.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/qxl_surface.h b/src/qxl_surface.h
index 450a563..e57d282 100644
--- a/src/qxl_surface.h
+++ b/src/qxl_surface.h
@@ -18,8 +18,8 @@ struct qxl_surface_t
void * address;
void * end;
-qxl_surface_t *next;
-qxl_surface_t *prev; /* Only used in the 'live'
+struct qxl_surface_t * next;
+struct qxl_surface_t * prev; /* Only used in the 'live'
* chain in the surface cache
*/
@@ -33,7 +33,7 @@ struct qxl_surface_t
union
{
- qxl_surface_t *copy_src;
+ struct qxl_surface_t *copy_src;
Pixel solid_pixel;
struct
@@ -42,9 +42,9 @@ struct qxl_surface_t
PicturePtr src_picture;
PicturePtr mask_picture;
PicturePtr dest_picture;
- qxl_surface_t *src;
- qxl_surface_t *mask;
- qxl_surface_t *dest;
+ struct qxl_surface_t*src;
+ struct qxl_surface_t*mask;
+ struct qxl_surface_t*dest;
} composite;
} u;
};
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 4/9] qxl: fix memory leak on driver exit.
We were leaking two allocations on driver exit.
Signed-off-by: Dave Airlie
---
src/qxl_driver.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index 9a8de82..73c7534 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -258,10 +258,15 @@ qxl_unmap_memory (qxl_screen_t *qxl)
{
qxl_mem_free_all (qxl->mem);
qxl_drop_image_cache (qxl);
+ free(qxl->mem);
+ qxl->mem = NULL;
}
-if (qxl->surf_mem)
+if (qxl->surf_mem) {
qxl_mem_free_all (qxl->surf_mem);
+ free(qxl->surf_mem);
+ qxl->surf_mem = NULL;
+}
unmap_memory_helper (qxl);
qxl->ram = qxl->ram_physical = qxl->vram = qxl->rom = NULL;
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 5/9] qxl: split common pre init code out from qxl pre init
This just moves the options parsing and color setup calls
to a separate function.
Signed-off-by: Dave Airlie
---
src/qxl_driver.c | 76 +---
1 file changed, 45 insertions(+), 31 deletions(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index 73c7534..21bac83 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -956,6 +956,49 @@ qxl_check_device (ScrnInfoPtr pScrn, qxl_screen_t *qxl)
#endif /* !XSPICE */
static Bool
+qxl_pre_init_common(ScrnInfoPtr pScrn)
+{
+int scrnIndex = pScrn->scrnIndex;
+qxl_screen_t *qxl = pScrn->driverPrivate;
+
+if (!qxl_color_setup (pScrn))
+ goto out;
+
+/* option parsing and card differentiation */
+xf86CollectOptions (pScrn, NULL);
+memcpy (qxl->options, DefaultOptions, sizeof (DefaultOptions));
+xf86ProcessOptions (scrnIndex, pScrn->options, qxl->options);
+
+qxl->enable_image_cache =
+xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_IMAGE_CACHE, TRUE);
+qxl->enable_fallback_cache =
+xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_FALLBACK_CACHE,
TRUE);
+qxl->enable_surfaces =
+xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_SURFACES, TRUE);
+qxl->num_heads =
+get_int_option (qxl->options, OPTION_NUM_HEADS, "QXL_NUM_HEADS");
+
+#ifdef XSPICE
+qxl->deferred_fps = get_int_option(qxl->options,
OPTION_SPICE_DEFERRED_FPS, "XSPICE_DEFERRED_FPS");
+if (qxl->deferred_fps > 0)
+xf86DrvMsg(scrnIndex, X_INFO, "Deferred FPS: %d\n", qxl->deferred_fps);
+else
+xf86DrvMsg(scrnIndex, X_INFO, "Deferred Frames: Disabled\n");
+#endif
+
+xf86DrvMsg (scrnIndex, X_INFO, "Offscreen Surfaces: %s\n",
+qxl->enable_surfaces ? "Enabled" : "Disabled");
+xf86DrvMsg (scrnIndex, X_INFO, "Image Cache: %s\n",
+qxl->enable_image_cache ? "Enabled" : "Disabled");
+xf86DrvMsg (scrnIndex, X_INFO, "Fallback Cache: %s\n",
+qxl->enable_fallback_cache ? "Enabled" : "Disabled");
+
+return TRUE;
+out:
+return FALSE;
+}
+
+static Bool
qxl_pre_init (ScrnInfoPtr pScrn, int flags)
{
int scrnIndex = pScrn->scrnIndex;
@@ -1003,39 +1046,10 @@ qxl_pre_init (ScrnInfoPtr pScrn, int flags)
}
#endif /* XSPICE */
pScrn->monitor = pScrn->confScreen->monitor;
-
-if (!qxl_color_setup (pScrn))
+
+if (!qxl_pre_init_common(pScrn))
goto out;
-
-/* option parsing and card differentiation */
-xf86CollectOptions (pScrn, NULL);
-memcpy (qxl->options, DefaultOptions, sizeof (DefaultOptions));
-xf86ProcessOptions (scrnIndex, pScrn->options, qxl->options);
-
-qxl->enable_image_cache =
-xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_IMAGE_CACHE, TRUE);
-qxl->enable_fallback_cache =
-xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_FALLBACK_CACHE,
TRUE);
-qxl->enable_surfaces =
-xf86ReturnOptValBool (qxl->options, OPTION_ENABLE_SURFACES, TRUE);
-qxl->num_heads =
-get_int_option (qxl->options, OPTION_NUM_HEADS, "QXL_NUM_HEADS");
-
-#ifdef XSPICE
-qxl->deferred_fps = get_int_option(qxl->options,
OPTION_SPICE_DEFERRED_FPS, "XSPICE_DEFERRED_FPS");
-if (qxl->deferred_fps > 0)
-xf86DrvMsg(scrnIndex, X_INFO, "Deferred FPS: %d\n", qxl->deferred_fps);
-else
-xf86DrvMsg(scrnIndex, X_INFO, "Deferred Frames: Disabled\n");
-#endif
-xf86DrvMsg (scrnIndex, X_INFO, "Offscreen Surfaces: %s\n",
-qxl->enable_surfaces ? "Enabled" : "Disabled");
-xf86DrvMsg (scrnIndex, X_INFO, "Image Cache: %s\n",
-qxl->enable_image_cache ? "Enabled" : "Disabled");
-xf86DrvMsg (scrnIndex, X_INFO, "Fallback Cache: %s\n",
-qxl->enable_fallback_cache ? "Enabled" : "Disabled");
-
if (!qxl_map_memory (qxl, scrnIndex))
goto out;
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 6/9] qxl_edid: add missing config.h
Signed-off-by: Dave Airlie --- src/qxl_edid.c | 4 1 file changed, 4 insertions(+) diff --git a/src/qxl_edid.c b/src/qxl_edid.c index de52f11..adaab61 100644 --- a/src/qxl_edid.c +++ b/src/qxl_edid.c @@ -44,6 +44,10 @@ *Dave Airlie */ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + #include #include #include -- 1.8.1.2 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 7/9] qxl: pass surface struct instead of ids in drawable functions.
this just changes it so we pass the surfaces not just the ids.
Signed-off-by: Dave Airlie
---
src/qxl_surface.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index d95054b..90cf8c6 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -437,7 +437,7 @@ enum ROPDescriptor
};
static struct QXLDrawable *
-make_drawable (qxl_screen_t *qxl, int surface, uint8_t type,
+make_drawable (qxl_screen_t *qxl, qxl_surface_t *surf, uint8_t type,
const struct QXLRect *rect
/* , pRegion clip */)
{
@@ -451,7 +451,11 @@ make_drawable (qxl_screen_t *qxl, int surface, uint8_t
type,
drawable->type = type;
-drawable->surface_id = surface;/* Only primary for now */
+if (surf)
+ drawable->surface_id = surf->id;/* Only primary for now
*/
+else
+ drawable->surface_id = 0;
+
drawable->effect = QXL_EFFECT_OPAQUE;
drawable->self_bitmap = 0;
drawable->self_bitmap_area.top = 0;
@@ -502,12 +506,12 @@ push_drawable (qxl_screen_t *qxl, struct QXLDrawable
*drawable)
}
static void
-submit_fill (qxl_screen_t *qxl, int id,
+submit_fill (qxl_screen_t *qxl, qxl_surface_t *surf,
const struct QXLRect *rect, uint32_t color)
{
struct QXLDrawable *drawable;
-drawable = make_drawable (qxl, id, QXL_DRAW_FILL, rect);
+drawable = make_drawable (qxl, surf, QXL_DRAW_FILL, rect);
drawable->u.fill.brush.type = SPICE_BRUSH_TYPE_SOLID;
drawable->u.fill.brush.u.color = color;
@@ -999,7 +1003,7 @@ real_upload_box (qxl_surface_t *surface, int x1, int y1,
int x2, int y2)
rect.top = y1;
rect.bottom = y2;
-drawable = make_drawable (qxl, surface->id, QXL_DRAW_COPY, &rect);
+drawable = make_drawable (qxl, surface, QXL_DRAW_COPY, &rect);
drawable->u.copy.src_area = rect;
translate_rect (&drawable->u.copy.src_area);
drawable->u.copy.rop_descriptor = ROPD_OP_PUT;
@@ -1061,7 +1065,7 @@ upload_one_primary_region(qxl_screen_t *qxl, PixmapPtr
pixmap, BoxPtr b)
rect.top = b->y1;
rect.bottom = b->y2;
-drawable = make_drawable (qxl, 0, QXL_DRAW_COPY, &rect);
+drawable = make_drawable (qxl, NULL, QXL_DRAW_COPY, &rect);
drawable->u.copy.src_area = rect;
translate_rect (&drawable->u.copy.src_area);
drawable->u.copy.rop_descriptor = ROPD_OP_PUT;
@@ -1294,7 +1298,7 @@ qxl_surface_solid (qxl_surface_t *destination,
p = destination->u.solid_pixel;
-submit_fill (qxl, destination->id, &qrect, p);
+submit_fill (qxl, destination, &qrect, p);
}
/* copy */
@@ -1335,7 +1339,7 @@ qxl_surface_copy (qxl_surface_t *dest,
if (dest->id == dest->u.copy_src->id)
{
- drawable = make_drawable (qxl, dest->id, QXL_COPY_BITS, &qrect);
+ drawable = make_drawable (qxl, dest, QXL_COPY_BITS, &qrect);
drawable->u.copy_bits.src_pos.x = src_x1;
drawable->u.copy_bits.src_pos.y = src_y1;
@@ -1352,7 +1356,7 @@ qxl_surface_copy (qxl_surface_t *dest,
image->descriptor.height = 0;
image->surface_image.surface_id = dest->u.copy_src->id;
- drawable = make_drawable (qxl, dest->id, QXL_DRAW_COPY, &qrect);
+ drawable = make_drawable (qxl, dest, QXL_DRAW_COPY, &qrect);
drawable->u.copy.src_bitmap = physical_address (qxl, image,
qxl->main_mem_slot);
drawable->u.copy.src_area.left = src_x1;
@@ -1505,7 +1509,7 @@ qxl_surface_composite (qxl_surface_t *dest,
rect.top = dest_y;
rect.bottom = dest_y + height;
-drawable = make_drawable (qxl, dest->id, QXL_DRAW_COMPOSITE, &rect);
+drawable = make_drawable (qxl, dest, QXL_DRAW_COMPOSITE, &rect);
composite = &drawable->u.composite;
@@ -1583,7 +1587,7 @@ qxl_surface_put_image (qxl_surface_t *dest,
rect.top = y;
rect.bottom = y + height;
-drawable = make_drawable (qxl, dest->id, QXL_DRAW_COPY, &rect);
+drawable = make_drawable (qxl, dest, QXL_DRAW_COPY, &rect);
drawable->u.copy.src_area.top = 0;
drawable->u.copy.src_area.bottom = height;
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 8/9] qxl: add direct pointer from qxl surface to qxl screen
This is prep work to allow the cache to be bypassed for kms.
Signed-off-by: Dave Airlie
---
src/qxl_surface.c | 12 +++-
src/qxl_surface.h | 3 ++-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index 90cf8c6..eaf1761 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -157,6 +157,7 @@ surface_cache_init (surface_cache_t *cache, qxl_screen_t
*qxl)
{
cache->all_surfaces[i].id = i;
cache->all_surfaces[i].cache = cache;
+ cache->all_surfaces[i].qxl = qxl;
cache->all_surfaces[i].dev_image = NULL;
cache->all_surfaces[i].host_image = NULL;
cache->all_surfaces[i].evacuated = NULL;
@@ -376,6 +377,7 @@ qxl_surface_cache_create_primary (qxl_screen_t *qxl,
surface->dev_image = dev_image;
surface->host_image = host_image;
surface->cache = cache;
+surface->qxl = qxl;
surface->bpp = mode->bits;
surface->next = NULL;
surface->prev = NULL;
@@ -994,7 +996,7 @@ real_upload_box (qxl_surface_t *surface, int x1, int y1,
int x2, int y2)
struct QXLRect rect;
struct QXLDrawable *drawable;
struct QXLImage *image;
-qxl_screen_t *qxl = surface->cache->qxl;
+qxl_screen_t *qxl = surface->qxl;
uint32_t *data;
int stride;
@@ -1287,7 +1289,7 @@ qxl_surface_solid (qxl_surface_t *destination,
intx2,
inty2)
{
-qxl_screen_t *qxl = destination->cache->qxl;
+qxl_screen_t *qxl = destination->qxl;
struct QXLRect qrect;
uint32_t p;
@@ -1323,7 +1325,7 @@ qxl_surface_copy (qxl_surface_t *dest,
int dest_x1, int dest_y1,
int width, int height)
{
-qxl_screen_t *qxl = dest->cache->qxl;
+qxl_screen_t *qxl = dest->qxl;
struct QXLDrawable *drawable;
struct QXLRect qrect;
@@ -1475,7 +1477,7 @@ qxl_surface_composite (qxl_surface_t *dest,
int dest_x, int dest_y,
int width, int height)
{
-qxl_screen_t *qxl = dest->cache->qxl;
+qxl_screen_t *qxl = dest->qxl;
PicturePtr src = dest->u.composite.src_picture;
qxl_surface_t *qsrc = dest->u.composite.src;
PicturePtr mask = dest->u.composite.mask_picture;
@@ -1578,7 +1580,7 @@ qxl_surface_put_image (qxl_surface_t *dest,
const char *src, int src_pitch)
{
struct QXLDrawable *drawable;
-qxl_screen_t *qxl = dest->cache->qxl;
+qxl_screen_t *qxl = dest->qxl;
struct QXLRect rect;
struct QXLImage *image;
diff --git a/src/qxl_surface.h b/src/qxl_surface.h
index e57d282..0f05d9d 100644
--- a/src/qxl_surface.h
+++ b/src/qxl_surface.h
@@ -6,7 +6,8 @@ struct evacuated_surface_t;
struct qxl_surface_t
{
surface_cache_t*cache;
-
+
+qxl_screen_t *qxl;
uint32_t id;
pixman_image_t * dev_image;
--
1.8.1.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 9/9] qxl: abstract object allocation away from surface/image/cursor code
This abstracts the object bo/surface allocation away from the user code.
The idea is we can then plug in a KMS backend for this abstraction and mostly
keep the surrounding code intact.
This is probably the biggest change to the driver in terms of impact of KMS
code on UMS code. At the moment I'm storing linked list of bos for release
handling, and that might be better done with a different data structure,
since we are looking them up by phy_addr, either a hash table or some sort
of rb tree perhaps, rather than a linear search.
This commit also starts usign the xorg list macros, which may require
some compat code to work in history.
Signed-off-by: Dave Airlie
---
src/qxl.h | 52 +++--
src/qxl_cursor.c | 52 +
src/qxl_driver.c | 8 +-
src/qxl_image.c | 69 +++
src/qxl_mem.c | 343 +-
src/qxl_surface.c | 302 +--
src/qxl_surface.h | 4 +-
src/qxl_uxa.c | 6 +-
8 files changed, 605 insertions(+), 231 deletions(-)
diff --git a/src/qxl.h b/src/qxl.h
index 2d1840a..9eb249c 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -45,6 +45,7 @@
#include "micmap.h"
#include "uxa/uxa.h"
+#include "list.h"
#ifndef XSPICE
#ifdef XSERVER_PCIACCESS
#include "pciaccess.h"
@@ -139,6 +140,42 @@ enum {
QXL_DEVICE_PRIMARY_CREATED,
};
+struct qxl_bo;
+/*
+ * for relocations
+ * dst_bo + dst_offset are the bo and offset into it the reloc is being
written,
+ * src_bo is the bo who's offset is being relocated.
+ */
+struct qxl_bo_funcs {
+struct qxl_bo *(*bo_alloc)(qxl_screen_t *qxl, unsigned long size, const
char *name);
+struct qxl_bo *(*cmd_alloc)(qxl_screen_t *qxl, unsigned long size, const
char *name);
+void *(*bo_map)(struct qxl_bo *bo);
+void (*bo_unmap)(struct qxl_bo *bo);
+void (*bo_decref)(qxl_screen_t *qxl, struct qxl_bo *bo);
+void (*bo_incref)(qxl_screen_t *qxl, struct qxl_bo *bo);
+void (*bo_output_bo_reloc)(qxl_screen_t *qxl, uint32_t dst_offset,
+ struct qxl_bo *dst_bo, struct qxl_bo *src_bo);
+void (*write_command)(qxl_screen_t *qxl, uint32_t type, struct qxl_bo *bo);
+void (*update_area)(qxl_surface_t *surf, int x1, int y1, int x2, int y2);
+struct qxl_bo *(*create_primary)(qxl_screen_t *qxl, uint32_t width,
uint32_t height, int32_t stride, uint32_t format);
+void (*destroy_primary)(qxl_screen_t *qxl, struct qxl_bo *primary_bo);
+
+qxl_surface_t *(*create_surface)(qxl_screen_t *qxl, int width,
+int height, int bpp);
+void (*destroy_surface)(qxl_surface_t *surf);
+
+void (*bo_output_surf_reloc)(qxl_screen_t *qxl, uint32_t dst_offset,
+struct qxl_bo *dst_bo,
+qxl_surface_t *surf);
+ /* surface create / destroy */
+};
+
+void qxl_ums_setup_funcs(qxl_screen_t *qxl);
+
+/* ums specific functions */
+struct qxl_bo *qxl_ums_surf_mem_alloc(qxl_screen_t *qxl, uint32_t size);
+struct qxl_bo *qxl_ums_lookup_phy_addr(qxl_screen_t *qxl, uint64_t phy_addr);
+
struct _qxl_screen_t
{
/* These are the names QXL uses */
@@ -153,7 +190,7 @@ struct _qxl_screen_t
struct qxl_ring * release_ring;
int device_primary;
-
+struct qxl_bo * primary_bo;
intnum_modes;
struct QXLMode * modes;
intio_base;
@@ -268,6 +305,9 @@ struct _qxl_screen_t
uint32_t deferred_fps;
#endif /* XSPICE */
+
+struct xorg_list ums_bos;
+struct qxl_bo_funcs *bo_funcs;
};
typedef struct qxl_output_private {
@@ -461,7 +501,7 @@ void qxl_allocate_monitors_config (qxl_screen_t *qxl);
/*
* Images
*/
-struct QXLImage *qxl_image_create (qxl_screen_t *qxl,
+struct qxl_bo *qxl_image_create (qxl_screen_t *qxl,
const uint8_t *data,
int x,
int y,
@@ -471,7 +511,7 @@ struct QXLImage *qxl_image_create (qxl_screen_t
*qxl,
int Bpp,
Boolfallback);
void qxl_image_destroy(qxl_screen_t *qxl,
- struct QXLImage *image);
+ struct qxl_bo *bo);
void qxl_drop_image_cache (qxl_screen_t *qxl);
@@ -484,12 +524,6 @@ struct qxl_mem * qxl_mem_create (void
*base,
unsigned long n_bytes);
void qxl_mem_dump_stats (struct qxl_mem *mem,
Re: [Spice-devel] qxl X.org driver bo abstraction for user mode setting
On Wed, Feb 27, 2013 at 1:15 AM, Jeremy White wrote: > Hey Dave, > > On 02/25/2013 10:32 PM, Dave Airlie wrote: >> Hi, >> >> Okay this is the next chunk of prep for getting KMS into the driver, >> the first 8 patches are just preparation work and moving stuff around, >> along with a couple of minor fixes. >> >> The big guy on the end adds the BO abstraction layer, and makes all >> the code use it, it doesn't contain any kms code, it prepares the way for it. >> >> I've probably broken xspice with this lot! > > I'm interested in tracking this to avoid that fate for xspice. Can you > give me a cluebat to 'bo abstraction' so I know what we're talking about? Well it shouldn't change anything from Xspice execpt I broke the build or something. But essentially instead of having the core rendering routines in UXA/surface code talk directly to the hardware, we introduce an abstraction layer so the routines use generic buffer object based interfaces. Then when I plug in KMS as a backend we don't have lots of ugly ifdefs or hacks. For Xspice using the UMS codepaths is always the right thing. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] UMS memory management
> > Can you please explain how all this relates to Dave's work on the KMS? He > mentioned that he implemented paging there as well. Well we won't be using the KMS driver in RHEL6, so we need to improve the old UMS driver for that use case. Though I expect UMS eviction will hit the same problems I hit with KMS, drawables that never get released, until you poke OOM. I think the interfaces you suggested would work okay, ssp from my testing with cairo-perf traces we got some 14MB allocations, if we can't evict one of those for some reason you are pretty much locked out. The other problem is that surface create cmds are implicitly pinned while the surface is active, which can create some pretty brutal fragmentation in the non-surface RAM area. I ended up suballocating all the surface creates/destroys in their own area and pinning them in KMS land, brutal but the only way I could make it work. Best explained I suppose as you don't get surface create cmd in signalled in the release ring until after the surface destroy command is sent. So having infinite surfaces just means you are going to run out of non-surface command RAM after another while. I'm not really sure the amount of information that is stored in surface create command really justifies it being pinned, the server should probably duplicate it and release the cmd ring area for the create. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] any dev plan for NVIDIA GRID
> hi，all. > > is there any dev plan for NVIDIA GRID ? > I saw that citrix is ready for it. how about kvm ? > I think it is the big hardware progress in VDI, and what is the plan of kvm > for supporting it ? > All pieces are closed source, so it would require work on reverse engineering, and probably using the nouveau project. So I don't think anyone has looked into actually doing it yet. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-gtk] any roadmap for supporting of OpenGL ?
> > There are any roadmap for OpenGL ? it will be expecting :) No, Its under investigation, by which I mean when its ready. But I am actually doing a lot of full time work on it at present, but quite when that work will a) be ready to demonstrate b) be actually useable is very indeterminate, also what form it will take wrt how much of spice display framework it will use are also unknown. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Broken xf86-video-qxl commit
> > commit 3e37b2c38f661b0b8e285cfa7f0549aa3d216eb5 > Author: Dave Airlie > Date: Thu May 9 13:43:57 2013 +1000 > > qxl: add KMS support v1.2 > > Avoid DRI create busid symbol for now. > fix warnings. > > Creates this error for me: > > qxl.h:189:21: fatal error: qxl_drm.h: No such file or directory > > This appears to be because I don't have a very recent mesa/drm. I'm not > sure what the best fix is; I would think we could detect my 'old' > environment at configure time. Perhaps my environment was deceptive. I'll add a libdrm version check tomorrow to the configure.ac. > Also, forgive me if I missed it, but I do not see that patch posted > anywhere publicly; it appears to have just been silently pushed. Full > disclosure, I probably wouldn't have reviewed it either way, but it > seems like a bad habit to encourage. So consider this a grumping . You can still review it :) The main reason I pushed it was a certain person was pushing to get dfps into Fedora, and since we had the KMS patch in there already rebasing it was getting to be a pain, so I just realigned things, but yeah I'll try not do it again. Though the KMS driver still needs more work, I need to find some way to notice we are running a 3D compositor and to stop any remoting for the non-primary surface, otherwise it does still send a lot of pointless stuff to the remote, and also does a fair bit of stalling in the guest on update areas to do readback, when we should have just rendered stuff with pixman in the guest. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Broken xf86-video-qxl commit
>> >> Though the KMS driver still needs more work, I need to find some way >> to notice we are running a 3D compositor and to stop any remoting for >> the non-primary surface, otherwise it does still send a lot of >> pointless stuff to the remote, and also does a fair bit of stalling in >> the guest on update areas to do readback, when we should have just >> rendered stuff with pixman in the guest. > > Yah; I've been swamped with some other stuff lately. I was hoping to > try to get my arms around the KMS driver and kibitz at some point in the > hopefully-not-too-distant-future. (I felt, for a brief period, that I > understood the whole of the qxl driver, and your kms patches pushed me > rather unceremoniously out of that fantasy world). Well now that 90% of the driver is in the kernel, the kms userspace bits are mostly just wrappers around kernel functionality now. Primarily the userspace driver has no idea about surface location or surface ids anymore, the kernel manages the resources, primary surface is totally handled inside the kernel. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Broken xf86-video-qxl commit
> commit 3e37b2c38f661b0b8e285cfa7f0549aa3d216eb5 > Author: Dave Airlie > Date: Thu May 9 13:43:57 2013 +1000 > > qxl: add KMS support v1.2 > > Avoid DRI create busid symbol for now. > fix warnings. > > Creates this error for me: > > qxl.h:189:21: fatal error: qxl_drm.h: No such file or directory Okay should be fixed now. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl: add uevent handler support
From: Dave Airlie
This allows the driver to process uevents from the kernel when the mode
changes.
Signed-off-by: Dave Airlie
---
configure.ac | 14 +
src/Makefile.am | 6 +-
src/qxl_drmmode.c | 62 +++
src/qxl_drmmode.h | 10 +
src/qxl_kms.c | 3 +++
5 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d481cc1..8b2d450 100644
--- a/configure.ac
+++ b/configure.ac
@@ -135,6 +135,20 @@ fi
AM_CONDITIONAL(BUILD_XSPICE, test "x$enable_xspice" = "xyes")
AM_CONDITIONAL(BUILD_QXL, test "x$enable_qxl" = "xyes")
+AC_ARG_ENABLE([udev],
+ AS_HELP_STRING([--disable-udev], [Disable libudev support
[default=auto]]),
+ [enable_udev="$enableval"],
+ [enable_udev=auto])
+if test "x$enable_udev" != "xno"; then
+ PKG_CHECK_MODULES(LIBUDEV, [libudev], [LIBUDEV=yes], [LIBUDEV=no])
+ if test "x$LIBUDEV" = xyes; then
+ AC_DEFINE(HAVE_LIBUDEV, 1,[libudev support])
+ elif test "x$enable_udev" != "xauto"; then
+ AC_MSG_ERROR([Building with udev requested but libudev not
found])
+ fi
+fi
+AM_CONDITIONAL(LIBUDEV, test x$LIBUDEV = xyes)
+
PKG_CHECK_MODULES([SPICE_PROTOCOL], [spice-protocol >= 0.12.0])
# AC_CHECK_FILE is not supported when cross compiling
diff --git a/src/Makefile.am b/src/Makefile.am
index 4349b4e..d6a5445 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -27,7 +27,7 @@
SUBDIRS=uxa
-AM_CFLAGS = $(SPICE_PROTOCOL_CFLAGS) $(XORG_CFLAGS) $(PCIACCESS_CFLAGS)
$(CWARNFLAGS) $(DRM_CFLAGS)
+AM_CFLAGS = $(SPICE_PROTOCOL_CFLAGS) $(XORG_CFLAGS) $(PCIACCESS_CFLAGS)
$(CWARNFLAGS) $(DRM_CFLAGS) @LIBUDEV_CFLAGS@
if BUILD_QXL
qxl_drv_la_LTLIBRARIES = qxl_drv.la
@@ -35,6 +35,10 @@ qxl_drv_la_LDFLAGS = -module -avoid-version
qxl_drv_ladir = @moduledir@/drivers
qxl_drv_la_LIBADD = uxa/libuxa.la
+if LIBUDEV
+qxl_drv_la_LIBADD += $(LIBUDEV_LIBS)
+endif
+
qxl_drv_la_SOURCES = \
qxl.h \
diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c
index c1f5c15..03b4124 100644
--- a/src/qxl_drmmode.c
+++ b/src/qxl_drmmode.c
@@ -875,4 +875,66 @@ Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int cpp)
return TRUE;
}
+#ifdef HAVE_LIBUDEV
+static void
+drmmode_handle_uevents(int fd, void *closure)
+{
+ drmmode_ptr drmmode = closure;
+ ScrnInfoPtr scrn = drmmode->scrn;
+ struct udev_device *dev;
+ dev = udev_monitor_receive_device(drmmode->uevent_monitor);
+ if (!dev)
+ return;
+
+ RRGetInfo(xf86ScrnToScreen(scrn), TRUE);
+ udev_device_unref(dev);
+}
+#endif
+
+void qxl_drmmode_uevent_init(ScrnInfoPtr scrn, drmmode_ptr drmmode)
+{
+#ifdef HAVE_LIBUDEV
+ struct udev *u;
+ struct udev_monitor *mon;
+
+ u = udev_new();
+ if (!u)
+ return;
+ mon = udev_monitor_new_from_netlink(u, "udev");
+ if (!mon) {
+ udev_unref(u);
+ return;
+ }
+
+ if (udev_monitor_filter_add_match_subsystem_devtype(mon,
+ "drm",
+ "drm_minor") < 0 ||
+ udev_monitor_enable_receiving(mon) < 0) {
+ udev_monitor_unref(mon);
+ udev_unref(u);
+ return;
+ }
+
+ drmmode->uevent_handler =
+ xf86AddGeneralHandler(udev_monitor_get_fd(mon),
+ drmmode_handle_uevents,
+ drmmode);
+
+ drmmode->uevent_monitor = mon;
+#endif
+}
+
+void qxl_drmmode_uevent_fini(ScrnInfoPtr scrn, drmmode_ptr drmmode)
+{
+#ifdef HAVE_LIBUDEV
+ if (drmmode->uevent_handler) {
+ struct udev *u = udev_monitor_get_udev(drmmode->uevent_monitor);
+ xf86RemoveGeneralHandler(drmmode->uevent_handler);
+
+ udev_monitor_unref(drmmode->uevent_monitor);
+ udev_unref(u);
+ }
+#endif
+}
+
#endif
diff --git a/src/qxl_drmmode.h b/src/qxl_drmmode.h
index df076c7..04752ec 100644
--- a/src/qxl_drmmode.h
+++ b/src/qxl_drmmode.h
@@ -34,6 +34,9 @@
#include "xf86str.h"
#include "randrstr.h"
#include "xf86Crtc.h"
+#ifdef HAVE_LIBUDEV
+#include "libudev.h"
+#endif
typedef struct {
int fd;
@@ -42,6 +45,10 @@ typedef struct {
drmModeFBPtr mode_fb;
int cpp;
ScrnInfoPtr scrn;
+#ifdef HAVE_LIBUDEV
+ struct udev_monitor *uevent_monitor;
+ InputHandlerProc uevent_handler;
+#endif
} drmmode_rec, *drmmode_ptr;
typedef struct {
@@ -78,6 +85,9 @@ typedef struct {
} drmmode_output_private_rec,
Re: [Spice-devel] [PATCH] qxl: Report actual module version
On Wed, Jul 3, 2013 at 6:19 AM, Cole Robinson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=813684 > > Signed-off-by: Cole Robinson Since I'm in the area, seems fine to me, applied. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice hardware acceleration
On Fri, Jul 5, 2013 at 12:25 PM, bigclouds wrote: > hi > i am not farmilar with this eara,i have several question ,trouble you all to > answer me. > it involves both server and client > 1.if hardware accelaration needs special hardware? > 2.if i have such hardware, how to use it with spice? how to check out > whether acceleration takes effect? You seem to be remaining perpetually confused on what spice is. Let me try and answer this: spice the protocol doesn't require any acceleration anywhere, its just a protocol between server and client. The current implementation of spice in spice-server and spice-gtk client don't require any hardware acceleration or take advantage of any hardware acceleration the system provides. The old spice client code had OpenGL rendering capabilities that could use client side 3D hardware to do some of the rendering, its not known if that code still works, if it was ever proven useful or faster, or if it even renders correctly. This isn't to say spice will run fine without hardware acceleration, there maybe low-end cpus that can't handle the client side of spice very well and as such will not keep up, even with a GPU and a spice client to use it, it might still not be possible. So maybe you need to explain the high level of what you are trying to do, then implement it and see if it works. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 2/3] qxl: fix broken cursor hotspot on KMS driver
From: Dave Airlie
bugzilla: http://bugzilla.redhat.com/974662
Signed-off-by: Dave Airlie
---
configure.ac | 3 ++-
src/qxl_drmmode.c | 14 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8b2d450..81b7ad7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -78,7 +78,8 @@ CFLAGS="$save_CFLAGS"
# Checks for libraries.
if test "x$QXL_DRM" = xyes; then
- PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.42])
+ # require support for kms cursor hotspot
+ PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.46])
AC_ARG_ENABLE(kms,
AS_HELP_STRING([--disable-kms],
diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c
index 03b4124..5fe056c 100644
--- a/src/qxl_drmmode.c
+++ b/src/qxl_drmmode.c
@@ -43,6 +43,7 @@
#define DPMS_SERVER
#include
#endif
+#include
#include "qxl.h"
#include "qxl_surface.h"
@@ -271,7 +272,18 @@ drmmode_show_cursor (xf86CrtcPtr crtc)
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmmode_ptr drmmode = drmmode_crtc->drmmode;
uint32_t handle = qxl_kms_bo_get_handle(drmmode_crtc->cursor_bo);
-
+ static Bool use_set_cursor2 = TRUE;
+
+ if (use_set_cursor2) {
+ xf86CrtcConfigPtr xf86_config =
XF86_CRTC_CONFIG_PTR(crtc->scrn);
+ CursorPtr cursor = xf86_config->cursor;
+ int ret;
+ ret = drmModeSetCursor2(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id, handle, 64, 64, cursor->bits->xhot,
cursor->bits->yhot);
+ if (ret == -ENOSYS)
+ use_set_cursor2 = FALSE;
+ else
+ return;
+ }
drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, handle,
64, 64);
}
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 3/3] qxl: disable composite/a8 surfaces under KMS for now
From: Dave Airlie
this just disables composite and a8 surfaces under KMS
there are still some issues when enabled.
Signed-off-by: Dave Airlie
---
src/qxl_uxa.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/qxl_uxa.c b/src/qxl_uxa.c
index 875d663..47371e4 100644
--- a/src/qxl_uxa.c
+++ b/src/qxl_uxa.c
@@ -222,11 +222,15 @@ qxl_has_composite (qxl_screen_t *qxl)
#ifdef XF86DRM_MODE
if (qxl->kms_enabled) {
static Bool result, checked;
+#if 0 /* KMS Composite support seems broken - needs better hw support */
if (!checked) {
result = qxl_kms_check_cap(qxl, SPICE_DISPLAY_CAP_COMPOSITE);
checked = TRUE;
}
return result;
+#else
+ return FALSE;
+#endif
}
#endif
#ifndef XSPICE
@@ -244,12 +248,16 @@ qxl_has_a8_surfaces (qxl_screen_t *qxl)
{
#ifdef XF86DRM_MODE
if (qxl->kms_enabled) {
+#if 0 /* KMS Composite support seems broken - needs better hw support */
static Bool result, checked;
if (!checked) {
result = qxl_kms_check_cap(qxl, SPICE_DISPLAY_CAP_A8_SURFACE);
checked = TRUE;
}
return result;
+#else
+ return FALSE;
+#endif
}
#endif
#ifndef XSPICE
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/3] qxl: disable image cache for KMS
From: Dave Airlie
Currently this code can't work with KMS, need to work out how
the image cache could be effectively used with KMS enabled.
Signed-off-by: Dave Airlie
---
src/qxl_image.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/qxl_image.c b/src/qxl_image.c
index 40798b3..6c39214 100644
--- a/src/qxl_image.c
+++ b/src/qxl_image.c
@@ -50,7 +50,7 @@ static unsigned int
hash_and_copy (const uint8_t *src, int src_stride,
uint8_t *dest, int dest_stride,
int bytes_per_pixel, int width, int height,
- uint32_t hash)
+ uint32_t hash, Bool do_hashing)
{
int i;
@@ -63,7 +63,8 @@ hash_and_copy (const uint8_t *src, int src_stride,
if (dest)
memcpy (dest_line, src_line, n_bytes);
- MurmurHash3_x86_32 (src_line, n_bytes, hash, &hash);
+ if (do_hashing)
+ MurmurHash3_x86_32 (src_line, n_bytes, hash, &hash);
}
return hash;
@@ -165,7 +166,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
chunk->data_size = n_lines * dest_stride;
hash = hash_and_copy (data, stride,
chunk->data, dest_stride,
- Bpp, width, n_lines, hash);
+ Bpp, width, n_lines, hash, !qxl->kms_enabled);
if (tail_bo)
{
@@ -230,8 +231,9 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
qxl->bo_funcs->bo_decref(qxl, head_bo);
/* Add to hash table if caching is enabled */
- if ((fallback && qxl->enable_fallback_cache)||
- (!fallback && qxl->enable_image_cache))
+ if (!qxl->kms_enabled &&
+ ((fallback && qxl->enable_fallback_cache) ||
+(!fallback && qxl->enable_image_cache)))
{
if ((info = insert_image_info (hash)))
{
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [xf86-video-qxl] Provide compatibility for Xorg list code with Xorg < 1.12, for RHEL 6 support (resend)
On Sat, Sep 14, 2013 at 5:40 AM, Jeremy White wrote:
> Signed-off-by: Jeremy White
> ---
> src/qxl.h | 12 +++-
> src/qxl_kms.c |2 +-
> src/qxl_mem.c |2 +-
> 3 files changed, 13 insertions(+), 3 deletions(-)
Seems fine to me, ACK
Dave.
>
> diff --git a/src/qxl.h b/src/qxl.h
> index c026b63..a3bc7db 100644
> --- a/src/qxl.h
> +++ b/src/qxl.h
> @@ -56,6 +56,16 @@
>
> #include "qxl_drmmode.h"
>
> +#if (XORG_VERSION_CURRENT < XORG_VERSION_NUMERIC(1, 11, 99, 903, 0))
> +typedef struct list xorg_list_t;
> +#define xorg_list_init list_init
> +#define xorg_list_add list_add
> +#define xorg_list_del list_del
> +#define xorg_list_for_each_entrylist_for_each_entry
> +#else
> +typedef struct xorg_list xorg_list_t;
> +#endif
> +
> #include "compat-api.h"
> #define hidden _X_HIDDEN
>
> @@ -332,7 +342,7 @@ struct _qxl_screen_t
> #endif /* XSPICE */
>
> uint32_t deferred_fps;
> -struct xorg_list ums_bos;
> +xorg_list_t ums_bos;
> struct qxl_bo_funcs *bo_funcs;
>
> Bool kms_enabled;
> diff --git a/src/qxl_kms.c b/src/qxl_kms.c
> index 32859cc..6c5b427 100644
> --- a/src/qxl_kms.c
> +++ b/src/qxl_kms.c
> @@ -338,7 +338,7 @@ struct qxl_kms_bo {
> const char *name;
> uint32_t size;
> int type;
> -struct xorg_list bos;
> +xorg_list_t bos;
> void *mapping;
> qxl_screen_t *qxl;
> int refcnt;
> diff --git a/src/qxl_mem.c b/src/qxl_mem.c
> index 44be8c4..fde0976 100644
> --- a/src/qxl_mem.c
> +++ b/src/qxl_mem.c
> @@ -448,7 +448,7 @@ struct qxl_ums_bo {
> void *internal_virt_addr;
> int refcnt;
> qxl_screen_t *qxl;
> -struct xorg_list bos;
> +xorg_list_t bos;
> };
>
> static struct qxl_bo *qxl_bo_alloc_internal(qxl_screen_t *qxl, int type, int
> flags, unsigned long size, const char *name)
> --
> 1.7.10.4
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
> I've already had a quick discussion about this with Dave Airlie, and > our ideas on this aligned perfectly. > > The basic idea is to use qemu's console layer (include/ui/console.h) > as an abstraction between the new virtio-vga device Dave has in mind > (which will include optional 3D rendering capability through VIRGIL), > and various display options, ie SDL, vnc and Spice. > > The console layer would need some extensions for this: > > 1) Multi head support, a question which comes up here, is do we only > add support for multiple heads on a single card, or do we also want > to support multiple cards each driving a head here ? I myself tend > to go with the KISS solution for now and only support a single > card with multiple heads. I'm thinking it shouldn't be a major enhancement to go for multiple-cards with multiple-heads, I'm not sure its a worthy goal in the real world though, but it might be nice for testing corner cases. > > 2) The ability for a video-card generating output to pass a dma-buf > context to the display (ui in qemu terms) to get the contents from, > rather then requiring the contents to be rendered to some memory > buffer. This way we can save the quite expensive read-back from gpu > memory of the rendered result and then copying that back to the > framebuffer of the gpu for local displays (ie gtk, SDL), we would > of course still need the read back of the rendered output for > vnc / spice. Well at the moment I'm just using SDL/GLX inside the qemu process to talk direct to the X server, this isn't suitable long term for VMs that aren't running directly on the desktop, So the longer term plan is to abstract the GLX bits away and hopefully with SDL2.0, use EGL to talk to the GPU device, now it could still use GLX for local testing VMs, but in the libvirt situation the qemu process running as the qemu user would talk to the new drm rendernodes via EGL, then using an EGL extension export the scanout buffer via dma-buf (hand wavy magic not withstanding). There are some EGL extensions in the works for this. Then we'd just need to make the libvirt viewer use EGL/GLX so it can actually render the scanout buffer to the screen. > For proper multi-head support in the ui layer for local displays, > we will need to use SDL-2, either by porting the current SDL ui code > to SDL-2, or by introducing a new SDL-2 ui component. I've done an initial SDL2 port already just using ifdef :) http://cgit.freedesktop.org/~airlied/qemu/commit/?h=virtio-gpu&id=ee44399a3dbce8da810329230f0a439a3b88cd67 however the input side of SDL changed quite a bit and it needs a bit more work, though if people are inclined towards a separate sdl2.c I could do that I suppose. The other reason I wanted SDL2.0 is it supports argb cursors. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
> That leaves the question how to do single-card multihead. I think the > most sensible approach here is to go the spice route, i.e. have one big > framebuffer and define scanout rectangles for the virtual monitors. > This is how real hardware works, and is also provides a natural fallback > mode for UIs not supporting scanout rectangles: They show a single > window with the whole framebuffer, simliar to old spice clients. No real hw doesn't work like that, that is how we program real hw at the moment, but for example wayland won't do this, and neither does Windows mostly, real hw can have multiple separate framebuffers with separate strides, and separate scanouts from them, and the kms device drivers fully support this mode of operation, just the X server prevents it from being useable. I'd ideally want to have a window per gpu output, since the idea would be to allow them to be placed on different monitors on the host side, and doing it as a single app might limit the possiblities. The other thing is for virgil to work at all we need to render the whole console using GL interfaces, at the moment I just use glDrawPixels in the SDL ui update when in GL mode, so there is no direct access to the framebuffer in this case anyways, its all just GL rendered. >> 2) The ability for a video-card generating output to pass a dma-buf >> context to the display (ui in qemu terms) to get the contents from, >> rather then requiring the contents to be rendered to some memory >> buffer. This way we can save the quite expensive read-back from gpu >> memory of the rendered result and then copying that back to the >> framebuffer of the gpu for local displays (ie gtk, SDL), > > Hmm? Not sure what you are asking for... > > First, reading from gpu memory isn't expensive. It's all virtual, no > slow read cycles as with real hardware. There is almost no difference > between gpu memory and main memory for kvm guests. It's not clear to me > why you are copying stuff from/to gpu memory. > > Second, you can have your scanout framebuffer in main memory. That > isn't a problem at all. It only needs to be contiguous in guest > physical memory, scatter-gather for the framebuffer isn't going to fly. Scatter-gather for the framebuffer is fine as long as its not VESA LFB. I already have virtio-vga device allocating a non-contig framebuffer and just using DMA operations to move data in/out. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
> > Ah, host dma-buf not guest dma-buf. It makes more sense then. yes host side for the viewer. > > So virgil just opens one of those new render-only drm nodes, asks the > gpu to process the rendering ops from the guest & store the results in a > dma-buf, then this dma-buf must be displayed somehow, correct? Yes, the viewer would essentially be a compositing process, taking the outputs from multiple VMs and deciding where to draw them. I suppose like boxes does now. > >> When displaying locally (so SDL-2 or gtk ui), we want to avoid the read by >> passing a kernel dma_buf handle from the virtual card (in this case >> virtio-vga with Virgil) to the ui (in this case SDL-2), so it can then >> directly ask the GPU to blit from that dma_buf to its own visible surface. > > Hmm. Both SDL and gtk ui have the problem that they effectively bind > your VM to the desktop session. Which is not what you want for anything > but short-running test VMs. It's also a PITA to maintain them with > libvirt. Yeah I've hit that. So far virgil is only running via libvirt with a very hacked insecure config to draw to the local X server of my user. Getting past that is however going to involve a bit of lifting all over the place. > > Any plans for a separate UI process? Something using a unix socket for > control commands and to hand over a dma-buf handle using fd descriptor > passing maybe? That would be the local rendering solution I think we'd prefer, qemu runs as qemu user, uses EGL to talk to the drm render-nodes, has some sort of unix socket that the viewer connects to and can hand fds across, then the client viewer uses EGL or GLX to render on-screen and import the handles into EGL and displays the contents, there may be a small bit of sync info to send across. For remoting then we'd have an extra readback (slow) from the GPU and then spice or vnc encoding stages. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
On Wed, Oct 9, 2013 at 3:36 PM, Steven Newbury wrote: > On Tue, 8 Oct 2013, 23:51:13 BST, Dave Airlie wrote: >> >> That would be the local rendering solution I think we'd prefer, >> >> qemu runs as qemu user, uses EGL to talk to the drm render-nodes, >> has some sort of unix socket that the viewer connects to and can hand >> fds across, then the client viewer uses EGL or GLX to render on-screen >> and import the handles into EGL and displays the contents, there may >> be a small bit of sync info to send across. >> >> For remoting then we'd have an extra readback (slow) from the GPU and >> then spice or vnc encoding stages. > For the non-local case wouldn't it be possible to have the GPU render > directly to a shared buffer in system RAM rather than to the GPU memory and > reading back? No that generally is a really bad idea, since things like blending involve reading back from the video ram, and it would generally end up being worse for framerates than reading back. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
On Thu, Oct 10, 2013 at 10:50 PM, Marc-André Lureau wrote: > > > - Original Message - >> Hi, >> >> On 10/10/2013 01:25 PM, Gerd Hoffmann wrote: >> >Hi, >> > >> > Nice summary. >> > >> >> 3) Virgil will render using the host gpu, using EGL to talk to >> >> a drm render node. For non local displays the rendered contents >> >> will be read back from the gpu and then passed as a pixmap to the >> >> ui to transport over the network >> > >> > Interesting in this context: What is the status of 3d support for >> > qxl/spice? >> >> Non existent AFAIK >> >> > Is it be possible to transform virgil 3d ops into spice 3d >> > ops, so you could offload the rendering to spice-client? Does it make >> > sense to try? Or would the transfer of the data needed to render more >> > expensive than transferring the rendered screen? >> >> AFAIK, people more knowledgable people then me on 3d (ie Keith Packard) >> all seem to agree on that transfering the commands to render would be >> more expensive. IOW adding 3d support to Spice would be not really useful. > > afaik, opengl has been designed originally with remote rendering in mind. > OpenGL 1.0 maybe nobody has made any accommodation to remote rendering in years, they haven't defined GLX protocol for new extensions in probably 8-10 years, The thing is 3D rendering is high bandwidth for anything non-trivial, the amount of data apps move to GPUs is huge for most things. > I am no opengl expert, but it probably very much depends on the kind of > application (Alon reported us about Android apps remoting being fine). > Wouldn't glx gears be fine too? ;) I think the upcost is pretty big in > general, because of upload of textures and data arrays which are not very > well compressed in raw protocol. Probably a remote protocol, like spice, > could help compress those (and cache on disk!). Then result can be read back > in some applications, but that is not always the case (even rendering to > texture and composition could be done remotely). Usage of readback is > discouraged in general. Imho, it could be worth some experiments. But current > local only approach is necessary anyway, and the server rendering approach > could be complementary too. There are numerous massive problems with remote rendering the android remoting guys don't solve because they either don't need to or they are too hard, but for a desktop you'd have to. I'll enumerate them for posterity :-) Also your GL knowledge is a bit out of date :-P 1) readback - spice currently doesn't do remote readback it always does pixman rendering locally when the client reads something back, now GL isn't pixel perfect and if we have different rendering hw or sw rendering on the host and the client then we'd be giving back results that weren't entirely accurate. Now do we just readback from the client then? probably going to suck. Now things like gnome-shell use a technique called picking on mouse movement and clicks, every mouse movement can cause a readback so it know what object is under the mouse, can you say latency enough? 2) disconnected operation - if we are remoting to a 3D client, what do we do when it disconnects? fallback to local sw rendering? fallback to local hw rendering? GL isn't pixel perfect so the results may not be the same as we get on the old remote, so should we be reading back from the clients when they've rendered to have accurate results., GL also has insane number of versions and extensions, do we block apps from using higher levels because we might get disconnected? So it might be possible if you had same 3D hw in the server and guest to do something, where'd you double render everything, and keep some sort of transaction log of what the client has finished with so the server could throw it away, but it would be a lot of work, the android guys afaik don't do readback and just kill the app on disconnect. This is of course on top of the upcost you mention, which is vast for most apps, not so bad for gnome-shell. The on gpu encoding seems to be what most of the solutions in the area are doing, vmware, nvidia grid etc, the GPU streams the rendered output through the h264 encoder so the cpu has a lot less to readback and transfer over the network, it would be what we'd like to pursue but the usual patent issues around h264 means we might never get there. I think we are hoping that something like Daala can be used, and it possibly has better support for straight edges and text. But that is a lot more long term than getting virgil and possible some spice integration. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
On Thu, Oct 10, 2013 at 11:10 PM, Gerd Hoffmann wrote: >> > > IIRC some high-end nvidia gfx cards (which can be partitioned for > virtual machines) can encode the guests display as H.264 stream in > hardware. > > Given that there are use cases for hardware assisted video encoding in > the consumer space too (beam your android tablet display to the smart tv > over wifi) I wouldn't be surprised if video encoding support is > commonplace in gpus in near future (maybe it even is there today). > > That'll make sending a H.264 stream as display channel an interesting > option. Should be a reasonable efficient protocol, with the ability to > offload alot of the actual work to the gpu on both server and client > side. I think nearly all GPUs, Intel ones included can do on-board H264 encoding now, the vaapi for Intel exports this ability, not sure how to expose it on non-intel GPUs, or how they expose it under Windows etc. The problem for us is the usual patent minefield around h264. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
>> >> OpenGL 1.0 maybe nobody has made any accommodation to remote rendering >> in years, they haven't defined GLX protocol for new extensions in >> probably 8-10 years, >> >> The thing is 3D rendering is high bandwidth for anything non-trivial, >> the amount of data apps move to GPUs is huge for most things. > > Most opengl applications, but perhaps that's not so true for desktop apps in > general (including aero etc), as you noted for gnome-shell, which is more > animated than most applications that just want simple smooth transitions. I > am not looking at remote gaming or 3d benchmark. > > Even when a lot of data moves to GPU, I wonder how much can actually be > cached (ie how much is generated on CPU). A lot of our desktop apps however are going to GL, like libreoffice and firefox and I expect they'll be generating a fair amount of data, not as much as games or benchmarks but still enough. >> There are numerous massive problems with remote rendering the android >> remoting guys don't solve because they either don't need to or they >> are too hard, but for a desktop you'd have to. I'll enumerate them for >> posterity :-) Also your GL knowledge is a bit out of date :-P >> >> 1) readback - spice currently doesn't do remote readback it always >> does pixman rendering locally when the client reads something back, >> now GL isn't pixel perfect and if we have different rendering hw or sw >> rendering on the host and the client then we'd be giving back results >> that weren't entirely accurate. Now do we just readback from the >> client then? probably going to suck. Now things like gnome-shell use a >> technique called picking on mouse movement and clicks, every mouse >> movement can cause a readback so it know what object is under the >> mouse, can you say latency enough? > > This is already in opengl 1.0 iirc (so probably with remoting in mind ;), and > I don't think latency for picking matters so much in remote environment (even > then, when there is a mouse click/event on client side, we could already > gather some picking information perhaps, to avoid round trip), I was also > imagining the double rendering that you mentionned. No you are thinking about GL 1.0 GL_SELECT this isn't what is used anymore, gnome-shell renders a backbuffer with colors and then does a glReadPixels on it, there are optimisation to aviod this in some cases but in any complex scene its probably the only useful way. The latency is every mouse movement is going to generate another round drop for the readpixels of the place it lands, that is going to be sluggish. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
On Thu, Oct 10, 2013 at 11:04 AM, Hans de Goede wrote: > Hi All, > > So trying to summarize what has been discussed before: > > The basic idea for virgil + spice integration is to use qemu's console > layer as an abstraction between the new virtio-vga device Dave has in > mind: http://airlied.livejournal.com/ > > and various display options, ie SDL, vnc and Spice. > > The console layer would need some extensions for this: > > 1) Multi head support, this will be in the form of virtual gfx cards > registering 1 or more QemuConsoles (one for each virtual connector), > > with some infrastructure bits in the ui core + frontends to allow > enabling/disabling them. > Okay I've done some of this work on ui in my virtio-gpu branch of my qemu repo http://cgit.freedesktop.org/~airlied/qemu/log/?h=virtio-gpu I've added multiple display surfaces to a QemuConsole and add an idx parameter in a couple of places, Then I've hooked it up to SDL2, this lets me with my virtio-gpu to create a screen panning two windows. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: Integrating Virgil and Spice
> > /me looks at bf9a3b69c80a6fbd289b6340b8bdc9e994630bdc, console.c > changes. > > This isn't what I've meant, guess I wasn't verbose enough .. Yeah I'mt not sure I liked that idea as you seem to associate a QemuConsole as being a distinct console, whereas in this case the multiple heads aren't distinct consoles. While it might work I feel you'll then have to add some extra things make the frontends understand the difference between multi-card and multi-head. Though maybe that doesn't matter, I'll probably try it your way once I've hacked it up a bit more. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] linux with multiple "monitors" issues
On Sat, Nov 9, 2013 at 7:34 AM, Marc-André Lureau wrote: > > > - Original Message - >> Hi All, >> >> You may remember me as the guy who about once a month complains that >> multiple "monitors" simply doesn't work in linux. >> >> I have tested various configurations of centos 6, fedora 19 and fedora >> 20 beta as host, guest and client. >> >> Well I think I've finally made some progress which I'll thought worth >> reporting back. >> >> These results (below) are approximately the same on Fedora 20 beta and >> Fedora 19 (host+guest+client). >> >> I was trolling through the Fedora "features" (or whatever they're called >> now) and noticed that qxl KMS driver has made it's way into fedora. >> That gave me an idea: disable it! Sure enough, things are WYYY more >> stable after blacklisting qxl.ko. > > Some multiple monitor and arbitrary resolution fixes are in drm-next: > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next > > With f20, you may also need the mutter fix: > https://bugzilla.gnome.org/show_bug.cgi?id=711216 > > For f19, it should be working with drm-next. Most of the fixes are now pushed into the Fedora kernel repos, I don't have versions for where they'll show up yet. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fedora 19 and 20 spice guest Xorg crashes
On Tue, Nov 19, 2013 at 7:04 AM, Nahum Shalman wrote: > Context: > Host is running qemu-kvm 1.1.2 and spice 0.12.2. > Fedora 16 VMs ran rock solid on these same virtualization hosts. > The Fedora 19 and 20(testing) VMs are running xf86-video-qxl compiled from > the master branch of the git repo. > > We've been seeing a lot of X server crashes in Fedora 19 and 20, generally > after the VM has been running for at least 2-3 days. > The last gasp in the Xorg logs from these crashes generally look something > like: > > [1024592.839] Out of memory allocating 261140 bytes > [1024592.839] Out of mem - stats > > [1024592.850] max system bytes = 243257344 > [1024592.850] system bytes = 243257344 > [1024592.850] in use bytes = 133245384 > > Someone here managed to get a stack trace out of one such crash: > > (EE) [mi] EQ overflowing. Additional events will be discarded until existing > events are processed. > (EE) > (EE) Backtrace: > (EE) 0: /usr/bin/X (mieqEnqueue+0x22b) [0x57691b] > (EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44d862] > (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (_init+0x2913) > [0x7ff0faeb17e3] > (EE) 3: /usr/bin/X (DPMSSupported+0xe8) [0x4861f8] > (EE) 4: /usr/bin/X (xf86SerialModemClearBits+0x230) [0x4ae7b0] > (EE) 5: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3b7de0ef9f] > (EE) 6: /lib64/libpthread.so.0 (__nanosleep_nocancel+0x24) [0x3b7de0e804] > (EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (qxl_handle_oom+0x69) > [0x7ff10fceccb9] > (EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (qxl_allocnf+0x48) > [0x7ff10fcecd08] > (EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so > (qxl_bo_alloc_internal+0x76) [0x7ff10fcece06] > (EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (qxl_image_create+0xf2) > [0x7ff10fce9782] > (EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so > (qxl_surface_put_image+0xf5) [0x7ff10fceb045] > (EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (uxa_copy_n_to_n+0x5e7) > [0x7ff10fcf7127] > (EE) 13: /usr/bin/X (miCopyRegion+0x1ad) [0x574d2d] > (EE) 14: /usr/bin/X (miDoCopy+0x456) [0x5752b6] > (EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (uxa_copy_area+0xae) > [0x7ff10fcf5efe] > (EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) [0x433a31] > (EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fa7] > (EE) 18: /usr/bin/X (_init+0x3aaa) [0x429b4a] > (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3b7d221b75] > (EE) 20: /usr/bin/X (_start+0x29) [0x4267b1] > (EE) 21: ? (?+0x29) [0x29] > (EE) > (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up > the stack. > (EE) [mi] mieq is NOT the cause. It is a victim. > (EE) [mi] EQ overflow continuing. 100 events have been dropped. > > His comment was: > > Examining the stack trace more closely, the functions identified are > misleading. The offsets are sometimes larger than the named functions, and > point to different functions not listed in the stripped symbol table. > Looking at the source, it seems that: > > (EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) [0x433a31] > > This is probably ProcCreatePixmap() > > (EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fa7] > > This is possibly init_screen() or AddScreen() > > So, it appears the memory allocation fails while setting up a new screen > structure. This makes more sense, but still leaves open the question why > it's trying to create new screens long after startup. > > It's hard to recreate the crashes other than by simply booting and using a > VM for a few days. One theory we're tossing around is that the memory buffer > xf86-video-qxl has to work with is getting fragmented and when the > fragmentation gets bad enough an allocation can fail. > Our best guess is that this is a bug in the xf86-video-qxl driver. Has > anyone else seen similar Xorg crashes? > > Guidance on how to fix or at least troubleshoot this further would be > greatly appreciated. > Why aren't you running the Fedora packages? Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] W8.0 video drivers
On 19 September 2014 07:00, ToddAndMargo wrote: > On 09/18/2014 01:46 PM, Klaus Hochlehnert wrote: >> >> Hi, >> >> I saw herehttps://pve.proxmox.com/wiki/SPICE#Windows_8_64-bit that RH has >> something available. >> I was wondering if they will release that to the "public"... >> >> CU, Klaus > > > That would be nice of them. > Not sure what you read into that statement, but it has nothing to do with spice, its for the virtio drivers spice isn't virtio. Dave. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/2] Change the way slot is detected
On 12 October 2015 at 23:02, Frediano Ziglio wrote:
> Instead of relaying on surface type use the actual placement.
> This allow to have different placement for a single type of
> surface.
These two look fine, just 2 things,
a) missing Signed-off-by
b) no prefix - please prefix qxl kernel patches with drm/qxl.
Dave.
> ---
> qxl/qxl_cmd.c | 2 +-
> qxl/qxl_drv.h | 9 -
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
> index fdc1833..3a1b055 100644
> --- a/qxl/qxl_cmd.c
> +++ b/qxl/qxl_cmd.c
> @@ -511,7 +511,7 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev,
> cmd->u.surface_create.height = surf->surf.height;
> cmd->u.surface_create.stride = surf->surf.stride;
> if (new_mem) {
> - int slot_id = surf->type == QXL_GEM_DOMAIN_VRAM ?
> qdev->main_mem_slot : qdev->surfaces_mem_slot;
> + int slot_id = qxl_bo_get_slot_id(qdev, surf);
> struct qxl_memslot *slot = &(qdev->mem_slots[slot_id]);
>
> /* TODO - need to hold one of the locks to read tbo.offset */
> diff --git a/qxl/qxl_drv.h b/qxl/qxl_drv.h
> index 01a8694..60f0062 100644
> --- a/qxl/qxl_drv.h
> +++ b/qxl/qxl_drv.h
> @@ -365,11 +365,18 @@ qxl_fb_virtual_address(struct qxl_device *qdev,
> unsigned long physical)
> return 0;
> }
>
> +static inline int
> +qxl_bo_get_slot_id(struct qxl_device *qdev, struct qxl_bo *bo)
> +{
> + return ((bo->tbo.cur_placement & TTM_PL_MASK_MEM) ==
> TTM_PL_FLAG_VRAM) ?
> + qdev->main_mem_slot : qdev->surfaces_mem_slot;
> +}
> +
> static inline uint64_t
> qxl_bo_physical_address(struct qxl_device *qdev, struct qxl_bo *bo,
> unsigned long offset)
> {
> - int slot_id = bo->type == QXL_GEM_DOMAIN_VRAM ? qdev->main_mem_slot :
> qdev->surfaces_mem_slot;
> + int slot_id = qxl_bo_get_slot_id(qdev, bo);
> struct qxl_memslot *slot = &(qdev->mem_slots[slot_id]);
>
> /* TODO - need to hold one of the locks to read tbo.offset */
> --
> 2.4.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
