On Fri, Jul 05, 2013 at 08:35:21AM -0400, Yonit Halperin wrote:
> Ack. Thanks! We have recently associated this problem with some
> opened bugs we have. I believe Uri is working on a patch for a
> similar fix to the red_pipes.* routines in red_worker.
https://bugzilla.redhat.com/show_bug.cgi?id=88
Hi,
On 07/05/2013 06:07 PM, Fedor Lyakhov wrote:
Thanks for your answers!
Looks like the issue is more complicated than I originally thought. But I'm
still excited to continue working on it.
Ok, I'm going to follow Hans' view now.
Good.
One thing I don't understand: why would we want to ap
Thanks for your answers!
Looks like the issue is more complicated than I originally thought. But I'm
still excited to continue working on it.
Ok, I'm going to follow Hans' view now.
One thing I don't understand: why would we want to apply these 'effects'
settings via vdagentd (system level)? For
rhbz#968050
In contrast to Microsoft Msdn documentation, the iUniq of a SURFOBJ doesn't
always change when the surface changes. However, it seems that the
iUniq of the associated color_trans (XLATEOBJ) changes, while its
flXlate=XO_TRIVIAL. Since we tried to retrieve the alpha bitmap key
only by t
Hi,
On 07/05/2013 03:08 PM, Marc-André Lureau wrote:
hi
On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov wrote:
Hello everyone,
I continue working on this "bug62033 means to detect local only" issue, and
want to confirm whether I'm going in the right direction so the result can
be committed int
hi
On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov wrote:
> Hello everyone,
>
> I continue working on this "bug62033 means to detect local only" issue, and
> want to confirm whether I'm going in the right direction so the result can
> be committed into Spice.
> My plan is:
> 1. Announce capability
Hi,
On 07/05/2013 09:11 AM, David Gibson wrote:
Currently, both red_channel_pipes_add_type() and
red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not
safe versus removals from the ring within the loop body.
Thanks for the patch, applied and pushed.
Regards,
Hans
_
Hello everyone,
I continue working on this "bug62033 means to detect local only" issue, and
want to confirm whether I'm going in the right direction so the result can
be committed into Spice.
My plan is:
1. Announce capability of DisplayConfig by vdagentd, then receive
VDAgentDisplayConfig message
Ack. Thanks! We have recently associated this problem with some opened
bugs we have. I believe Uri is working on a patch for a similar fix to
the red_pipes.* routines in red_worker.
On 07/05/2013 03:11 AM, David Gibson wrote:
Currently, both red_channel_pipes_add_type() and
red_channel_pipes_
ack
- Mensaje original -
> For now this makes the usb-code even more of a #ifdef party (albeit only
> slightly so). But it does give us (theoretical, untested) usb support on
> Mac OS X, and once the libusb Windows backend also gets hotplug support, we
> can bump the required libusb versio
For now this makes the usb-code even more of a #ifdef party (albeit only
slightly so). But it does give us (theoretical, untested) usb support on
Mac OS X, and once the libusb Windows backend also gets hotplug support, we
can bump the required libusb version to a new enough one, and drop both the
w
Hi,
Thanks for the review!
On 07/05/2013 01:46 AM, Marc-André Lureau wrote:
Hi
On Thu, Jul 4, 2013 at 5:13 PM, Hans de Goede wrote:
+/* Can be called from both the main-thread as well as the event_thread */
+static int spice_usb_device_manager_hotplug_cb(libusb_context *ctx,
+
On Fri, Jul 05, 2013 at 05:11:46PM +1000, David Gibson wrote:
> Currently, both red_channel_pipes_add_type() and
> red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not
> safe versus removals from the ring within the loop body.
>
> Although it's rare, such a removal can occur in
Currently, both red_channel_pipes_add_type() and
red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not
safe versus removals from the ring within the loop body.
Although it's rare, such a removal can occur in both cases. In the case
of red_channel_pipes_add_type() we have:
r
14 matches
Mail list logo
