Re: [Spice-devel] [PATCH] qxl_kms: read virtual monitor size from xorg.conf
Hi, On 06/09/2014 01:40 PM, Alon Levy wrote: > Signed-off-by: Alon Levy A better commit messages explaining the why, what and how of this patch would be nice. Regards, Hans > --- > src/qxl_kms.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/src/qxl_kms.c b/src/qxl_kms.c > index c31c62d..d952495 100644 > --- a/src/qxl_kms.c > +++ b/src/qxl_kms.c > @@ -164,8 +164,8 @@ Bool qxl_pre_init_kms(ScrnInfoPtr pScrn, int flags) > if (drmmode_pre_init(pScrn, &qxl->drmmode, pScrn->bitsPerPixel / 8) == > FALSE) >goto out; > > -qxl->virtual_x = 1024; > -qxl->virtual_y = 768; > +qxl->virtual_x = -1; > +qxl->virtual_y = -1; > > pScrn->display->virtualX = qxl->virtual_x; > pScrn->display->virtualY = qxl->virtual_y; > @@ -335,6 +335,9 @@ Bool qxl_screen_init_kms(SCREEN_INIT_ARGS_DECL) > if (!xf86CrtcScreenInit (pScreen)) > return FALSE; > > +qxl->virtual_x = pScrn->currentMode->HDisplay; > +qxl->virtual_y = pScrn->currentMode->VDisplay; > + > if (!qxl_resize_primary_to_virtual (qxl)) > return FALSE; > > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/09/2014 09:29 AM, Alon Levy wrote: On 06/09/2014 04:18 PM, David Mansfield wrote: On 06/09/2014 07:18 AM, Alon Levy wrote: On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) "We're too busy with RHEL 7/paying clients, come back in a month/some timeframe" b) "There's an SEP field on these problems, everyone who understands that code has moved on" c) "Go away" d) "Oops, I've been meaning to get back to you but I keep forgetting and life is hectic..." e) "Didn't you hear? SPICE is dead." f) "Other." Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. Hi Alon, I followed Marc-André's advice and sent these out to DRI ond xorg mailing lists, respectively. The qxl.ko patch was picked up by Dave Airlie and committed to drm-next branch. The second is still without a home. (BTW: An SEP is a "somebody else's problem" effect, see http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Missed that. Any possibility of help with issue #2, the xorg-devel list is silent on this one and I don't know who the maintainer is specifically. Without this patch xorg-qxl is trivially crashable when using dual head at 1920x1200 resolution (or potentially lower resolution). 96 relocs with 512x512 chunks - what do you do to crash it? Note each pass requires two relocs (and most call sites require at least one slot for themselves, too). So we have a maximum image size (at full DE width of 3840 pixels): (96/2) * 512 * 512 / 4 / 3840 = 819 pixels high. And mine is 1200 pixels high. So anything updating the entire 3840x1200 at once will crash. See below: Soren Sandmann is the maintainer, but I did a release once, I can commit it once I'm done testing (need to allow large resolutions which by default are limited to surface0_area_size). So there are two "easy" ways to crash. Both involve 1920x1200 dual head, which means (for me) editing the domain.xml: After this, I can crash if I launch "shutter" screenshot program, and click the "Selection" button. This button "grays out" the entire desktop and at this point it often crashes. If not the very first time then the second or third. Just keep clicking and pressing ESC and it'll crash for sure. NOTE: my environment is F20 guest, host and client - all on the same box. The other way is: after you set up dual head 1920x1200 then logout, shutdown (maybe not necessary), close remote-viewer then login again, and re-activate the second monitory window. As soon as the second monitor window is activated, gsd or something automatically "remembers" that both monitors should be 1920x1200, instead of 1024x768 or whatever, and crashes. It is customary practice here to remove ~/.config/monitors.xml before logging in to prevent this crash, because then the automatic re-sizing doesn't occur. This is with MATE (or xfce) desktop. Not sure about GNOME3 which re-orders the ioctl a bit and you may get lucky. NOTE2: To get dual head working properly for non-gnome3 you need the qxl.ko patch OR a patch to remote-viewer I sent out a while back or else the second monitor won't work properly. Thanks, David ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/09/2014 04:18 PM, David Mansfield wrote: > > On 06/09/2014 07:18 AM, Alon Levy wrote: >> On 06/03/2014 04:14 PM, David Mansfield wrote: >>> Bump. I'll make it easy. This is a multiple choice response form. >>> Anyone reading this can respond with one letter so save time and effort. >>> >>> a) "We're too busy with RHEL 7/paying clients, come back in a month/some >>> timeframe" >>> b) "There's an SEP field on these problems, everyone who understands >>> that code has moved on" >>> c) "Go away" >>> d) "Oops, I've been meaning to get back to you but I keep forgetting and >>> life is hectic..." >>> e) "Didn't you hear? SPICE is dead." >>> f) "Other." Please elaborate using the space provided below: >> The first patch looks good (just adjusting the #if to disable the >> print). I'll pick it up, thanks, you deserved a faster response. >> >> No idea what SEP is. > > Hi Alon, > > I followed Marc-André's advice and sent these out to DRI ond xorg > mailing lists, respectively. The qxl.ko patch was picked up by Dave > Airlie and committed to drm-next branch. > > The second is still without a home. > > (BTW: An SEP is a "somebody else's problem" effect, see > http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in > Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Missed that. > > Any possibility of help with issue #2, the xorg-devel list is silent on > this one and I don't know who the maintainer is specifically. Without > this patch xorg-qxl is trivially crashable when using dual head at > 1920x1200 resolution (or potentially lower resolution). > 96 relocs with 512x512 chunks - what do you do to crash it? Soren Sandmann is the maintainer, but I did a release once, I can commit it once I'm done testing (need to allow large resolutions which by default are limited to surface0_area_size). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/09/2014 07:18 AM, Alon Levy wrote: On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) "We're too busy with RHEL 7/paying clients, come back in a month/some timeframe" b) "There's an SEP field on these problems, everyone who understands that code has moved on" c) "Go away" d) "Oops, I've been meaning to get back to you but I keep forgetting and life is hectic..." e) "Didn't you hear? SPICE is dead." f) "Other." Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. Hi Alon, I followed Marc-André's advice and sent these out to DRI ond xorg mailing lists, respectively. The qxl.ko patch was picked up by Dave Airlie and committed to drm-next branch. The second is still without a home. (BTW: An SEP is a "somebody else's problem" effect, see http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Any possibility of help with issue #2, the xorg-devel list is silent on this one and I don't know who the maintainer is specifically. Without this patch xorg-qxl is trivially crashable when using dual head at 1920x1200 resolution (or potentially lower resolution). -- Thanks, David Mansfield Cobite, INC. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled
Signed-off-by: Alon Levy
---
src/qxl_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index b9aa0e9..d9bf447 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -1242,7 +1242,7 @@ qxl_init_scrn (ScrnInfoPtr pScrn, Bool kms)
pScrn->ValidMode= NULL;
}
-#ifdef XF86DRM_MODE
+#if defined(XF86DRM_MODE) && !defined(XSPICE)
static char *
CreatePCIBusID(const struct pci_device *dev)
{
--
1.9.3
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl_kms: read virtual monitor size from xorg.conf
Signed-off-by: Alon Levy --- src/qxl_kms.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/qxl_kms.c b/src/qxl_kms.c index c31c62d..d952495 100644 --- a/src/qxl_kms.c +++ b/src/qxl_kms.c @@ -164,8 +164,8 @@ Bool qxl_pre_init_kms(ScrnInfoPtr pScrn, int flags) if (drmmode_pre_init(pScrn, &qxl->drmmode, pScrn->bitsPerPixel / 8) == FALSE) goto out; -qxl->virtual_x = 1024; -qxl->virtual_y = 768; +qxl->virtual_x = -1; +qxl->virtual_y = -1; pScrn->display->virtualX = qxl->virtual_x; pScrn->display->virtualY = qxl->virtual_y; @@ -335,6 +335,9 @@ Bool qxl_screen_init_kms(SCREEN_INIT_ARGS_DECL) if (!xf86CrtcScreenInit (pScreen)) return FALSE; +qxl->virtual_x = pScrn->currentMode->HDisplay; +qxl->virtual_y = pScrn->currentMode->VDisplay; + if (!qxl_resize_primary_to_virtual (qxl)) return FALSE; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE
On 06/09/2014 02:20 PM, Marc-André Lureau wrote:
>
>
> - Original Message -
>> On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
>>> From: Marc-André Lureau
>>>
>>> When both the client and the agent advertize
>>> VD_AGENT_CAP_ANY_SELECTION_TYPE capability, the existing
>>> VDAgentClipboard messages are modified to embed string
>>> representation of the selection mime type.
>>>
>>> Handling arbitrary mime types allows to describe any selection data
>>> type, instead of a limited fixed list. The approach to reuse the integer
>>> representation to extend the type with a registry (like X's atoms) has
>>> been discarded (too complicated without substential benefits)
>>>
>>> A string is a \0 terminated utf8 byte array: foo\0
>>> A string[] is a \0\0 terminated array of utf8 strings: foo\0bar\0\0.
>>
>> So no null strings in the list? sounds fine to me (just need to verify
>> this in code).
>
> Yes, empty string are invalid here (of course, shouldn't crash anyway)
>
>> And the client will need to handle window system specific changes? or
>> can it pass the mime types on without looking at them?
>
> As long as the content is a MIME description-like, it can pass it.
>
> (some application or window system may use invalid MIME, but I consider this
> is not Spice to take care of, applications are flexible, they take what they
> handle best)
And such behaviour will just be 'bug compatible' under spice - ACK by me.
>
>>
>>> ---
>>> spice/vd_agent.h | 33 +++--
>>> 1 file changed, 23 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/spice/vd_agent.h b/spice/vd_agent.h
>>> index 7464661..2e24c87 100644
>>> --- a/spice/vd_agent.h
>>> +++ b/spice/vd_agent.h
>>> @@ -161,15 +161,6 @@ enum {
>>> VD_AGENT_ERROR,
>>> };
>>>
>>> -typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
>>> -#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
>>> -uint8_t selection;
>>> -uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
>>> -#endif
>>> -uint32_t type;
>>> -uint8_t data[0];
>>> -} VDAgentClipboard;
>>> -
>>> enum {
>>> VD_AGENT_CLIPBOARD_NONE = 0,
>>> VD_AGENT_CLIPBOARD_UTF8_TEXT,
>>> @@ -179,12 +170,29 @@ enum {
>>> VD_AGENT_CLIPBOARD_IMAGE_JPG, /* optional */
>>> };
>>>
>>> +typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
>>> +#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
>>> +uint8_t selection;
>>> +uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
>>> +#endif
>>> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
>>> +string type;
>>> +#else
>>> +uint32_t type;
>>> +#endif
>>> +uint8_t data[0];
>>> +} VDAgentClipboard;
>>> +
>>> typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
>>> #if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
>>> uint8_t selection;
>>> uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
>>> #endif
>>> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
>>> +string[] types;
>>> +#else
>>> uint32_t types[0];
>>> +#endif
>>> } VDAgentClipboardGrab;
>>>
>>> typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest {
>>> @@ -192,7 +200,11 @@ typedef struct SPICE_ATTR_PACKED
>>> VDAgentClipboardRequest {
>>> uint8_t selection;
>>> uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
>>> #endif
>>> -uint32_t type;
>>> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
>>> +string type;
>>> +#else
>>> +uint32_t type; /* string type; */
>>> +#endif
>>> } VDAgentClipboardRequest;
>>>
>>> typedef struct SPICE_ATTR_PACKED VDAgentClipboardRelease {
>>> @@ -218,6 +230,7 @@ enum {
>>> VD_AGENT_CAP_GUEST_LINEEND_LF,
>>> VD_AGENT_CAP_GUEST_LINEEND_CRLF,
>>> VD_AGENT_CAP_MAX_CLIPBOARD,
>>> +VD_AGENT_CAP_ANY_SELECTION_TYPE,
>>> VD_AGENT_END_CAP,
>>> };
>>>
>>>
>>
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE
- Original Message -
> On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
> > From: Marc-André Lureau
> >
> > When both the client and the agent advertize
> > VD_AGENT_CAP_ANY_SELECTION_TYPE capability, the existing
> > VDAgentClipboard messages are modified to embed string
> > representation of the selection mime type.
> >
> > Handling arbitrary mime types allows to describe any selection data
> > type, instead of a limited fixed list. The approach to reuse the integer
> > representation to extend the type with a registry (like X's atoms) has
> > been discarded (too complicated without substential benefits)
> >
> > A string is a \0 terminated utf8 byte array: foo\0
> > A string[] is a \0\0 terminated array of utf8 strings: foo\0bar\0\0.
>
> So no null strings in the list? sounds fine to me (just need to verify
> this in code).
Yes, empty string are invalid here (of course, shouldn't crash anyway)
> And the client will need to handle window system specific changes? or
> can it pass the mime types on without looking at them?
As long as the content is a MIME description-like, it can pass it.
(some application or window system may use invalid MIME, but I consider this
is not Spice to take care of, applications are flexible, they take what they
handle best)
>
> > ---
> > spice/vd_agent.h | 33 +++--
> > 1 file changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/spice/vd_agent.h b/spice/vd_agent.h
> > index 7464661..2e24c87 100644
> > --- a/spice/vd_agent.h
> > +++ b/spice/vd_agent.h
> > @@ -161,15 +161,6 @@ enum {
> > VD_AGENT_ERROR,
> > };
> >
> > -typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
> > -#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> > -uint8_t selection;
> > -uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> > -#endif
> > -uint32_t type;
> > -uint8_t data[0];
> > -} VDAgentClipboard;
> > -
> > enum {
> > VD_AGENT_CLIPBOARD_NONE = 0,
> > VD_AGENT_CLIPBOARD_UTF8_TEXT,
> > @@ -179,12 +170,29 @@ enum {
> > VD_AGENT_CLIPBOARD_IMAGE_JPG, /* optional */
> > };
> >
> > +typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
> > +#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> > +uint8_t selection;
> > +uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> > +#endif
> > +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> > +string type;
> > +#else
> > +uint32_t type;
> > +#endif
> > +uint8_t data[0];
> > +} VDAgentClipboard;
> > +
> > typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
> > #if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> > uint8_t selection;
> > uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> > #endif
> > +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> > +string[] types;
> > +#else
> > uint32_t types[0];
> > +#endif
> > } VDAgentClipboardGrab;
> >
> > typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest {
> > @@ -192,7 +200,11 @@ typedef struct SPICE_ATTR_PACKED
> > VDAgentClipboardRequest {
> > uint8_t selection;
> > uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> > #endif
> > -uint32_t type;
> > +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> > +string type;
> > +#else
> > +uint32_t type; /* string type; */
> > +#endif
> > } VDAgentClipboardRequest;
> >
> > typedef struct SPICE_ATTR_PACKED VDAgentClipboardRelease {
> > @@ -218,6 +230,7 @@ enum {
> > VD_AGENT_CAP_GUEST_LINEEND_LF,
> > VD_AGENT_CAP_GUEST_LINEEND_CRLF,
> > VD_AGENT_CAP_MAX_CLIPBOARD,
> > +VD_AGENT_CAP_ANY_SELECTION_TYPE,
> > VD_AGENT_END_CAP,
> > };
> >
> >
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/03/2014 04:14 PM, David Mansfield wrote: > Bump. I'll make it easy. This is a multiple choice response form. > Anyone reading this can respond with one letter so save time and effort. > > a) "We're too busy with RHEL 7/paying clients, come back in a month/some > timeframe" > b) "There's an SEP field on these problems, everyone who understands > that code has moved on" > c) "Go away" > d) "Oops, I've been meaning to get back to you but I keep forgetting and > life is hectic..." > e) "Didn't you hear? SPICE is dead." > f) "Other." Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. > > > On 05/27/2014 10:49 AM, David Mansfield wrote: >> >> On 05/19/2014 10:01 AM, David Mansfield wrote: >>> This patch series addresses two critical bugs that prevent dual-head >>> from working in a linux-linux environment. (All testing done on F20 >>> fully updated as guest, host and client). >>> >>> We (myself and a colleague) have been using patched versions of qxl.ko >>> and xorg-qxl for a week or so and these patches definitely solve the >>> problems addressed by the invididual patches. >>> >>> Patches are against F20 package source. >>> >>> Please consider reviewing/accepting these patches without which dual >>> head cannot be used(*) in linux. >>> >>> These patches or previous versions have been sent to the list but I >>> have not received any feedback. >>> >>> (*) by coincidence, dual head with small-ish monitor sizes does work >>> better on gnome3 than it does with other DE (ie. MATE or fluxbox) due >>> simply to luck in the order that the monitors/surfaces ioctl are >>> called, but not due to any design. >>> >> >> I've opened/updated the freedesktop.org bugs with these two patches >> and some commentary. It would be helpful if the maintainers of the >> respective code bases (qxl.ko and xorg-qxl) could comment on these two >> patches or at least a "resend in one month - we're really busy" or >> something. >> >> Bugs: >> >> Multiple monitors broken in desktops other than gnome3 : >> https://bugs.freedesktop.org/show_bug.cgi?id=78131 >> >> xorg crashes due to assert() when a large "image" is created : >> https://bugs.freedesktop.org/show_bug.cgi?id=79317 >> > > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE
On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
> From: Marc-André Lureau
>
> When both the client and the agent advertize
> VD_AGENT_CAP_ANY_SELECTION_TYPE capability, the existing
> VDAgentClipboard messages are modified to embed string
> representation of the selection mime type.
>
> Handling arbitrary mime types allows to describe any selection data
> type, instead of a limited fixed list. The approach to reuse the integer
> representation to extend the type with a registry (like X's atoms) has
> been discarded (too complicated without substential benefits)
>
> A string is a \0 terminated utf8 byte array: foo\0
> A string[] is a \0\0 terminated array of utf8 strings: foo\0bar\0\0.
So no null strings in the list? sounds fine to me (just need to verify
this in code).
And the client will need to handle window system specific changes? or
can it pass the mime types on without looking at them?
> ---
> spice/vd_agent.h | 33 +++--
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/spice/vd_agent.h b/spice/vd_agent.h
> index 7464661..2e24c87 100644
> --- a/spice/vd_agent.h
> +++ b/spice/vd_agent.h
> @@ -161,15 +161,6 @@ enum {
> VD_AGENT_ERROR,
> };
>
> -typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
> -#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> -uint8_t selection;
> -uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> -#endif
> -uint32_t type;
> -uint8_t data[0];
> -} VDAgentClipboard;
> -
> enum {
> VD_AGENT_CLIPBOARD_NONE = 0,
> VD_AGENT_CLIPBOARD_UTF8_TEXT,
> @@ -179,12 +170,29 @@ enum {
> VD_AGENT_CLIPBOARD_IMAGE_JPG, /* optional */
> };
>
> +typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
> +#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> +uint8_t selection;
> +uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> +#endif
> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> +string type;
> +#else
> +uint32_t type;
> +#endif
> +uint8_t data[0];
> +} VDAgentClipboard;
> +
> typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
> #if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
> uint8_t selection;
> uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> #endif
> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> +string[] types;
> +#else
> uint32_t types[0];
> +#endif
> } VDAgentClipboardGrab;
>
> typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest {
> @@ -192,7 +200,11 @@ typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest
> {
> uint8_t selection;
> uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
> #endif
> -uint32_t type;
> +#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
> +string type;
> +#else
> +uint32_t type; /* string type; */
> +#endif
> } VDAgentClipboardRequest;
>
> typedef struct SPICE_ATTR_PACKED VDAgentClipboardRelease {
> @@ -218,6 +230,7 @@ enum {
> VD_AGENT_CAP_GUEST_LINEEND_LF,
> VD_AGENT_CAP_GUEST_LINEEND_CRLF,
> VD_AGENT_CAP_MAX_CLIPBOARD,
> +VD_AGENT_CAP_ANY_SELECTION_TYPE,
> VD_AGENT_END_CAP,
> };
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] how to read the spice-server source code?
On 05/29/2014 11:16 AM, aaron_0119 wrote: > hi, > guys, i built the spice-gtk on an arm board(Contex A9). i test it and found > that it is not very smoothly when i playing the video. > so i decided to how the video streamer be transmitted or compressed between > the server and client. i try to read the source code but i found the > spice-server source code is very trival and hard to follow. > plz give me some suggestion to do this?which file should i read first?the > red_worker.c or the reds.c or others? > And If you have some idea to improve the performance of the client on ARM, > you can send it to me,too. > thx a lot~ > best regard to you ~ > Aaron Zhang red_worker contains the whole of the display channel logic, including video detection. Spice doesn't passthrough video streams from the app in the vm to the client, it recompresses decoded images using a heuristic (framerate / same area / large enough). mjpeg code is separate in mjpeg_encoder.c reds.c is the server itself, not interesting for you I think. Channel logic is in red_channel.c > > > > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] About rendering
Hi all， I am really curious about why spice client can draw the graphic window in linux just the same as it in Windows 7. QXL driver gets the drawing operations from GDI using the functions in drv_calls， and translates it to QXL command， which eventually sent to spice client and executed using cairo or X11. Why the graphic window cairo draws can be the same as GDI? I am not familiarly with graphic program, and hope anyone can illustrate it with more details, thank you very much. Thanks & Regards Li JiaMin ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
