> Also, do you account for intermediate CA in your setup? You have basically
> two options how to handle it:
>
> 1) "standard": server-cert.pem should contain the whole chain of certificates
> under root CA, e.g:
> * Int. CA 1
> * Int. CA 2
> * server cert
> you just cat them to the fi
> To make sure I understand, you start with a Root CA which I assume you
> generated yourself and is self-signed?
We use official certs from "StartCom Certification Authority" using
" StartCom Class 2 Primary Intermediate Server CA" intermediate CA.
But we just observed that the same setup wor
> I think you must be able to "openssl verify" your file without specifying the
> CAfile, if you want Spice ssl checks to pass.
Sorry, but how should that work? For example:
# cat server.pem intermediate_certificate.pem ca.pem >mix.pem
So the file contains all needed certificates, but:
# openss
I use the following certificate files:
# openssl verify -CAfile /etc/pve/pve-root-ca.pem /etc/pve/local/pve-ssl.pem
/etc/pve/local/pve-ssl.pem: OK
I pass the content of /etc/pve/pve-root-ca.pem to virt-viewer:
[virt-viewer]
ca=-BEGIN CERTIFICATE-\nXX/Q=\n-END CERTIFICATE-\
>support for unencrypted tickets, the server can
> instruct it it should send one. For now, this is restricted to encrypted
> channels as
> we don't want to expose an unencrypted password over a non-TLS channel.
> Clients with unencrypted password support won't send these just yet as the
> server
> Now, let's say the user connects from their Android device to the same VM
> while
> on the road. If the VM is set to use QWERTZ, but I am using the "common"
> layout file that is under discussion
I think you are confused. Nobody used the 'common' layout. Instead, that file is
used as default ma
> We're discussing (for example) a German user who has picked QWERTZ inside
> their VM so that when they're connecting from their laptop which also has
> QWERTZ, everything is sane.
> Now, let's say the user connects from their Android device to the same VM
> while
> on the road. If the VM is set
> So it certainly doesn't cover all the cases (QWERTZ, AZERTY, etc) that
> Opaque/aSPICE need to cover!
I am not sure why you want to depend on the andriod keyboard layout?
Simply set the VM to use a QWERTZ keyboard, and use the same layout
with oqaque?
Or do you want to emulate android devices
> Case in point. Let's consider:
> /usr/share/qemu/keymaps/de
> The user wants to input the letter "q" from their Android device. Since this
> is
> QWERZ, I need a mapping of unicode 0x71 to scancode 0x10.
> All I can find in /usr/share/qemu/keymaps/de that mentions 0x10 is the "at"
> symbol with
Not sure if I understand your question. Those files have mappings for letters
and numbers.
You can look up the used names in /usr/include/X11/keysymdef.h file.
I use a small script to extract those name->unicode mappings:
https://git.proxmox.com/?p=spiceterm.git;a=blob;f=genkeysym.pl;h=cdccf3cf
> I really didn't like the idea of releasing Opaque (the oVirt/RHEV VM console
> Android client) into production supporting only English (QWERTY), so I decided
> to implement a workaround for the existing inability to send Unicode directly
> to
> the OS of the VMs. It's not perfect, because it req
> On Fri, Oct 25, 2013 at 10:43:13AM +0200, Christophe Fergeau wrote:
> > On Tue, Oct 22, 2013 at 11:07:56AM +0200, diet...@proxmox.com wrote:
> > > Current code works with DIGEST-MD5, but not with PLAIN.
> >
> > After spending quite some time on this, this seems right, we need to
> > handle
> > sa
> This seems to be asking for a username both in the SASL case when it makes
> sense, but also in the usual 'ticket' case (spice-server -spice password=foo
> command line option). In the latter case, we should not be asking for a
> username as it is meaningless.
OK, sent a fix for that.
Also set username if set inside configuration file.
Signed-off-by: Dietmar Maurer
Index: new/src/virt-viewer-session-spice.c
===
--- new.orig/src/virt-viewer-session-spice.c2013-10-24 06:17:52.0
+0200
+++ new/src/virt
Authentication with SASL needs username and password.
Signed-off-by: Dietmar Maurer
Index: new/gtk/spice-session.c
===
--- new.orig/gtk/spice-session.c2013-10-23 12:25:12.0 +0200
+++ new/gtk/spice-session.c 2013
Changelog for v2:
Only ask for username if SASL is used.
Description:
Current implementation always use the unix user name the client runs,
which is usually not what we want.
Instead, remote-viewer should ask for a username (as we do fo VNC).
___
Spi
> I think you could add a SPICE_CHANNEL_ERROR_AUTH_USER_AND_PASS (and a
> property "username" on the session)
This does not work because auth is expected to signal different error, for
example
SPICE_CHANNEL_ERROR_LINK.
___
Spice-devel mailing list
Spic
> All you need is:
>
> auth_method: plain
>
> And set a password with 'saslpassword2 root@your.domainname'
Sorry, you need to use the FQDM as realm (root@)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/ma
> This bit makes me much more uncomfortable, especially this is touching
> security-
> sensitive code. Things are not working without it?
> If you have a working sasl plain config for spice, I'd be interested in it as
> I could
> not get that to work for testing :((
All you need is:
auth_method
Authentication with SASL needs username and password.
Signed-off-by: Dietmar Maurer
Index: new/gtk/spice-session.c
===
--- new.orig/gtk/spice-session.c2013-10-23 12:25:12.0 +0200
+++ new/gtk/spice-session.c 2013
Current implementation always use the unix user name the client runs,
which is usually not what we want.
Instead, remote-viewer should ask for a username (as we do fo VNC).
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.free
Signed-off-by: Dietmar Maurer
Index: new/src/virt-viewer-session-spice.c
===
--- new.orig/src/virt-viewer-session-spice.c2013-07-31 13:57:28.0
+0200
+++ new/src/virt-viewer-session-spice.c 2013-10-23 12:10:56.0
Introduce a new capability SPICE_INPUTS_CAP_KEY_UTF8.
Signed-off-by: Dietmar Maurer
Index: new/spice-common/spice.proto
===
--- new.orig/spice-common/spice.proto 2013-07-17 17:33:52.0 +0200
+++ new/spice-common
minor fix (see Changelog for v4)
Description:
The SPICE input channel currently only sends scancodes. Thus the
server does not know what character was pressed (server does not know
the client keymap).
But some SPICE applications want to use the keymap from the client
side, and work directly wit
Signed-off-by: Dietmar Maurer
Index: new/server/inputs_channel.c
===
--- new.orig/server/inputs_channel.c2013-10-21 07:32:57.0 +0200
+++ new/server/inputs_channel.c 2013-10-21 07:33:01.0 +0200
@@ -124,6 +124,11
Signed-off-by: Dietmar Maurer
Index: new/gtk/channel-inputs.c
===
--- new.orig/gtk/channel-inputs.c 2013-10-16 09:53:10.0 +0200
+++ new/gtk/channel-inputs.c2013-10-16 10:00:11.0 +0200
@@ -451,6 +451,21
The current implementation does not work with mechanism using
WANT_CLIENT_FIRST (plain, ntlm).
I am not sure if the fix is 100% correct, because the comment in the
source says that we always need an additional sasl_step?
___
Spice-devel mailing list
Spi
Current code works with DIGEST-MD5, but not with PLAIN.
Signed-off-by: Dietmar Maurer
Index: new/gtk/spice-channel.c
===
--- new.orig/gtk/spice-channel.c2013-10-22 09:04:23.0 +0200
+++ new/gtk/spice-channel.c
> I don't think mandating that the username we use for SASL is the unix user
> name
> the client runs as makes a lot of sense. Imo it would be better if we always
> asked
> for username/password when SASL asks for it, and prefill the username field
> with the local unix user name.
Exactly. I can
Seems that ticket auth does not work as soon as SASL is enabled on client and
server.
Is that expected behaviour?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > While this is not perfect, it would be far better than what we have now.
>
>
> "Far better", in what way? Wouldn't it have the same limitations, using a us
> layout -> scancode table? I know it's configurable at qemu side, but that's
> not
> per client, so it would be US anyway.
We (and man
> Current SASL implementation in Spice doesn't support username.
>
> > And you can still use tickets if you check for strlen(username) == 0 ?
>
> There is noneed to ask the user a username for the current methods. He
> wouldn't do what to put there.
Sure. That is why I asked if you would accept
> > Would you accept a patch for that, or do you think above code is all we
> > need?
>
> We shouldn't ask username for the current auth methods.
Why? Using SASL without username is a bit limited - or do I miss something?
And you can still use tickets if you check for strlen(username) == 0 ?
_
Current remote viewer only ask for a password when connecting to a spice session
which requires auth:
from virt-viewer-session-spice.c:
case SPICE_CHANNEL_ERROR_AUTH:
DEBUG_LOG("main channel: auth failure (wrong password?)");
int ret = virt_viewer_auth_collect_credentials(self
> I understand. you are sending keysym, and avoid the layout and hw scancode...
> But Spice, in general, is talking to a VM, and currently only via scancodes.
>
> Quite clearly, I understand that using the agent and XTest, input-methdod or
> accessible-technology will avoid the hw layer altogether
> > Besides, I still not understand how that should work. You (Marc) told
> > me that it is easy to get the correct scancodes, but the sources
> > contain the following comment:
>
> Did I? I don't remember the context.
Again, my keysym patches provides a workaround for that problem.
> >
> > "**
> > well that s weird, im using firefox too and add the mapping there, but
> > wouldnt work. the following change solves the problem for me though
> > /firefox_scanmap[173] = 0x4a;/
>
> Ah, then it was fixed some time ago:
> http://cgit.freedesktop.org/spice/spice-
> html5/commit/
> > And AFAIK SASL does not even compile with mingw, so it is quite useless.
>
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> app
> > And AFAIK SASL does not even compile with mingw, so it is quite useless.
>
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> app
> Which is just re-inventing the wheel. IMHO re-inventing wheels is bad,
> particularly when security is involved.
Maybe. But using complex code instead of easy code is also bad.
Using the whole SASL layer to callback the PVE auth layer adds a
lot of useless code, without any gain!
> Marc-Andre did some work to make it build
>
> http://fedorapeople.org/cgit/elmarco/public_git/mingw32-cyrus-sasl.git/
>
> though I do not know what the current status of it is, whether his fixes were
> ever
> applied by upstream or not.
Please do not force me to use such complex framework.
> SASL has a "plain" plugin for straing (username,password) auth, so this
> offers no
> new functionality.
But it offers that functionality without the requirement of SASL.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.free
> > The password is not encryped, so this method is only safe if you use TLS.
>
> Can you describe what you are trying to achieve exactly through this
> auth_plain_verify_credentials callback? I assume you want to check the
> (username, password) against 'something' once you got them from the clie
> Can you describe what you are trying to achieve exactly through this
> auth_plain_verify_credentials callback?
> I assume you want to check the
> (username, password) against 'something' once you got them from the client?
yes
> Can the SASL support already do what you are looking for?
SASL is
This adds a very simple authentication method using username/pasword.
The password is not encryped, so this method is only safe if you use TLS.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/
Index: new/server/reds.c
===
--- new.orig/server/reds.c 2013-10-17 10:32:37.0 +0200
+++ new/server/reds.c 2013-10-17 13:33:53.0 +0200
@@ -146,6 +146,9 @@
SpiceLinkMess *link_mess;
int mess_pos;
Tic
Index: new/spice-common/spice-protocol/spice/protocol.h
===
--- new.orig/spice-common/spice-protocol/spice/protocol.h 2013-10-17
09:05:41.0 +0200
+++ new/spice-common/spice-protocol/spice/protocol.h2013-10-17
09:49:
> > Why is that wrong?
> You are right. And yet thunderbird won't show me the contents on reply, and I
> saw there was an attachment, so I assumed. My bad. Still I don't know why
> thunderbird fails to quote the message on reply and instead gives me an empty
> message.
I also noticed that the mail
> On 10/16/2013 02:04 PM, diet...@proxmox.com wrote:
> For next time: can you send the patches inline? it is easier to respond to
> then to
> mails with attachments.
I guess I have already done that. I use 'quilt mail' to send the patches, and
the
raw email contains:
Content-Disposition: inlin
Signed-off-by: Dietmar Maurer
Index: new/gtk/channel-inputs.c
===
--- new.orig/gtk/channel-inputs.c 2013-10-16 09:53:10.0 +0200
+++ new/gtk/channel-inputs.c2013-10-16 10:00:11.0 +0200
@@ -451,6 +451,21
Signed-off-by: Dietmar Maurer
Index: new/server/inputs_channel.c
===
--- new.orig/server/inputs_channel.c2013-10-16 12:37:14.0 +0200
+++ new/server/inputs_channel.c 2013-10-16 12:37:41.0 +0200
@@ -124,6 +124,11
Introduce a new capability SPICE_INPUTS_CAP_KEY_UTF8.
Signed-off-by: Dietmar Maurer
Index: new/spice-common/spice.proto
===
--- new.orig/spice-common/spice.proto 2013-07-17 17:33:52.0 +0200
+++ new/spice-common
This version sends utf8 characters instead of keysyms.
I tried to include all suggestion from Marc.
Description:
The SPICE input channel currently only sends scancodes. Thus the
server does not know what character was pressed (server does not know
the client keymap).
But some SPICE applications
> > I just send this to the list to archive the work I have done so far.
> > Marc already expressed that he do like the current patches, so I will
> > rewrite them and post v3 soon.
Oh sorry - I want to write "Marc already expressed that he do NOT like the
current patches"
> Yes, but I have conc
Note: This is an ugly hack because there is currently no clean way to do it.
But experiments showed that the X11 agent is the wrong place to do such things,
because it is started to late (after login).
Future: Maybe it is possible to extent the linux uinput framework for that
purpose?
Index:
Signed-off-by: Dietmar Maurer
Index: new/gtk/channel-inputs.c
===
--- new.orig/gtk/channel-inputs.c 2013-10-03 11:11:56.0 +0200
+++ new/gtk/channel-inputs.c2013-10-11 11:59:07.0 +0200
@@ -451,6 +451,48
forward messages if the agent is connected and has VD_AGENT_CAP_KEYSYM
Index: new/server/inputs_channel.c
===
--- new.orig/server/inputs_channel.c2013-10-14 13:36:58.0 +0200
+++ new/server/inputs_channel.c 2013-10-14 15:04
This allows us to send keysyms directly into the guest.
Index: new/spice-common/spice-protocol/spice/vd_agent.h
===
--- new.orig/spice-common/spice-protocol/spice/vd_agent.h 2013-07-17
17:33:52.0 +0200
+++ new/spice-com
[code_len] @end;
} @ctype(SpiceMsgcKeyX11KeySym) key_x11_keysym;
Signed-off-by: Dietmar Maurer
Index: new/spice-common/common/client_marshallers.h
===
--- new.orig/spice-common/common/client_marshallers.h 2013-10-11
09:26
We automatically call the standard callbacks if a server does not implement
this new callback.
Signed-off-by: Dietmar Maurer
Index: new/server/inputs_channel.c
===
--- new.orig/server/inputs_channel.c2013-10-14 10:27
This version adds code to directly forward keysmys to vdagent, which then
tries to inject keysyms into X11.
That way you always have correct input characters even if VM and
client do not share the same keymap!
Experiemts showed that is quite useful, but very difficult to
implement correctly with
[code_len] @end;
} @ctype(SpiceMsgcKeyX11KeySym) key_x11_keysym;
Signed-off-by: Dietmar Maurer
Index: new/spice-common/common/client_marshallers.h
===
--- new.orig/spice-common/common/client_marshallers.h 2013-10-11
09:26
Signed-off-by: Dietmar Maurer
Index: new/gtk/channel-inputs.c
===
--- new.orig/gtk/channel-inputs.c 2013-10-03 11:11:56.0 +0200
+++ new/gtk/channel-inputs.c2013-10-11 11:59:07.0 +0200
@@ -451,6 +451,48
The SPICE input channel currently only sends scancodes. Thus the
server does not know what character was pressed (server does not know
the client keymap).
But Some SPICE applications want to use the keymap from the client
side, and work directly with UTF input characters (for example the
'spiceter
We automatically call the standard callbacks if a server does not implement
this new callback.
Signed-off-by: Dietmar Maurer
Index: new/server/inputs_channel.c
===
--- new.orig/server/inputs_channel.c2013-10-11 10:51
> > > If you really want to send scancode, do it the same way as "Data
> > key_scancode"
> > > for arbitrary sequence.
>
> Just want to mention that you have the following definitions in the default
> protocol:
>
> message {
> uint32 code;
> } @ctype(SpiceMsgcKeyDown) key_down = 101
> > If you really want to send scancode, do it the same way as "Data
> key_scancode"
> > for arbitrary sequence.
Just want to mention that you have the following definitions in the default
protocol:
message {
uint32 code;
} @ctype(SpiceMsgcKeyDown) key_down = 101;
message {
lution?
But wait, I will post a patch with many cleanups tomorrow. You can then see how
it
fits all together.
Many thanks for your patience,
Dietmar
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 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?
> 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
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+dietma
> 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
> > 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()
> > 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
> 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
> > 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
> 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
> > 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
> > 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
> > 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
> 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 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
> > 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
> > 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
> > 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?
> 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)!
I guess one would see the same effect when running a xterm inside a VM, because
a terminal has a size of 80x25 character
ation).
I already sent such patch 2 weeks ago - please can you review?
http://lists.freedesktop.org/archives/spice-devel/2013-September/014342.html
http://lists.freedesktop.org/archives/spice-devel/2013-September/014339.html
http://lists.freedesktop.org/archives/spice-devel/2013
> 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
> 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
> 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
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 +0200
+++ new/spice-common/spice-protocol/spice
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?
___
Spice-devel
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:51.0 +0200
@@ -191,6 +191,7
> > And I don't see any connection to http connect proxy .
> >
> > Is it a bug ?
>
> What are guest OS, agent & driver, and client versions?
>
> Can you provide SPICE_DEBUG=1 log of spice client?
> (G_MESSAGES_DEBUG=all SPICE_DEBUG=1 ./remote-viewer...)
I am not sure if the following is related,
> > I guess that should be renamed to remote-viewer.com?
>
> Yes, do you have needs for it? (it's not as useful as I wished it would,
> unfortunately)
no, I do not need it - I was just curios.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.o
Seems the msi files for virt-viewer contains the file:
windows-cmdline-wrapper.exe
I guess that should be renamed to remote-viewer.com?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-d
> > remote-viewer prints:
> >
> > JPEG parameter struct mismatch: library thinks size is 464, caller
> > expects
> > 432
> >
> > Any ideas?
>
> That looks like a compilation issue to me. libjpeg and jpeg-turbo might have
> slightly different ABI. I don't think you can just drop and replace the dll
1 - 100 of 127 matches
Mail list logo
