For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buffer (using the dmabuf
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also ensures that the
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream pointer associated with
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved the stream initialization
We need to convert the scanout's drm format to the correct Gstreamer
format while configuring the pipeline. Otherwise, visual artifacts or
corruption might be seen. This can be done using the Gstreamer API
gst_video_dma_drm_fourcc_to_format(), which will take the drm fourcc
value and return the
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- Avoid the usage of
For clients that cannot accept a dmabuf fd directly (such as those
running on a remote system), this patch series provides a way for
the Spice server to stream the gl/dmabuf data/buffer instead. This
is mostly done by enabling the creation of Gst memory using a dmabuf
fd as the source. This
Il giorno mer 5 giu 2024 alle ore 20:47 Andrei Boros ha scritto:
>
> Hi,
>
> On your website, on the page https://www.spice-space.org/download.html there
> is a link under windows binaries to
> https://gitlab.freedesktop.org/spice/win32/spice-nsis
> This yields a 404 not found error.
>
Hi,
Hi,
On your website, on the page https://www.spice-space.org/download.html
there is a link under windows binaries to
https://gitlab.freedesktop.org/spice/win32/spice-nsis
This yields a 404 not found error.
Thank you.
--
*ing. Andrei Boros*
Serviciul IT
*Radio Romania*
|Tel: +40-21-303-1870
Hi,
sent my patch as MR.
https://gitlab.freedesktop.org/spice/spice/-/merge_requests/226.
Frediano
Il giorno sab 1 giu 2024 alle ore 17:14 Frediano Ziglio
ha scritto:
>
> Il giorno lun 27 mag 2024 alle ore 16:19 Victor Toso
> ha scritto:
> >
> > Hi,
> >
> > On Tue, Apr 16, 2024 at
Il giorno lun 27 mag 2024 alle ore 16:19 Victor Toso
ha scritto:
>
> Hi,
>
> On Tue, Apr 16, 2024 at 12:59:50PM GMT, Michael Scherle wrote:
> > Hello,
> >
> > Thanks for your changesets, they definitely reduce the delay significantly
> > (to a similar level as our provosoric fixes, but yours are
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- Avoid the usage of
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream pointer associated with
For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buffer (using the dmabuf
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved the stream initialization
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also ensures that the
For clients that cannot accept a dmabuf fd directly (such as those
running on a remote system), this patch series provides a way for
the Spice server to stream the gl/dmabuf data/buffer instead. This
is mostly done by enabling the creation of Gst memory using a dmabuf
fd as the source. This
On 5/28/24 00:01, Victor Toso wrote:
Hi,
On Mon, May 27, 2024 at 12:22:54PM GMT, ToddAndMargo wrote:
On 5/27/24 08:07, Victor Toso wrote:
On Wed, May 22, 2024 at 12:58:41AM GMT, ToddAndMargo wrote:
Hi All,
Host:
Fedora 39
spice-server-0.15.1-3.fc39.x86_64
Hi,
On Mon, May 27, 2024 at 12:22:54PM GMT, ToddAndMargo wrote:
> On 5/27/24 08:07, Victor Toso wrote:
> > On Wed, May 22, 2024 at 12:58:41AM GMT, ToddAndMargo wrote:
> > > Hi All,
> > >
> > > Host:
> > > Fedora 39
> > > spice-server-0.15.1-3.fc39.x86_64
> > >
Hi Frediano,
> >
> > For clients that cannot accept a dmabuf fd directly (such as those
> > running on a remote system), this patch series provides a way for
> > the Spice server to stream the gl/dmabuf data/buffer instead. This
> > is mostly done by enabling the creation of Gst memory using a
On 5/27/24 08:07, Victor Toso wrote:
On Wed, May 22, 2024 at 12:58:41AM GMT, ToddAndMargo wrote:
Hi All,
Host:
Fedora 39
spice-server-0.15.1-3.fc39.x86_64
spice-glib-0.42-3.fc39.x86_64
spice-gtk3-0.42-3.fc39.x86_64
spice-vdagent-0.22.1-6.fc39.x86_64
Hi,
On Tue, Apr 16, 2024 at 12:59:50PM GMT, Michael Scherle wrote:
> Hello,
>
> Thanks for your changesets, they definitely reduce the delay significantly
> (to a similar level as our provosoric fixes, but yours are much cleaner).
>
> On the client side (spice-gtk) I looked at the problem with
On Mon, May 20, 2024 at 06:52:34PM GMT, Andreas Yankopolus wrote:
> All—
>
> I’m on an M1 MacBook Pro accessing VMs running on an amd86
> Linux server.
>
> Is there a way to connect a USB device on the Mac to a VM?
That's the use case for USB redirection. Spice has spice-usbredir
channel which
On Wed, May 22, 2024 at 12:58:41AM GMT, ToddAndMargo wrote:
> Hi All,
>
> Host:
>Fedora 39
>spice-server-0.15.1-3.fc39.x86_64
>spice-glib-0.42-3.fc39.x86_64
>spice-gtk3-0.42-3.fc39.x86_64
>spice-vdagent-0.22.1-6.fc39.x86_64
>qemu-kvm-8.1.3-5.fc39.x86_64
>
> VM:
>
Il giorno lun 4 mar 2024 alle ore 11:10 Vivek Kasireddy
ha scritto:
>
> For clients that cannot accept a dmabuf fd directly (such as those
> running on a remote system), this patch series provides a way for
> the Spice server to stream the gl/dmabuf data/buffer instead. This
> is mostly done by
Hi All,
Host:
Fedora 39
spice-server-0.15.1-3.fc39.x86_64
spice-glib-0.42-3.fc39.x86_64
spice-gtk3-0.42-3.fc39.x86_64
spice-vdagent-0.22.1-6.fc39.x86_64
qemu-kvm-8.1.3-5.fc39.x86_64
VM:
Windows 11 23H2
Virtio-win-driver-installer 0.1.240
Virtio-win-guest-tools
All—
I’m on an M1 MacBook Pro accessing VMs running on an amd86 Linux server.
Is there a way to connect a USB device on the Mac to a VM?
I’m not able to install additional software on the VMs and am trying to sort
out mouse tracking, which is very laggy using the VirtIO Tablet device. Passing
Hi
I haven't used any of this in a while so I can't help much. Quickemu is a
great tool for getting started, maybe their support forums can help.
OSX is pretty tricky so you might have to look around and change your
quickemu scripts or opencore setup.
For audio to work through spice you need a
On Wed, May 08, 2024 at 02:51:10PM +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 08.05.24 14:35, Anders Blomdell wrote:
> > On 2024-05-07 07:04, Linux regression tracking (Thorsten Leemhuis) wrote:
> >> On 06.05.24 16:30, David Wang wrote:
> On 30.04.24 08:13, David Wang
Hi Dorothy
This sounds more like a guest problem - you could probably find more help
on the quickemu Discord or looking through github issues/discussions.
It's been a while but changes to Opencore or qemu settings can break audio
and other things.
Spice probably isn't redirecting your usb
Hi Dorothy,
On Sat, Apr 27, 2024 at 12:57:49PM GMT, Dorothy Calhoon wrote:
> Hi!
>
> I use spice to redirect the usb ports from my POPos host to my
> Mac Catalina operating system in my QEMU virtual machine which
> was set up using quickemu and now is accessed via quickgui.
> Spice works fine
On 08.05.24 14:35, Anders Blomdell wrote:
> On 2024-05-07 07:04, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 06.05.24 16:30, David Wang wrote:
On 30.04.24 08:13, David Wang wrote:
>>
And confirmed that the warning is caused by
07ed11afb68d94eadd4ffc082b97c2331307c5ea
On 06.05.24 16:30, David Wang wrote:
>> On 30.04.24 08:13, David Wang wrote:
>> And confirmed that the warning is caused by
>> 07ed11afb68d94eadd4ffc082b97c2331307c5ea and reverting it can fix.
>
> The kernel warning still shows up in 6.9.0-rc7.
> (I think 4 high load processes on a 2-Core VM
On 2024-05-07 07:04, Linux regression tracking (Thorsten Leemhuis) wrote:
On 06.05.24 16:30, David Wang wrote:
On 30.04.24 08:13, David Wang wrote:
And confirmed that the warning is caused by
07ed11afb68d94eadd4ffc082b97c2331307c5ea and reverting it can fix.
The kernel warning still
The kernel warning still shows up in 6.9.0-rc7.
(I think 4 high load processes on a 2-Core VM could easily trigger the kernel
warning.)
Thanks
David
Hi,
I got following kernel WARNING when the my 2-core KVM(6.9.0-rc6) is under high
cpu load.
[Mon Apr 29 21:36:04 2024] [ cut here ]
[Mon Apr 29 21:36:04 2024] workqueue: WQ_MEM_RECLAIM
ttm:ttm_bo_delayed_delete [ttm] is flushing !WQ_MEM_RECLAIM
Hi!
I use spice to redirect the usb ports from my POPos host to my Mac Catalina
operating system in my QEMU virtual machine which was set up using quickemu and
now is accessed via quickgui. Spice works fine for redirecting the keyboard,
mouse, wifi and printer. Now I need it for audio.
I know
Hi,
I suppose we could take this as a group thing, I suppose we don't
have many updates on spice-html.
Can you write something like
https://gitlab.freedesktop.org/spice/spice/-/blob/master/docs/how_to_release.md?ref_type=heads
?
Regards,
Frediano
Il giorno mar 2 apr 2024 alle ore 18:23
Hello,
Thanks for your changesets, they definitely reduce the delay
significantly (to a similar level as our provosoric fixes, but yours are
much cleaner).
On the client side (spice-gtk) I looked at the problem with the high
decoding time (2 frames buffering) and was able to find a simple
Hi,
I'm trying to use the remote-viewer with an HTTPS connection to a proxy
(proxy=https://...). This does not work. (I've tested my setup with
"openssl s_client ...", so I'm quite sure that the proxy is configured
properly).
I searched a bit and found that "the only supported proxy is HTTP
On Thu, 04 Apr 2024 19:14:48 +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due
This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
Changes since v1:
- replace new code logic in v1 with past code version by reverting
commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
- add missing code dependency from
commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2")
---
Hi,
To clarify, the reason for my original
Frediano
Il giorno mar 2 apr 2024 alle ore 15:27 Michael Scherle
ha scritto:
>
> Hi Frediano,
>
> thank you very much for your detailed answer.
>
>
> On 02.04.24 14:13, Frediano Ziglio wrote:
>
> > Really short explanation: Lipsync.
> >
> > Less cryptic explanation: video streaming was added
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: c0b832517f627ead3388c6f0c74e8ac10ad5774b Add linux-next specific
files for 20240402
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404021504.ytp51bl3-...@intel.com
I've become largely inactive on Spice (due to my semi retirement), and
the Fedora folks are thinking I should no be a packager [1].
I agree :-/.
Anyone want the job?
Cheers,
Jeremy
[1] https://pagure.io/find-inactive-packagers/issue/1840
Hi Frediano,
thank you very much for your detailed answer.
On 02.04.24 14:13, Frediano Ziglio wrote:
Really short explanation: Lipsync.
Less cryptic explanation: video streaming was added much time ago when
desktops used 2D graphic drawings, like lines, fillings, strings and
so on. At that
Il giorno mer 20 mar 2024 alle ore 15:32 Michael Scherle
ha scritto:
>
> Hello spice developers,
>
> I looked further and found the function get_min_playback_delay(
> https://gitlab.freedesktop.org/spice/spice/-/blob/fe1c25f530b95d32cc81bc1a395d80ace631d2dd/server/gstreamer-encoder.c#L507)
>
On Thu, Mar 28, 2024 at 11:18 AM Maxime Ripard wrote:
>
> "a while ago" here being 2 hours before your message :)
Ah, I meant the original reports that Nathan mentioned in his message.
Yeah, the message itself from Nathan happened right before :)
> I've added a Closes tag for that report too.
>
Hello, all. I reported an issue to the gitlab
(https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/183), but I see
the readme wants issues sent to the mailing list. I will summarize here:
VM viewers that use spice-gtk do not render properly when running under
wayland with GNOME/Mutter's
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: a6bd6c997f5a0e2667d4d82fef8c970108f2 Add linux-next specific
files for 20240328
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "memcpy"
On Wed, Mar 27, 2024 at 8:59 AM Maxime Ripard wrote:
>
> It looks reasonable to me, can you send a formal patch?
Will do -- I found another one when running the CI with the above one fixed:
drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: error: variable
'num_relocs' set but not used
On Wed, Mar 27, 2024 at 3:43 PM Miguel Ojeda
wrote:
>
> Will do -- I found another one when running the CI with the above one fixed:
>
> drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: error: variable
> 'num_relocs' set but not used [-Werror,-Wunused-but-set-variable]
>
> I will send you one for that
On Wed, Mar 27, 2024 at 07:14:12PM +0100, Miguel Ojeda wrote:
> On Wed, Mar 27, 2024 at 6:56 PM Miguel Ojeda wrote:
> >
> > Closes:
> > https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
>
> Should have a [1] at the end.
I added it while committing
Hi,
On Wed, Mar 20, 2024 at 04:25:48PM +0100, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 08.03.24 02:08, Alex Constantino wrote:
> > Fix OOM scenario by doing multiple notifications to the OOM handler through
> > a busy wait logic.
> > Changes from commit 5a838e5d5825 ("drm/qxl:
Clang 14 in an (essentially) defconfig loongarch64 build for next-20240327
reports [1]:
drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: error: variable 'num_relocs'
set but not used [-Werror,-Wunused-but-set-variable]
The variable was originally used in the `out_free_bos` label, but commit
On Wed, Mar 27, 2024 at 6:56 PM Miguel Ojeda wrote:
>
> Closes:
> https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
Should have a [1] at the end.
> Signed-off-by: Miguel Ojeda
> ---
> Given there is a loop going on here, it would be good to
Clang 14 in an (essentially) defconfig loongarch64 build for next-20240326
reports [1]:
drivers/gpu/drm/qxl/qxl_cmd.c:424:6: error: variable 'count' set
but not used [-Werror,-Wunused-but-set-variable]
The variable is already unused in the version that got into the tree.
Thus remove the
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 26074e1be23143b2388cacb36166766c235feb7c Add linux-next specific
files for 20240327
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202403271905.bybgjipi-...@intel.com
Hi Miguel,
On Tue, Mar 26, 2024 at 07:04:34PM +0100, Miguel Ojeda wrote:
> Hi,
>
> In today's next, I got:
>
> drivers/gpu/drm/qxl/qxl_cmd.c:424:6: error: variable 'count' set
> but not used [-Werror,-Wunused-but-set-variable]
>
> `count` seems to be there since commit f64122c1f6ad ("drm:
Hi,
In today's next, I got:
drivers/gpu/drm/qxl/qxl_cmd.c:424:6: error: variable 'count' set
but not used [-Werror,-Wunused-but-set-variable]
`count` seems to be there since commit f64122c1f6ad ("drm: add new QXL
driver. (v1.4)").
Untested diff below -- if you want a formal patch, please
Hi,
Do you mean the pre-built bundle? I think the os x users I know are using
virt-manager from homebrew instead.
-Timo
Mar 25, 2024 11:31:38 presi300work :
> I am sorry if this sounds a bit rude, but it really is in a horrible state.
> It's UI is old and slow, it doesn't use the global menu
I am sorry if this sounds a bit rude, but it really is in a horrible state.
It's UI is old and slow, it doesn't use the global menu system and it leaks
memory all over the place. I'm sending this e-mail with the hope of someone
seeing it and either taking a closer look at the OSX spice client
On 08.03.24 02:08, Alex Constantino wrote:
> Fix OOM scenario by doing multiple notifications to the OOM handler through
> a busy wait logic.
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
>
Hello spice developers,
I looked further and found the function get_min_playback_delay(
https://gitlab.freedesktop.org/spice/spice/-/blob/fe1c25f530b95d32cc81bc1a395d80ace631d2dd/server/gstreamer-encoder.c#L507)
which calculates the delay I was looking for. However, some of the
calculations do
Il giorno lun 11 mar 2024 alle ore 18:02 Santiago Paiva
ha scritto:
>
> Hello from Canada,
>
> I was wondering if there is any chance we could use the username @spice on
> Github for some FOSS?
>
> Thanks for your time and consideration. All the best
>
> Santiago.
>
Hi,
I would suggest
Hi,
On 2024/2/27 18:14, Thomas Zimmermann wrote:
Temporarily lock the fbdev buffer object during updates to prevent
memory managers from evicting/moving the buffer. Moving a buffer
object while update its content results in undefined behaviour.
Fbdev-generic updates its buffer object from a
Hi,
On 2024/2/27 18:14, Thomas Zimmermann wrote:
Acquire the buffer object's reservation lock in drm_gem_pin() and
remove locking the drivers' GEM callbacks where necessary. Same for
unpin().
DRM drivers and memory managers modified by this patch will now have
correct dma-buf locking
Hello from Canada,
I was wondering if there is any chance we could use the username @spice on
Github for some FOSS?
Thanks for your time and consideration. All the best
Santiago.
Fix OOM scenario by doing multiple notifications to the OOM handler through
a busy wait logic.
Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Fixes: 5a838e5d5825 ("drm/qxl: simplify
On 08.03.24 02:08, Alex Constantino wrote:
> Fix OOM scenario by doing multiple notifications to the OOM handler through
> a busy wait logic.
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
>
Hi,
As initially reported by Timo in the QXL driver will crash given enough
workload:
https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b...@leemhuis.info/
I initially came across this problem when migrating Debian VMs from Bullseye
to Bookworm. This bug will somewhat randomly
The variable num_relocs is being initialized and incremented but it is
never actually referenced in any other way. The variable is redundant
and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: warning: variable 'num_relocs'
set but not used
Hi
Am 05.03.24 um 22:58 schrieb Dmitry Osipenko:
On 2/27/24 13:14, Thomas Zimmermann wrote:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM's console emulation. Similar
On 2/27/24 13:14, Thomas Zimmermann wrote:
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
> for vmap and mmap have been posted at
For clients that cannot accept a dmabuf fd directly (such as those
running on a remote system), this patch series provides a way for
the Spice server to stream the gl/dmabuf data/buffer instead. This
is mostly done by enabling the creation of Gst memory using a dmabuf
fd as the source. This
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also ensures that the
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream pointer associated with
For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buffer (using the dmabuf
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- Avoid the usage of
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved the stream initialization
Il giorno sab 2 mar 2024 alle ore 03:21 Vivek Kasireddy
ha scritto:
>
> For non-gl/remote clients, if there is no stream associated with
> the DisplayChannel, then we create a new stream. Otherwise, we
> just update the current stream's timestamp.
>
> v2: (suggestions and fixups from Frediano)
>
For clients that cannot accept a dmabuf fd directly (such as those
running on a remote system), this patch series provides a way for
the Spice server to stream the gl/dmabuf data/buffer instead. This
is mostly done by enabling the creation of Gst memory using a dmabuf
fd as the source. This
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved the stream initialization
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also ensures that the
For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buffer (using the dmabuf
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream pointer associated with
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- Avoid the usage of
Return value of a function 'drm_cvt_mode' is dereferenced without
checking for NULL but drm_mode_create() in drm_cvt_mode() may
return NULL value in case of memory allocation error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode
Return value of a function 'drm_cvt_mode' is dereferenced without
checking for NULL but drm_mode_create() in drm_cvt_mode() may
return NULL value in case of memory allocation error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode
On 2/28/24 11:19, Thomas Zimmermann wrote:
> Hi
>
> Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
>> Hello,
>>
>> Thank you for the patches!
>>
>> On 2/27/24 13:14, Thomas Zimmermann wrote:
>>> Dma-buf locking semantics require the caller of pin and unpin to hold
>>> the buffer's reservation
On Fri, Mar 01, 2024 at 11:55:11AM +0300, Aleksandr Burakov wrote:
> Return value of a function 'drm_cvt_mode' is dereferenced without
> checking for NULL but drm_mode_create() in drm_cvt_mode() may
> return NULL value in case of memory allocation error.
>
> Found by Linux Verification Center
Il giorno mer 28 feb 2024 alle ore 08:41 Vivek Kasireddy
ha scritto:
>
> We do not want to stop a stream associated with gl_draw as a result
> of timeout because we may not get another opportunity to create a
> new stream if the current one gets stopped. However, when the
> stream does get
Il giorno mer 28 feb 2024 alle ore 08:41 Vivek Kasireddy
ha scritto:
>
> This patch adds a new function to enable the creation of Gst memory with
> the dmabuf fd as the source by using a dmabuf allocator. And, it also
> adds a mechanism to register and invoke any callbacks once the Gst memory
>
Il giorno mer 28 feb 2024 alle ore 08:41 Vivek Kasireddy
ha scritto:
>
> For non-gl/remote clients, if there is no stream associated with
> the DisplayChannel, then we create a new stream. Otherwise, we
> just update the current stream's timestamp.
>
> v2: (suggestions and fixups from Frediano)
>
Il giorno mer 28 feb 2024 alle ore 08:41 Vivek Kasireddy
ha scritto:
>
> We need to determine if the client is new enough to support multiple
> codecs -- which might include any of the Gstreamer based ones.
>
> v2: (suggestions and fixups from Frediano)
> - Add is_gl_client() method to
Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
>
1 - 100 of 48088 matches
Mail list logo
