Re: [Spice-devel] [PATCH] make celt to be optional
On Tue, 2012-06-12 at 16:33 +0200, Christophe Fergeau wrote: On Tue, Jun 12, 2012 at 09:59:39AM -0400, Marc-André Lureau wrote: - Mensaje original - On Tue, Jun 12, 2012 at 09:11:24AM -0400, Marc-André Lureau wrote: As long as the bitstream is not frozen, we can't use opus, or we will have the same problems as with celt today. As I understand it, while the bitstream is not officially frozen yet, it's very unlikely to change before the real freeze (unless big last minute issues are fine), so an Opus mode (marked as no compat guarantees, use at your own risk, ...) will probably not cause significant compatibilities issues. That's just guesses. It's not about library API, but about bitstream. There is no guarantee. A guess supported by the slides at http://www.opus-codec.org/presentations/ , by various mailing posts from opus developers, ... Sticking to celt051 is still a safer alternative. Not suggesting dropping celt051 support upstream... Otherwise, how would you identify almost-frozen bitstream to frozen bitstream? You would have to identify by library version (erk!) and be compatible with the old and new bitstram (which might be complicated depending on library design), or be incompatible with the intermediate version, situation which we better avoid! We would make no guarantee with interoperability between binaries using different opus versions until the format is officially frozen. I agree there's a bit of uncertainty in this move, but I think that at this point it's a reasonable assumption that things will work, even with different opus versions. It seems like Opus is at a stage where we want to at least start adding support for it so we can switch to it by default as early as possible. Its not like this is a new idea, the plan was always to jump to a stable bitstream format when one appeared. However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
On Thu, 2012-06-14 at 12:31 +0200, Christophe Fergeau wrote: On Thu, Jun 14, 2012 at 10:14:36AM +0200, Alexander Larsson wrote: However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. It all depends if we consider remote SPICE access with limited bandwidth and with audio needed will be an important use case that must run as good as possible. In my opinion, sound is most of the time not the most important thing if what you want is a remote desktop. It also won't be really noticeable on LAN, or in GNOME Boxes use case, ... What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? I don't know if no audio at all is more acceptable than not doing audio well in some cases. I don't know if that is true. If nothing else works then in some cases PCM is a good approach. However, maybe the client should warn about this and allow disabling audio? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
On Sat, 2012-06-02 at 15:46 +0400, Michael Tokarev wrote: I plan to use this patch in the upcoming Debian release, codename wheezy, to get rid of celt codec library there, since we decided celt051 is not going to be included, but it is obviously not a good idea to drop spice entirely. Isn't it better to drop spice completely rather than shipping a version thats essentially protocol incompatible? (Well, it will fall back to no audio or non-compressed audio, but that is untested and pretty bad for actual use of spice.) Then users that want to use spice can get a working version somewhere else instead of just thinking that spice sucks because of this change. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
On Tue, 2012-06-12 at 12:54 +0400, Michael Tokarev wrote: On 12.06.2012 12:48, Alexander Larsson wrote: On Sat, 2012-06-02 at 15:46 +0400, Michael Tokarev wrote: I plan to use this patch in the upcoming Debian release, codename wheezy, to get rid of celt codec library there, since we decided celt051 is not going to be included, but it is obviously not a good idea to drop spice entirely. Isn't it better to drop spice completely rather than shipping a version thats essentially protocol incompatible? (Well, it will fall back to no audio or non-compressed audio, but that is untested and pretty bad for actual use of spice.) It isn't incompatible. It might be incompatible with older releases of spice where audio codec negotiation/fallback were not properly implemented (read: was buggy), but it is okay now. Did you read the whole my email where I mention testing I performed? Its not incompatible, like I i said in my (Well, .. part above. But what it means is that it will send audio as PCM instead of compressing it. This is much larger, and will cause anyone using the debian spice client to connect to a spice server (even one that supports celt) to use much more bandwidth due to this. Its not very obvious that the reason for this is that Debian decided to package Spice that way, but rather the likely conclusion that any user would draw is that Spice just works like that. Thats not exactly a good impression for Spice. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
On Tue, 2012-06-12 at 14:31 +0400, Michael Tokarev wrote: On 12.06.2012 13:15, Alexander Larsson wrote: [] Its not incompatible, like I i said in my (Well, .. part above. But what it means is that it will send audio as PCM instead of compressing it. This is much larger, and will cause anyone using the debian spice client to connect to a spice server (even one that supports celt) to use much more bandwidth due to this. Its not very obvious that the reason Why do you think it is really that bad? When used in a LAN, bandwidth doesn't matter, and it will even work a tiny bit better due to less cpu usage for encoding/decoding. It may matter for slow/long Internet links, but these are much less important for audio. Also, audio does not come alone usually (except of a few windows sounds), it usually comes together with video (ie, movies etc), which has their own requiriments which are much stronger than even raw audio. I'm not saying celt or other codec is bad or not needed, something is definitely worth to have to be able to transmit audio cheaply, but it is not the first priority thing for sure. Much more important is to have good visual expirence, and this is what spice is all about, and this is something what is not changed by this patch. Do you not agree? I don't really agree. Its true that if you have unlimited bandwidth, then bandwidth doesn't matter. But I don't think in practice this is true, as bandwidth always has some limits in reality. Its possible that it works fine in some situations, but its also quite possible that its a deal-breaker in some others, and we have no data to substantiate the claim that it doesn't matter (in fact, it seems unlikely since the developers spent time and energy to implement audio compression). Spice is very much about more than just pixels, that it does more than graphics (usb, sound, audio-video sync, clipboard, etc) is an important part of why Spice is better than other solutions. In fact, our support of movies by using compressed video and audio is a pretty important selling point of spice. The main thing I disagree with this change is that you change how spice works, making act differently than its creators intended, due to a packaging technicallity. You decide that spice users are not interested in low-bandwidh audio, without asking and without telling them. (I'm sure it'll be mentioned somewhere, but its unlikely that most users will see it.) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] xf86-video-qxl performance
On Wed, 2012-05-23 at 15:20 -0500, Jeremy White wrote: Also, as a crazy idea, has anyone considered implementing a pure streaming video driver? That is, what if we had a frame buffer driver, and then a thread that fired 29 times a second to drive a theora or vp8 encoder, simply feeding the current frame at those intervals. Its not crazy at all. In fact, all the times I've been pondering how to support modern (i.e. GPU-based) 3D acceleration to spice I've always ended up at this. Its not really practical to support GPUs like a set of remoted drawing operations, since: a) They are infinitely flexible (turing complete) b) Work on huge amounts on temporary data (textures, buffers, etc), often multiple times the size of what the final rendered screen size is. c) Its impossible (comparable to halting problem) to figure out in general which part of the input sources some GPU code snippet uses, or to calculate the bounding box of the result. So, what I think we want for GPU accelerated spice is an eventually-losless video codec. By that I mean the fact that individual frames might be lossy (so it can be effective for video and games), but if the input is static we'd (quickly) converge on the lossless result (so that you can read your word documents). If additionally we could separate each toplevel window as its own stream that would be even nicer, but It might be hard as these are composed to the final screen using the GPU. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [announce] alpha glib/gtk client library + app.
On Wed, 2010-09-29 at 12:07 +0200, Gerd Hoffmann wrote: Hi folks, /me proudly presents some early glib/gtk bits for the client side of the spice protocol. The code is available in the gtk.v2 branch in my personal spice repo @ freedesktop.org: http://cgit.freedesktop.org/~kraxel/spice/log/?h=gtk.v2 The README is here: http://cgit.freedesktop.org/~kraxel/spice/tree/gtk/README?h=gtk.v2 Good enougth to start playing with it. Far from being stable enougth for production use. Tested with winxp guest only so far. Reviews are very welcome. Especially looking at the design and interfaces of the glib/gtk objects would be very helpful. Looking at the actual code isn't that useful (yet) as there are plenty of known issues anyway. I had a quick look at this. It seems this is a re-write of a client implementation (based on the existing code i guess). I don't necessarily disagree with this (as the current code isn't exactly well suited for librarification), but this is a pretty big chunk of work that will take a while to stabilize. Also, unless we completely replace the old client implementation we will have to maintain two independent client implementations. I guess if we make the gtk+ one work on windows too then we can drop the old one. If this is the plan we need to ensure that the APIs and implementations are not tied to tightly to unix. A few random API comments: spice_watch, spice_msg_out etc is a pretty uncommon capitalization for Gtk+/GObject APIs. Generally all (public) types are CamelCase. spice_watch_put = spice_watch_free is a more typical Gtk+ naming convention (or possibly _destroy). Or _ref/_unref for refcounted types. Also, i don't like the audio integration, as it exposes the backend implementation (at least by name) in the API. If we have multiple sound implementations then each client must have code to integrate with each one. So, I'd rather have a public SpiceAudioSink type that has different implementations under the hood (which one gets picked might be solely a build-time thing, or we could have an env var to choose between them). Things like this is a bit uncommon/lowlevel in a gtk+ api (and, binds badly to other languages): int spice_session_get_channels(SpiceSession *session, SpiceChannel **channels, int max); A more typical Gtk+ style call is: SpiceChannel ** spice_session_get_channels(SpiceSession *session); returning a NULL-terminated array of items. Or possibly a GList *. More later... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an uncontrollable guitar-strumming paranormal investigator with acid for blood. She's a sharp-shooting gold-digging Valkyrie from aristocratic European stock. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [announce] alpha glib/gtk client library + app.
On Thu, 2010-09-30 at 14:48 +0200, Alexander Larsson wrote: More later... Bit more before I disappear: why do you have a spice_channel_destroy()? Its a gobject, just unref it. I don't like that you have three libs. We've learned this lesson in gnome by now: It seems that splitting things up into small separate libraries is a good thing, but in practice its problematic because of the per-library overhead in things like symbol resolving (one extra lookup per item in the link list, for all symbols). So, at a minimum, combine libspice-client-pulse and libspice-client-gtk. Although i'm not really sure we need the separate non-ui library either... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a benighted arachnophobic hairdresser haunted by memories of 'Nam. She's a cold-hearted gold-digging archaeologist in the witness protection program. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [announce] alpha glib/gtk client library + app.
On Thu, 2010-09-30 at 22:22 +0200, Gerd Hoffmann wrote: Hi, If this is the plan we need to ensure that the APIs and implementations are not tied to tightly to unix. I have some X11 MIT-SHM bits in there for performance reasons, that needs to be #ifdef'ed and have a alternative (generic cairo/pixman based?) implementation for !x11 platforms. Other that that there should be nothing major. glib helps alot here. Oh, and while talking about windows: The windows client has the gdi renderer, how does that compare to the sw one performance-wise? I don't actually know. I guess its hardware accelerated. On the other hand, the operations spice does are hardly expensive on todays cpus. Maybe its better to drop it in favour of a consistant behaviour and less code to maintain. Needs some profiling though. Actually i think all GDI stuff is software only in vista, but i think they added back some acceleration in win7. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a hate-fuelled flyboy cop on the run. She's a radical red-headed research scientist from aristocratic European stock. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] vd_agent: add protocol messages for clipboard/selection-owner model
On Sun, 2010-09-26 at 10:27 +0200, Arnon Gilboa wrote:
Alexander Larsson wrote:
On Wed, 2010-09-22 at 11:47 +0200, Arnon Gilboa wrote:
with the current msgs we can use multiple GRAB(type)s REQUEST(type)s ;)
I don't think that works. You'd need to know when to reset the list of
types and when to add to it.
You are right. Should we vectorize the type in the grab msg?
e.g.
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
uint32_t type[0];
} VDAgentClipboardGrab;
In the request data we will keep type as is, which is enough for our
needs.
Yeah, might as well do this for future possibilities.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] 0.6.1 release and cut and paste
On Mon, 2010-09-27 at 16:45 +0200, Arnon Gilboa wrote: +1 to your 0.6.1 now. what's the cons of cp only in 0.6.2 (in a week or 2!) ? I'm for this too, and will do a 0.6.1 release today. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Replace epoll with select in X client
The use of epoll in the client is totally overkill in terms of
scalability, and its a problem for portability. The OSX port converts
this to use select, but keeps some of the old complexities in the code.
This new patch makes it simpler and look much more like the windows
code.
Review?
diff --git a/client/x11/event_sources_p.h b/client/x11/event_sources_p.h
index 09703c0..959460c 100644
--- a/client/x11/event_sources_p.h
+++ b/client/x11/event_sources_p.h
@@ -21,24 +21,18 @@
#include common.h
#include threads.h
-#if __GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ = 8)
-#define USING_EVENT_FD
-#endif
-
#define INFINITE -1
-class EventWrapper;
+class EventSource;
class EventSources_p {
-public:
-void remove_wrapper(EventWrapper*);
+protected:
+void add_event(int fd, EventSource* source);
+void remove_event(EventSource* source);
public:
-int _epoll;
-typedef std::listEventWrapper* Events;
-Events _events;
-
-friend class EventWrapper;
+std::vectorEventSource* _events;
+std::vectorint _fds;
};
class Trigger_p {
@@ -49,9 +43,7 @@ public:
public:
int _event_fd;
-#ifndef USING_EVENT_FD
int _event_write_fd;
-#endif
bool _pending_int;
Mutex _lock;
};
diff --git a/client/x11/event_sources_p.cpp b/client/x11/event_sources_p.cpp
index d59bffd..54d950f 100644
--- a/client/x11/event_sources_p.cpp
+++ b/client/x11/event_sources_p.cpp
@@ -15,189 +15,141 @@
License along with this library; if not, see http://www.gnu.org/licenses/.
*/
-#include sys/epoll.h
+#include sys/select.h
#include sys/fcntl.h
#include event_sources.h
#include debug.h
#include utils.h
-#ifdef USING_EVENT_FD
-#include sys/eventfd.h
-#endif
-
-#define NUM_EPOLL_EVENTS 10
-
-#ifdef USING_EVENT_FD
-#define WRITE_FD _event_fd
-#define EVENT_DATA_TYPE eventfd_t
-#else
-#define WRITE_FD _event_write_fd
-#define EVENT_DATA_TYPE uint8_t
-#endif
-
-class EventWrapper {
-public:
-EventWrapper(EventSources owner, EventSource event)
-: _owner (owner)
-, _event (event)
-, _refs (1)
-{
-}
-
-EventWrapper* ref()
-{
-_refs++;
-return this;
+static void set_non_blocking(int fd)
+{
+int flags;
+if ((flags = ::fcntl(fd, F_GETFL)) == -1) {
+THROW(failed to set socket non block: %s, strerror(errno));
}
-void unref()
-{
-if (!--_refs) {
-_owner.remove_wrapper(this);
-delete this;
-}
+if (::fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
+THROW(failed to set socket non block: %s, strerror(errno));
}
+}
-EventSource* get_event()
-{
-return _event;
+static void set_blocking(int fd)
+{
+int flags;
+if ((flags = ::fcntl(fd, F_GETFL)) == -1) {
+THROW(failed to clear socket non block: %s, strerror(errno));
}
-void invalidate()
-{
-_event = NULL;
+if (::fcntl(fd, F_SETFL, flags ~O_NONBLOCK) == -1) {
+THROW(failed to clear socket non block: %s, strerror(errno));
}
-
-private:
-EventSources _owner;
-EventSource* _event;
-int _refs;
-};
+}
EventSources::EventSources()
{
-_epoll = epoll_create(NUM_EPOLL_EVENTS);
-if (_epoll == -1) {
-THROW(create epool failed);
-}
}
EventSources::~EventSources()
{
-Events::iterator iter = _events.begin();
-for (; iter != _events.end(); iter++) {
-delete *iter;
-}
-close(_epoll);
}
-bool EventSources::wait_events(int timeout_ms)
+void EventSources_p::add_event(int fd, EventSource* source)
{
-struct epoll_event events[NUM_EPOLL_EVENTS];
-int num_events = epoll_wait(_epoll, events, NUM_EPOLL_EVENTS, timeout_ms);
+int size = _events.size();
+_events.resize(size + 1);
+_fds.resize(size + 1);
+_events[size] = source;
+_fds[size] = fd;
+}
-if (num_events == -1) {
-if (errno == EINTR) {
-return false;
+void EventSources_p::remove_event(EventSource* source)
+{
+int size = _events.size();
+for (int i = 0; i size; i++) {
+if (_events[i] == source) {
+for (i++; i size; i++) {
+_events[i - 1] = _events[i];
+_fds[i - 1] = _fds[i];
+}
+_events.resize(size - 1);
+_fds.resize(size - 1);
+return;
}
-THROW(wait error eventfd failed);
+}
+THROW(event not found);
+}
+
+bool EventSources::wait_events(int timeout_msec)
+{
+int maxfd = 0;
+fd_set rfds;
+struct timeval tv;
+struct timeval *tvp;
+int ready;
+
+FD_ZERO(rfds);
+
+int size = _events.size();
+for (int i = 0; i size; i++) {
+maxfd = MAX(maxfd, _fds[i]);
+FD_SET(_fds[i], rfds);
}
-for (int i = 0; i num_events; i++) {
-((EventWrapper*)events[i].data.ptr)-ref();
+if (timeout_msec == INFINITE) {
+tvp = NULL;
+} else {
+tv.tv_sec = timeout_msec / 1000;
+
Re: [Spice-devel] Replace epoll with select in X client
On Wed, 2010-09-29 at 17:28 +0200, Alexander Larsson wrote:
I'm commiting this part:
diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp
index 1133414..ca5f1d5 100644
--- a/client/x11/platform.cpp
+++ b/client/x11/platform.cpp
@@ -3024,8 +3024,12 @@ void
Platform::set_clipboard_listener(ClipboardListener* listener)
return;
}
clipboard_listener = listener;
-XConvertSelection(x_display, XA_PRIMARY, utf8_atom, clipboard_prop,
-platform_win, CurrentTime);
+/* Seems platform_win can be NULL, we'll just ignore that for now.
+ This will be fixed when the rest of cut and paste lands */
+if (platform_win) {
+ XConvertSelection(x_display, XA_PRIMARY, utf8_atom, clipboard_prop,
+ platform_win, CurrentTime);
+}
}
As it works around crashes here. Then i'll do the 0.6.1 release and we
can land this post release.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Announcing Spice 0.6.1
Today we released the first bugfix update to the stable spice 0.6 series. Updated sources and windows binaries are availible at: http://spice-space.org/download.html We hope to have packages in Fedora 14 shortly. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice 6.0
On Wed, 2010-09-22 at 09:10 +0200, len...@opensourcemedia.de wrote: Hi there, I am experimenting with the newest version of Spice (6.0) on Fedora14 alpha. I managed to get everything installed fine via yum but my qemu doesn't seem to work with the qxl device. If I start it like this: qemu xp.img -usbdevice tablet -soundhw ac97 -vga qxl -m 3200 -spice port=5930,disable-ticketing -enable-kvm and start the client like this: spicec -h localhost -p 5930 i get eventually a tiny little window for the client which I cannot maximize or toggle fullscreen. Yes, this is a bug in the qemu spice integration (bug https://bugzilla.redhat.com/show_bug.cgi?id=634535 waiting for update to reach repos). For now, to work around it, pass -global qxl.revision=2 on the qemu command line. Sorry about this. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a globe-trotting moralistic paranormal investigator searching for his wife's true killer. She's a mentally unstable Bolivian schoolgirl fleeing from a Satanic cult. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice roadmap
On Mon, 2010-09-20 at 13:27 -0700, Stephen Duse-Anthony wrote: HI, I would like to know if you have a roadmap with an ETA for the following features: Network tunneling: - usb device redirection - CD-ROM redirection - Printer redirection There is some initial experimental support for network tunneling, but its not enabled by default and we don't know if it is the right approach. For the others, no ETA exists, but they're all things we eventually want to have. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a globe-trotting coffee-fuelled rock star from a doomed world. She's a scantily clad tempestuous fairy princess with a song in her heart and a spring in her step. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] vdservice: use com.redhat.spice.0 symbolic link as virtio-serial port path
On Wed, 2010-09-22 at 08:53 +0200, Arnon Gilboa wrote: remove get_device_path() by GUID dependency on setupapi.lib --- What exactly is setupapi.lib and why did you remove it here and then add it in some places in a later patch? Otherwise this looks good. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a war-weary hunchbacked filmmaker haunted by memories of 'Nam. She's a psychotic belly-dancing stripper from out of town. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] vd_agent: add protocol messages for clipboard/selection-owner model
On Tue, 2010-09-21 at 13:54 +0200, Hans de Goede wrote:
Hi,
On 09/21/2010 09:31 AM, Arnon Gilboa wrote:
pasting clipboard data is now only-by-demand from both sides (client and
agent), whose behavior is symmetric.
-VD_AGENT_CLIPBOARD_GRAB(type) - tell the other side that an application in
our side (we) got ownership of the clipboard.
-VD_AGENT_CLIPBOARD_REQUEST(type) - after we know the other side owns the
clipboard (GRAB received), we notify the os we are the owner. when we are
asked by the os/app for the clipboard data, we send this REQUEST msg to the
other side.
-VD_AGENT_CLIPBOARD(type, data) - the existing message for sending the
clipboard, is now sent only in response to REQUEST.
-VD_AGENT_CLIPBOARD_RELEASE - tell the other side that we are no longer the
owner of the clipboard (e.g. the owner app was closed).
this patch will be followed by agent client patches handling the above
messages.
---
spice/vd_agent.h | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/spice/vd_agent.h b/spice/vd_agent.h
index 9e5adec..0da23aa 100644
--- a/spice/vd_agent.h
+++ b/spice/vd_agent.h
@@ -65,6 +65,9 @@ enum {
VD_AGENT_CLIPBOARD,
VD_AGENT_DISPLAY_CONFIG,
VD_AGENT_ANNOUNCE_CAPABILITIES,
+VD_AGENT_CLIPBOARD_GRAB,
+VD_AGENT_CLIPBOARD_REQUEST,
+VD_AGENT_CLIPBOARD_RELEASE,
VD_AGENT_END_MESSAGE,
};
@@ -121,7 +124,6 @@ enum {
VD_AGENT_ERROR,
};
-//FIXME: size required?
typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
uint32_t type;
uint8_t data[0];
@@ -129,8 +131,17 @@ typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
enum {
VD_AGENT_CLIPBOARD_UTF8_TEXT = 1,
+VD_AGENT_CLIPBOARD_BITMAP,
};
Hmm, I'm not sure about this bit, wouldn't it be better to
use a string with a mimetype in there, that brings us much
larger flexibility. I think this is esp. usefull when the
guest as and the client os are the same os, then
copying of all kind of things could be .
Not sure about this, if we want full compatibility with same-os cut and
paste we need more features anyway, like multiple formats. I think its
more important to allow some common subset of clipboard types to work
across os types than supporting all native types.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a shy Amish sorceror trapped in a world he never made. She's a
disco-crazy Buddhist former first lady from a secret island of warrior women.
They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] vd_agent: support clipboard/selection-owner model
On Wed, 2010-09-22 at 11:45 +0200, Arnon Gilboa wrote: MSDN is saying: WM_RENDERALLFORMATS Message is sent to the clipboard owner before it is destroyed, if the clipboard owner has delayed rendering one or more clipboard formats. For the content of the clipboard to remain available to other applications, the clipboard owner must render data in all the formats it is capable of generating, and place the data on the clipboard by calling the SetClipboardData function. When our agent is killed, do we really want to send a REQUEST to the client? I see no reason to render in this case or keep the clipboard available for other apps. That indeed seems a bit silly. Isn't windows waiting for you to render something though? You could just set the data to a zero size block. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an unconventional amnesiac ex-con in drag. She's a radical green-skinned soap star with a knack for trouble. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] vd_agent: add protocol messages for clipboard/selection-owner model
On Wed, 2010-09-22 at 11:47 +0200, Arnon Gilboa wrote: with the current msgs we can use multiple GRAB(type)s REQUEST(type)s ;) I don't think that works. You'd need to know when to reset the list of types and when to add to it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an immortal hunchbacked card sharp with a robot buddy named Sparky. She's a high-kicking hypochondriac mechanic who hides her beauty behind a pair of thick-framed spectacles. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/17] Win32 driver thread safety
On Tue, 2010-09-14 at 21:08 +0200, al...@redhat.com wrote: From: Alexander Larsson al...@redhat.com Izik reviewed all of these and found no issues, and i've been running it for a while without issues, so i'm pushing it now. However, if anyone has time please do review this anyway as there is a non-neglible risk we missed some case. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a superhumanly strong white trash gentleman spy on the run. She's a vivacious green-skinned snake charmer with a knack for trouble. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 01/17] Make global_res be an array of pointers and Res a pointer
On Tue, 2010-09-14 at 21:08 +0200, al...@redhat.com wrote: From: Alexander Larsson al...@redhat.com Instead of allocating an array of DevRes we allocate each DevRes dynamically for each element. Also make PDEV-Res be a pointer instead of copying the global pdev. This also drops the needto Sync it when the pdev is made inactive, as all pdevs share the same DevRes. This way shared things like semaphores are really shared. --- Got an ack from izik on irc. Pushed. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a notorious flyboy Green Beret on the run. She's a sarcastic paranoid soap star from a family of eight older brothers. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] smartcard: add channel
On Tue, 2010-09-14 at 14:50 -0400, Alon Levy wrote: - Gerd Hoffmann kra...@redhat.com wrote: I don't think this is a good idea. This is just a chardev passthrough, right? If so, then we should just make it that. Name it 'chardev' or 'datapipe' or something simliar. Have a additional 'init' message to specify the kind of chardev. Then we can just reuse it when we'll have more simliar users in the future. Do you think this is a better direction then adding the actual messages? (see below) I don't think its better. Or we could make this a real interface definition where each smartcard message gets its own message type. Yes, I was lazy - actually let me back up a little. For the smartcard reader device to be viable on it's own, it has to talk some protocol that is defined outside of spice. That protocol is also a header type/size protocol, so it is easy to write the spice.proto channel definition for it - that's were I was lazy and haven't done it. I guess it's time to be less lazy. Sounds good to me. Then you'd get automatic (de)marshalling support for it in the client too. Oh, and shouldn't the channel-specific messages better start with '101' like all other channels do? Yeah. Anyone know why they start at that particular number? Its because all channels derive from BaseChannel, adding some unused numbers so that it can be extended in the future. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Memory Leak on spicec
On Tue, 2010-09-14 at 16:02 +0200, Alex Peter wrote: I referred Target is the one running the spicec client We had a shared memory leak in the X client, but that was fixed before 0.6.0 was released. I have not personally seen any other client leaks. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] smartcard: add channel
On Mon, 2010-09-13 at 13:58 -0400, Alon Levy wrote: --- spice/enums.h | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/spice/enums.h b/spice/enums.h Is this change generated? If not, just update the spice.proto and run ./spice_codegen.py -e spice.proto ../spice-proto/spice/enums.h -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an unconventional white trash paramedic with no name. She's a scantily clad French-Canadian mercenary with an evil twin sister. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/3] move command flags handling to the qxl parser
On Tue, 2010-09-14 at 10:45 +0200, Gerd Hoffmann wrote: Pass through command flags to the qxl parser, so we can hide all compat bits for spice 0.4 within the qxl parser. ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a suicidal hunchbacked hairdresser fleeing from a secret government programme. She's a ditzy junkie vampire with the soul of a mighty warrior. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/3] fix brush handling for 0.4 compat
On Tue, 2010-09-14 at 10:45 +0200, Gerd Hoffmann wrote: spice 0.4 guests pass 16bpp colors for brushes when running in a 16bpp video mode. Convert them to 32bpp. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a short-sighted native American romance novelist with a secret. She's a manipulative snooty cab driver with a flame-thrower. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Are there 64 bit Windows 7 QXL drivers?
On Thu, 2010-09-09 at 10:23 -0400, Matt Feinberg wrote: I apologize if this information is on the list somewhere. I could not find it. Are there binaries for 64 bit Windows 7 QXL drivers? I have a 64 bit Windows 7 guest which I'm trying to access. I'm not sure if the current qxl sources build in 64bit. You'd have to try. Alternatively, are there instructions on how to build the drivers for Windows? The information in the user manual appears incomplete for this task. Download the windows driver kit, start a build console from it, set SPICE_COMMON_DIR to point to spice-protocol, then go to the qxl dir and run build. This is all pretty standard windows driver building. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an uncontrollable shark-wrestling librarian with nothing left to lose. She's a time-travelling Bolivian bounty hunter looking for love in all the wrong places. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/35] *** SUBJECT HERE ***
On Thu, 2010-09-09 at 19:15 +0200, al...@redhat.com wrote: From: Alexander Larsson al...@redhat.com *** BLURB HERE *** Sorry. Didn't mean to send this one... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an obese guitar-strumming dog-catcher in a wheelchair. She's a radical paranoid queen of the dead on her way to prison for a murder she didn't commit. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] leaking drawables
On Thu, 2010-09-09 at 09:31 +0200, Gerd Hoffmann wrote: There is one special thing in the release ring usage though. As you know qxl builds up a linked lists there, where the heads are in the ring. qxl does also store the head of the list which it currently builds into the ring, but doesn't bump prod (yet) so the guest will not grab it. Which needs one extra ring entry. Because of that the IS_FULL macro simply doesn't work for the release ring and the check is open coded. So, the old code checks whenever prod - cons + 1 != num_items. Lets assume the guest didn't take out any entries yet, so cons is 0. When prod is 7 the check fails and qxl will stop pushing stuff to the ring due to being full. Lets have a look at the prod == 6 case: * The extra entry (ring[7%8]) holds the head for the list qxl is building). * qxl pushes that ring item to the guest (SPICE_RING_PUSH), prod is 7 now. * qxl gets a pointer to the next entry (SPICE_RING_PROD_ITEM), which is ring[8%8]. * qxl zero-initializes the ring entry as new list head, thereby overriding ring[0], which isn't yet consumed by the guest. Correct? No, that doesn't seem correct to me. Initially, both prod an cons are zero, and has num items = prod - cons = 0 - 0 = 0 Then we release an item (interface_release_resource). This starts writing to the current producer item SPICE_RING_PROD_ITEM(ring, item), either initializing it or appending to the list. In this case prod is zero, so we're writing to ring-items[0]. Then we push this, which increases prod to 1 and then initializes the new temp item (at 1). Eventually we reach the case where prod is 6 (and lets say cons is still 0). We put stuff in item 6, then SPICE_RING_PUSH increasing prod to 7, initialize item 7. No overwrite here. Then when prod is 7 we keep appending to the item 7 list, but never push it because prod - cons + 1 = 7 - 0 + 1 = 8 == num_items. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] leaking drawables
On Tue, 2010-09-07 at 17:08 +0200, Gerd Hoffmann wrote: Hi, This happens for several consecutive resource releases. Looking at what actually gets released by the driver we see that the resources are freed in the same order as they were release, its just that a chunk of resources are missing here and there. Try the attached patch. I'm pretty sure qxl just overruns the release ring, making complete release lists disappear now and then. This doesn't seem right. The ring doesn't wrap cons and prod, as they are incremented. Instead they are % num_items when used as indexes. This means that its ok to have the ring be completely full (and indeed, the IS_FULL macro just checks prod - cons == num_items). Thus, prod - cons means we're pushing to the last item in the ring. And, testing with this patch I still see the leak. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an otherworldly white trash Green Beret fleeing from a secret government programme. She's a transdimensional winged wrestler from out of town. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] leaking drawables
I've been tracking the out of memory issue. i.e. we seem to be getting these to often. And it seems we might be leaking resources. I modified the driver and the server to print Drawables as they are freed. In one run there were several instances of the server releasing a drawable. I.E. in free_red_drawable we call release_resource, but the corresponding resource is never seen in ReleaseOutput. This happens for several consecutive resource releases. Looking at what actually gets released by the driver we see that the resources are freed in the same order as they were release, its just that a chunk of resources are missing here and there. To me this sounds like a race, and we know there are threadsafety issues in the win32 driver. For instance, we might be racing over reading the release ring, thus missing one list of items to free. Unfortunately I don't have time to look into this until thursday. Maybe someone else want to take a look before then? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a one-legged hunchbacked cyborg fleeing from a secret government programme. She's a green-fingered Buddhist research scientist trying to make a difference in a man's world. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: avoid creating a stream from traces more than once for the same drawable
On Wed, 2010-09-01 at 12:10 +0300, Yonit Halperin wrote: could have caused ASSERT(!drawable-stream) in red_create_stream --- server/red_worker.c | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) ack ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] asking help to implement spice
On Wed, 2010-09-01 at 11:05 +0530, mohan Doss wrote: hello sir i am mohan dass i am doing BE final year , i like doing project in desktop virtulization .can you help me to implement your protocol in my project. Implement a protocol is a very vague term. You need to describe more what you want to do. Reimplement spice? If so, which part? server? client? drivers? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: avoid creating a stream from traces more than once for the same drawable
On Thu, 2010-09-02 at 15:24 +0200, Alexander Larsson wrote: On Wed, 2010-09-01 at 12:10 +0300, Yonit Halperin wrote: could have caused ASSERT(!drawable-stream) in red_create_stream --- server/red_worker.c | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) ack Pushing this to master. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: red_current_add_equal - don't push a drawable to the middle of the pipe if it depends on surfaces.
On Tue, 2010-08-31 at 10:29 +0300, Yonit Halperin wrote: This will prevent: 1) rendering problems (commands sent to the client in the wrong order) 2) sending commands for surfaces that haven't been created yet on the client side. --- Ack. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a Nobel prize-winning coffee-fuelled cat burglar haunted by memories of 'Nam. She's a mentally unstable mute detective with a birthmark shaped like Liberty's torch. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/5] qxl parser: add cursor parsing
On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote:
+red-data_size = qxl-data_size;
+size = red_get_data_chunks_ptr(slots, group_id,
+ get_memslot_id(slots, addr),
+ chunks, qxl-chunk);
+data = red_linearize_chunk(chunks, size, free_data);
+red_put_data_chunks(chunks);
+red-data = spice_malloc(size);
+memcpy(red-data, data, size);
+
+if (free_data) {
+free(data);
+}
Ack, but this part could be more efficient. In the n_chunks 1 case the
red_linearize_chunk part will already malloc and copy the data so we
don't need to do it then. We should have a linearlize_chunks variant
that always copies and use that.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a time-tossed flyboy boxer with a winning smile and a way with the
ladies. She's a wealthy junkie advertising executive from aristocratic
European stock. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/5] zap dead qxl chunk code
On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- server/red_worker.c | 29 - 1 files changed, 0 insertions(+), 29 deletions(-) Ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a shy pirate firefighter on the run. She's a strong-willed African-American mechanic from a family of eight older brothers. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 5/5] fix red_cursur_flush segfault
On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- server/red_worker.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced zombie dog-catcher with a robot buddy named Sparky. She's a hard-bitten hypochondriac mercenary with only herself to blame. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/5] zap dead qxl chunk code
On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- server/red_worker.c | 29 - 1 files changed, 0 insertions(+), 29 deletions(-) Actually, you can get rid of BufDescriptor-type, slot_id, and group_id too. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a war-weary overambitious inventor on a search for his missing sister. She's an elegant winged politician with a flame-thrower. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/5] qxl parser: add cursor parsing
On Fri, 2010-08-27 at 08:51 +0200, Gerd Hoffmann wrote:
On 08/27/10 08:38, Alexander Larsson wrote:
On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote:
+red-data_size = qxl-data_size;
+size = red_get_data_chunks_ptr(slots, group_id,
+ get_memslot_id(slots, addr),
+chunks,qxl-chunk);
+data = red_linearize_chunk(chunks, size,free_data);
+red_put_data_chunks(chunks);
+red-data = spice_malloc(size);
+memcpy(red-data, data, size);
+
+if (free_data) {
+free(data);
+}
Ack, but this part could be more efficient. In the n_chunks 1 case the
red_linearize_chunk part will already malloc and copy the data so we
don't need to do it then.
Right. Incremental patch attached.
Ack
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a hate-fuelled zombie barbarian looking for a cure to the poison coursing
through his veins. She's a scantily clad cat-loving politician who hides her
beauty behind a pair of thick-framed spectacles. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/5] zap dead qxl chunk code
On Fri, 2010-08-27 at 08:49 +0200, Gerd Hoffmann wrote: On 08/27/10 08:41, Alexander Larsson wrote: On Fri, 2010-08-27 at 00:09 +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmannkra...@redhat.com --- server/red_worker.c | 29 - 1 files changed, 0 insertions(+), 29 deletions(-) Actually, you can get rid of BufDescriptor-type, slot_id, and group_id too. I suspect with only minor marshaller adjustments we can get rid of BufDescriptor altogether ... Possibly, but if you're removing unused stuff, might as well remove all unused stuff. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an impetuous ninja boxer with no name. She's a violent red-headed magician's assistant with only herself to blame. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/1] Add API to turn on backwards compatibility mode
On Fri, 2010-08-27 at 15:08 +0200, Gerd Hoffmann wrote: As you are talking about set of features already ... I think we should use a feature bitmask instead of a version number in the API. How would you use this in qemu though? Say you link to spice 0.10.0, which has a set of new features not in 0.8.0. Why would you want to make a spice instance that doesn't use all features in 0.10.0, yet is not compatible with 0.8.0, so you can't migrate between them. I would only enable features qemu knows about, i.e. something like features = spice_get_features() features = qemu_supported_features; spice_server_enable_features(features); Where qemu_supported_features is the set of features the qemu qxl code knows about and can handle. Have options to turn off specific features. In case a new release adds multiple new features users / admins might want to selectively enable/disable them depending on how they affect compatibility. qemu live migration compatibility is only affected in case the new feature requires additional state to be saved. client compatibility is only affected in case the wire protocol changes. So it might make sense to enable a subset of the new features, although that most likely isn't the common case. I don't think the onus should be on the sysadmin to know what features is compatible with what version of spice. Thus, in my mind you'll specify compat with 0.6 which in 0.8 will enable all the features in 0.8 that are possible to migrate to/from 0.6 (including some that may not be in 0.6). Having a more fine-grained command line feature selection just causes complexity and risk that sysadmins get things wrong. I don't see any gain in it. I'll note that this switch is really only about migration compatibility. For the client side i think in the future we should either: * Add a similar switch for client compat or * Make sure that we always support connecting with old clients in future releases. I was expecting to do the second. But maybe thats not always possible? Right now we don't do any compat with 0.4, but the plan is that eventually we want to add a qemu mode where it doesn't use offscreen surfaces, nor the new qxl pci device, and allows migration to/from spice 0.4.0 instances. It's there. The new qxl device handles old guest drivers just fine. With the spice.v17 branch even live migration should work. At least new qxl parses old qxl state just fine when switched into compatibility mode. Not fully tested yet though due to some non-spice-related migration issues. Cool. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an immortal native American gangster whom everyone believes is mad. She's a wealthy green-skinned fairy princess from Mars. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/1] Add API to turn on backwards compatibility mode
On Fri, 2010-08-27 at 17:28 +0200, Gerd Hoffmann wrote: Hi, Having a more fine-grained command line feature selection just causes complexity and risk that sysadmins get things wrong. I don't see any gain in it. Point. I'll note that this switch is really only about migration compatibility. Any reason to add this now? We could delay it until we actually hit a migration compatibility issue. Don't we have any migration incompatibilities with 0.4? Anyway, its probably ok to delay this until we need to call it from qemu. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a lonely bohemian cyborg whom everyone believes is mad. She's a high-kicking nymphomaniac opera singer prone to fits of savage, blood-crazed rage. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/2] server: add subtype to SpiceCharDeviceInterface, use for vdagent
On Thu, 2010-08-26 at 04:45 -0400, Alon Levy wrote:
diff --git a/server/spice-experimental.h b/server/spice-experimental.h
index e40b3ec..fd8ef67 100644
--- a/server/spice-experimental.h
+++ b/server/spice-experimental.h
@@ -10,6 +10,7 @@ typedef struct SpiceCharDeviceState SpiceCharDeviceState;
struct SpiceCharDeviceInterface {
SpiceBaseInterface base;
+const char* (*subtype)(SpiceCharDeviceInstance *sin);
void (*state)(SpiceCharDeviceInstance *sin, int connected);
int (*write)(SpiceCharDeviceInstance *sin, const uint8_t *buf, int len);
int (*read)(SpiceCharDeviceInstance *sin, uint8_t *buf, int len);
@@ -21,6 +22,7 @@ struct SpiceCharDeviceInstance {
};
I think you should move this from a method on the interface to a const
char * on the instance.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/2] spice-{vdi, vmc}: rename SpiceVDIPort* to SpiceCharDevice*
On Thu, 2010-08-26 at 04:46 -0400, Alon Levy wrote: --- hw/spice-vdi.c | 16 hw/spice-vmc.c | 22 +++--- 2 files changed, 19 insertions(+), 19 deletions(-) Ack ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: clean glz drawables when reseting qxl
On Wed, 2010-08-25 at 10:06 +0300, Yonit Halperin wrote: When the we reset qxl, we destroy all srufaces. Since surfaces and glz drawables are no longer dependent, we need to call red_display_clear_glz_drawables explicitly in order to clear all our drawables references in the server. --- Ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a lonely Republican card sharp on a mission from God. She's a hard-bitten hip-hop journalist from a secret island of warrior women. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fwd: [PATCH 2/3] server: fix race when data arrives from guest through vdi interface
On Wed, 2010-08-25 at 06:28 -0400, Alon Levy wrote: - Forwarded Message - From: Alon Levy al...@redhat.com To: al...@redhat.com Sent: Sunday, August 22, 2010 10:28:37 PM (GMT+0200) Auto-Detected Subject: [PATCH 2/3] server: fix race when data arrives from guest through vdi interface The call chains that could lead to write_to_vdi_port from two threads: guest paste: per cpu thread: kvm_main_loop_cpu..vmc_have_data..spice_server_vdi_port_wakeup ..write_to_vdi_port Is this enough though? It seems to me that read_from_vdi_port() is not threadsafe either. It changes some state and does not seem to have any locking or anything. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 2/2] server: remove the no longer used glz drawables list that was maintained for each surface.
On Mon, 2010-08-23 at 09:36 +0300, Yonit Halperin wrote: From: Yonit Halperin yhalp...@yhalperi.tlv.redhat.com --- server/red_worker.c |8 1 files changed, 0 insertions(+), 8 deletions(-) Ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly arachnophobic astronaut who hides his scarred face behind a mask. She's a hard-bitten motormouth soap star who can talk to animals. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 5/8] Make malloc_sem global
On Sun, 2010-08-22 at 14:58 +0300, Yonit Halperin wrote: On 08/20/2010 09:54 PM, al...@redhat.com wrote: From: Alexander Larssonal...@redhat.com It protects shared data (mspace info) so it needs to be shared. --- Don't see a problem with making it global, but not sure it is needed. Can alloc operations occur on an inactive pdev? For sure things like DrvDeleteDeviceBitmap() can happen (you said above that this will be called for all surfaces before disabling the pdev). And DrvDeleteDeviceBitmap will eventually reach e.g. GetSurfaceCmd which will cause an AllocMem call. Also, this points to another issue with the malloc_sem. If ifs protecting pdev-Res.mspaces, then we really should take it in FreeMem too, as that calls mspace_free(). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed Republican astronaut possessed of the uncanny powers of an insect. She's a supernatural winged stripper with someone else's memories. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 7/8] Store surfaces_used in a bit-array
On Sun, 2010-08-22 at 15:56 +0300, Yonit Halperin wrote:
On 08/20/2010 09:54 PM, al...@redhat.com wrote:
From: Alexander Larssonal...@redhat.com
This is smaller than a byte array, and allows us to skip full
blocks of 32 ids in one check.
---
Hi,
why not use a linked list, for free surfaces, in a static
UINT32[n_surfaces] array? Any reason besides space, which is 4k?
In fact, the best way to do this would probably be to chain the free
surfaces together into a linked list using e.g. SurfaceInfo-pdev which
are unused for free surface_infos. This way we use no extra memory.
shouldn't it be ~(0x8000 (surface_id % 32))?
+if (used_mask == 0x) {
shouldn't it be used_mask != 0x?
Yeah, Good catches.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a notorious sweet-toothed cat burglar moving from town to town, helping
folk in trouble. She's a supernatural tempestuous doctor married to the Mob.
They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] client: disable clipboard for now (defined out)
On Mon, 2010-08-23 at 10:34 -0400, Alon Levy wrote:
---
client/application.cpp |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/client/application.cpp b/client/application.cpp
index 490cd8c..8eac8f6 100644
--- a/client/application.cpp
+++ b/client/application.cpp
@@ -1325,7 +1325,9 @@ void Application::on_app_activated()
{
_active = true;
_key_handler-on_focus_in();
+#ifdef CLIPBOARD_ENABLED
Platform::set_clipboard_listener(this);
+#endif
}
void Application::on_clipboard_change()
Ack
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a war-weary guitar-strumming stage actor looking for 'the Big One.' She's
a transdimensional blonde opera singer from a secret island of warrior women.
They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: remove unnecessary dependency between surfaces and Glz drawables
On Wed, 2010-08-11 at 14:21 +0300, Yonit Halperin wrote: Fixes freedesktop bug #28568 --- Ack, although it would be nice to split this into two commits. One that removes the unnecessary red_clear_surface_glz_drawables() calls and moves the red_destroy_surface() call to release_drawable, which is the core problem. Then a second one that just removes the now-unused lists surface_id references. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a world-famous pirate Green Beret on the edge. She's a scantily clad streetsmart fairy princess with only herself to blame. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] spice: vdagent: support x64 arch
On Mon, 2010-08-09 at 12:58 +0300, Arnon Gilboa wrote: /* 7.18.1.4 Integer types capable of holding object pointers */ +#ifndef _WIN64 + typedef int intptr_t; typedef unsigned uintptr_t; +#endif + So, the win64 compiler supports (u)intptr_t, but the win32 one doesn't? Seems kinda weird. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a hate-fuelled arachnophobic barbarian on the hunt for the last specimen of a great and near-mythical creature. She's a wealthy hip-hop magician's assistant who can talk to animals. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] spice: vdagent: return error code -1 on service install/uninstall failure #576625
On Mon, 2010-08-09 at 12:58 +0300, Arnon Gilboa wrote: From: Arnon Gilboa agil...@agilboa.usersys.redhat.com --- Ack -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an uncontrollable native American barbarian from a doomed world. She's an artistic cat-loving politician who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] spice: vdagent: add basic clipboard support
On Mon, 2010-08-09 at 12:58 +0300, Arnon Gilboa wrote: From: Arnon Gilboa agil...@agilboa.usersys.redhat.com -currently supports text only (UTF8) -add VDAgent::dispatch_message() -in VDAgent::read_completion() handle multi-chunk msgs -fix chunk size bug in VDService::handle_pipe_data() -add size to VDPipeMessage This reads out the clipboard and writes it to the client on every change. This is bad for two reasons: 1) It sends a lot of data to the client when it might not be needed 2) It always forces clipboard using apps to serialize any clip board data it has to text and pass it to windows every time someone copies and pastes. This is unnecessary in most cases since cut and paste is mostly intra-application. Additionally it may be costly since if you copy something more complex like pdf or html extracting the text from it may not be trivial. I know we discussed this on irc. What is the status of that? I guess we could split out the pure bugfixes from this and commit though. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a globe-trotting amnesiac grifter possessed of the uncanny powers of an insect. She's a sarcastic junkie snake charmer with a birthmark shaped like Liberty's torch. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] spice: vdagent: add basic clipboard support
On Wed, 2010-08-18 at 14:18 +0200, Attila Sukosd wrote: Sorry for hijacking this, but whats the irc server/channel name? #spice on gimpnet -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a maverick bohemian jungle king whom everyone believes is mad. She's a beautiful mute opera singer fleeing from a Satanic cult. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [RFC] patch to remove CEGUI dependency
On Fri, 2010-08-13 at 08:42 +0200, Attila Sukosd wrote: Hi Darren, Not yet, I havent really had the time. As far as I've seen, other than the limited libraries, the graphics and audio will definitely need reimplementing, since androids don't run X11 or ALSA. It might be possible to port the current OpenGL code to OpenGL ES ? Not sure if that would be easier than a full gfx rewrite? (I haven't been able to get the current OpenGL implementation to run..) Yes, the current OpenGL implementation doesn't really work in the new offscreen surfaces world. We have some patches from izik that begins to fix this, but I don't know the status of them. Anyway, I don't think the OpenGL backend is very interesting atm, its main interest would be if we supported 3d stuff, as then we could avoid mixing software (2d) and hardware (3d) rendering to avoid slowdowns. But at this point we don't do any 3d stuff, so its not really useful (and actually slower than the software version in many cases). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an unconventional Jewish Green Beret from the Mississippi delta. She's a transdimensional extravagent doctor on the trail of a serial killer. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice client requirements
On Tue, 2010-08-10 at 03:17 -0700, Steven Tan wrote: Hi All, I can't find information on minimum HW requirements to run a Spice client. Is there some specific information on requirements for CPU, RAM, GPU etc. with regard to a Spice client environment? I don't think we really know these things exactly, but in general not very much. All the spice client does is render 2d graphics, so no GPU needed , and generally the CPU requirements are pretty low. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a Nobel prize-winning umbrella-wielding cop on a search for his missing sister. She's an orphaned paranoid vampire with an incredible destiny. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Qxl PATCH] Change surfaces allocation method.
On Tue, 2010-08-17 at 14:26 +0300, Yonit Halperin wrote: The driver no longer claims to support DirectDraw. It uses mspace to allocate surfaces and not HeapVidMemAllocAligned. This fixes freedesktop bug #29254. Ack (although you should git rm dd.c too). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American pirate cowboy looking for a cure to the poison coursing through his veins. She's a warm-hearted out-of-work research scientist with a birthmark shaped like Liberty's torch. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] server: Consider the surface id when identifying video streams, and draw the stream on the proper surface, #28088
On Mon, 2010-07-26 at 09:18 +0300, Yonit Halperin wrote: --- server/red_worker.c | 21 + 1 files changed, 17 insertions(+), 4 deletions(-) The changes look ok, but don't you also need to check in VideoStream::maintenance() if surface is 0 before calling _channel.invalidate(dest), as that will just cause the area on the primary surface to be updated on the screen. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an immortal guerilla assassin who hangs with the wrong crowd. She's a mistrustful cat-loving Valkyrie from aristocratic European stock. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Spice-commits] Changes to 'refs/tags/0.5.2'
On Thu, 2010-07-22 at 10:02 +0200, Attila Sukosd wrote: Quick question, why has the pkgconfig files been moved to share/pkgconfig instead of the original lib/pkgconfig path? This means that since all the other libraries put their pkgconfig file in lib/pkgconfig, two paths need to be set for it to find the libs... This is because spice-protocol is architecture independent. This means it can e.g. be a noarch package in rpm based distros. You only need to set two paths if you're installing in a nonstandard prefix though, for the system prefix both the /usr/lib[64] and /usr/share directories are read by default. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a benighted vegetarian cop who dotes on his loving old ma. She's a radical snooty detective with the power to see death. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice works with qtopia?
On Fri, 2010-07-09 at 17:55 +0800, 吕广俊 wrote: HI: Spice client has been support X11, How Spice client works with qtopia? The spice client only works on X11 and win32 at the moment. I don' think qtopia uses x11, so it will not work there. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an all-American chivalrous farmboy on the wrong side of the law. She's a manipulative junkie traffic cop with a knack for trouble. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Released: spice 0.5.2
I just made releases of spice and spice-protocol version 0.5.2. The releases are availible at http://spice-space.org/download.html and as the tag 0.5.2 in git. We expect this release to be API stable up to the 0.6 release, but the network major and the PCI ids are still marked as unstable, because the ABIs are not 100% finalized. We expect the 0.5.3 release (schedule: http://spice-space.org/page/Releases/SpiceZeroPointSix) to be network and ABI stable. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a notorious coffee-fuelled ex-con on his last day in the job. She's a time-travelling belly-dancing single mother who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Status of 0.6 release
We're now two weeks from the 0.6 feature freeze as per: http://www.spice-space.org/page/Releases/SpiceZeroPointSix I think its time to figure out the current status so that we're focusing on the right things the following two weeks. Lets first start with the proposed feature list for the release: * Qemu integration We have a new qemu repository, based on the current upstream version, with clean patch-series using a new, nicer spice API. Patches have been posted upstream at least for the initial integration (no qxl device support yet though). There has been any feedback yet though, so its hard to judge the status here. Will it be possible to get this merged? * Surfaces This has landed and seems to generally work. The dependency calculations for surfaces is a bit lax atm due to a bug in the UPDATE_AREA_BY_TREE code in red_worker.c, so might not be as efficient as possible. However, generally this seems to work. * Marshalling layer for compatability We're now using the (de)marshalling layer for almost everything. The tunnel channel has not been ported yet to the new marshaller, but we're not sure exactly if and how tunneling should work anyway, so its not a real problem. * PCI compatibility layer We've landed most of this, however there are still a few items left to do before we can remove all use of draw.h from the qxl users and make the spice types internal. Missing types are: SpiceCursorHeader, SpiceImageDescriptor, SpiceBitmap, SpiceQUICData, SpiceSurface. When these are done we also need to move the draw.h header from spice-protocol to spice/common and remove the packed attributes. Also, when the image types are internalized we can do some changes to the demarshalling of them to avoid unnecessary copying of image data. * Improved support for WAN We have landed support for lossy compression (jpeg) and lz compression of glz images, for low bandwidth mode. We need to add some command line arguments to allow this to be enabled/tuned. This is a good basis for wan support, but needs ongoing measurements, tuning and tweaking. * Cut and paste between client and guest This has not landed yet. Arnon has been working on this and is now cleaning it up and testing it. We need to ensure that this happens before July 19th to hit the feature freeze. There are also some other things we need to look at: * New agent implementation We have a new agent implementation using virtio rather than a custom protocol. I believe the new qemu repositiory has the qemu side code for this and i don't think the spice side needs any changes. Right? However, we don't have a new win32 agent upstream yet, do we? And is the win32 virtio driver availible somewhere yet? Need to ensure this all happens. Alon, what is the status here? * Live migration With the new qemu stuff we've lost live migration. This would be very good to get back. I don't know the status of this and what blocks it. Gerd, what is the status here? * Making upstream easier to build We've removed the forked qcairo and qpixman, dropped the dependency on ffmpeg, made opengl and cegui optional. We've also split out the required headers from spice into spice-protocol so that drivers etc can build without a spice dependency. This all makes the upstream spice much easier to build, which should hopefully mean more contributors, etc. I don't think we have any more outstanding work here. Do we? * Network protocol changes We've bumped the major to 2 (well, atm it a high unstable number, but it will be 2 after the freeze). With this we've done a bunch of changes to the network protocol, like changing offsets to 32bit, and avoiding to send unused parts of messages, made enum fields smaller, and dropped unused clip paths and some line attributes. There are some outstanding changes here to avoid using offsets in more places that await the finishing of the pci compat layer. This is our one chance to remove stuff from the protocol though. We need to go through everything looking for if there is anything more to change before we freeze. Can people please look for things that could be better. * Migration from 0.4 to 0.6 This is not possible atm. Is it doable? Is it interesting? Opinions? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish umbrella-wielding hairdresser with a winning smile and a way with the ladies. She's a strong-willed wisecracking Valkyrie who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Demarshaller work landed on master
On Mon, 2010-06-21 at 10:11 +0200, Gerd Hoffmann wrote: On 06/18/10 21:37, Alexander Larsson wrote: After a lot of work I finally got the marshaller/demarshaller work in a state where its interesting for others to look at and test. It works in my testing on both linux and win32, between both pre-marshaller versions (both ways) and between post-marshaller versions. i.e. spice client can talk to both 0.4 and unstable spice servers now? No, but it can be made to. Right now it just handles the current upstream protocol. Python is now an additional dependency when building from git (not when building from tarballs though). You also need the pyparsing module. Just noticed that RHEL-6 doesn't ship pyparsing ... Well, for RHEL we'll build from tarballs that will ship the generated code. There are some things that are still not ideal due to all the types in spice/draw.h being used in the qxl PCI ABI, so those could not be internalized and changed. For instance, some of the image type use inline data arrays which are unnecessarily copied in the current setup. This will be fixed when we the qxl ABI is split out from the spice-private structures and those can be changed. Ok. Was just about to ask what the status here is ;) What is the plan? Can the python code generator also be used for the qxl struct translation? This is one of the items pretty high on my priority list as it needs to be done for 0.4 compatibility for guest drivers ... The plan is to do this soon, its obviously the next step in making this really work. There is some initial work in bugzilla at: https://bugs.freedesktop.org/show_bug.cgi?id=28171 But i have not looked at it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a suicidal hunchbacked grifter from a doomed world. She's a cynical Buddhist politician in the wrong place at the wrong time. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice flash redirection
On Tue, 2010-06-15 at 14:17 -0400, Steven Harms wrote: In thin client deployments, recently there has been some work around with flash redirection in the proprietary systems. I would like to start working on a similar system for Spice, and was looking for input. My thought would be to make a browser modification that intercepts the swf on the vm, and forwards that data to the spice client that would embed the flash player and just launch the swf there on the client. Good approach, horrible idea? I think this will be very hard. The flash plugin integrates quite deeply with the browser (for sizeing, positioning, clipping, DOM integration, etc) and the browser will be running in the guest OS, not on the client. Furthermore such deep interaction with the client is not suitable to the spice protocol, because it must handle e.g. the client terminating or the guest being migrated to another machine. In this model a lot of important state is being stored in the client and not in the server and this doesn't nicely handle situations like that. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an old-fashioned playboy astronaut possessed of the uncanny powers of an insect. She's a cold-hearted nymphomaniac journalist with someone else's memories. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] --disable-opengl support. uses existing USE_OGL flag
On Wed, 2010-06-16 at 05:53 -0400, Alon Levy wrote: Provides a default off --disable-opengl option to configure. Doesn't remove libGL.so dependency from resulting binary since CEGUI depends on it (which we need for our dialogs right now). Would be nice to have --disable-dialog too. I pushed this with some changes: * fix win32 build * default opengl to off * USE_GLZ is not opengl related * if opengl enabled and not found, error out configure -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a lounge-singing gay librarian with a passion for fast cars. She's a foxy tempestuous bodyguard married to the Mob. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] fix for not reseting client palette caches on migration
On Wed, 2010-06-09 at 13:21 +0300, Yonit Halperin wrote: --- server/red_worker.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) pushed -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a notorious misogynist boxer on the run. She's a brilliant kleptomaniac former first lady in the witness protection program. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: client: don't invalidate unless primary surface
On Sun, 2010-05-23 at 14:40 -0400, Alon Levy wrote: Izik suggested this, said it will save some performance - in bitmap operations on non primary surfaces no need to invalidate the rectangle. Did some very minimal tests on windows xp guest. Can anyone have a look? Pushed. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an underprivileged arachnophobic messiah with a robot buddy named Sparky. She's a cosmopolitan Bolivian widow living on borrowed time. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice install problem
On Wed, 2010-05-26 at 20:33 -0500, Brian Milliron wrote: You quoted this: In case of an older kernel (version 2.6.30) Get kernel sources using the following git repository: ... Obviously the version numbers involved here (2.6.30) refer to upstream versions. Whats in the centos kernel is quite different than any upstream kernel versions. So, try following the instructions as if you had a = 2.6.30 version and see if that works. Ok, I just skipped ahead to the next step which is: In both cases: cd spice_root/vdesktop ./configure --enable-spice First ./configure complained about not having libgcrypt, which was installed. Clearly it meant to complain about not having libgcrypt-devel because when I installed that it proceeded to give me a new error: configure typically looks for upstream source tarball modules, like libgcrypt, these are often split into multiple packages on a distro, but the configure scripts don't have any idea about this. [r...@localhost vdesktop]# ./configure --enable-spice Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /usr/local/src/spice_root/vdesktop/qemu C compilergcc Host C compiler gcc ARCH_CFLAGS -m64 make make install install host CPU x86_64 host big endian no target list x86_64-softmmu gprof enabled no sparse enabledno profiler no static build no -Werror enabled no SDL support no curses supportno mingw32 support no Audio drivers oss Extra audio cards ac97 Mixer emulation no VNC TLS support no libgcrypt support yes gcrypt CFLAGS gcrypt LIBS-lgcrypt -ldl -lgpg-error kqemu support no kvm support yes CPU emulation yes brlapi supportno Documentation no NPTL support yes vde support no AIO support yes QXL yes Spice yes SMB directoresyes SCSI devices yes ISAPC support yes KVM nestedyes USB storage yes USB wacom yes USB serialyes USB net yes USB bluez no VMware driversyes NBD support yes bluetooth support no Only generic cpus no The error log from compiling the libSDL test is: /tmp/qemu-conf-18013-7491-1531.c:1:17: error: SDL.h: No such file or directory /tmp/qemu-conf-18013-7491-1531.c: In function ‘main’: /tmp/qemu-conf-18013-7491-1531.c:3: error: ‘SDL_INIT_VIDEO’ undeclared (first use in this function) /tmp/qemu-conf-18013-7491-1531.c:3: error: (Each undeclared identifier is reported only once /tmp/qemu-conf-18013-7491-1531.c:3: error: for each function it appears in.) [r...@localhost vdesktop]# This means you don't have libsdl devel packages installed, however I don't think this is actually a problem, it just means sdl won't be supported. You can probably continue with the next step here (or install sdl headers if you want to). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Initial work on demarshalling
I've commited my initial work on a real network message demarshalling to a private branch: http://cgit.freedesktop.org/~alexl/spice-protocol/log/?h=demarshaller http://cgit.freedesktop.org/~alexl/spice/log/?h=demarshaller In this version the client does demarshalling, validation and pointer localization on all recieved messages before passing it on to the client code. This means those functions is removed from the client code. This requires python and pyparsing for the generation step when building from git (but not from tarballs). Please have a look at this if you're interested. My next step is to look at the marshalling side. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice install problem
On Tue, 2010-05-25 at 16:34 -0500, Brian Milliron wrote: I posted this question to the kvm list as had been suggested. I was told that is not the right list and vdesktop uses an outdated version of kvm and something about user code and kernel code having been forked. It doesn't make a whole lot of sense to me, but I'm still looking for answers to my problem. I've included the original question below: Brian I apologize if this is not the right place for this question, but I'm running into some problems installing Spice .4 on my CentOS 5.5. I was following the instructions here: http://www.spice-space.org/docs/spice_user_manual.pdf I've compiled and installed all the dependencies and have the spice client installed also, but ran into problems with the vdesktop. Specifically this portion of the instructions for my older kernel: I don't know how the kvm/kernel stuff of vdesktop is set up really, but i think your problem is that the kernels you're using are not compatible somehow. Possibly because the rhel kernel you're using already has kvm backports in it. Have you tried to not get the new kernel source (i.e. act as if you had a new kernel). Personally i never built the kernel part of vdesktop as the kvm modules were always availible on the kernels I was running already. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed albino ex-con who hangs with the wrong crowd. She's a sarcastic cat-loving soap star with only herself to blame. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice install problem
On Wed, 2010-05-26 at 12:33 -0500, Brian Milliron wrote: I don't know how the kvm/kernel stuff of vdesktop is set up really, but i think your problem is that the kernels you're using are not compatible somehow. Possibly because the rhel kernel you're using already has kvm backports in it. Have you tried to not get the new kernel source (i.e. act as if you had a new kernel). No and I'm not sure what you are trying to say here. You quoted this: In case of an older kernel (version 2.6.30) Get kernel sources using the following git repository: ... Obviously the version numbers involved here (2.6.30) refer to upstream versions. Whats in the centos kernel is quite different than any upstream kernel versions. So, try following the instructions as if you had a = 2.6.30 version and see if that works. Personally i never built the kernel part of vdesktop as the kvm modules were always availible on the kernels I was running already. Is the vdesktop optional then? I really don't even understand what vdesktop is supposed to do. vdesktop is a module that contains several things, its got kernel modules for kvm, some kvm userspace library and an old copy of qemu-kvm modified to use spice. With a recent kernel you don't need anything but the qemu part. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly zombie ex-con on the wrong side of the law. She's an elegant gypsy socialite from a family of eight older brothers. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] sound channels: restart audio on client reconnect.
On Thu, 2010-05-20 at 13:33 +0200, Gerd Hoffmann wrote: Some brackets missing after if, but otherwise this looks good to me. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an impetuous crooked astronaut in drag. She's a foxy nymphomaniac soap star from aristocratic European stock. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] RFC: client: don't invalidate unless primary surface
On Sun, 2010-05-23 at 14:40 -0400, Alon Levy wrote:
Izik suggested this, said it will save some performance - in bitmap
operations on non primary surfaces no need to invalidate the
rectangle. Did some very minimal tests on windows xp guest. Can anyone
have a look?
Its true that you don't have to invalidate on offscreen surfaces, but
your patch below misses the main one:
#define DRAW(type) {\
PRE_DRAW; \
canvas-draw_##type(*type, message-size());\
POST_DRAW; \
invalidate(type-base.box, false); \
}
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a time-tossed moralistic astronaut who dotes on his loving old ma. She's
a high-kicking thirtysomething bodyguard looking for love in all the wrong
places. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] cannot boot from virtio / no -qxl option
On Fri, 2010-05-21 at 12:21 +0200, Frédéric Grelot wrote: Tanks anyway for all your work, it becomes easier and easier to test spice! (and I can't imagine what it will be when spice gets into upstream qemu!). Well, the goal is that you shouldn't have to even build it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fast talking voodoo matador who dotes on his loving old ma. She's an orphaned French-Canadian barmaid with a song in her heart and a spring in her step. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 36/39] NetWireInterface: redesign
On Tue, 2010-05-18 at 17:43 +0200, Gerd Hoffmann wrote: +void spice_server_net_wire_recv_packet(SpiceNetWireInstance *sin, + const uint8_t *pkt, int len); + Uhm? I can't find the definition of this. In fact there are zero changes to red_tunnel_worker.c in the patch. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish Jewish messiah fleeing from a secret government programme. She's a manipulative foul-mouthed detective from Mars. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 38/39] zap vd_interface.h
On Tue, 2010-05-18 at 17:43 +0200, Gerd Hoffmann wrote:
+struct SpiceRect;
+struct QXLWorker {
+uint32_t minor_version;
+uint32_t major_version;
+void (*wakeup)(QXLWorker *worker);
+void (*oom)(QXLWorker *worker);
+void (*start)(QXLWorker *worker);
+void (*stop)(QXLWorker *worker);
+void (*update_area)(QXLWorker *qxl_worker, uint32_t surface_id,
+ struct SpiceRect *area, struct SpiceRect *dirty_rects,
+ uint32_t num_dirty_rects, uint32_t
clear_dirty_region);
I don't like how this puts the SpiceRect typedef in the public API, as
we want to convert all Spice types that qxl uses to qxl specific types
(i.e. QXLRect), and then make SpiceRect internal (in fact we want to
change SpiceRect to be binary compat with the pixman box_t type).
Furthermore, the API as is doesn't even define SpiceRect as it doesn't
pull in the right header from spice-protocol for it. I'm not sure what
the best approach here is. We should add QXLRect to qxl_dev.h and just
use it for update_area for now. Then we can pull in qxl_dev.h into
spice.h or we could forward declare it like SpiceRect above.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a leather-clad Amish stage actor moving from town to town, helping folk
in trouble. She's a blind out-of-work queen of the dead with only herself to
blame. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 38/39] zap vd_interface.h
On Wed, 2010-05-19 at 11:11 +0200, Gerd Hoffmann wrote:
On 05/19/10 10:45, Alexander Larsson wrote:
On Tue, 2010-05-18 at 17:43 +0200, Gerd Hoffmann wrote:
+struct SpiceRect;
+struct QXLWorker {
+uint32_t minor_version;
+uint32_t major_version;
+void (*wakeup)(QXLWorker *worker);
+void (*oom)(QXLWorker *worker);
+void (*start)(QXLWorker *worker);
+void (*stop)(QXLWorker *worker);
+void (*update_area)(QXLWorker *qxl_worker, uint32_t surface_id,
+ struct SpiceRect *area, struct SpiceRect
*dirty_rects,
+ uint32_t num_dirty_rects, uint32_t
clear_dirty_region);
I don't like how this puts the SpiceRect typedef in the public API,
I don't put it there. It already is there, I'm just moving the bits
from one header to another.
I agree that it needs fixing, but that is IMHO independent from this
patch series.
Yeah, just pointing it out when i saw it.
as
we want to convert all Spice types that qxl uses to qxl specific types
(i.e. QXLRect), and then make SpiceRect internal (in fact we want to
change SpiceRect to be binary compat with the pixman box_t type).
Furthermore, the API as is doesn't even define SpiceRect as it doesn't
pull in the right header from spice-protocol for it. I'm not sure what
the best approach here is. We should add QXLRect to qxl_dev.h and just
use it for update_area for now.
qxl_dev.h uses SpiceRect too. Wasn't there a patch from izik which
started cleaning that up and separate QXL* and Spice* types?
Yeah, this is
http://www.spice-space.org/page/Features/PCICompatLayer
I added iziks initial patch to
https://bugs.freedesktop.org/show_bug.cgi?id=28171
I haven't looked at it yet, but its not supposed to be in any finished
state.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a sword-wielding chivalrous messiah on the edge. She's a beautiful
psychic pearl diver in the wrong place at the wrong time. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 31/35] replace worker load/save with loadvm_commands, allow keeping surface content
On Mon, 2010-05-17 at 20:37 +0200, Gerd Hoffmann wrote: On 05/17/10 11:54, Alexander Larsson wrote: @@ -9138,7 +9086,7 @@ static inline void handle_dev_create_primary_surface(RedWorker *worker) } red_create_surface(worker, 0, surface.width, surface.height, surface.stride, surface.format, - line_0); + line_0, 1); Maybe add a comment saying why we data_is_valid is needed for primary surfaces. Needed only in the save/restore case. Not fully sure it is really ok to do it unconditionally, although I can't think of a reason why it shouldn't. Comments? The alternative would be to do it depending on some bit in surface.flags. I think what we want to do is: 1) By default, don't zero out data, its just a waste of cycles. However, also don't guarantee that the data is kept (as that would require a data upload to texture memory for a GL canvas). So, we give no guarantees at all about surface contents after creation, each canvas doing minimal work. 2) Add a flag to surface.create to keep the data. This is a no-op on the sw canvas but an upload on the gl backend. Some driver may want to use this if a new surface has data in it to avoid having to send a separate DrawImage to fill it. 3) Have the restore case override this flag like your code code above does when recreating the surfaces. (I.e. it doesn't actually change the flags value in the stored CreateSurface commands) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/35] new libspice-server API patches.
On Mon, 2010-05-17 at 20:59 +0200, Gerd Hoffmann wrote:
Hi,
I reviewed the patches up to 31. Some minor issues were pointed out in
separate mails, but generally i think this looks good and should go in
now.
Yes, I agree on it. Sort the remaining minor bits, then merge.
There are still some old references that we should try to get rid of:
vd_interface.h should be renamed. Maybe spice_interfaces.h?
Is there any reason to keep it separate from spice.h? If not, then let
us just move over all content (after a cleanup pass).
Sounds good to me.
Are these needed:
#define VM_INTERFACE_VERSION 1
typedef unsigned long VDObjectRef;
#define INVALID_VD_OBJECT_REF 0
Can go away I think.
typedef enum {
VD_LOG_ERROR = 1,
VD_LOG_WARN,
VD_LOG_INFO,
} LogLevel;
should be SPICE_LOG_foo?
Looks like it isn't used anywhere. Just drop?
I think you deleted the uses of it in:
http://lists.freedesktop.org/archives/spice-devel/2010-May/000341.html
typedef struct DrawArea {
This should probably be QxlDrawArea, since its a public header.
Yes.
enum VDIArgType{
typedef struct VDIArgDescriptor {
typedef struct VDICmdArg {
typedef void (*VDICmdHandler)(const VDICmdArg* args);
typedef void (*VDIInfoCmdHandler)(void);
Not sure what they are used for. Either drop or move to a private
header file I'd guess, but needs investigation.
Was used in:
http://lists.freedesktop.org/archives/spice-devel/2010-May/000365.html
So, just drop.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 20/35] VDInterface: redesign.
On Wed, 2010-05-12 at 13:32 +0200, Gerd Hoffmann wrote:
+} else if (strcmp(interface-type, VD_INTERFACE_NET_WIRE) == 0) {
#ifdef HAVE_SLIRP
-NetWireInterface * net_wire = (NetWireInterface *)interface;
-red_printf(VD_INTERFACE_NET_WIRE);
-if (red_tunnel) {
-red_printf(net wire already attached);
-return;
-}
-if (interface-major_version != VD_INTERFACE_NET_WIRE_MAJOR ||
-interface-minor_version VD_INTERFACE_NET_WIRE_MINOR) {
-red_printf(unsuported net wire interface);
-return;
-}
-red_tunnel = red_tunnel_attach(core, net_wire);
+NetWireInterface * net_wire = (NetWireInterface *)interface;
+red_printf(VD_INTERFACE_NET_WIRE);
+if (red_tunnel) {
+red_printf(net wire already attached);
+return -1;
+}
+if (interface-major_version != VD_INTERFACE_NET_WIRE_MAJOR ||
+interface-minor_version VD_INTERFACE_NET_WIRE_MINOR) {
+red_printf(unsuported net wire interface);
+return -1;
+}
+red_tunnel = red_tunnel_attach(core, net_wire);
#else
-red_printf(unsupported net wire interface);
+red_printf(unsupported net wire interface);
#endif
The switch from not returning anything to returning -1 on failure means
that #else HAVE_SLIRP case need to return -1.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a sword-wielding hunchbacked messiah haunted by memories of 'Nam. She's a
wealthy tempestuous vampire with the power to see death. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 28/35] vdi port: redesign.
On Wed, 2010-05-12 at 13:32 +0200, Gerd Hoffmann wrote:
-while (reds-agent_state.plug_ref != INVALID_VD_OBJECT_REF) {
+sif = SPICE_CONTAINEROF(vdagent-base.sif, SpiceVDIPortInterface, base);
+for (;;) {
Changing a while to for(;;;) doesn't seem right. We can still hit:
read_from_vdi_port()- dispatch_vdi_port_data()- default: -
reds_agent_remove()
which used to set plug_ref to INVALID_VD_OBJECT_REF, only now it sets
connected to 0 instead, so we should check that.
+if (sif-state)
+sif-state(vdagent, reds-agent_state.connected);
reds-agent_state.plug_generation++;
Missing brackets around block.
+if (sif-state)
+sif-state(vdagent, state-connected);
Here too.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's an oversexed ninja vagrant on the run. She's a chain-smoking red-headed
opera singer in the wrong place at the wrong time. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 31/35] replace worker load/save with loadvm_commands, allow keeping surface content
On Wed, 2010-05-12 at 13:32 +0200, Gerd Hoffmann wrote:
-static void qxl_worker_stop(QXLWorker *qxl_worker)
-{
-RedDispatcher *dispatcher = (RedDispatcher *)qxl_worker;
-RedWorkeMessage message = RED_WORKER_MESSAGE_STOP;
+RedWorkeMessage message = RED_WORKER_MESSAGE_LOADVM_COMMANDS;
+red_printf();
Eh?
static inline void red_create_surface(RedWorker *worker, uint32_t
surface_id, uint32_t width,
uint32_t height, int32_t stride,
uint32_t format,
- void *line_0)
+ void *line_0, int data_is_valid)
{
uint32_t i;
RedSurface *surface = worker-surfaces[surface_id];
@@ -8039,7 +8040,8 @@ static inline void red_create_surface(RedWorker
*worker, uint32_t surface_id, ui
surface-context.format = format;
surface-context.stride = stride;
surface-context.line_0 = line_0;
-memset(line_0 + (int32_t)(stride * (height - 1)), 0, height*abs(stride));
+if (!data_is_valid)
+memset(line_0 + (int32_t)(stride * (height - 1)), 0,
height*abs(stride));
Missing brackets around block.
@@ -9138,7 +9086,7 @@ static inline void
handle_dev_create_primary_surface(RedWorker *worker)
}
red_create_surface(worker, 0, surface.width, surface.height,
surface.stride, surface.format,
- line_0);
+ line_0, 1);
Maybe add a comment saying why we data_is_valid is needed for primary
surfaces.
+case RED_WORKER_MESSAGE_LOADVM_COMMANDS: {
+uint32_t count;
+QXLCommandExt ext;
+QXLCursorCmd *cursor_cmd;
+QXLSurfaceCmd *surface_cmd;
+
+red_printf(loadvm_commands);
+receive_data(worker-channel, count, sizeof(uint32_t));
+while (count 0) {
+receive_data(worker-channel, ext, sizeof(QXLCommandExt));
+switch (ext.cmd.type) {
+case QXL_CMD_CURSOR:
+cursor_cmd = (QXLCursorCmd *)get_virt(worker-mem_slots,
+ ext.cmd.data,
+ sizeof(QXLCursorCmd),
+ ext.group_id);
+qxl_process_cursor(worker, cursor_cmd, ext.group_id);
+break;
+case QXL_CMD_SURFACE:
+surface_cmd = (QXLSurfaceCmd *)get_virt(worker-mem_slots,
+ext.cmd.data,
+
sizeof(QXLSurfaceCmd),
+ext.group_id);
+red_process_surface(worker, surface_cmd, ext.group_id, 1);
+break;
+}
Maybe we want a default: here to catch any weird things happening with a
printf?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a leather-clad bohemian vagrant haunted by an iconic dead American
confidante She's a hard-bitten junkie schoolgirl with someone else's memories.
They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/35] new libspice-server API patches.
On Wed, 2010-05-12 at 13:31 +0200, Gerd Hoffmann wrote:
Hi,
Ok folks, here is what I have right now for review. The first patches
of the patch series has been posted already a while back. Now the
remaining issues have been addressed. Well, almost. Client migration
is not solved yet.
Most of the patches are pretty straight forward. A more careful review
is needed for the last six patches (30+). 30+31 are about savevm/loadvm
support for the qxl device. 32-35 are about client migration.
I reviewed the patches up to 31. Some minor issues were pointed out in
separate mails, but generally i think this looks good and should go in
now.
There are still some old references that we should try to get rid of:
vd_interface.h should be renamed. Maybe spice_interfaces.h?
Are these needed:
#define VM_INTERFACE_VERSION 1
typedef unsigned long VDObjectRef;
#define INVALID_VD_OBJECT_REF 0
typedef enum {
VD_LOG_ERROR = 1,
VD_LOG_WARN,
VD_LOG_INFO,
} LogLevel;
should be SPICE_LOG_foo?
typedef struct DrawArea {
This should probably be QxlDrawArea, since its a public header.
Do we need any of:
enum VDIArgType{
typedef struct VDIArgDescriptor {
typedef struct VDICmdArg {
typedef void (*VDICmdHandler)(const VDICmdArg* args);
typedef void (*VDIInfoCmdHandler)(void);
This seem to still not be converted to the new world:
VDObjectRef (*register_route_packet)(NetWireInterface *vlan,
net_wire_packet_route_proc_t proc,
void *opaque);
The patches 32-35 are largely untested and I'm not sure yet we'll really
want to go into that direction. So we might commit only patches 1-31
for now and wait with the client migration bits. Comments are welcome
nevertheless.
I have not looked at these yet, but given your comments above, lets land
the other parts first and move to the new qemu. Then we could put these
on a new branch.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's an underprivileged devious jungle king with no name. She's a warm-hearted
streetsmart magician's assistant from a family of eight older brothers. They
fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions on security.
On Mon, 2010-05-03 at 16:56 -0700, Robert Relyea wrote: Hi all, I've been asked to look at the security of the spice protocol. I've looked at the project a bit already and have a few potential things to talk about, but I wanted to understand some of the underlying assumptions before I get too far into it. Sorry for the late answer. We were a bit busy with team meetings and whatnot. First, I want to confirm that the protocol itself is not meant to be 'secure' (resistant to active and passive attacks) unless secured by some higher level channel protocol (like SSL). NOTE: this is not unusual, most internet protocols are not secured unless transported through a trusted pipe like SSL. -- It's usually considered better to use an existing security protocol for a transport than to create a brand new secure protocol from scratch. The chances of getting something wrong is pretty high even for security protocol experts. It depends on what you mean. Spice is a somewhat complex protocol that uses multiple tcp connections per client connection, so there is no simple layering of spice over ssl. However, spice itself does (optionally) support encrypting some or all of the channels using ssl. This all depends on how you launch/configure it. If it is meant to be secure, what types of attacks is it supposed to prevent without a secure channel? Is it, for instance, meant to have strong authentication? There will probably be some more questions depending on the answers to these. I couldn't find any security deployment guide (not surprising at this stage), which would answer these questions. I don't think we ever sat down and discussed this, but I think these are the kinds of things we expect spice to be robust against: * Software running inside the guest trying to attack the host that runs the guest os instance * When the client connects to the server there is some form of authentication so that not anyone can connect to a private guest instance. This is atm done via password set at the server side which the client must supply (i'm not sure how exactly this is implemented, i hope its not passing the password over the net) * When a client is active we (optionally) don't want anyone to be able listen to the data, or hijack the connection. This is done by allowing channels to be secured via ssl. * When we're migrating the guest os to another server we automatically have the client connect to the new server, and we need to ensure that the client doesn't connect to some rouge server but really to the same (migrated) guest. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an unconventional moralistic househusband from a doomed world. She's a transdimensional kleptomaniac research scientist who dreams of becoming Elvis. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 33/35] [debug] migration troubleshooting
On Wed, 2010-05-12 at 13:32 +0200, Gerd Hoffmann wrote: --- client/application.cpp |2 +- server/reds.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/client/application.cpp b/client/application.cpp index 4eb8ac8..74f5543 100644 --- a/client/application.cpp +++ b/client/application.cpp @@ -2110,7 +2110,7 @@ void Application::init_logger() } log4cpp::Category root = log4cpp::Category::getRoot(); -#ifdef RED_DEBUG +#if 1 // RED_DEBUG root.setPriority(log4cpp::Priority::DEBUG); root.removeAllAppenders(); root.addAppender(new log4cpp::FileAppender(_, fd)); diff --git a/server/reds.c b/server/reds.c index e499770..7a8cada 100644 --- a/server/reds.c +++ b/server/reds.c @@ -93,7 +93,7 @@ int agent_mouse = TRUE; static void openssl_init(); -#define MIGRATE_TIMEOUT (1000 * 10) /* 10sec */ +#define MIGRATE_TIMEOUT (1000 * 100) /* 10sec */ #define PING_INTERVAL (1000 * 10) #define KEY_MODIFIERS_TTL (1000 * 2) /*2sec*/ #define MM_TIMER_GRANULARITY_MS (1000 / 30) Uhm, You don't propose this for merging, do you? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly alcoholic cyborg looking for 'the Big One.' She's a supernatural out-of-work lawyer with an evil twin sister. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] C version of find_msb()
On Mon, 2010-05-03 at 11:30 +0200, Gerd Hoffmann wrote: Hi, This patch allows people to build the spice-client on any 32bit/64bit architecture, but it doesn't solve the endianess problems in the SPICE protocol itself. Has anyone looked into the network byte-ordering issues? spice protocol (on the wire) is defined to be little endian. Alexander Larsson is working on a marshaller/demarshaller for the spice network protocol, I think this will also handle endianness, i.e. byteswap the data if needed when parsing the data from the network into host structures. Yeah, this will be handled by the marshalling changes. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] C version of find_msb()
On Sat, 2010-05-01 at 22:25 -0600, Bryan Stillwell wrote: Recently I tried building the Ubuntu SPICE packages on powerpc and found that the spicec package fails on some x86 assembly code in common/gl_utils.h. This motivated me to create an optimized C version of the find_msb() function, which I've attached. This patch allows people to build the spice-client on any 32bit/64bit architecture, but it doesn't solve the endianess problems in the SPICE protocol itself. Has anyone looked into the network byte-ordering issues? Cool, i pushed this to git. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] libspice and save/restore/migration
Plan for unstable: (1) Keep surface metadata in device memory, i.e. delay the release of QXL_SURFACE_CMD_CREATE command until the surface is destroyed. (2) Keep the most recent QXL_CURSOR_SET command in device memory, i.e. delay the release until the next one comes in. (3) qemu/qxl keeps track of the active surfaces and the cursor (the later is required anyway for local rendering). Because of (1)+(2) it just needs to maintain pointers to the commands creating them. savevm: qxl saves surface+cursor state (no help from libspice needed). loadvm: qxl feeds libspice with the commands needed to restore state. This could be done using either the usual get_command() interface callbacks or with a new worker-loadvm_commands(cmdlist, count) call. This sounds good to me, although I haven't really looked much at migration in general. One thing it lacks is a way to extend it in the future, if we get more state that needs preserving in the future. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice in Fedora Rawhide?
On Wed, 2010-04-21 at 12:00 -0400, Matthew Miller wrote: Hi everyone. I've been following spice development casually, hopefully as a technology we can use for a big virtualization project in the next year or so. I notice that Spice is included in the RHEL 6 beta, which is very cool -- congratulations to everyone who worked on that. However, the state of things in the Fedora project is a little weak. There's a repo for Fedora 12, but it hasn't been updated in some time. What would it take to get Spice into Fedora Rawhide and updated with regular development snapshots? This would increase practical exposure significantly by making the technology easily available to a lot more testers. We're currently working heavily on getting spice into fedora. We've now dropped all the problematic dependencies (ffmpeg, forked cairo, etc) so we're in a much better state for his. The next major problem is that Fedora doesn't really accept leaf libraries (i.e. ones not used by an application), so we need to get the fedora qemu to use spice, which means we need to get upstream qemu to take patches for spice support. This work is led by Gerd Hoffmann and can be followed in this list. We hope to have patches that we can send to upstream qemu very soon. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an immortal ninja werewolf on the edge. She's a provocative motormouth magician's assistant married to the Mob. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Pixel format handling with offscreen surfaces
On Thu, 2010-04-15 at 02:12 +0300, Izik Eidus wrote:
On Wed, 14 Apr 2010 16:12:21 +0200
Alexander Larsson al...@redhat.com wrote:
enum {
SPICE_SURFACE_FMT_INVALID,
SPICE_SURFACE_FMT_1A,
SPICE_SURFACE_FMT_8A,
SPICE_SURFACE_FMT_16_555,
SPICE_SURFACE_FMT_16_565,
SPICE_SURFACE_FMT_32_xRGB,
SPICE_SURFACE_FMT_32_ARGB,
SPICE_SURFACE_FMT_32_Axxx,
};
So this thing is attached for bitmaps as well?
No, that would keep using SPICE_BITMAP_FMT_xxx i think, because there
are a bunch of image formats that we don't want to be able to support as
surface types, like the palette-based modes and the 24bit rgb mode
(these are fine for sending data over the network, but not very
efficient when used to draw to).
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] libjpeg performance
On Wed, 2010-04-14 at 09:33 +0300, Uri Lublin wrote: On 04/12/2010 09:57 PM, Alexander Larsson wrote: I did some simple testing of the new mjpeg encoder. Showing the youtube will it blend - ipad video i got quite better compression (24k per frame average as opposed to 35k before), but the code used a bit more cpu (9.8 msec per frame where it was 4.2 before). I made a simple change in the libjpeg code to make it a bit faster, but we might still be able to tweak this a bit in favour of performance rather than compression if thats what we want. Hi Alex, Nice. In client/mjpeg_decoder.cpp - decode_data(), there is a code that memmove data to the beginning of the buffer. Do you think we can gain better performance by actually implementing _cinfo.src functions ? This way we may be able to avoid (some) memory copying, e.g. by using a circular-buffer (and modulo calculation) or maybe even with no internal buffer. In current use we actually always pass an entire frame of data to decode_data() each time. I think rather than doing some fancy buffer work we could just special case that case and avoid copying data at all. i.e. if there is no existing data, just set _jsrc.next_input_byte to point to to data, and if not everything is copied (unlikely given the above), just copy the remainder into _data afterwards. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a gun-slinging coffee-fuelled inventor from the Mississippi delta. She's a bloodthirsty insomniac doctor from a different time and place. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Pixel format handling with offscreen surfaces
the actually used ones we'll get good performance anyway.
Then there is the question of destination surface format. For the
simple case of rgb32 vs argb32 it would be safe and not a large
performance cost to just always use argb32 for offscreen surfaces and
rgb32 for the primary surface. However, this is not enough when it
comes to e.g. 16bit surfaces. You really need to know if things are
555 or 565 when rendering. So, we need to specify the destination
format somehow.
First I thought about adding a new destination format to each
operation, but it feels like a bad idea for me. First of all most
operations don't need it (since they are bit specified), and secondly
its not something that in practice differs for each operation. As per
above, it'll basically be argb32 for all 32bit destinations always
(because you don't know when its safe to use only rgb32), and for
win32 drivers 16bit surfaces will always be 555 and on X i think we
should always make them 565 (and if some weird app uses 555 we'd
handle that in software fallbacks in X).
So, for destination format i propose that we add a format to each
surface that is set on construction, and is used when drawing *to* the
surface. So, something like:
typedef struct SPICE_ATTR_PACKED SpiceMsgSurfaceCreate {
uint32_t surface_id;
uint32_t width;
uint32_t height;
uint8_t depth;
uint8_t format; - new member
uint32_t flags;
uint32_t type;
} SpiceMsgSurfaceCreate;
BTW, what is the type member here used for? Seems unused.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a short-sighted zombie matador who knows the secret of the alien
invasion. She's a foxy insomniac soap star married to the Mob. They fight
crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Spice relicensed to LGPL 2.1 or later
I just commited a change of all header and copyright notices changing the license of spice to LGPL 2.1 or later. This includes the client program, because we want to convert much of that code into a library. We hope this will help make spice interesting to more people. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a jaded Catholic gangster with a passion for fast cars. She's an enchanted hip-hop stripper from out of town. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] New win32 binary set
We just added a new set of win32 dependency libraries for unstable spice at: http://spice-space.org/download.html This contains both the new dependencies (libjpeg and pixman 0.18.0), and removes the ones not needed anymore (ffmpeg) and some version updates (freetype). Furthermore all the libraries are rebuild with visual studio 2008, and both the release and the debug builds now build without any warnings. Some library name changed, so if you update to latest git master you need the new libraries in order to build. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an impetuous zombie paranormal investigator on the run. She's an artistic punk cab driver who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] spice for upstream qemu
On Wed, 2010-04-07 at 17:50 +0200, Gerd Hoffmann wrote:
Hi,
I'm busy fixing up the libspice-server API and preparing patches for
upstream qemu. The bits start to become usable now, so I've prepared
git trees for you to checkout.
spice bits:
http://cgit.freedesktop.org/~kraxel/spice/log/?h=api.v2
I like this a lot, some comments:
channel security cleanup:
+for (i = 0; i sizeof(names)/sizeof(names[0]); i++) {
Can use SPICE_N_ELEMENTS(names) here
Also, this is a change in behavior, SPICE_CHANNEL_NAME_ALL used to
set *all* channels to the new value, but this only changes the default
(i.e. whats used for channels that don't have a specific security set).
This is not necessarily a problem, but needs checking with the qemu side
so that it handles this correctly.
shlib major:
- -version-number $(SPICE_LT_VERSION) \
+ -version-number 1:0:0 \
This is not right. We should change configure.ac to have the right
libtool version style for SPICE_LT_VERSION, not hardcode it in the
Makefile.
MouseInterface: redesign:
-void (*moution)(MouseInterface* mouse, int dx, int dy, int dz,
+void (*moution)(SpiceMouseInstance *sin, int dx, int dy, int dz,
uint32_t buttons_state);
Its 'motion', please fix it while we can.
qemu bits:
http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/spice.v2
You also need a recent spice-protocol checkout for both and the usual
spice build dependencies. This is for unstable, so you need the
unstable guest drivers from the www.spice-space.org download section.
I can't really comment to much on this, since i don't know the qemu code
much, but this looks pretty nice and clean to me. Does it work with the
recent multi-surface code that izik commited this week?
We probably want izik to review this stuff.
I did notice this:
+ spice_proto_ver=$(pkg-config --modversion spice-protocol 2/dev/null)
+ spice_server_ver=$(pkg-config --modversion spice-server 2/dev/null)
+ spice_cflags=$(pkg-config --cflags spice-protocol spice-server 2/dev/null)
+ spice_libs=$(pkg-config --libs spice-protocol spice-server 2/dev/null)
+
+ spice_cflags=-I/export/git/work/spice/server/include $spice_cflags
+ spice_cflags=-L/export/git/work/spice/server/.libs $spice_cflags
+ spice_cflags=$spice_cflags -L/export/git/work/slirp/release
+ spice_libs=$spice_libs -lspice-server -lslirp
/export/git, eh?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a notorious moralistic househusband haunted by an iconic dead American
confidante She's a beautiful French-Canadian museum curator from beyond the
grave. They fight crime!
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] autoconf for slirp
On Fri, 2010-03-26 at 10:25 +1000, Dave Airlie wrote: this is quick and dirty, and not completely tested yet, but it makes my life a little bit easier, since I don't install stuff in /usr ever. I took this, cleaned it up and made it pass distcheck and commited. However, whats the general deal with us maintaining a copy of the slirp code from qemu? That code is in turn a cut and paste from an already existing (autoconf-using) upstream library at: http://slirp.sourceforge.net/ Why are we not using that? And if we have good reasons, why don't we call our copy something that does not conflict with the original package? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scrappy dishevelled waffle chef who hangs with the wrong crowd. She's a sarcastic green-skinned wrestler who can talk to animals. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] bilinear fast path
On Fri, 2010-03-12 at 16:18 +0100, Alexander Larsson wrote: I took this as a base and created a new branch that does fast scaling, achieving similar performance, and passing scaling-test. http://cgit.freedesktop.org/~alexl/pixman/log/?h=alex-scaler Based on this i also made a simple bilinear scaler. I get performace changes like: From: Scaling from 640x480 to 1152x864 in 13467 usec To: Scaling from 640x480 to 1152x864 in 11031 usec And even more for smaller scaling. Not extraordinary, but still a solid gain. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a gun-slinging albino astronaut from the 'hood. She's a strong-willed goth femme fatale operating on the wrong side of the law. They fight crime! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
