Tested and works well!
Big thanks!
Fred
> -Original Message-
> From: spice-devel-bounces+fred_liu=issi@lists.freedesktop.org
> [mailto:spice-devel-bounces+fred_liu=issi@lists.freedesktop.org] On
> Behalf Of Christophe Fergeau
> Sent: 星期二, 十月 08, 2013 0:10
> To: spice-devel@lists.f
> Well, you were not really explaining your particular case, or were you?
Yes, I tried at least, and I even provided a complete, working example code
(spiceterm).
> bypassing all of server, x & qemu & kernel etc...
>
> Arbitrary utf8 input can only be handled at user space / agent level (no way
- Original Message -
> >
> > 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
>
> 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 include optional 3D rendering c
- Original Message -
> > You said it yourself, unicode doesn't have representation for all keyboard
> > keys.
> > As you have seen in my previous reply, I am looking at the problem from an
> > "input-method" level. And I don't know if it's a good idea to depend on
> > X11/gdk
> > keysyms
Hi,
On 10/08/2013 04:30 PM, Daniel P. Berrange wrote:
On Tue, Oct 08, 2013 at 04:27:38PM +0200, Hans de Goede wrote:
Hi All,
I'm having this weird problem with qemu master + spice/qxl using
guests. As soon as the guest starts Xorg, I get the following message
from qemu:
main-loop: WARNING: I/
> You said it yourself, unicode doesn't have representation for all keyboard
> keys.
> As you have seen in my previous reply, I am looking at the problem from an
> "input-method" level. And I don't know if it's a good idea to depend on
> X11/gdk
> keysyms in general for Spice.
VNC use that for 2
Hi
- Original Message -
> > Keys that don't have utf8 equivalent should be sent with the current input,
> > I don't
> > see a benefit changing that.
> >
> > Having a utf8 input is mainly useful for utf8 input from client (input
> > method,
> > browser) and to bypass guest keymaps.
> >
>
> Keys that don't have utf8 equivalent should be sent with the current input, I
> don't
> see a benefit changing that.
>
> Having a utf8 input is mainly useful for utf8 input from client (input method,
> browser) and to bypass guest keymaps.
>
> It shouldn't be used for all inputs.
I need that
---
server/snd_worker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server/snd_worker.c b/server/snd_worker.c
index 5346d96..9156bf5 100644
--- a/server/snd_worker.c
+++ b/server/snd_worker.c
@@ -52,7 +52,7 @@
#define RECORD_SAMPLES_SIZE (SND_RECEIVE_BUF_SIZE >> 2)
-en
- Original Message -
>
>
> - Original Message -
> > > Yes, although I think we should be able to send arbitrary utf8 input in
> > > the
> > > protocol. If I read your proposal right, you are sending UCS-4 codes, no
> > > utf8?
> > >
> > > I think you should use gdk_keyval_to_un
Hi
> 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?
It sounds to me like this is something that an egl extension should provide,
but I can't find it yet.
___
- Original Message -
> > Yes, although I think we should be able to send arbitrary utf8 input in the
> > protocol. If I read your proposal right, you are sending UCS-4 codes, no
> > utf8?
> >
> > I think you should use gdk_keyval_to_unicode() then g_ucs4_to_utf8() for
> > key
> > input a
> Yes, although I think we should be able to send arbitrary utf8 input in the
> protocol. If I read your proposal right, you are sending UCS-4 codes, no utf8?
>
> I think you should use gdk_keyval_to_unicode() then g_ucs4_to_utf8() for key
> input and efficiency (in your spice-gtk patch).
Unfortu
Hi,
> This is mostly Dave's area of expertise, but let me try to explain things
> a bit better here. The dma-buf pass-through is for the Virgil case, so
> we're passing through 3D rendering commands from the guest to a real,
> physcial GPU inside the host, which then renders the final image to s
Hey Hans,
On Tue, Oct 08, 2013 at 04:27:38PM +0200, Hans de Goede wrote:
> I'm having this weird problem with qemu master + spice/qxl using
> guests. As soon as the guest starts Xorg, I get the following message
> from qemu:
>
> main-loop: WARNING: I/O thread spun for 1000 iterations
I've also s
Hi!
- Original Message -
> This is my second approach to implement the ability to send utf8 input from
> spice-gtk to spiceterm.
> https://git.proxmox.com/?p=spiceterm.git;a=summary
>
> The patch is quite simple.
>
> I still hope there is some interest to get that working?
Yes, althou
On Tue, Oct 08, 2013 at 04:27:38PM +0200, Hans de Goede wrote:
> Hi All,
>
> I'm having this weird problem with qemu master + spice/qxl using
> guests. As soon as the guest starts Xorg, I get the following message
> from qemu:
>
> main-loop: WARNING: I/O thread spun for 1000 iterations
>
> And f
Hi All,
I'm having this weird problem with qemu master + spice/qxl using
guests. As soon as the guest starts Xorg, I get the following message
from qemu:
main-loop: WARNING: I/O thread spun for 1000 iterations
And from then on the guest hangs and qemu consumes 100% cpu. The qemu
console still w
However, I can see the record path has a fixed 44100 value, which is probably
bogus today for != 44100 recording?
Yah; there is a fair amount of hard coding (although I'm probably
overly biased by my time in the old client :-/).
And, afaik, there's not a lot of testing done at anything other t
- Original Message -
> > On old client connection, new qemu/new spice-server should also use celt,
> > the old client should be able to decode that even if it's 48kHz.
>
> Perhaps; but the number of hard coded values, and the fact
> that this code has never been run at anything but 44.1
On Tue, Oct 08, 2013 at 08:32:26AM -0500, Jeremy White wrote:
> >On old client connection, new qemu/new spice-server should also use celt,
> >the old client should be able to decode that even if it's 48kHz.
>
> Perhaps; but the number of hard coded values, and the fact
> that this code has never b
Hi,
On 10/08/2013 03:18 PM, Gerd Hoffmann wrote:
Hi,
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, i
On old client connection, new qemu/new spice-server should also use celt,
the old client should be able to decode that even if it's 48kHz.
Perhaps; but the number of hard coded values, and the fact
that this code has never been run at anything but 44.1 makes me nervous.
At the very least, won't
- Original Message -
> >> Attached is a patch that suggests my idea. I've done some hacks,
> >> and it seems 'safe' to adjust the rate on the fly like this.
> >
> > line_out_ctl is driven by guest. Why would you change the rate when the
> > device start/stop a stream? I don't think that'
Hi,
> 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 w
On Tue, Oct 08, 2013 at 08:03:05AM -0500, Jeremy White wrote:
> >If qemu is old, it should use 44.1 celt only.
> >If qemu is new, it can use 48 celt or opus.
> >
> >This doesn't have to change dynamically, the client should be able to adapt
> >to any of these situations.
>
> Yes, a new client sho
Attached is a patch that suggests my idea. I've done some hacks,
and it seems 'safe' to adjust the rate on the fly like this.
line_out_ctl is driven by guest. Why would you change the rate when the device
start/stop a stream? I don't think that's the right approach.
Well, if you're going to
On Tue, Oct 08, 2013 at 07:03:20AM -0400, Marc-André Lureau wrote:
>
> - Original Message -
> > reds_on_main_agent_monitor_config() is manually implementing
> > a grow-on-append char *. glib's GByteArray can do this for us,
> > using it makes the code simpler to read.
>
> Also I don't cle
- Original Message -
> reds_on_main_agent_monitor_config() is manually implementing
> a grow-on-append char *. glib's GByteArray can do this for us,
> using it makes the code simpler to read.
Given that we don't have test suite, I am not really for such small cleanup
changes. Also I don'
ack all
- Original Message -
> ---
> server/main_channel.h | 4 ++--
> server/red_worker.c | 8
> server/snd_worker.c | 6 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/server/main_channel.h b/server/main_channel.h
> index 29eb8d4..c8e9ade 100644
reds_on_main_agent_monitor_config() is manually implementing
a grow-on-append char *. glib's GByteArray can do this for us,
using it makes the code simpler to read.
---
server/reds-private.h | 4 +---
server/reds.c | 27 +--
2 files changed, 14 insertions(+), 17 de
---
server/reds.c | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index dd1bd68..c2b3fff 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -141,7 +141,7 @@ typedef struct AsyncRead {
typedef struc
'receive' was mispelt 'recive' in multiple places.
---
server/red_worker.c | 8 +++---
server/reds-private.h | 6 ++---
server/reds.c | 72 +--
server/snd_worker.c | 40 ++--
4 files changed, 63 insertions(+), 63
---
server/main_channel.h | 4 ++--
server/red_worker.c | 8
server/snd_worker.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/server/main_channel.h b/server/main_channel.h
index 29eb8d4..c8e9ade 100644
--- a/server/main_channel.h
+++ b/server/main_channel
Hey,
The following 3 patches fix a few typos, and also make sure we don't have
multiple constants named RECEIVE_BUF_SIZE in the codebase.
Christophe
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
Hi All,
I realize that it may be a bit early to start this discussion,
given the somewhat preliminary state of Virgil, still I would
like to start a discussion about this now for 2 reasons:
1) I believe it would be good to start thinking about this earlier
rather then later.
2) I would like to
- Original Message -
> > 2. Modify qemu to change the device sample rate dynamically
> >
> > This seems like it should be possible. I'm working up a
> > hack to try it (basically, we regen the rate at voice_enable
> > time). This seems to fly in the face of 'normal
40 matches
Mail list logo
