Hi,
> 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.
Yep.
>>
>> 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
- Original Message -
>
>
> - Original Message -
> > 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
- Original Message -
> 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,
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
---
gtk/channel-main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index 699cff3..5c33e67 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -191,6 +191,9 @@ static const char *agent_caps[] = {
[ VD_AGENT_CAP_DISPLAY_CONFIG ] =
Hi Chuan,
On Thu, Oct 10, 2013 at 12:20 PM, wrote:
> The workaround in v3.3.3 works, and I can’t tell any difference on my
> samsung Galaxy s4, too. But on some of my friends’ devices it can tell.
> I also have a workaround. the idea is that, when the issue occurs we just
> recycle the bitmap an
Hi
- Original Message -
> Marc,
>
> > - Original Message -
> > It's using the same pixman functions. Even on linux, we currently use
> > it.
> >
> > In your graph, it is showing 100ms of cumulative time, that's not so
> > much. Draw alphablend is an expensive function, and it's u
> > Did the spice-html5 people already found a way to generate scancodes?
>
> I don't see the relation. For example, in case of html5 client to spiceterm,
> you
> don't need (and don't have) hw scancode.
I talk about html client with qemu. The suggested protocol extension provides
a clean soluti
Marc,
- Original Message -
It's using the same pixman functions. Even on linux, we currently use
it.
In your graph, it is showing 100ms of cumulative time, that's not so
much. Draw alphablend is an expensive function, and it's used
frequently.
Couldn't there be another reason for slo
- Original Message -
> > > The point is that we already have the code in qemu, and there is not
> > > really an other solutions for the javascript client (or is there a
> > > better way to do it?).
> >
> > I don't follow you.
>
> Did the spice-html5 people already found a way to generat
On Thu, Oct 10, 2013 at 05:47:03PM +0200, Marc-André Lureau wrote:
> clipboard_get() exits when the clipboard data is received, or when the
> agent connection state change. However, if the agent is already
> disconnected, neither of those 2 conditions can be reached.
>
> Check agent is connected b
ACK
On Thu, Oct 10, 2013 at 05:36:29PM +0200, Marc-André Lureau wrote:
> Use swapped connection to pass data as first argument to signal handler.
> ---
> gtk/spice-gtk-session.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gtk/spice-gtk-session.c b/gtk/spice-gtk-sessi
clipboard_get() exits when the clipboard data is received, or when the
agent connection state change. However, if the agent is already
disconnected, neither of those 2 conditions can be reached.
Check agent is connected before running loop, exit early if not.
---
gtk/spice-gtk-session.c | 9 +
clipboard_get() exists when the clipboard data is received, or the agent
connection state change. However, if the agent is already disconnected,
either of those 2 conditions can be reached.
Check agent is connected before running loop, exit early if not.
---
gtk/spice-gtk-session.c | 9 +
On Thu, Oct 10, 2013 at 05:34:28PM +0200, Marc-André Lureau wrote:
> spice_main_channel_reset_agent() reset connected state, and prevent
> notify of property change.
ACK
Christophe
>
> This is a minor regression introduced in c3adb24425.
> ---
> gtk/channel-main.c | 5 -
> 1 file changed,
Use swapped connection to pass data as first argument to signal handler.
---
gtk/spice-gtk-session.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/spice-gtk-session.c b/gtk/spice-gtk-session.c
index 476af95..af491d2 100644
--- a/gtk/spice-gtk-session.c
+++ b/gtk/spice-gtk
spice_main_channel_reset_agent() reset connected state, and prevent
notify of property change.
This is a minor regression introduced in c3adb24425.
---
gtk/channel-main.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index b342e97.
This partially reverts b19acbc. This commit broke the fallback
to the old protocol as it added a check for c->peer_msg != NULL
before calling switch_protocol(), but mismatch between local
and remote protocol versions is detected before c->peer_msg is
allocated, so:
if (c->peer_msg != NULL && c-
Looks good, thanks for fixing this.
ack
On Thu, Oct 10, 2013 at 5:15 PM, Christophe Fergeau wrote:
> After the previous commit, spice_channel_switch_protocol() is now
> called when needed, but it's not doing anything. What happens is
> that spice_channel_switch_protocol() triggers a channel disc
ack
On Thu, Oct 10, 2013 at 5:15 PM, Christophe Fergeau wrote:
> This partially reverts b19acbc. This commit broke the fallback
> to the old protocol as it added a check for c->peer_msg != NULL
> before calling switch_protocol(), but mismatch between local
> and remote protocol versions is detect
> > The point is that we already have the code in qemu, and there is not
> > really an other solutions for the javascript client (or is there a
> > better way to do it?).
>
> I don't follow you.
Did the spice-html5 people already found a way to generate scancodes?
After the previous commit, spice_channel_switch_protocol() is now
called when needed, but it's not doing anything. What happens is
that spice_channel_switch_protocol() triggers a channel disconnection
and then it queues an idle to reconnect (after having changed the
protocol version to be used).
W
Connecting to a RHEL5 host using SPICE is currently not working,
this patch series fixes this.
Christophe
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Sorry, I'll stop replying to each of you mails, because it becomes incoherent
and hard to follow.
Either try to summarize and wait for reply, or let's discuss it on IRC.
- Original Message -
>
>
> - Original Message -
> > > If you really want to send scancode, do it the same wa
- Original Message -
> > If you really want to send scancode, do it the same way as "Data
> > key_scancode"
> > for arbitrary sequence.
>
> will try.
>
> > Why did you drop the flags in the end?
>
> The information can be generated on the server side, so there is no real need
> to send
> If you really want to send scancode, do it the same way as "Data key_scancode"
> for arbitrary sequence.
will try.
> Why did you drop the flags in the end?
The information can be generated on the server side, so there is no real need
to send it over the wire.
> > Another advantage is that a
- Original Message -
> > > So the following message could in fact replace all existing messages for
> > keyboard input:
> > >
> > > message {
> > >uint32 keyval;
> > >uint32 scancode;
> > >keyboard_keyval_flags flags;
> > > } @ctype(SpiceMsgcKeyKeyval) key
- Original Message -
> > Ok, so I will add more space for scancodes. I have further optimized my
> > patch,
> > and I currently use:
> >
> > message {
> > uint32 keysym;
> > uint32 scancode_down;
> > uint32 scancode_up;
> > } @ctype(SpiceMsgcKeyX11Keysym
Oh, seems pause/break is 8bytes:
http://retired.beyondlogic.org/keyboard/keybrd.htm
E1,14,77,E1,F0,14,F0,77
Looks like a bad joke.
> -Original Message-
> From: spice-devel-bounces+dietmar=proxmox@lists.freedesktop.org
> [mailto:spice-devel-bounces+dietmar=proxmox@lists.freedeskt
- Original Message -
> > The Pause key seems to be sending 4 bytes scancodes if I read the docs I
> > looked
> > at recently correctly. Didn't get around to test it to see what happens
> > though ;)
>
> current code in spice-gtk only use 2 bytes:
>
> guint16 spice_make_scancode(guint s
> The Pause key seems to be sending 4 bytes scancodes if I read the docs I
> looked
> at recently correctly. Didn't get around to test it to see what happens
> though ;)
current code in spice-gtk only use 2 bytes:
guint16 spice_make_scancode(guint scancode, gboolean release)
___
> > So the following message could in fact replace all existing messages for
> keyboard input:
> >
> > message {
> >uint32 keyval;
> >uint32 scancode;
> >keyboard_keyval_flags flags;
> > } @ctype(SpiceMsgcKeyKeyval) key_keyval;
> >
>
> Let's keep the messages seper
> Ok, so I will add more space for scancodes. I have further optimized my patch,
> and I currently use:
>
> message {
> uint32 keysym;
> uint32 scancode_down;
> uint32 scancode_up;
> } @ctype(SpiceMsgcKeyX11Keysym) key_x11_keysym;
Another advantage is that a clie
> >
> > 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 rende
- 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 an
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 netwo
On Thu, Oct 10, 2013 at 01:20:11PM +0200, Marc-André Lureau wrote:
> Let's keep the messages seperate, as only one or the other will be
> used by the remote.
>
> Btw, scancode sequences can be arbitrary long in the current protocol.
> (there are scancode of 3-bytes out-there, even though we haven'
This fixes at least some issues when building with clang
---
m4/warnings.m4 | 82 --
1 file changed, 62 insertions(+), 20 deletions(-)
diff --git a/m4/warnings.m4 b/m4/warnings.m4
index 69d05a6..e3d239b 100644
--- a/m4/warnings.m4
+++ b/m4/w
m4/ contains several files tracked in git, so we should not ignore
the whole directory.
---
.gitignore | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 6318a83..8e73162 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,7 +17,11 @@ depcomp
instal
This commit reuse several macros from libvirt to test for
support for "-Wl,-z -Wl,relro", "-Wl,-z -Wl,now" and
"-Wl,--no-copy-dt-needed-entries", and use them if available.
---
configure.ac | 2 ++
m4/virt-linker-no-indirect.m4 | 32
m4/virt-linke
Hey, this series makes sure that we use the "-Wl,-z -Wl,relro",
"-Wl,-z -Wl,now" and "-Wl,--no-copy-dt-needed-entries" linker
flags when available, and update warnings.m4 to the latest
version from gnulib.
Christophe
___
Spice-devel mailing list
Spice-d
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
On Thu, Oct 10, 2013 at 6:10 AM, Dietmar Maurer wrote:
>> You didn't explain why you needed to add a new message, and a new DOWN/UP
>> flag. How to interpret scancode with the flag? You can't stick 2 3-bytes
>> scancodes for DOWN/UP, so is the server supposed to generate the UP
>> scancode? (that
- Original Message -
> > > So what happens if you connect to a VM from client with different
> > > keyboard layout than specified inside the VM?
> >
> > Just like with a guest, Spice sends hw scancode, and it's converted by the
> > server/application side.
>
> Ok, I will try to explain
- Original Message -
> Marc,
>
> as I read your message I started to dig deeper into the timings of the
> spicy process. Using the "Instruments" App on OSX I sampled the spicy
> and figured out that the major time while moving a Window within the
> spice session (on the guest VM) seems t
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.
48 matches
Mail list logo
