Re: [PATCH xrandr] Split verbose mode printing into a helper function
On 04/22/2015 12:10 AM, Kenneth Graunke wrote:
On Thursday, April 09, 2015 11:18:58 AM Aaron Plattner wrote:
Combine the two forms of verbose mode printing into a single function. Pass the
'current' and 'preferred' flags as arguments. This fixes the code that prints
unassociated modes to print the flags as well.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
---
xrandr.c | 62 ++
1 file changed, 30 insertions(+), 32 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 8a345427a226..5be2167d724f 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -566,7 +566,7 @@ mode_geometry (XRRModeInfo *mode_info, Rotation rotation,
/* v refresh frequency in Hz */
static double
-mode_refresh (XRRModeInfo *mode_info)
+mode_refresh (const XRRModeInfo *mode_info)
{
double rate;
double vTotal = mode_info-vTotal;
@@ -592,7 +592,7 @@ mode_refresh (XRRModeInfo *mode_info)
/* h sync frequency in Hz */
static double
-mode_hsync (XRRModeInfo *mode_info)
+mode_hsync (const XRRModeInfo *mode_info)
{
double rate;
@@ -603,6 +603,30 @@ mode_hsync (XRRModeInfo *mode_info)
return rate;
}
+static void print_verbose_mode (const XRRModeInfo *mode, Bool current,
+ Bool preferred)
+{
Seems like maybe static void should be on its own line, but I'm not
familiar with the coding style in xrandr.
Good catch.
This looks correct to me, looks like a nice cleanup, and printing the
flags seems sensible (though I've never read xrandr code before).
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Thanks! I'll get it checked in with the style thing fixed.
--
Aaron
___
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
[xserver PATCH] dix: Send KeyPress and KeyRelease events to the XACE_KEY_AVAIL hook
While it's documented in the XACE spec, the XACE_KEY_AVAIL hook is
currently never actually invoked by the xserver.
This hook was added in 13c6713c82 (25 Aug 2006), but as the keyboard
processing was moved into XKB, the hook was forgotten and silently
dropped. The code calling this hook was removed by 7af53799c (4 Jan
2009), but it was probably already unused before that.
This patch re-adds support for this hook. The count hook parameter is
unused.
Signed-off-by: Andrew Eikum aei...@codeweavers.com
---
I'm not intimately familiar with the xserver input code, but this seems
like a logical place to invoke this XACE hook. The various keyboard
devices call QueueKeyboardEvents, which places the events into a generic
input queue for sending to clients. So, I think this makes a decent
bottleneck through which we can expect all keyboard input events to
flow.
Updates to the XACE spec documentation for the count parameter will
follow, pending acceptance.
dix/getevents.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index d0a87f7..e18248f 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -51,6 +51,7 @@
#include inpututils.h
#include mi.h
#include windowstr.h
+#include xace.h
#include X11/extensions/XKBproto.h
#include xkbsrv.h
@@ -1058,9 +1059,24 @@ void
QueueKeyboardEvents(DeviceIntPtr device, int type,
int keycode)
{
-int nevents;
+int nevents, i;
nevents = GetKeyboardEvents(InputEventList, device, type, keycode);
+
+/* send KeyPress and KeyRelease events to XACE plugins */
+for (i = 0; i nevents; i++) {
+if (InputEventList[i].any.type == ET_KeyPress ||
+InputEventList[i].any.type == ET_KeyRelease) {
+xEvent *core;
+int count;
+
+if (EventToCore(InputEventList[i], core, count) == Success) {
+XaceHook(XACE_KEY_AVAIL, core, device, 0);
+free(core);
+}
+}
+}
+
queueEventList(device, InputEventList, nevents);
}
--
2.3.5
___
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] composite: Don't bother copying the pixmap for ForgetGravity windows
If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.
Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.
A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.
---
composite/compalloc.c | 94 ++-
1 file changed, 48 insertions(+), 46 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..70c83f0 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -542,54 +542,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
pPixmap-screen_x = x;
pPixmap-screen_y = y;
-if (pParent-drawable.depth == pWin-drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, val);
-ValidateGC(pPixmap-drawable, pGC);
-(*pGC-ops-CopyArea) (pParent-drawable,
- pPixmap-drawable,
- pGC,
- x - pParent-drawable.x,
- y - pParent-drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (pWin-bitGravity != ForgetGravity) {
+if (pParent-drawable.depth == pWin-drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, val);
+ValidateGC(pPixmap-drawable, pGC);
+(*pGC-ops-CopyArea) (pParent-drawable,
+ pPixmap-drawable,
+ pGC,
+ x - pParent-drawable.x,
+ y - pParent-drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
}
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
- pParent-drawable,
- pSrcFormat,
- CPSubwindowMode,
- inferiors,
- serverClient, error);
-
-PicturePtr pDstPicture = CreatePicture(None,
- pPixmap-drawable,
- pDstFormat,
- 0, 0,
- serverClient, error);
-
-if (pSrcPicture pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent-drawable.x,
- y - pParent-drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+ pParent-drawable,
+ pSrcFormat,
+ CPSubwindowMode,
+ inferiors,
+ serverClient, error);
+
+PicturePtr pDstPicture = CreatePicture(None,
+ pPixmap-drawable,
+ pDstFormat,
+ 0, 0,
+ serverClient, error);
+
+if (pSrcPicture pDstPicture) {
+CompositePicture(PictOpSrc,
+ pSrcPicture,
+ NULL,
+ pDstPicture,
+ x - pParent-drawable.x,
+ y - pParent-drawable.y, 0, 0, 0, 0, w, h);
+}
+if (pSrcPicture)
+FreePicture(pSrcPicture, 0);
+if (pDstPicture)
+
Re: [PATCH:lbxproxy] Ensure lbxMaxServers stays within a reasonable range
On 04/21/15 11:50 PM, Kenneth Graunke wrote: Never heard of this software before now :) Consider yourself lucky. I read up on it a bit; it sounds like hardly anyone actually uses it. Since the server side was dropped around Xorg 1.2 or so, there shouldn't be, but I know some distros/packagers still have the client side out of inertia, for talking to old servers. (I'm guilty of that, but it's on my list to remove in the next release. It's too late to remove it from Solaris 10 11 though, so this patch is a simple fix to quiet our static analysis for those.) I expect there are basically 0 users who want to proxy connections to more than 1024 X servers at a time. If there are, they should be able to start more than 1 instance of lbxproxy as a viable workaround. Or they can submit a patch. I'd agree with all of that. So, for what it's worth, Reviewed-by: Kenneth Graunke kenn...@whitecape.org Thanks. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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] xfree86: attempt to autoconfig gpu slave devices (v3)
On Tue, Apr 21, 2015 at 9:08 PM, Dave Airlie airl...@gmail.com wrote: On 1 April 2015 at 11:33, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This allows us to skip the screen section, the first Device section will get assigned to the screen, any remaining ones will get assigned to the GPUDevice sections for the screen. v2: fix the skipping unsuitable screen logic (Aaron) v3: fix segfault if not conf file (me, 5s after sending v2) Anyone care to r-b this? I'm not too familiar with the code in question, but the logic seems correct. Reviewed-by: Alex Deucher alexander.deuc...@amd.com Dave. ___ 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 ___ 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: glamor cleanups
On Tuesday, March 24, 2015 01:25:49 PM Eric Anholt wrote: Here are some documentation fixes and dead code removal from glamor, as well as a tiny patch from trying to figure out how some of the large pixmap code works. This can be found on the glamor-cleanups branch of my tree. Series is: Reviewed-by: Kenneth Graunke kenn...@whitecape.org 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] glamor: fix build when DRI3 is not defined
On Wednesday, April 15, 2015 09:29:58 PM Jonathan Gray wrote:
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
glamor/glamor_egl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 6033780..dc54561 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -595,6 +595,7 @@ glamor_egl_close_screen(ScreenPtr screen)
return screen-CloseScreen(screen);
}
+#ifdef DRI3
static int
glamor_dri3_open_client(ClientPtr client,
ScreenPtr screen,
@@ -651,12 +652,12 @@ static dri3_screen_info_rec glamor_dri3_info = {
.pixmap_from_fd = glamor_pixmap_from_fd,
.fd_from_pixmap = glamor_fd_from_pixmap,
};
+#endif /* DRI3 */
void
glamor_egl_screen_init(ScreenPtr screen, struct glamor_context *glamor_ctx)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
-glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
struct glamor_egl_screen_private *glamor_egl =
glamor_egl_get_screen_private(scrn);
@@ -668,7 +669,9 @@ glamor_egl_screen_init(ScreenPtr screen, struct
glamor_context *glamor_ctx)
glamor_ctx-make_current = glamor_egl_make_current;
+#ifdef DRI3
if (glamor_egl-dri3_capable) {
+ glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
/* Tell the core that we have the interfaces for import/export
* of pixmaps.
*/
@@ -691,6 +694,7 @@ glamor_egl_screen_init(ScreenPtr screen, struct
glamor_context *glamor_ctx)
}
}
}
+#endif
}
static void
Looks reasonable to me...
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
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:lbxproxy] Ensure lbxMaxServers stays within a reasonable range
On Thursday, April 16, 2015 10:15:41 PM Alan Coopersmith wrote:
Avoid opportunity for integer overflow when allocating servers array.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
di/utils.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/di/utils.c b/di/utils.c
index 7f7aa46..752d913 100644
--- a/di/utils.c
+++ b/di/utils.c
@@ -392,7 +392,11 @@ proxyProcessArgument(int argc, char **argv, int i)
if (strcmp (argv[i], -maxservers) == 0)
{
if (++i argc)
+ {
lbxMaxServers = atoi(argv[i]);
+ if (lbxMaxServers = 0 || lbxMaxServers 1024)
+ FatalError(out of range value for -maxservers);
+ }
else
ShowHelpAndExit (1);
return 2;
@@ -449,6 +453,8 @@ ProcessCommandLine(int argc, char *argv[])
*/
if ((env = getenv (LBXPROXY_MAXSERVERS)))
lbxMaxServers = atoi (env);
+if (lbxMaxServers = 0 || lbxMaxServers 1024)
+FatalError(out of range value for LBXPROXY_MAXSERVERS);
for ( i = 1; i argc; i++ )
{
Never heard of this software before now :) I read up on it a bit;
it sounds like hardly anyone actually uses it. I expect there are
basically 0 users who want to proxy connections to more than 1024 X
servers at a time. If there are, they should be able to start more
than 1 instance of lbxproxy as a viable workaround. Or they can
submit a patch.
So, for what it's worth,
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
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] glamor: remove const from the return type of glamor_get_drawable_location()
On Wednesday, April 15, 2015 09:29:07 PM Jonathan Gray wrote:
Fixes a build error with gcc 4.2.1 on OpenBSD due to
-Werror=return-type from xorg-macros.
error: type qualifiers ignored on function return type
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
glamor/glamor_core.c | 2 +-
glamor/glamor_priv.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 5517454..965024e 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -35,7 +35,7 @@
#include glamor_priv.h
-const Bool
+Bool
glamor_get_drawable_location(const DrawablePtr drawable)
{
PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 898a934..4b9ba4d 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -676,7 +676,7 @@ glamor_pixmap_fbo
*glamor_create_fbo_array(glamor_screen_private *glamor_priv,
void glamor_init_finish_access_shaders(ScreenPtr screen);
void glamor_fini_finish_access_shaders(ScreenPtr screen);
-const Bool glamor_get_drawable_location(const DrawablePtr drawable);
+Bool glamor_get_drawable_location(const DrawablePtr drawable);
void glamor_get_drawable_deltas(DrawablePtr drawable, PixmapPtr pixmap,
int *x, int *y);
GLint glamor_compile_glsl_prog(GLenum type, const char *source);
Indeed, returning const Bool is just silly :)
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
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 xrandr] Split verbose mode printing into a helper function
On Thursday, April 09, 2015 11:18:58 AM Aaron Plattner wrote:
Combine the two forms of verbose mode printing into a single function. Pass
the
'current' and 'preferred' flags as arguments. This fixes the code that prints
unassociated modes to print the flags as well.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
---
xrandr.c | 62 ++
1 file changed, 30 insertions(+), 32 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 8a345427a226..5be2167d724f 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -566,7 +566,7 @@ mode_geometry (XRRModeInfo *mode_info, Rotation rotation,
/* v refresh frequency in Hz */
static double
-mode_refresh (XRRModeInfo *mode_info)
+mode_refresh (const XRRModeInfo *mode_info)
{
double rate;
double vTotal = mode_info-vTotal;
@@ -592,7 +592,7 @@ mode_refresh (XRRModeInfo *mode_info)
/* h sync frequency in Hz */
static double
-mode_hsync (XRRModeInfo *mode_info)
+mode_hsync (const XRRModeInfo *mode_info)
{
double rate;
@@ -603,6 +603,30 @@ mode_hsync (XRRModeInfo *mode_info)
return rate;
}
+static void print_verbose_mode (const XRRModeInfo *mode, Bool current,
+ Bool preferred)
+{
Seems like maybe static void should be on its own line, but I'm not
familiar with the coding style in xrandr.
This looks correct to me, looks like a nice cleanup, and printing the
flags seems sensible (though I've never read xrandr code before).
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
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] Add amdgpu as a default driver for AMD GPUs
On 22.04.2015 00:51, Aaron Plattner wrote: Is there any chance you could use the new OutputClass match rules in /usr/share/X11/xorg.conf.d rather than adding to this list? Yes, that seems to work nicely. :) Thanks for the suggestion! This patch is retracted. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ 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
[PULL] Build fixes for MinGW
Hi Keith, A few patches to fix building Xserver using the MinGW-w64 toolchain. I'm not sure what the status is of releasing 1.18, so I can resend this after that is done, if you prefer. Please consider pulling into master. The following changes since commit b1029716e41e252f149b82124a149da180607c96: systemd-logind: don't second guess D-Bus default timeout (2015-04-17 10:57:48 -0700) are available in the git repository at: git://people.freedesktop.org/~jturney/xserver for you to fetch changes up to c7b49bdbb9321fe9a7dc35f47b91cac85516988f: os/utils.c: Fix prototype for Win32TempDir() (2015-04-22 12:55:32 +0100) Colin Harrison (3): os/xdmcp.c: Include Xtrans.h when building for WIN32 os/utils.c: Don't try to build os_move_fd() for WIN32 os/utils.c: Fix prototype for Win32TempDir() Jon TURNEY (2): hw/xwin/winclipboard: Link xwinclip with -lpthread hw/xnest: Fix build for MinGW hw/xnest/Keyboard.c | 4 hw/xwin/winclipboard/Makefile.am | 2 +- os/utils.c | 4 +++- os/xdmcp.c | 4 4 files changed, 12 insertions(+), 2 deletions(-) ___ 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
