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,
> has some sort of unix socket that the viewer connects to and can hand
> fds across, then the client v
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,
>> has some sort of unix socket that the view
On Mi, 2013-10-09 at 08:46 +1000, Dave Airlie wrote:
> > 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 ha
Hi,
On 10/09/2013 10:44 AM, Gerd Hoffmann wrote:
What is virtio-vga btw? The virgil virtual vga device
Yes, see:
http://airlied.livejournal.com/78104.html
Regards,
Hans
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://list
I just detected that my simple spiceterm generates more than
1000 drawables, so alloc_drawable() always fail.
The effect is that I always draw twice (on server and at client)!
I guess one would see the same effect when running a xterm inside a VM, because
a terminal has a size of 80x25 character
Hi,
> > When the guests virtual gfx card doesn't let the gpu render into a
> > dma-buf we have to copy the bits anyway. Ideally just memcpy from guest
> > framebuffer to a dma-buf (not sure drm allows that), so we can hand out
> > a dma-buf handle for rendering no matter whenever the guest uses
On 09/25/2013 09:56 AM, Christophe Fergeau wrote:
On Tue, Sep 24, 2013 at 08:47:37PM +0300, Uri Lublin wrote:
It seems better to me that spice-common would check whatever it is
asked, via v->verifyop,
and not return after the first successful test.
If hostname is known to be wrong, it should no
On 09/20/2013 06:07 PM, Christophe Fergeau wrote:
It contains the same information as before, but should be more readable.
---
common/ssl_verify.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/ssl_verify.c b/common/ssl_verify.c
index e10ed52..d4b89f0 100644
---
- Original Message -
> > 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).
It shouldn't be necessary to read your code to understand what you try to
achieve and what are
- Original Message -
>
>
> I just detected that my simple spiceterm generates more than
>
> 1000 drawables, so alloc_drawable() always fail.
>
>
>
> The effect is that I always draw twice (on server and at client)!
This is an area I am newbie ;)
Isn't the server always drawing any
> I still have to answer myself the question "why is the current XT scancode
> input
> not enough"? Although I think I have guessed, it would be good to explain
> that,
> to motivate the reason for this change.
Some SPICE applications want to use the keymap from the client side, and
works direc
> > I just detected that my simple spiceterm generates more than
> >
> > 1000 drawables, so alloc_drawable() always fail.
> >
> >
> >
> > The effect is that I always draw twice (on server and at client)!
>
> This is an area I am newbie ;)
>
> Isn't the server always drawing anyway at some point?
- Original Message -
> > > I just detected that my simple spiceterm generates more than
> > >
> > > 1000 drawables, so alloc_drawable() always fail.
> > >
> > >
> > >
> > > The effect is that I always draw twice (on server and at client)!
> >
> > This is an area I am newbie ;)
> >
> > I
- Original Message -
> > I still have to answer myself the question "why is the current XT scancode
> > input
> > not enough"? Although I think I have guessed, it would be good to explain
> > that,
> > to motivate the reason for this change.
>
> Some SPICE applications want to use the ke
Hi,
I think the hardcoded limit was intended for limiting the occupancy of
the dev ram with drawables that are referenced by the display channel.
If the limit is reasonable it should help with keeping allocations in
the driver fluent, and avoiding IO_OOM.
An alternative approach is to monitor t
> > No. There is no need to draw anything at the server side (for spiceterm).
>
> Ok, that would be interesting. I wonder if you are not better off
> implementing a
> new display channel for your use case, if you just need to send off your own
> rendering commands without any change.
why is that
> > Note: you cannot translate a scancode to utf8 (because you do not know
> > the keymap of the client).
>
> Or perhaps you could, that would allow to sync client and guest with the same
> keymap.
That is clumsy, and also requires a protocol extension - so what is the
advantage?
> > Hope that
> I think the hardcoded limit was intended for limiting the occupancy of the dev
> ram with drawables that are referenced by the display channel.
> If the limit is reasonable it should help with keeping allocations in the
> driver
> fluent, and avoiding IO_OOM.
> An alternative approach is to moni
> An alternative approach is to monitor the actual size that is currently
> occupied
> by drawables that are referenced by the display channel, and to limit *this*
> size,
> instead of the number of drawables
Another alternative is to draw always (see DRAW_ALL in the code).
My tests with spicet
I've just pushed this patch as I hit that issue.
Christophe
On Tue, Oct 01, 2013 at 04:00:30PM -0500, Jeremy White wrote:
> Signed-off-by: Jeremy White
> ---
> client/screen.cpp |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/client/screen.cpp b/client/screen.cpp
> index e76fd50.
- Original Message -
> > > Note: you cannot translate a scancode to utf8 (because you do not know
> > > the keymap of the client).
> >
> > Or perhaps you could, that would allow to sync client and guest with the
> > same
> > keymap.
>
> That is clumsy, and also requires a protocol exten
> > That is clumsy, and also requires a protocol extension - so what is
> > the advantage?
>
> "sync client and guest with the keymap" & avoid the need for new key event.
I guess you over-simplify that. There are many different keymaps on the client
side!
So you do you correctly translate the sc
On Wed, Oct 9, 2013 at 8:20 PM, Dietmar Maurer wrote:
>> So why do you ask? I am just answering your question.
>
> Oh, I get you wrong. So you really think we can modify existing message
> formats based on caps?
> That looks a bit confusing to me, and it is not clear how that should work
> beca
> > Oh, I get you wrong. So you really think we can modify existing message
> formats based on caps?
> > That looks a bit confusing to me, and it is not clear how that should
> > work because message marshallers are auto-generated?
>
> I don't remember. In the case of clipboard selection, it was
- Original Message -
> > > Oh, I get you wrong. So you really think we can modify existing message
> > formats based on caps?
> > > That looks a bit confusing to me, and it is not clear how that should
> > > work because message marshallers are auto-generated?
> >
> > I don't remember.
> > Not everything is a VM (there is no server side keymap in spiceterm).
>
> But even *userspace* x11 or weston spice server handle keymaps. You could
> too, using xkb common.
I am not sure what you want to tell here. The problem is that you do not know
the
keymap of the client side.
So even i
On Mon, Oct 7, 2013 at 11:44 AM, wrote:
> Signed-off-by: Dietmar Maurer
>
> Index: new/spice-common/spice-protocol/spice/vd_agent.h
> ===
> --- new.orig/spice-common/spice-protocol/spice/vd_agent.h 2013-10-07
> 10:51:28.0
> I think you should keep the UP flag there you had in your previous proposal
> (to
> avoid problems of network latency, generating spurious key repeatition events
> on application/guest side)
OK
> Why not have SUPER (win key), HYPER and META?
Sure, I can add them
>
> > +typedef struct SPICE
On Mon, Oct 7, 2013 at 11:44 AM, wrote:
> Signed-off-by: Dietmar Maurer
>
> Index: new/gtk/channel-main.c
> ===
> --- new.orig/gtk/channel-main.c 2013-10-07 11:01:52.0 +0200
> +++ new/gtk/channel-main.c 2013-10-07 11:02
- Original Message -
> > > Not everything is a VM (there is no server side keymap in spiceterm).
> >
> > But even *userspace* x11 or weston spice server handle keymaps. You could
> > too, using xkb common.
>
> I am not sure what you want to tell here. The problem is that you do not know
> > switch (key->type) {
> > case GDK_KEY_PRESS:
> > +flags |= VD_AGENT_KEYVAL_FLAG_DOWN;
> > +spice_main_send_keyval(d->main, key->keyval, flags);
>
> This is the wrong place if you want to avoid the key repeatition issue solved
> by
> "send_key" (synthesize press_and_r
- Original Message -
> > > switch (key->type) {
> > > case GDK_KEY_PRESS:
> > > +flags |= VD_AGENT_KEYVAL_FLAG_DOWN;
> > > +spice_main_send_keyval(d->main, key->keyval, flags);
> >
> > This is the wrong place if you want to avoid the key repeatition issue
> > so
> 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 would be different from existing scancode events)
I read th
> > 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 the problem again.
Spice/qemu currently assu
> > I want to get key repetition message here!
>
> Can you be more precise? As you can read in spice-gtk code, send_key() is
> still
> doing some filtering of gtk key events, not directly sending them as Spice
> events:
I miss-understood that code, but now I can see how it works.
> send_key()
35 matches
Mail list logo
