Hi!
I've been trying out spice on fedora 14 x86_64. I have an F14 guest
that I configured to test things out. Things look really promising.
The first stumbling block is getting native full-screen to work.
Because my monitor is 1900x1200 I had to apply this to qemu and rebuild
the RPM, or else
H
i,
On 01/20/2011 12:27 PM, Christoph Hellwig wrote:
On Wed, Jan 19, 2011 at 07:15:47PM +0100, Hans de Goede wrote:
Hi All,
As most of you know I'm working on usb redirection (making client usb
devices
accessible in guests over the network).
I thought it would be a good idea
,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Perhaps the client should fork and the parent process can watch for this
scenario and restore the resolution safely that way?
O
n Tue, 2011-03-01 at 18:25 +0200, Hans de Goede wrote:
This avoids us trying to restore the original resolution when we're fullscreen
and an X error happens. As
On 03/09/2012 12:26 PM, Nahum Shalman wrote:
Allow applications to pre-open a file descriptor and have spice listen
on it.
Thanks to Daniel Berrange for his comments
---
server/reds.c| 21 +
server/spice-server.syms |1 +
server/spice.h |
On 04/05/2012 11:58 AM, Alon Levy wrote:
On Thu, Apr 05, 2012 at 01:24:54PM +0200, Michael Niehren wrote:
Hi together,
i successfully installed and connected to Xspice und FC16, great work, i was
very pleased
to see, what's possible with spice.
1 thing left to use it as an Server to
On 06/12/2012 09:11 AM, Marc-André Lureau wrote:
Hi
- Mensaje original -
The ideal solution would be to have support for Opus, I think Marc
André
and Alon had started to look into that, but that's not done yet :(
No, I didn't. Long time ago I proposed we have celt unstable flag,
.
---
Should this be working, or do I need a different set of packages, or to
recompile something from source or something else?
I'd love to give this a try.
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel
Hi All,
I'm trying to get dual-head spice to work and having lots of problems.
- host is fully up-to-date F18 without virt preview repo.
- guest is freshly created/installed F19 (today), created with
virt-manager, and with this option manually added to domain xml
afterwards, as per Hans's
is offset up and left from displayed mouse
position.
Any ideas to get this working?
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
On 08/20/2013 09:21 AM, David Mansfield wrote:
Hi All,
I'm trying to get two displays working. Host and guest are fully
updated Fedora 19 (x86_64).
When I open the second display using the menu in remote-viewer, it
comes up black.
As soon as I run xrandr (with NO options) from
and reconnect on the original
and be able to get two monitors again, fullscreen with correct resolution.
Is this something that anyone has been able to get working ever?
Thanks,
David Mansfield
___
Spice-devel mailing list
Spice-devel
to a resolution less
than what I requested, and stays stable.
If anyone wants any kind of debugging, logs etc. with/without qxl.ko
installed to narrow this down, I'll do it. Let me know.
So kudos to all for what I've always hoped to see, and finally do!
Looking good everybody.
--
Thanks,
David Mansfield
On 11/10/2013 07:27 PM, Dave Airlie wrote:
On Sat, Nov 9, 2013 at 7:34 AM, Marc-André Lureau mlur...@redhat.com 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
On 04/09/2014 07:15 AM, Itamar Heim wrote:
On 04/09/2014 01:57 PM, René Koch wrote:
On 04/09/2014 11:24 AM, René Koch wrote:
Thanks a lot for testing.
Too bad that multiple monitors didn't work for you, too.
I'll test RHEL next - maybe this works better then Fedora...
I just tested CentOS
On 04/11/2014 10:35 AM, David Mansfield wrote:
On 04/11/2014 04:16 AM, Christophe Fergeau wrote:
On Thu, Apr 10, 2014 at 05:24:21PM -0400, David Mansfield wrote:
On 04/09/2014 07:15 AM, Itamar Heim wrote:
On 04/09/2014 01:57 PM, René Koch wrote:
On 04/09/2014 11:24 AM, René Koch wrote
(if that is the correct term) that the
spice-server is managing.
Any pointers?
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
On 04/15/2014 10:35 AM, David Mansfield wrote:
Hi All:
I'd like to be able to trace all events going back and forth between
spice server / client and also between Xorg driver (qxl) and spice
server regarding monitor connect resize etc.
The reason for this is that I'd like to debug why
On 04/15/2014 04:32 PM, Lindsay Mathieson wrote:
On Tue, 15 Apr 2014 10:35:32 AM David Mansfield wrote:
I'd like to be able to trace all events going back and forth between
spice server / client and also between Xorg driver (qxl) and spice
server regarding monitor connect resize etc.
Monitor
On 04/16/2014 03:15 AM, Christophe Fergeau wrote:
On Wed, Apr 16, 2014 at 06:32:30AM +1000, Lindsay Mathieson wrote:
Monitor resize is handled by the spice-vdagent app in the *guest* system, it
must be installed and running in the guest for that to work. It serves the
same purpose as the guest
On 04/16/2014 09:41 AM, David Mansfield wrote:
On 04/16/2014 03:15 AM, Christophe Fergeau wrote:
On Wed, Apr 16, 2014 at 06:32:30AM +1000, Lindsay Mathieson wrote:
Monitor resize is handled by the spice-vdagent app in the *guest*
system, it
must be installed and running in the guest
in spice-server at this point) periodically?
I'm happy to compile from source, run gdb debug c code etc, but I need
some direction.
Seems first question is:
Is this an issue only for spice-gtk (ie. client) or is there an actual
spice-server / qemu / qxl.ko / xorg-qxl bug?
--
Thanks,
David
,
David Mansfield
Cobite, INC.
David, did you open a bug on this anywhere? I have the same problem going on
with LXDE. Cinnamon works great.
I'm planning to open a fedora bug for it, but I'm doing a bit more
debugging first in the client... I'm not certain I understand how the
above change (which
On 04/21/2014 01:23 PM, David Mansfield wrote:
On 04/21/2014 12:02 PM, Greg Sheremeta wrote:
In particular, with MATE we get a bunch of:
(remote-viewer:12916): GSpice-WARNING **: FIXME: only support monitor
config with primary surface 0, but given config surface 5
Which seems suspicious
Hi all:
Is it possible to configure spice agent to lock the (guest) screen when
disconnect occurs?
If the answer is not currently, the next question would be: are
patches welcome?
The command:
xdg-screensaver lock
should lock the screen in most (linux) environments.
--
Thanks,
David
On 04/23/2014 09:45 AM, David Mansfield wrote:
On 04/21/2014 01:23 PM, David Mansfield wrote:
On 04/21/2014 12:02 PM, Greg Sheremeta wrote:
In particular, with MATE we get a bunch of:
(remote-viewer:12916): GSpice-WARNING **: FIXME: only support monitor
config with primary surface 0
Hi All:
I'm experiencing massive memory leaks in remote-viewer. It seems that I
can leak amout 100MB in 15 seconds by opening google chrome, and hitting
a page which gives the spinny mouse cursor and then madly wiggling the
mouse over the chrome window.
By the end of the day, I'm way over
On 05/06/2014 06:04 AM, Marc-André Lureau wrote:
Hi
- Original Message -
On 05/05/2014 04:10 PM, Marc-André Lureau wrote:
Hi
- Original Message -
Any way to easily trace memory leaks in remote-viewer? A naive attempt
at valgrind remote-viewer spice://blah didn't turn up
On 05/06/2014 09:49 AM, David Mansfield wrote:
On 05/06/2014 06:04 AM, Marc-André Lureau wrote:
Hi
- Original Message -
On 05/05/2014 04:10 PM, Marc-André Lureau wrote:
Hi
- Original Message -
Any way to easily trace memory leaks in remote-viewer? A naive
attempt
On 05/06/2014 11:12 AM, Marc-André Lureau wrote:
- Original Message -
Hi
- Original Message -
On 05/06/2014 09:49 AM, David Mansfield wrote:
On 05/06/2014 06:04 AM, Marc-André Lureau wrote:
Hi
- Original Message -
On 05/05/2014 04:10 PM, Marc-André Lureau wrote
On 05/06/2014 02:35 PM, Marc-André Lureau wrote:
Hi
- Original Message -
I patched gtk3 with the attached and the problem seems fixed. Note: I
added the cairo_surface_destroy in gdkcursor.c because:
1) symmetry - it's allocated there
2) looking at a few of the different backends,
On 05/02/2014 09:05 AM, Marc-André Lureau wrote:
Hi
FYI: I have been running with the attached patch (not the inline above)
to spice-gtk for one week now, and so has my colleague. Dual monitor
works perfectly. There is one other crash scenario (xorg in guest
crashes and won't restart) which
On 05/07/2014 05:41 PM, David Mansfield wrote:
On 05/02/2014 09:05 AM, Marc-André Lureau wrote:
Hi
FYI: I have been running with the attached patch (not the inline above)
to spice-gtk for one week now, and so has my colleague. Dual monitor
works perfectly. There is one other crash
surface_id inside qxl.ko. These two things seem to get confused.
Hopefully Alon or Dave can shed some light here.
Yes, please!
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http
or is
something else broken here?
FYI: I'm running F20 fully updated guest, host and client (all same
box). I'm running dual head 1920x1200 (3840x1200 total FB resolution).
Thanks,
David Mansfield
Cobite, INC.
Thread 1 (Thread 0x7f35578169c0 (LWP 1256)):
#0 0x003810c35c39 in __GI_raise
MAX_RELOCS or is
something else broken here?
FYI: I'm running F20 fully updated guest, host and client (all same
box). I'm running dual head 1920x1200 (3840x1200 total FB
resolution).
Thanks,
David Mansfield
Cobite, INC.
Thread 1 (Thread 0x7f35578169c0 (LWP 1256)):
#0 0x003810c35c39
On 05/13/2014 04:01 PM, David Mansfield wrote:
Hi All:
I'd like help tracking down the solution to a very repeatable xorg
crash. I can cause the crash by either:
1) logging in and opening the second monitor without having removed
~/.config/monitors.xml first.
2) using shutter (screen
The maximum number of commands that can be queued at once is fixed at
compile time at MAX_RELOCS. However, during the creation of an image
object in qxl_image_create(), the image is split into commands of
maximum size 512*512. For a large dual-head system, it is easy to create
an image for
spice-server and downstream code expect that the primary surface will
always have surface_id = 0. In a dual head environment, all monitors
render portions of the primary surface.
However, when the monitor config events are generated and sent, the
primary surface (which has an internal id
not received any feedback.
(*) by coincidence, dual head with small-ish monitor sizes does work
better on gnome3 than it does with other DE (ie. MATE or fluxbox) due
simply to luck in the order that the monitors/surfaces ioctl are called,
but not due to any design.
--
Thanks,
David Mansfield
On 05/19/2014 10:01 AM, David Mansfield wrote:
spice-server and downstream code expect that the primary surface will
always have surface_id = 0. In a dual head environment, all monitors
render portions of the primary surface.
However, when the monitor config events are generated and sent
On 05/19/2014 10:01 AM, David Mansfield wrote:
This patch series addresses two critical bugs that prevent dual-head
from working in a linux-linux environment. (All testing done on F20
fully updated as guest, host and client).
We (myself and a colleague) have been using patched versions
that code has moved on
c) Go away
d) Oops, I've been meaning to get back to you but I keep forgetting and
life is hectic...
e) Didn't you hear? SPICE is dead.
f) Other. Please elaborate using the space provided below:
On 05/27/2014 10:49 AM, David Mansfield wrote:
On 05/19/2014 10:01 AM, David
On 06/09/2014 07:18 AM, Alon Levy wrote:
On 06/03/2014 04:14 PM, David Mansfield wrote:
Bump. I'll make it easy. This is a multiple choice response form.
Anyone reading this can respond with one letter so save time and effort.
a) We're too busy with RHEL 7/paying clients, come back
On 06/09/2014 09:29 AM, Alon Levy wrote:
On 06/09/2014 04:18 PM, David Mansfield wrote:
On 06/09/2014 07:18 AM, Alon Levy wrote:
On 06/03/2014 04:14 PM, David Mansfield wrote:
Bump. I'll make it easy. This is a multiple choice response form.
Anyone reading this can respond with one letter
On 06/09/2014 09:29 AM, Alon Levy wrote:
On 06/09/2014 04:18 PM, David Mansfield wrote:
On 06/09/2014 07:18 AM, Alon Levy wrote:
On 06/03/2014 04:14 PM, David Mansfield wrote:
Bump. I'll make it easy. This is a multiple choice response form.
Anyone reading this can respond with one letter
On 06/17/2014 03:24 AM, Alon Levy wrote:
On 06/16/2014 04:16 PM, David Mansfield wrote:
On 06/09/2014 09:29 AM, Alon Levy wrote:
On 06/09/2014 04:18 PM, David Mansfield wrote:
On 06/09/2014 07:18 AM, Alon Levy wrote:
On 06/03/2014 04:14 PM, David Mansfield wrote:
Bump. I'll make it easy
forbidden, so I'm doing a temperature check before
I do anything. The alternative would be to auto-tune the value. If the
auto-tune route is the way to go, I can come up with some ideas, but
that can stay on hold.
Thoughts?
--
Thanks,
David Mansfield
Cobite, INC
would like
to see make it's way into distributions ASAP (fixes repeatable xorg
crash), but I didn't submit a patch for any spec file.
If an upstream release is not a possibility, can you point me to the
spec you are patching? Is it Fedora? RHEL?
--
Thanks,
David Mansfield
Cobite, INC
or configuration changes to address
this to track it down.
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
implemented in qemu that may be different?
Your help would be most welcome to investigate and improve this further.
I'll do my best :-) . Sometimes it's just a maze of twisty little
passages, all alike...
--
Thanks,
David Mansfield
Cobite, INC
0001-worst-hack-of-all-time-to-qxl-driver.patch
# Support for old revision 1 qxl device (which won't go upstream)
0002-Add-old-driver-in-as-a-compatibility-layer.patch
0003-Link-in-the-compat-driver-various-renamings.patch
0004-compat-bump-to-new-server-API-changes.patch
--
Thanks,
David
On 07/29/2014 11:09 AM, David Mansfield wrote:
On 07/28/2014 09:10 AM, Hans de Goede wrote:
Hi,
$subject says it all, I've looked into doing this myself,
but there are quite a few patches, which likely can be all dropped,
but I believe it is better for the update to be done by someone who
On 07/29/2014 01:01 PM, David Mansfield wrote:
On 07/29/2014 11:09 AM, David Mansfield wrote:
On 07/28/2014 09:10 AM, Hans de Goede wrote:
Hi,
$subject says it all, I've looked into doing this myself,
but there are quite a few patches, which likely can be all dropped,
but I believe
On 07/16/2014 05:39 PM, David Mansfield wrote:
On 07/15/2014 11:22 AM, Marc-André Lureau wrote:
Hi
- Original Message -
Hi All,
We have been piloting deployments of VM using Fedora 20 host and guest
and have been very happy with performance and stability in almost every
respect, so
.
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
On 08/12/2014 05:10 AM, Christophe Fergeau wrote:
On Mon, Aug 11, 2014 at 03:34:07PM -0400, David Mansfield wrote:
Hi All,
I have a qemu 1.6.2 (SRPM from F20 recompiled on Centos 7) which crashed
with the following in the qemu log.
Not sure exactly what the timing of the messages are here
On 08/12/2014 05:10 AM, Christophe Fergeau wrote:
On Mon, Aug 11, 2014 at 03:34:07PM -0400, David Mansfield wrote:
Hi All,
I have a qemu 1.6.2 (SRPM from F20 recompiled on Centos 7) which crashed
with the following in the qemu log.
Not sure exactly what the timing of the messages are here
On 08/06/2014 01:47 PM, David Mansfield wrote:
On 07/16/2014 05:39 PM, David Mansfield wrote:
On 07/15/2014 11:22 AM, Marc-André Lureau wrote:
Hi
- Original Message -
Hi All,
We have been piloting deployments of VM using Fedora 20 host and guest
and have been very happy
before? After this, Xorg / GDM restarts ok and
system works fine without a reboot.
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
saver, I think the current behavior is pretty
ok: local screensaver is inhibited until the exact moment of ungrab
(e.g. leaving fullscreen and moving the mouse out) and then the local
screensaver kicks in.
--
Thanks,
David Mansfield
Cobite, INC
have a discard policy when the client is missing and
is the 150-300ms timing loop in the guest based on anything?
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org
Hi All,
Can anyone point me in the right direction for snooping on USB messages
going to a windows VM either from host device passthrough or spice usb
passthrough?
I'd like to reverse engineer some USB speakerphone HID stuff.
--
Thanks,
David Mansfield
Cobite, INC
mouse over to answer a
call, the screen locks! Funny!
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
it is
configurable.
The environment variable approach that's floating would work but is so
hidden that the two of us would be the only ones on the planet using
it! But aside from that, I'm all for it!
--
Thanks,
David Mansfield
Cobite, INC
conclusion is that the command line argument isn't working anymore
and the 16MB default is back in place.
Has qemu/libvirt changed somehow making this old syntax invalid?
--
Thanks,
David Mansfield
Cobite, INC.
___
Spice-devel mailing list
Spice-devel
On 06/19/2015 02:22 PM, David Mansfield wrote:
Hi All,
We (4 of us in my company) have been very happy with spice over the
last year or so running with dual 1920x1200 monitors, for which
qxl-vga.vgamem_mb always needed to be set to 32 (default is 16) or
Xorg-qxl doesn't get enough video ram
On 10/01/2015 02:47 AM, Vinzenz Feenstra wrote:
On 09/30/2015 10:03 PM, Barak Azulay wrote:
Barak
On Sep 30, 2015, at 10:04, Michal Skrivanek
<<mailto:michal.skriva...@redhat.com>michal.skriva...@redhat.com> wrote:
On Sep 25, 2015, at 19:40 , David Mansfield
<<mailto:o
is
launched by remote-viewer. This password expires after a short period of
time. So is there a mechanism where access is denied if a user is
already connected or is this allowed?
Enough questions for now, sorry for the battering.
--
Thanks,
David Mansfield
Cobite, INC.
_
see how anyone would be able to control using configuration
files.
7) Windows agent feature parity?
--
Thanks,
David Mansfield
Cobite, INC.
diff -ur spice-vdagent-0.15.0.orig/src/vdagent-x11.c spice-vdagent-0.15.0/src/vdagent-x11.c
--- spice-vdagent-0.15.0.orig/src/vdagent-x11.c 2013-10-14 08:5
On 09/23/2015 10:56 AM, Michal Suchanek wrote:
Hello,
On Wed, Sep 23, 2015 at 10:05:40AM -0400, David Mansfield wrote:
Hi,
The attached is a very simple patch, which is working but possibly not
suitable for inclusion at this point, that locks the x11 session when the
client disconnects
On 09/24/2015 12:46 PM, Victor Toso wrote:
Hey,
On Wed, Sep 23, 2015 at 10:05:40AM -0400, David Mansfield wrote:
Hi,
The attached is a very simple patch, which is working but possibly not
suitable for inclusion at this point, that locks the x11 session when the
client disconnects.
Locking
72 matches
Mail list logo
