Hi,
>> So a spice client must somehow figure how to translate the input it gets into
>> scancodes. And IMO this should best be done on the client side so the
>> client can
>> use all information it has to do it. For gtk this is easy as the key events
>> carry not
>> only the character but th
ACK.
On 08/06/2013 08:51 PM, Yonit Halperin wrote:
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other existing related bugs
ACK.
On 08/06/2013 10:29 PM, Yonit Halperin wrote:
---
gtk/usb-device-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/usb-device-manager.c b/gtk/usb-device-manager.c
index 0535609..71d3462 100644
--- a/gtk/usb-device-manager.c
+++ b/gtk/usb-device-manager.c
@
---
gtk/usb-device-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/usb-device-manager.c b/gtk/usb-device-manager.c
index 0535609..71d3462 100644
--- a/gtk/usb-device-manager.c
+++ b/gtk/usb-device-manager.c
@@ -329,10 +329,10 @@ static gboolean
spice_usb_device_m
Check my src rpm there is an xorg config file in there for qxl that
contains a workaround .
It contains the following :
Section "Device"
Identifier "QXL video"
Driver "qxl"
Option "EnableSurfaces" "0"
EndSection
just save it as : /etc/X11/xorg.conf.d/50-qxl.conf
That works for me.
Rob
2
Hi Rob,
Thanks! I actually got it building after I realized that there was a
0.1.0 version. I the spice-space.org site still points to 0.0.17.
There is one issue that I found confirmation of on the RHEL site. It's
the "Out of surfaces" messages in the X log and very poor performance.
Is there a w
Oh yeah before I forget.
I've packaged 0.1.0 from :
http://xorg.freedesktop.org/releases/individual/driver/
Rob
2013/8/6 Erik Lotspeich :
> Hi,
>
> The qxl driver fails to build on OpenSUSE 12.3 with the following error.
> Incidentally, it also fails to build on CentOS 5.3 with a different error.
I've packaged it.
The repo with the src rpm is here :
http://download.opensuse.org/repositories/home:/robverduijn:/Spice/openSUSE_12.3/
Regards
Rob
2013/8/6 Erik Lotspeich :
> Hi,
>
> The qxl driver fails to build on OpenSUSE 12.3 with the following error.
> Incidentally, it also fails to build
should be PATCH 1/1 :)
On 08/06/2013 02:51 PM, Yonit Halperin wrote:
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other exi
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other existing related bugs emphasize why it is important to decrease
the timeout
> Perhaps this brokenness is unavoidable with spice android/html5 clients, but
> you
> should be aware that if you go down that route, you are picking a solution
> which
> is unfixably broken.
It is also broken if you implement it on the client side ;-) And we already
have that code,
so it woul
Hi,
The qxl driver fails to build on OpenSUSE 12.3 with the following error.
Incidentally, it also fails to build on CentOS 5.3 with a different error.
I don't have much experience with X development. Does anyone have any
pointers?
Thanks,
Erik
# make
make all-recursive
make[1]: Entering dire
On Tue, Aug 06, 2013 at 03:42:29PM +, Dietmar Maurer wrote:
> > > Having utf8 input was discussed a few weeks ago, it is needed for html
> > > and android clients for ex.
> >
> > Note that this is a completely different problem.
> >
> > When running a virtual machine you need the scancodes, s
> > Having utf8 input was discussed a few weeks ago, it is needed for html
> > and android clients for ex.
>
> Note that this is a completely different problem.
>
> When running a virtual machine you need the scancodes, so you can feed the
> guest with the correct virtual keystrokes. Translating
Hi,
>> # spiceterm -c /bin/bash
>>
>> That way you can run any terminal based command over spice.
>>
>> We already have that for VNC.
>
> Having utf8 input was discussed a few weeks ago, it is needed for
> html and android clients for ex.
Note that this is a completely different problem.
Wh
Thanks for your reply , it's very helpful :)
I mainly interested in the data compression part of spice, but if we wanna do
some improvments, we must know well about the whole architecture right?
spice-gtk source code is not very difficult, i am on it now. With your
suggestion, i wll try playback
> So you want to have a terminal emulator using spice-server directly?
Yes. We have that for VNC, and it is quite convenient. For example, we can open
a login shell to the host, or run maintenance command requiring user input
like 'apt-get upgrade'. Or simply open a container console by running
> Having utf8 input was discussed a few weeks ago, it is needed for html and
> android clients for ex.
>
> Feel free to propose a solution.
Just extend the protocol to send both things (scancode and utf8)?
Or add another channel for utf8 input?
___
Sp
ACK.
And thanks for fixing this!
On 08/06/2013 12:13 PM, Marc-André Lureau wrote:
The Python bindings generator failed to bind the USB widget, because of
the object/class declaration. The declaration was circumventing the
deprecated errors when compiling with GTK_DISABLE_DEPRECATED. We used
to
The Python bindings generator failed to bind the USB widget, because of
the object/class declaration. The declaration was circumventing the
deprecated errors when compiling with GTK_DISABLE_DEPRECATED. We used
to need that because of broken gtk+ headers, but it is no longer
necessary since 15bd7ceb
> > > Scancodes are great for use in qemu/X11, but other applications needs
> > > utf8.
> >
> > Which?
>
> I want to write a terminal emulator, exporting the vt100 display over spice.
>
> Example:
>
> # spiceterm -c /bin/bash
>
> That way you can run any terminal based command over spice.
>
>
- Mensaje original -
> > > Scancodes are great for use in qemu/X11, but other applications needs
> > > utf8.
> >
> > Which?
>
> I want to write a terminal emulator, exporting the vt100 display over spice.
>
> Example:
>
> # spiceterm -c /bin/bash
>
> That way you can run any terminal
> > Scancodes are great for use in qemu/X11, but other applications needs utf8.
>
> Which?
I want to write a terminal emulator, exporting the vt100 display over spice.
Example:
# spiceterm -c /bin/bash
That way you can run any terminal based command over spice.
We already have that for VNC.
>
>
> Seems the keyboard interface only return scancodes? Is there a way to get the
>
> corresponding utf8 character (using client side keyboard mapping)?
>
>
>
> Scancodes are great for use in qemu/X11, but other applications needs utf8.
Which?
>
>
>
>
>
>
Seems the keyboard interface only return scancodes? Is there a way to get the
corresponding utf8 character (using client side keyboard mapping)?
Scancodes are great for use in qemu/X11, but other applications needs utf8.
___
Spice-devel mailing list
Sp
>
>
> Hi all,
>
>
>
> is there some example code for QXL_DRAW_TEXT.
>
>
>
> A simple command for spice-0.12.4/server/tests/ would be great.
>
>
>
> Or is there some documentation? What font is used?
I would love a test, but someone needs to write one. The best option to learn
how it is
26 matches
Mail list logo
