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
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 b
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/
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 designe
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
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
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 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_chann
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 patche
> 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 "olde
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 applicat
rn 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(-)
>
>
re 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
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
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 Airli
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.freede
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(-)
&g
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.
___
Spi
anup 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
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
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: Dav
rns 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
> 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 resen
he 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
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
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
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 j
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
>
>
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.
>
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 a
>
> /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 d
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.liv
>>
>> 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 m
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 consume
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 loc
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,
>>
>
> 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 someh
> 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
> 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 i
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/q
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
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
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
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
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.freedeskt
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
> 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
>>
>> 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 gues
>
> 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:
>
> 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, al
> 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 probab
>
> 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
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
h 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 +-
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
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
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 "con
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
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
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
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
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
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
>
> 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 fi
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 s
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 do
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 l
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 instr
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]
69 matches
Mail list logo
