Re: [PATCH xserver 1/2] Xi: Fix passive XI2 ungrabs on XIAll[Master]Devices
On Wed, Aug 31, 2011 at 12:46:52AM +0200, carl...@gnome.org wrote:
> From: Carlos Garnacho
>
> The corresponding DeviceIntPtr wasn't being gotten properly,
> resulting in BadDevice from dixLookupDevice().
>
> Signed-off-by: Carlos Garnacho
> ---
> Xi/xipassivegrab.c | 13 ++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Xi/xipassivegrab.c b/Xi/xipassivegrab.c
> index ae43433..5cdd8ac 100644
> --- a/Xi/xipassivegrab.c
> +++ b/Xi/xipassivegrab.c
> @@ -261,9 +261,16 @@ ProcXIPassiveUngrabDevice(ClientPtr client)
> REQUEST(xXIPassiveUngrabDeviceReq);
> REQUEST_AT_LEAST_SIZE(xXIPassiveUngrabDeviceReq);
>
> -rc = dixLookupDevice(&dev, stuff->deviceid, client, DixGrabAccess);
> -if (rc != Success)
> - return rc;
> +if (stuff->deviceid == XIAllDevices)
> +dev = inputInfo.all_devices;
> +else if (stuff->deviceid == XIAllMasterDevices)
> +dev = inputInfo.all_master_devices;
> +else
> +{
> +rc = dixLookupDevice(&dev, stuff->deviceid, client, DixGrabAccess);
> +if (rc != Success)
> + return rc;
> +}
>
> if (stuff->grab_type != XIGrabtypeButton &&
> stuff->grab_type != XIGrabtypeKeycode &&
> --
> 1.7.6
Merged into my -next branch, thanks
Cheers,
Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] Xi: Fix passive key grabs on XIAll[Master]Devices
On Wed, Aug 31, 2011 at 12:46:53AM +0200, carl...@gnome.org wrote:
> From: Carlos Garnacho
>
> The KeyClass is not set for these DeviceIntRec, but it's only used
> for XI1 grabs in order to check the XKB keycode range, and
> XIAll[Master]Devices doesn't apply there. So only spare the NULL
> check for XI grabs.
>
> Signed-off-by: Carlos Garnacho
> ---
> Xi/exevents.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Xi/exevents.c b/Xi/exevents.c
> index 3e3c67b..b279972 100644
> --- a/Xi/exevents.c
> +++ b/Xi/exevents.c
> @@ -1441,10 +1441,11 @@ GrabKey(ClientPtr client, DeviceIntPtr dev,
> DeviceIntPtr modifier_device,
> rc = CheckGrabValues(client, param);
> if (rc != Success)
> return rc;
> -if (k == NULL)
> - return BadMatch;
> if (grabtype == GRABTYPE_XI)
> {
> +if (k == NULL)
> +return BadMatch;
> +
this should have an additional check for the device ID, otherwise we'll
allow key grabs on slave pointers too.
Cheers,
Peter
> if ((key > k->xkbInfo->desc->max_key_code ||
> key < k->xkbInfo->desc->min_key_code)
> && (key != AnyKey)) {
> --
> 1.7.6
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] input: switch miPointerSetPosition to expect desktop-wide coordinates.
miPointerSetPosition traditionally took coordinates on a per-screen basis,
triggering a screen switch when these went out-of-bounds. Change it to take
desktop-coordinates instead and trigger screen switches when these coordinates
are not on the current screen.
This unifies the pointer behaviour of single ScreenRec multihead and
multiple ScreenRecs multihead in that the cursor by default moves about the
whole screen rather than be confined to one single screen. The transformation
matrix may then be used to actually confine the cursor to the screen again.
Signed-off-by: Peter Hutterer
---
Hints appreciated on how to make get_desktop_dimensions() more efficient.
Presumably this could be precalculated on screen changes only but frankly I
have no idea where to hook in here.
dix/getevents.c | 30 ++
mi/mipointer.c | 13 -
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index a0a26ce..7e9bd80 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -808,6 +808,21 @@ accelPointer(DeviceIntPtr dev, ValuatorMask* valuators,
CARD32 ms)
dev->valuator->accelScheme.AccelSchemeProc(dev, valuators, ms);
}
+static void
+get_desktop_dimensions(int *width, int *height)
+{
+int i;
+int w = 0, h = 0;
+for (i = 0; i < screenInfo.numScreens; i++) {
+ScreenPtr screen = screenInfo.screens[i];
+w = max(w, screen->x + screen->width);
+h = max(h, screen->y + screen->height);
+}
+
+*width = w;
+*height = h;
+}
+
/**
* If we have HW cursors, this actually moves the visible sprite. If not, we
* just do all the screen crossing, etc.
@@ -837,11 +852,14 @@ positionSprite(DeviceIntPtr dev, int mode,
ScreenPtr scr, int *screenx, int *screeny, float *screenx_frac,
float *screeny_frac)
{
int old_screenx, old_screeny;
+int w, h;
+
+get_desktop_dimensions(&w, &h);
-/* scale x&y to screen */
+/* scale x&y to whole desktop */
if (dev->valuator && dev->valuator->numAxes > 0) {
*screenx = rescaleValuatorAxis(*x, x_frac, screenx_frac,
-dev->valuator->axes + 0, NULL, scr->width);
+dev->valuator->axes + 0, NULL, w);
} else {
*screenx = dev->last.valuators[0];
*screenx_frac = dev->last.remainder[0];
@@ -849,7 +867,7 @@ positionSprite(DeviceIntPtr dev, int mode,
if (dev->valuator && dev->valuator->numAxes > 1) {
*screeny = rescaleValuatorAxis(*y, y_frac, screeny_frac,
-dev->valuator->axes + 1, NULL, scr->height);
+dev->valuator->axes + 1, NULL, h);
} else {
*screeny = dev->last.valuators[1];
*screeny_frac = dev->last.remainder[1];
@@ -1213,7 +1231,8 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
if (flags & POINTER_ABSOLUTE)
{
-if (flags & POINTER_SCREEN) /* valuators are in screen coords */
+/* valuators are in screen coords but relative to the screen */
+if (flags & POINTER_SCREEN)
{
int scaled;
@@ -1223,6 +1242,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
0.0, &x_frac, NULL,
pDev->valuator->axes + 0,
scr->width);
+scaled += scr->x; /* convert to desktop-wide coords */
valuator_mask_set(&mask, 0, scaled);
}
if (valuator_mask_isset(&mask, 1))
@@ -1231,6 +1251,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
0.0, &y_frac, NULL,
pDev->valuator->axes + 1,
scr->height);
+scaled += scr->y; /* convert to desktop-wide coords */
valuator_mask_set(&mask, 1, scaled);
}
}
@@ -1251,6 +1272,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
if ((flags & POINTER_NORAW) == 0)
set_raw_valuators(raw, &mask, raw->valuators.data);
+/* x/y are in desktop-wide coordinates */
positionSprite(pDev, (flags & POINTER_ABSOLUTE) ? Absolute : Relative,
&x, &y, x_frac, y_frac, scr, &sx, &sy, &sx_frac, &sy_frac);
updateHistory(pDev, &mask, ms);
diff --git a/mi/mipointer.c b/mi/mipointer.c
index 7680ca1..0e27808 100644
--- a/mi/mipointer.c
+++ b/mi/mipointer.c
@@ -580,6 +580,7 @@ miPointerSetPosition(DeviceIntPtr pDev, int mode, int *x,
int *y)
miPointerScreenPtr pScreenPriv;
ScreenPtr pScreen;
ScreenPtr newScreen;
+Bool switch_screen = FALSE;
miPointerPtrpPointer;
@@ -591,7 +592,17 @@ miPointerSetPosition(DeviceIntPtr pDev, int mode, int
[PATCH 1/2] Move pointOnScreen to inpututils.c
We need this from other files too.
Signed-off-by: Peter Hutterer
---
dix/events.c | 11 ++-
dix/inpututils.c |8
include/input.h |2 ++
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 8935ad9..199d115 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -498,13 +498,6 @@ SyntheticMotion(DeviceIntPtr dev, int x, int y) {
static void PostNewCursor(DeviceIntPtr pDev);
static Bool
-pointOnScreen(ScreenPtr pScreen, int x, int y)
-{
-return x >= pScreen->x && x < pScreen->x + pScreen->width &&
- y >= pScreen->y && y < pScreen->y + pScreen->height;
-}
-
-static Bool
XineramaSetCursorPosition(
DeviceIntPtr pDev,
int x,
@@ -523,13 +516,13 @@ XineramaSetCursorPosition(
x += screenInfo.screens[0]->x;
y += screenInfo.screens[0]->y;
-if(!pointOnScreen(pScreen, x, y))
+if(!point_on_screen(pScreen, x, y))
{
FOR_NSCREENS(i)
{
if(i == pScreen->myNum)
continue;
- if(pointOnScreen(screenInfo.screens[i], x, y))
+ if(point_on_screen(screenInfo.screens[i], x, y))
{
pScreen = screenInfo.screens[i];
break;
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 49e1758..0cecc62 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -37,6 +37,7 @@
#include "xkbstr.h"
#include "inpututils.h"
#include "eventstr.h"
+#include "scrnintstr.h"
/* Check if a button map change is okay with the device.
* Returns -1 for BadValue, as it collides with MappingBusy. */
@@ -584,3 +585,10 @@ void verify_internal_event(const InternalEvent *ev)
FatalError("Wrong event type %d. Aborting server\n", ev->any.header);
}
}
+
+Bool
+point_on_screen(ScreenPtr pScreen, int x, int y)
+{
+return x >= pScreen->x && x < pScreen->x + pScreen->width &&
+ y >= pScreen->y && y < pScreen->y + pScreen->height;
+}
diff --git a/include/input.h b/include/input.h
index 5377a0c..858d572 100644
--- a/include/input.h
+++ b/include/input.h
@@ -595,4 +595,6 @@ extern _X_EXPORT void valuator_mask_copy(ValuatorMask *dest,
const ValuatorMask *src);
extern _X_EXPORT int valuator_mask_get(const ValuatorMask *mask, int valnum);
+extern _X_HIDDEN Bool point_on_screen(ScreenPtr pScreen, int x, int y);
+
#endif /* INPUT_H */
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/2] Fixing screen crossing for Zaphod
Handling of multiple ScreenRecs is still an issue. We've had a problem for several years now where absolute devices get stuck on the right-most screen [1] This is basically just a scaling bug that can be fixed by extending the scaling range from 0...width to -1..width. This still gives us bad behaviour as the absolute device is then bound to the screen until it triggers the screen change - different to the behaviour of abs devices in RandR setups (device scaled to desktop). One of the problems this is obvious is if you have multi-headed Xephyr/Xnest/spice setups. You can't just move into window X and expect the pointer to be there, you'd need to trigger the screen change on each side first. So, patch 2 simply changes the screen scaling to desktop-with scaling, albeit not in the most efficient manner. This way the behaviour of absolute devices is the same as in RandR setups and we can then use the transformation matrix to bind to a specific screen. Cheers, Peter [1] https://bugs.freedesktop.org/show_bug.cgi?id=25182 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libXaw] Remove include directive to
On Thu, 2011-09-01 at 19:26 -0400, Gaetan Nadon wrote: > The -I directive to include/X11/Xaw is removed which will alert > developers not to include header files with quotes unless they are in > the /src directory. > > Currently no offending includes were found. > > Signed-off-by: Gaetan Nadon Tested-by: Yaakov Selkowitz Yaakov Cygwin/X ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXaw3d] Fix build after f28531a33d1f28bc86626b3013ef7857b564647f
From: Yaakov Selkowitz Signed-off-by: Yaakov Selkowitz --- src/laygram.y |2 +- src/laylex.l |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/laygram.y b/src/laygram.y index 1ac05a0..3644dd4 100644 --- a/src/laygram.y +++ b/src/laygram.y @@ -10,7 +10,7 @@ #include #include -#include"LayoutP.h" +#include #define yysetdest LayYYsetdest #define yywrap LayYYwrap diff --git a/src/laylex.l b/src/laylex.l index 8aa19ef..e357207 100644 --- a/src/laylex.l +++ b/src/laylex.l @@ -11,7 +11,7 @@ #include #include -#include"LayoutP.h" +#include #include"laygram.h" #define yylval LayYYlval -- 1.7.5.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libXaw3d: Changes to 'master'
On Thu, 2011-09-01 at 10:52 -0700, Gaetan Nadon wrote: > New commits: > commit daaa028c111276c3ba4d60b454f0fe39bf10666e > Author: Gaetan Nadon > Date: Tue Aug 30 22:06:36 2011 -0400 > > Add missing AC_CONFIG_HEADERS > > This is a requirement for all modules. > www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers > > Signed-off-by: Gaetan Nadon This commit causes a major problem; now none of the AC_DEFINEs (or the results of AC_CHECK_*) are seen by the source file because none of them #include "config.h". Either you need to add: #ifdef HAVE_CONFIG_H #include "config.h" #endif to the beginning of each source file, or revert commit daaa028c111276c3ba4d60b454f0fe39bf10666e. This is a release blocker. Yaakov Cygwin/X ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2 7/7] dix: NewCurrentScreen must work on pointers where possible
When a screen switch is triggered by PointerKeys, the device for
NewCurrentScreen is the keyboard. Submitting pointer events for this
keyboard (without valuators) has no effect as GPE ignores the event.
Force the dequeuing through the XTest device attached to this device.
Signed-off-by: Peter Hutterer
---
This patch replaces 6/7 and 7/7 of this series.
dix/events.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 6d37834..199d115 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3267,7 +3267,11 @@ WindowHasNewCursor(WindowPtr pWin)
void
NewCurrentScreen(DeviceIntPtr pDev, ScreenPtr newScreen, int x, int y)
{
-SpritePtr pSprite = pDev->spriteInfo->sprite;
+DeviceIntPtr ptr;
+SpritePtr pSprite;
+
+ptr = IsFloating(pDev) ? pDev : GetXTestDevice(GetMaster(pDev,
MASTER_POINTER));
+pSprite= ptr->spriteInfo->sprite;
pSprite->hotPhys.x = x;
pSprite->hotPhys.y = y;
@@ -3279,15 +3283,15 @@ NewCurrentScreen(DeviceIntPtr pDev, ScreenPtr
newScreen, int x, int y)
pSprite->screen = newScreen;
/* Make sure we tell the DDX to update its copy of the screen */
if(pSprite->confineWin)
- XineramaConfineCursorToWindow(pDev,
+ XineramaConfineCursorToWindow(ptr,
pSprite->confineWin, TRUE);
else
- XineramaConfineCursorToWindow(pDev,
screenInfo.screens[0]->root, TRUE);
+ XineramaConfineCursorToWindow(ptr, screenInfo.screens[0]->root,
TRUE);
/* if the pointer wasn't confined, the DDX won't get
told of the pointer warp so we reposition it here */
if(!syncEvents.playingEvents)
(*pSprite->screen->SetCursorPosition)(
- pDev,
+ ptr,
pSprite->screen,
pSprite->hotPhys.x + screenInfo.screens[0]->x -
pSprite->screen->x,
@@ -3297,7 +3301,7 @@ NewCurrentScreen(DeviceIntPtr pDev, ScreenPtr newScreen,
int x, int y)
} else
#endif
if (newScreen != pSprite->hotPhys.pScreen)
- ConfineCursorToWindow(pDev, newScreen->root, TRUE, FALSE);
+ ConfineCursorToWindow(ptr, newScreen->root, TRUE, FALSE);
}
#ifdef PANORAMIX
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXaw] Remove include directive to
The -I directive to include/X11/Xaw is removed which will alert
developers not to include header files with quotes unless they are in
the /src directory.
Currently no offending includes were found.
Signed-off-by: Gaetan Nadon
---
src/Makefile.am |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 3bc4b29..951dc26 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -60,7 +60,6 @@ COMMON_CFLAGS = \
COMMON_CPPFLAGS = \
-I${top_srcdir}/include \
- -I${top_srcdir}/include/X11/Xaw \
-DPROJECT_ROOT=\"$(prefix)\"
if BUILD_XAW6
--
1.7.4.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] RFCv2: video support for dri2
On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton wrote: > On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark wrote: >> To allow the potential use of overlays to display video content, a few >> extra parameters are required: >> >> + source buffer in different format (for example, various YUV formats) >> and size as compared to destination drawable >> + multi-planar formats where discontiguous buffers are used for >> different planes. For example, luma and chroma split across >> multiple memory banks or with different tiled formats. >> + flipping between multiple back buffers, perhaps not in order (to >> handle video formats with B-frames) >> + cropping during swap.. in case of video, perhaps the required hw >> buffers are larger than the visible picture to account for codec >> borders (for example, reference frames where a block/macroblock >> moves past the edge of the visible picture, but back again in >> subsequent frames). >> >> Current solutions use the GPU to do a scaled/colorconvert into a DRI2 >> buffer from the client context. The goal of this protocol change is >> to push the decision to use overlay or GPU blit to the xorg driver. >> >> In many cases, an overlay will avoid several passes through memory >> (blit/scale/colorconvert to DRI back-buffer on client side, blit to >> front and fake-front, and then whatever compositing is done by the >> window manager). On the other hand, overlays can often be handled >> directly by the scanout engine in the display hardware, with the GPU >> switched off. >> >> The disadvantages of overlays are that they are (usually) a limited >> resource, sometimes with scaling constraints, and certainly with >> limitations about transformational effects. >> >> The goal of combining video and dri2 is to have the best of both worlds, >> to have the flexibility of GPU blitting (ie. no limited number of video >> ports, no constraint about transformational effects), while still having >> the power consumption benefits of overlays (reduced memory bandwidth >> usage and ability to shut off the GPU) when the UI is relatively >> static other than the playing video. >> >> Note: video is not exactly the same as 3d, there are a number of other >> things to consider (scaling, colorconvert, multi-planar formats). But >> on the other hand the principle is similar (direct rendering from hw >> video codecs). And a lot infrastructure of connection, authentication, >> is same. So there are two options, either extend DRI2 or add a new >> protocol which duplicates some parts. I'd like to consider extending >> DRI2 first, but if people think the requirements for video are too >> much different from 3d, then I could split this into a new protocol. > > ... > >> +┌─── >> + DRI2SetAttribute >> + drawable: DRAWABLE >> + attribute: ATOM >> + value: INT32 >> + ▶ >> +└─── >> + Errors: Window, Match, Value >> + >> + The DRI2SetAttribute request sets the value of a drawable attribute. >> + The drawable attribute is identified by the attribute atom. The >> + following strings are guaranteed to generate valid atoms using the >> + InternAtom request. >> + >> + String Type >> + - >> + >> + "XV_ENCODING" ENCODINGID >> + "XV_HUE" [-1000..1000] >> + "XV_SATURATION" [-1000..1000] >> + "XV_BRIGHTNESS" [-1000..1000] >> + "XV_CONTRAST" [-1000..1000] >> + "XV_WIDTH" [0..MAX_INT] >> + "XV_HEIGHT" [0..MAX_INT] >> + "XV_OSD" XID >> + >> + If the given attribute doesn't match an attribute supported by the >> + drawable a Match error is generated. The supplied encoding >> + must be one of the encodings listed for the adaptor, otherwise an >> + Encoding error is generated. >> + >> + If the adaptor doesn't support the exact hue, saturation, >> + brightness, and contrast levels supplied, the closest levels >> + supported are assumed. The DRI2GetAttribute request can be used >> + to query the resulting levels. >> + >> + The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating >> + that no scaling is performed and the buffer sizes match the drawable >> + size. They can be overriden by the client if scaling is desired. >> + >> + The "XV_OSD" attribute specifies the XID of a pixmap containing >> + ARGB data to be non-destructively overlayed over the video. This >> + could be used to implement subtiles, on-screen-menus, etc. >> + >> + : TODO: Is there a need to support DRI2SetAttribute for non-video >> + : DRI2DRIVER types? >> + : >> + : TODO: Do we need to keep something like PortNotify.. if attributes >> + : are only changing in response to DRI2SetAttribute from the client, >> + : then having a PortNotify like mechanism seem
X.Org Developer's Conference: content needed
Two weeks from today, we should all be satisfied that we just spent three days at a useful, fun, and well-run X.Org Developer's Conference. However, in order to make that happen, we need your help! http://www.x.org/wiki/Events/XDC2011/Program currently does not have 3 days worth of content on it. Isn't there something you could add? We don't require abstracts, camera ready papers, or long writeups. All we require is a half hour to hour of talking (depending on what sort of slot you sign up for). You don't even have to do all the talking yourself - discussion sessions are accepted as well as presentation. Slides, demos or other visual aids are good, but also not required. Topics should be somehow related to X, Mesa, DRI, Wayland, or other usual suspects. Students may want to consider this a free chance to get experience in public speaking in a small friendly venue of people who already have some understanding of the subject matter. Attendees whose travel expenses are being subsidized by the X.Org Foundation should also remember that providing conference content is one of the best ways to show your appreciation for the chance to attend our conference. Any questions? There's lots of previous attendees on the mailing list and #xorg-devel IRC channel who can answer. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] RFCv2: video support for dri2
On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark wrote: > To allow the potential use of overlays to display video content, a few > extra parameters are required: > > + source buffer in different format (for example, various YUV formats) > and size as compared to destination drawable > + multi-planar formats where discontiguous buffers are used for > different planes. For example, luma and chroma split across > multiple memory banks or with different tiled formats. > + flipping between multiple back buffers, perhaps not in order (to > handle video formats with B-frames) > + cropping during swap.. in case of video, perhaps the required hw > buffers are larger than the visible picture to account for codec > borders (for example, reference frames where a block/macroblock > moves past the edge of the visible picture, but back again in > subsequent frames). > > Current solutions use the GPU to do a scaled/colorconvert into a DRI2 > buffer from the client context. The goal of this protocol change is > to push the decision to use overlay or GPU blit to the xorg driver. > > In many cases, an overlay will avoid several passes through memory > (blit/scale/colorconvert to DRI back-buffer on client side, blit to > front and fake-front, and then whatever compositing is done by the > window manager). On the other hand, overlays can often be handled > directly by the scanout engine in the display hardware, with the GPU > switched off. > > The disadvantages of overlays are that they are (usually) a limited > resource, sometimes with scaling constraints, and certainly with > limitations about transformational effects. > > The goal of combining video and dri2 is to have the best of both worlds, > to have the flexibility of GPU blitting (ie. no limited number of video > ports, no constraint about transformational effects), while still having > the power consumption benefits of overlays (reduced memory bandwidth > usage and ability to shut off the GPU) when the UI is relatively > static other than the playing video. > > Note: video is not exactly the same as 3d, there are a number of other > things to consider (scaling, colorconvert, multi-planar formats). But > on the other hand the principle is similar (direct rendering from hw > video codecs). And a lot infrastructure of connection, authentication, > is same. So there are two options, either extend DRI2 or add a new > protocol which duplicates some parts. I'd like to consider extending > DRI2 first, but if people think the requirements for video are too > much different from 3d, then I could split this into a new protocol. ... > +┌─── > + DRI2SetAttribute > + drawable: DRAWABLE > + attribute: ATOM > + value: INT32 > + ▶ > +└─── > + Errors: Window, Match, Value > + > + The DRI2SetAttribute request sets the value of a drawable attribute. > + The drawable attribute is identified by the attribute atom. The > + following strings are guaranteed to generate valid atoms using the > + InternAtom request. > + > + String Type > + - > + > + "XV_ENCODING" ENCODINGID > + "XV_HUE" [-1000..1000] > + "XV_SATURATION" [-1000..1000] > + "XV_BRIGHTNESS" [-1000..1000] > + "XV_CONTRAST" [-1000..1000] > + "XV_WIDTH" [0..MAX_INT] > + "XV_HEIGHT" [0..MAX_INT] > + "XV_OSD" XID > + > + If the given attribute doesn't match an attribute supported by the > + drawable a Match error is generated. The supplied encoding > + must be one of the encodings listed for the adaptor, otherwise an > + Encoding error is generated. > + > + If the adaptor doesn't support the exact hue, saturation, > + brightness, and contrast levels supplied, the closest levels > + supported are assumed. The DRI2GetAttribute request can be used > + to query the resulting levels. > + > + The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating > + that no scaling is performed and the buffer sizes match the drawable > + size. They can be overriden by the client if scaling is desired. > + > + The "XV_OSD" attribute specifies the XID of a pixmap containing > + ARGB data to be non-destructively overlayed over the video. This > + could be used to implement subtiles, on-screen-menus, etc. > + > + : TODO: Is there a need to support DRI2SetAttribute for non-video > + : DRI2DRIVER types? > + : > + : TODO: Do we need to keep something like PortNotify.. if attributes > + : are only changing in response to DRI2SetAttribute from the client, > + : then having a PortNotify like mechanism seems overkill. The > assumption > + : here is that, unlike Xv ports, DRI2 video drawables are not a limited > + : resource (ie. if you run out of (or
[PATCH] RFCv2: video support for dri2
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are used for
different planes. For example, luma and chroma split across
multiple memory banks or with different tiled formats.
+ flipping between multiple back buffers, perhaps not in order (to
handle video formats with B-frames)
+ cropping during swap.. in case of video, perhaps the required hw
buffers are larger than the visible picture to account for codec
borders (for example, reference frames where a block/macroblock
moves past the edge of the visible picture, but back again in
subsequent frames).
Current solutions use the GPU to do a scaled/colorconvert into a DRI2
buffer from the client context. The goal of this protocol change is
to push the decision to use overlay or GPU blit to the xorg driver.
In many cases, an overlay will avoid several passes through memory
(blit/scale/colorconvert to DRI back-buffer on client side, blit to
front and fake-front, and then whatever compositing is done by the
window manager). On the other hand, overlays can often be handled
directly by the scanout engine in the display hardware, with the GPU
switched off.
The disadvantages of overlays are that they are (usually) a limited
resource, sometimes with scaling constraints, and certainly with
limitations about transformational effects.
The goal of combining video and dri2 is to have the best of both worlds,
to have the flexibility of GPU blitting (ie. no limited number of video
ports, no constraint about transformational effects), while still having
the power consumption benefits of overlays (reduced memory bandwidth
usage and ability to shut off the GPU) when the UI is relatively
static other than the playing video.
Note: video is not exactly the same as 3d, there are a number of other
things to consider (scaling, colorconvert, multi-planar formats). But
on the other hand the principle is similar (direct rendering from hw
video codecs). And a lot infrastructure of connection, authentication,
is same. So there are two options, either extend DRI2 or add a new
protocol which duplicates some parts. I'd like to consider extending
DRI2 first, but if people think the requirements for video are too
much different from 3d, then I could split this into a new protocol.
---
dri2proto.txt | 133 -
1 files changed, 131 insertions(+), 2 deletions(-)
diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..92f85a4 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
6. Protocol Types
DRI2DRIVER { DRI2DriverDRI
-DRI2DriverVDPAU }
+DRI2DriverVDPAU,
+DRI2DriverXV }
These values describe the type of driver the client will want
to load. The server sends back the name of the driver to use
@@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
These values describe various attachment points for DRI2
buffers.
+ In the case of video driver (DRI2DriverXV) the attachment,
+ other than DRI2BufferFrontLeft, just indicates buffer
+ number and has no other special significance. There is no
+ automatic maintenance of DRI2BufferFakeFrontLeft.
+
DRI2BUFFER { attachment: CARD32
name: CARD32
pitch: CARD32
@@ -201,7 +207,8 @@ DRI2ATTACH_FORMAT { attachment: CARD32
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
- 'format' describes an opaque, device-dependent format for the buffer.
+ 'format' describes an opaque, device-dependent format for the buffer,
+ or a fourcc for non-device-dependent formats.
⚙ ⚙ ⚙ ⚙ ⚙ ⚙
@@ -440,6 +447,97 @@ The name of this extension is "DRI2".
DRI2SwapBuffers requests to swap at most once per interval frames,
which is useful useful for limiting the frame rate.
+┌───
+DRI2SetAttribute
+ drawable: DRAWABLE
+ attribute: ATOM
+ value: INT32
+ ▶
+└───
+ Errors: Window, Match, Value
+
+ The DRI2SetAttribute request sets the value of a drawable attribute.
+ The drawable attribute is identified by the attribute atom. The
+ following strings are guaranteed to generate valid atoms using the
+ InternAtom request.
+
+ StringType
+ -
+
+ "XV_ENCODING" ENCODINGID
+ "XV_HUE" [-1000..1000]
+ "XV_SATURATION" [-1000..1000]
+ "XV_BRIGHTNESS" [-1000..1000]
+ "XV_CONTRAST" [-1000..1000]
+ "XV_WIDTH"[0..MAX_INT]
Re: [PATCH libXaw3d 0/5] Fix old-style function definitions, round three
On Wed, Aug 31, 2011 at 10:12 PM, Yaakov (Cygwin/X) wrote: > From: Yaakov Selkowitz > > This completes my work in fixing all the old-style function definitions, > and some other warnings which these fixes exposed. The code is *much* > cleaner now; it should be a lot easier for others to help fix the > remaining warnings. > > Yaakov Selkowitz (5): > MultiSink: Fix old-style function definitions > MultiSrc: Fix old-style function definitions > XawIm: Fix old-style function definitions > Fix incompatible vfunc pointer warnings > Label: Fix nested extern declaration warnings > > src/AsciiSink.c | 23 +++--- > src/Label.c | 3 +- > src/MultiSink.c | 106 +- > src/MultiSrc.c | 128 > src/Vendor.c | 12 ++-- > src/Viewport.c | 4 +- > src/XawIm.c | 221 ++ > 7 files changed, 194 insertions(+), 303 deletions(-) > > -- > 1.7.5.1 Acked-by: Matt Turner ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libXaw3d 0/5] Fix old-style function definitions, round three
On Wed, 2011-08-31 at 21:12 -0500, Yaakov (Cygwin/X) wrote: > Yaakov Selkowitz (5): > MultiSink: Fix old-style function definitions > MultiSrc: Fix old-style function definitions > XawIm: Fix old-style function definitions > > Acked-by: Gaetan Nadon signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/7] Fix PointerKeys crash on switching ScreenRec
On Thu, 1 Sep 2011 20:41:23 +1000, Peter Hutterer wrote: > Either way, 7/7 is the key here, the others just make sure to avoid future > similar cases like this. This one of the issues listed in > https://bugs.freedesktop.org/show_bug.cgi?id=38313 Would it be cleaner to make NewCurrentScreen accept the keyboard device and get the associated pointer device itself? -- keith.pack...@intel.com pgploDQcj4Qhb.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 7/7] mi: add special handling for keyboard events on switching screens.
When a screen switch is triggered by PointerKeys, the device for
NewCurrentScreen is the keyboard. Submitting pointer events for this
keyboard (without valuators) has no effect as GPE ignores the event.
Force the dequeuing through the XTest device attached to this device.
Signed-off-by: Peter Hutterer
---
I've made this commit for the 1.10 branch, so for master I'll replace the
IsFloating() blah blah with the new GetMaster(POINTER_OR_FLOAT).
mi/mieq.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/mi/mieq.c b/mi/mieq.c
index 3a5aaf0..f13e264 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -350,6 +350,7 @@ CopyGetMasterEvent(DeviceIntPtr sdev,
static void
switch_screen(DeviceIntPtr dev, InternalEvent *event, ScreenPtr screen)
{
+DeviceIntPtr ptr;
int x = 0, y = 0;
switch (event->any.type)
@@ -357,19 +358,22 @@ switch_screen(DeviceIntPtr dev, InternalEvent *event,
ScreenPtr screen)
/* Catch events that include valuator information and check if they
* are changing the screen */
case ET_Motion:
-case ET_KeyPress:
-case ET_KeyRelease:
case ET_ButtonPress:
case ET_ButtonRelease:
-DequeueScreen(dev) = screen;
-x = event->device_event.root_x;
-y = event->device_event.root_y;
-NewCurrentScreen (dev, DequeueScreen(dev), x, y);
+ptr = dev;
+break;
+case ET_KeyPress:
+case ET_KeyRelease:
+ptr = IsFloating(dev) ? dev : GetXTestDevice(GetMaster(dev,
MASTER_POINTER));
break;
default:
return;
}
+x = event->device_event.root_x;
+y = event->device_event.root_y;
+DequeueScreen(ptr) = screen;
+NewCurrentScreen (ptr, DequeueScreen(ptr), x, y);
}
/**
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 6/7] mi: move switching screen on dequeue to separate helper function
Signed-off-by: Peter Hutterer
---
mi/mieq.c | 47 ---
1 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/mi/mieq.c b/mi/mieq.c
index fc3738a..3a5aaf0 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -347,6 +347,30 @@ CopyGetMasterEvent(DeviceIntPtr sdev,
return mdev;
}
+static void
+switch_screen(DeviceIntPtr dev, InternalEvent *event, ScreenPtr screen)
+{
+int x = 0, y = 0;
+
+switch (event->any.type)
+{
+/* Catch events that include valuator information and check if they
+ * are changing the screen */
+case ET_Motion:
+case ET_KeyPress:
+case ET_KeyRelease:
+case ET_ButtonPress:
+case ET_ButtonRelease:
+DequeueScreen(dev) = screen;
+x = event->device_event.root_x;
+y = event->device_event.root_y;
+NewCurrentScreen (dev, DequeueScreen(dev), x, y);
+break;
+default:
+return;
+}
+
+}
/**
* Post the given @event through the device hierarchy, as appropriate.
@@ -359,7 +383,6 @@ mieqProcessDeviceEvent(DeviceIntPtr dev,
ScreenPtr screen)
{
mieqHandler handler;
-int x = 0, y = 0;
DeviceIntPtr master;
InternalEvent mevent; /* master event */
@@ -368,24 +391,10 @@ mieqProcessDeviceEvent(DeviceIntPtr dev,
/* Custom event handler */
handler = miEventQueue.handlers[event->any.type];
-switch (event->any.type) {
-/* Catch events that include valuator information and check if they
- * are changing the screen */
-case ET_Motion:
-case ET_KeyPress:
-case ET_KeyRelease:
-case ET_ButtonPress:
-case ET_ButtonRelease:
-if (dev && screen && screen != DequeueScreen(dev) && !handler) {
-DequeueScreen(dev) = screen;
-x = event->device_event.root_x;
-y = event->device_event.root_y;
-NewCurrentScreen (dev, DequeueScreen(dev), x, y);
-}
-break;
-default:
-break;
-}
+
+if (dev && screen && screen != DequeueScreen(dev) && !handler)
+switch_screen(dev, event, screen);
+
master = CopyGetMasterEvent(dev, event, &mevent);
if (master)
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/7] dix: warn about keyboard events with valuator masks
We don't actually handle the mask correctly. They're clipped and dropped
into the event but that's about it. I don't think we did since 1.4, let's
warn the user if this happens.
Signed-off-by: Peter Hutterer
---
dix/getevents.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index 33847d0..a0a26ce 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -987,6 +987,11 @@ GetKeyboardEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
(key_code < 8 || key_code > 255))
return 0;
+if (valuator_mask_size(mask_in) > 1) {
+ErrorF("[dix] the server does not handle valuator masks with "
+"keyboard events. This is a bug. You may fix it.\n");
+}
+
num_events = 1;
events = UpdateFromMaster(events, pDev, DEVCHANGE_KEYBOARD_EVENT,
&num_events);
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/7] dix: fill out root_x/y for keyboard events
Switching screens relies on rootx/y to be set to the correct value. Though
we technically take a mask for GetKeyboardEvents we don't actually handle it
properly anyway, so this hack is acceptable for now. This should really be
shared code with GPE but not today.
Signed-off-by: Peter Hutterer
---
dix/getevents.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index 08c6269..33847d0 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1033,6 +1033,16 @@ GetKeyboardEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
set_valuators(pDev, event, &mask);
+/* FIXME: this should really be common code with GetPointerEvents */
+if (!IsFloating(pDev)) {
+ DeviceIntPtr master = GetMaster(pDev, MASTER_POINTER);
+
+ event->root_x = master->last.valuators[0];
+ event->root_y = master->last.valuators[1];
+ event->root_x_frac = master->last.remainder[0];
+ event->root_y_frac = master->last.remainder[0];
+}
+
return num_events;
}
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/7] dix: don't allow keyboard devices to submit motion or button events.
GPE unconditionally dereferences pDev->valuator if a mask is present. This
shouldn't really happen but if it does, don't crash, just ignore the events
with an error.
Signed-off-by: Peter Hutterer
---
dix/getevents.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index 511c96c..08c6269 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1158,6 +1158,11 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
switch (type)
{
case MotionNotify:
+if (!pDev->valuator)
+{
+ErrorF("[dix] motion events from device %d without
valuators\n", pDev->id);
+return 0;
+}
if (!mask_in || valuator_mask_num_valuators(mask_in) <= 0)
return 0;
break;
@@ -1165,6 +1170,11 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type, int buttons
case ButtonRelease:
if (!pDev->button || !buttons)
return 0;
+if (valuator_mask_size(mask_in) > 0 && !pDev->valuator)
+{
+ErrorF("[dix] button event with valuator from device %d
without valuators\n", pDev->id);
+return 0;
+}
break;
default:
return 0;
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/7] dix: rename cx/cy into sx/sy in GetPointerEvents.
cx/cy are legacy names (core x, core y). These days, sx/sy is more descriptive and less confusing. Signed-off-by: Peter Hutterer --- dix/getevents.c | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index 6a5ff51..511c96c 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -1143,8 +1143,8 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr pDev, int type, int buttons DeviceEvent *event; RawDeviceEvent*raw; int x = 0, y = 0, /* device coords */ -cx, cy; /* only screen coordinates */ -float x_frac = 0.0, y_frac = 0.0, cx_frac, cy_frac; +sx, sy; /* only screen coordinates */ +float x_frac = 0.0, y_frac = 0.0, sx_frac, sy_frac; ScreenPtr scr = miPointerGetScreen(pDev); ValuatorMask mask; @@ -1227,7 +1227,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr pDev, int type, int buttons set_raw_valuators(raw, &mask, raw->valuators.data); positionSprite(pDev, (flags & POINTER_ABSOLUTE) ? Absolute : Relative, - &x, &y, x_frac, y_frac, scr, &cx, &cy, &cx_frac, &cy_frac); + &x, &y, x_frac, y_frac, scr, &sx, &sy, &sx_frac, &sy_frac); updateHistory(pDev, &mask, ms); /* Update the valuators with the true value sent to the client*/ @@ -1257,10 +1257,10 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr pDev, int type, int buttons event->detail.button = buttons; } -event->root_x = cx; /* root_x/y always in screen coords */ -event->root_y = cy; -event->root_x_frac = cx_frac; -event->root_y_frac = cy_frac; +event->root_x = sx; /* root_x/y always in screen coords */ +event->root_y = sy; +event->root_x_frac = sx_frac; +event->root_y_frac = sy_frac; set_valuators(pDev, event, &mask); -- 1.7.6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/7] dix: update comments for moveAbsolute and moveRelative
These functions don't actually move anything, they just calculate x/y and clip into ranges Signed-off-by: Peter Hutterer --- dix/getevents.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index a12462a..6a5ff51 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -707,11 +707,12 @@ UpdateFromMaster(InternalEvent* events, DeviceIntPtr dev, int type, int *num_eve } /** - * Move the device's pointer to the position given in the valuators. + * Set x and y to the clipped position given in the valuators. x and y are + * in device coordinates. * * @param dev The device which's pointer is to be moved. - * @param x Returns the x position of the pointer after the move. - * @param y Returns the y position of the pointer after the move. + * @param x Returns the x position in device coordinates after the move. + * @param y Returns the y position in device coordinates after the move. * @param mask Bit mask of valid valuators. * @param valuators Valuator data for each axis between @first and *@first+@num. @@ -745,11 +746,13 @@ moveAbsolute(DeviceIntPtr dev, int *x, int *y, ValuatorMask *mask) } /** - * Move the device's pointer by the values given in @valuators. + * Move x,y to by the values given in valuators. x and y are + * in device coordinates, taking in to account the last position of this + * device. * * @param dev The device which's pointer is to be moved. - * @param x Returns the x position of the pointer after the move. - * @param y Returns the y position of the pointer after the move. + * @param x Returns the x position in device coordinates after the move. + * @param y Returns the y position in device coordinates after the move. * @param mask Bit mask of valid valuators. * @param valuators Valuator data for each axis between @first and *@first+@num. -- 1.7.6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/7] Fix PointerKeys crash on switching ScreenRec
Test case: 1) xorg.conf for two ScreenRecs 2) enable PointerKeys, move with keypad 4/6 across screens 3) Boom one of the above is a bug, even though RandR purists will argue that both 1 and 3 are not supposed to happen.. Either way, 7/7 is the key here, the others just make sure to avoid future similar cases like this. This one of the issues listed in https://bugs.freedesktop.org/show_bug.cgi?id=38313 Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: randr: stop immutable output properties from being deleted (v2)
On 08/24/2011 01:26 AM, Luc Verhaegen wrote: On Wed, Aug 24, 2011 at 12:19:58AM +0200, Luc Verhaegen wrote: This version of the server side patch now no longer mangles the output properties list directly. This incurs a slight bit of overhead, in what is an extremely low frequency path anyway. It also fixes the error thrown in case the property does not exist for the listed output, to match QueryOutputProperty. The new version of the randrproto.txt patch now fixes the two issues daniels spotted and now fully documents all the errors that RRDeleteOutputProperty might throw. Luc Verhaegen. From master this applied to the n9's xserver 1.9.5 tree cleanly, and was built and tested succesfully. Luc Verhaegen. Bumping this thread up because I'd like to see these changes committed. Reviewed-by: Rami Ylimäki ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
