Re: [PATCH xf86-video-vmware] vmwgfx: Use new DRI2 AuthMagic3 for xwayland
Good Morning,
I forgot to CC the vmware driver maintainer. Is this reply with
added CC ok or resubmit as v2?
Thanks,
Othmar Pasteka
On Sun, May 05, 2013 at 08:29:36PM +0200, Othmar Pasteka wrote:
Update for
http://cgit.freedesktop.org/xorg/xserver/commit/?h=xwayland-1.12id=e4566c049c7b385e2307fef3c72ef61762729f42
based on
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?h=xwaylandid=bb4e7c69349ae1ea6aca36977e0d01bea2966564
Signed-off-by: Othmar Pasteka past...@kabsi.at
---
This is for the xwayland branch.
Built and tested in a vmware player guest with wayland git.
vmwgfx/vmwgfx_dri2.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/vmwgfx/vmwgfx_dri2.c b/vmwgfx/vmwgfx_dri2.c
index a53cadd..b6a4480 100644
--- a/vmwgfx/vmwgfx_dri2.c
+++ b/vmwgfx/vmwgfx_dri2.c
@@ -373,7 +373,7 @@ dri2_copy_region(DrawablePtr pDraw, RegionPtr pRegion,
}
#ifdef XORG_WAYLAND
-static int dri2_auth_magic2(ScreenPtr pScreen, uint32_t magic)
+static int dri2_auth_magic3(ClientPtr client, ScreenPtr pScreen, uint32_t
magic)
{
ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
modesettingPtr ms = modesettingPTR(pScrn);
@@ -383,7 +383,7 @@ static int dri2_auth_magic2(ScreenPtr pScreen, uint32_t
magic)
return drmAuthMagic(ms-fd, magic);
/* Forward the request to our host */
-return xwl_drm_authenticate(ms-xwl_screen, magic);
+return xwl_drm_authenticate(client, ms-xwl_screen, magic);
}
#endif
@@ -435,7 +435,7 @@ xorg_dri2_init(ScreenPtr pScreen)
#ifdef XORG_WAYLAND
dri2info.version = 3;
-dri2info.AuthMagic2 = dri2_auth_magic2;
+dri2info.AuthMagic3 = dri2_auth_magic3;
#endif
return DRI2ScreenInit(pScreen, dri2info);
--
1.7.10.4
___
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 for compose key sequences J with acute
On 2013-02-20 17:28, James Cloos wrote: One quick review note: Per 10646 and unicode, that miniscule sequence should be U+006A U+0301 j́ and not U+0237 U+0303 ȷ́. Do you mean (only fix in tyop in quote of my proposal): U+006A U+0301 j́ and not U+0237 U+0301 ȷ́. I just noticed that on bitmap fonts such as the command line, one still sees the dot of the j or a j followed by a filled diamond shape. The i and j are defined to have soft dots; all combining sequence starting with either MUST ignore the dot on the base character. Not all font/rendering engines tuples get this right, but they should, and searches et al probably expect j́. So indeed there is some work on the rendering part. Attached is a new patch with you improvement. Does anyone would like to have the reverse order supported and/or dead keys supported for this? Could someone sign off patch 0.2 and add it to the repo? See also http://lists.x.org/archives/xorg-devel/2013-February/035544.html -JimC Regards, Pander ___ 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
MultiThreaded Xorg Server?
I am concentrating on performance of Xorg server for several months. I found that it seemed Dispatch() in dix/dispatch.c could be multi threaded, say, the event and request handling might be handled by several threads. Was it possible? Or it might not be as easy as it looks like? Thanks for your attention.___ 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
(Crowd funded) fix for SiS 671/771 video cards
Hi all, Since a few months the driver for SiS 671/771 video cards is no longer working in main stream distributions such as Ubuntu. This is affecting many users and I would like to ask the development community of Xorg who would like to fix this issue. For the details please see these bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=15190 and: https://bugs.launchpad.net/debian/+source/xserver-xorg-video-sis/+bug/301958 Since the number of users waiting for a fix is in the thousands, I am sure that some sort of crowd funding such as: https://www.catincan.com/proposal/altdrag/altdrag-10 might be possible. I am more than happy to make a financial contribution in order to not having to write off some still good hardware. I am sure many others are willing to chip in. Who would be interested in taking this on? Regards, Pander ___ 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: MultiThreaded Xorg Server?
On 05/ 6/13 01:36 AM, 小飞珑 wrote: I am concentrating on performance of Xorg server for several months. I found that it seemed Dispatch() in dix/dispatch.c could be multi threaded, say, the event and request handling might be handled by several threads. Was it possible? Or it might not be as easy as it looks like? Thanks for your attention. Making over a million lines of code thread-safe, plus all the loadable driver modules - both open closed source, doesn't look even remotely easy. There were experiments with multithreaded servers in the early 90's, in which I believe they found most operations simply ended up waiting on the lock for the graphics hardware - perhaps the different mix of operations today would have different results, but it's still not an easy task to try to find out. -- -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: [git pull] fifth times a charm
Dave Airlie airl...@gmail.com writes: Aaron Plattner (1): xfree86: don't enable anything in xf86InitialConfiguration for GPU screens Dave Airlie (8): randr: don't directly set changed bits in randr screen randr: make SetChanged modify the main protocol screen not the gpu screen randr: only respected changed on the protocol screen randr: report changes when we disconnect a GPU slave dix/gpu: remove asserts for output/offload from same slave xf86crtc: don't use scrn-display for gpu screens dix: allow pixmap dirty helper to be used for non-shared pixmaps gpu: call CreateScreenResources for GPU screens Merged. 451ba4b..dbfeaf7 master - master -- keith.pack...@intel.com pgpclUFOXiRrT.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 xaw3d 1/2] Fix --disable-feature options in configure
Make --disable-feature options passed to configure not enable
the feature but keep it disabled instead.
Signed-off-by: Javier Pello javier.pe...@urjc.es
---
configure.ac | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index a38ce7ff..32e21e97 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,18 +47,29 @@ fi
AM_CONDITIONAL(XAW_INTERNATIONALIZATION, [test x$XAW_I18N = xyes])
AC_ARG_ENABLE([multiplane-bitmaps],
-[AS_HELP_STRING([--enable-multiplane-bitmaps], dnl
- [enable XPM support])],
+[AS_HELP_STRING([--enable-multiplane-bitmaps], [enable XPM support])],
+[],
+[enable_multiplane_bitmaps=no])
+
+AS_IF([test x$enable_multiplane_bitmaps != xno],
[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_MULTIPLANE_PIXMAPS dnl
PKG_CHECK_MODULES(XPM, xpm)])
AC_ARG_ENABLE([gray-stipples],
-[AS_HELP_STRING([--enable-gray-stipples], dnl
- [enable gray stipples])], [XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS}
-DXAW_GRAY_BLKWHT_STIPPLES])
+[AS_HELP_STRING([--enable-gray-stipples], [enable gray stipples])],
+[],
+[enable_gray_stipples=no])
+
+AS_IF([test x$enable_gray_stipples != xno],
+[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_GRAY_BLKWHT_STIPPLES])
AC_ARG_ENABLE([arrow-scrollbars],
-[AS_HELP_STRING([--enable-arrow-scrollbars], dnl
- [enable arrow scrollbars])], [XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS}
-DXAW_ARROW_SCROLLBARS])
+[AS_HELP_STRING([--enable-arrow-scrollbars], [enable arrow scrollbars])],
+[],
+[enable_arrow_scrollbars=no])
+
+AS_IF([test x$enable_arrow_scrollbars != xno],
+[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_ARROW_SCROLLBARS])
AC_SUBST(XAW3D_CPPFLAGS)
--
1.8.2
___
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 xaw3d 2/2] Restore recording of build options in Xaw3dP.h
Xaw3d 1.5 had special magic in Imakefile to record the options
with which the library was built (internationalization, xpm support,
gray stipples, arrow scrollbars) in Xaw3dP.h, but this was lost in
commits 892b45fdb681a18c7ecaf456457fd7e4c588998d and
85bdcab66a56ca93a7eee0eadf12a90056dfa41d. Restore this behaviour by
making Xaw3dP.h be generated at configure time, so that old packages
continue to build against newer libXaw3d.
Signed-off-by: Javier Pello javier.pe...@urjc.es
---
.gitignore | 1 +
configure.ac| 12
include/Makefile.am | 4 +++-
include/X11/Xaw3d/{Xaw3dP.h = Xaw3dP.h.in} | 8
4 files changed, 16 insertions(+), 9 deletions(-)
rename include/X11/Xaw3d/{Xaw3dP.h = Xaw3dP.h.in} (94%)
diff --git a/.gitignore b/.gitignore
index 2f10f060..c569ad9a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -76,3 +76,4 @@ core
# Edit the following section as needed
# For example, !report.pc overrides *.pc. See 'man gitignore'
#
+include/X11/Xaw3d/Xaw3dP.h
diff --git a/configure.ac b/configure.ac
index 32e21e97..59e0fb72 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,7 @@ AC_PREREQ([2.60])
AC_INIT([libXaw3d], [1.6.2],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXaw3d])
AC_CONFIG_SRCDIR([Makefile.am])
-AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_HEADERS([config.h include/X11/Xaw3d/Xaw3dP.h])
# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
@@ -43,6 +43,7 @@ AC_ARG_ENABLE([internationalization],
[XAW_I18N=$enableval], [XAW_I18N=yes])
if test x$XAW_I18N = xyes; then
XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_INTERNATIONALIZATION
+AC_DEFINE([XAW_INTERNATIONALIZATION], [], [I18n support])
fi
AM_CONDITIONAL(XAW_INTERNATIONALIZATION, [test x$XAW_I18N = xyes])
@@ -52,7 +53,8 @@ AC_ARG_ENABLE([multiplane-bitmaps],
[enable_multiplane_bitmaps=no])
AS_IF([test x$enable_multiplane_bitmaps != xno],
- [XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_MULTIPLANE_PIXMAPS dnl
+[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_MULTIPLANE_PIXMAPS
+ AC_DEFINE([XAW_MULTIPLANE_PIXMAPS], [], [XPM support])
PKG_CHECK_MODULES(XPM, xpm)])
AC_ARG_ENABLE([gray-stipples],
@@ -61,7 +63,8 @@ AC_ARG_ENABLE([gray-stipples],
[enable_gray_stipples=no])
AS_IF([test x$enable_gray_stipples != xno],
-[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_GRAY_BLKWHT_STIPPLES])
+[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_GRAY_BLKWHT_STIPPLES
+ AC_DEFINE([XAW_GRAY_BLKWHT_STIPPLES], [], [gray stipples])])
AC_ARG_ENABLE([arrow-scrollbars],
[AS_HELP_STRING([--enable-arrow-scrollbars], [enable arrow scrollbars])],
@@ -69,7 +72,8 @@ AC_ARG_ENABLE([arrow-scrollbars],
[enable_arrow_scrollbars=no])
AS_IF([test x$enable_arrow_scrollbars != xno],
-[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_ARROW_SCROLLBARS])
+[XAW3D_CPPFLAGS=${XAW3D_CPPFLAGS} -DXAW_ARROW_SCROLLBARS
+ AC_DEFINE([XAW_ARROW_SCROLLBARS], [], [arrow scrollbars])])
AC_SUBST(XAW3D_CPPFLAGS)
diff --git a/include/Makefile.am b/include/Makefile.am
index 56824af6..1fa77345 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -1,5 +1,8 @@
xaw3dincludedir=${includedir}/X11/Xaw3d
+nodist_xaw3dinclude_HEADERS = \
+ X11/Xaw3d/Xaw3dP.h
+
if XAW_INTERNATIONALIZATION
I18N_HDRS = \
X11/Xaw3d/MultiSrc.h \
@@ -78,7 +81,6 @@ xaw3dinclude_HEADERS = \
X11/Xaw3d/TreeP.h \
X11/Xaw3d/Viewport.h \
X11/Xaw3d/ViewportP.h \
- X11/Xaw3d/Xaw3dP.h \
X11/Xaw3d/XawInit.h \
$(I18N_HDRS)
diff --git a/include/X11/Xaw3d/Xaw3dP.h b/include/X11/Xaw3d/Xaw3dP.h.in
similarity index 94%
rename from include/X11/Xaw3d/Xaw3dP.h
rename to include/X11/Xaw3d/Xaw3dP.h.in
index 9082fbff..d2f8af25 100644
--- a/include/X11/Xaw3d/Xaw3dP.h
+++ b/include/X11/Xaw3d/Xaw3dP.h.in
@@ -33,10 +33,10 @@ CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#include X11/IntrinsicP.h
/* These are set during the build to reflect capability and options. */
-/* I18n support */
-/* XPM support */
-/* gray stipples */
-/* arrow scrollbars */
+#undef XAW_INTERNATIONALIZATION
+#undef XAW_MULTIPLANE_PIXMAPS
+#undef XAW_GRAY_BLKWHT_STIPPLES
+#undef XAW_ARROW_SCROLLBARS
#ifndef XtX
#define XtX(w) (((RectObj)w)-rectangle.x)
--
1.8.2
___
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 xaw3d 0/2] Xaw3d build system
I am attaching a couple of patches to the Xaw3d build system.
The first patch deals with a bug when running configure. Xaw3d has
several optional features (multiplane bitmaps, gray stipples, arrow
scrollbars), disabled by default, that can be selected at configure
time via --enable-foo switches. However, if you pass an explicit
--disable-foo switch, configure will actually *enable* the feature,
which, in my opinion, breaks the principle of least astonishment.
The first patch corrects this.
The second patch restores recording of such compilation options in
Xaw3dP.h. In 1.5, features selected at configure time (multiplane
bitmaps, etc.) were recorded as defines in Xaw3dP.h, so packages
compiling against Xaw3d could check those defines by including
Xaw3dP.h to see what features were enabled. This has now changed,
and, as I understand it, detection of optional features should be
done by the additional -Dfoo flags reported by `pkgconfig --cflags
xaw3d`. This, however, breaks compilation of old packages against
version 1.6, since they no longer find the defines where they expect
them to be (in Xaw3dP.h), and know nothing about a .pc file. It would
be nice (and easy) to keep backwards API compatibility for those old
packages by restoring the defines in Xaw3dP.h.
Javier Pello (2):
Fix --enable-feature options in configure
Restore recording of build options in Xaw3dP.h
.gitignore | 1 +
configure.ac| 31 +
include/Makefile.am | 4 +++-
include/X11/Xaw3d/{Xaw3dP.h = Xaw3dP.h.in} | 8
4 files changed, 31 insertions(+), 13 deletions(-)
rename include/X11/Xaw3d/{Xaw3dP.h = Xaw3dP.h.in} (94%)
--
1.8.2
___
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: [PULL] hw/xwin warning fixes
Jon TURNEY jon.tur...@dronecode.org.uk writes: Jon TURNEY (10): hw/xwin: Fix unused-but-set-variable warnings in windialog.c hw/xwin: Fix unused-but-set-variable warning in winIsFakeCtrl_L() hw/xwin: Fix unused-but-set-variable warning in winFinishScreenInitFB() hw/xwin: Fix unused-but-set-variable warning in winCopyWindowNativeGDI() hw/xwin: Fix unused-but-set-variable warning in winWindowProc() hw/xwin: Fix unused-but-set-variable warning in winClipboardProc() hw/xwin: Fix unused-but-set-variable warning in winMinimizeWindow() when built !XWIN_MULTIWINDOWEXTWM hw/xwin: Fix unused-but-set-variable warning in winHotKeyAltTabPrimaryDD() hw/xwin: Fix unused-but-set-variable warning in winMWExtWMUpdateWindowDecoration() hw/xwin: Fix unused-but-set-variable warning in ProcWindowsWMFrameGetRect() Merged. dbfeaf7..1e6cf8e master - master -- keith.pack...@intel.com pgpsOr2q_f9yv.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
Re: [PULL: xserver master] cppcheck fixes (bug #50281) build fix for non-udev systems
Alan Coopersmith alan.coopersm...@oracle.com writes: Alan Coopersmith (6): __glXDRIscreenCreateContext: free context on failure, instead of leaking it __glXDRIscreenProbe: free screen when DRI2Connect fails, instead of leaking it dmxVDLRead: if we opened a file, close it instead of leaking it xf86SbusCmapLoadPalette: Delay malloc until needed, avoiding leak on error sparcPromPathname2Node: free name when returning error, instead of leaking it Only call xf86platformVTProbe() when it's defined Merged. 1e6cf8e..2746c68 master - master -- keith.pack...@intel.com pgpE2gL3CQTJY.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
Re: [git pull] GPU hotplugging fixes
Dave Airlie airl...@gmail.com writes: It would be a pointless ABI break at this point. Not ABI, just API, but even still, probably not worth it. -- keith.pack...@intel.com pgpicFhB8eiN_.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
Re: [PULL] unreviewed patches
Peter Hutterer peter.hutte...@who-t.net writes: Xi: fix comment - XI2 grabs aren't keysym grabs Reviewed-by: Keith Packard kei...@keithp.com dix: send the current axis value in DeviceChangedEvents (#62321) Reviewed-by: Keith Packard kei...@keithp.com Xi: always return BadMatch for XTest devices ChangeDeviceControl requests (this appears to cover all of the DDX entry points to avoid passing XTest devices to them) Reviewed-by: Keith Packard kei...@keithp.com If neither HAL nor udev backends are enabled, warn the user Reviewed-by: Keith Packard kei...@keithp.com xkb: free XkbRulesUsed and XkbRulesDflt on extension cleanup I think this should be done in CloseDownDevices -- XkbDeleteRulesDflts is already called there, adding a call to your new XkbDeleteRulesUsed (which looks fine, btw) seems like the right plan. Delete callbacks when extension are closed dix: delete all callbacks before reset Looks like the second patch makes the first unnecessary? dix: reset the registry before quitting Reviewed-by: Keith Packard kei...@keithp.com os: support pnprintf length modifiers for integers Reviewed-by: Keith Packard kei...@keithp.com os: support %% in pnprintf Reviewed-by: Keith Packard kei...@keithp.com os: support %c in pnprintf Reviewed-by: Keith Packard kei...@keithp.com os: complain about unsupported pnprintf directives Reviewed-by: Keith Packard kei...@keithp.com os: Use ErrorFSigSafe from FatalError and it's friends Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgpVlFS_pnwl0.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
Re: [PATCH] xrandr: calloc XRRModeInfo's passed to libXrandr.
On 05/02/2013 06:16 PM, Alan Coopersmith wrote: On 05/ 2/13 01:20 AM, Andy Ritger wrote: The --newmode commandline option initializes an XRRModeInfo and passes it into XRRCreateMode(). calloc(3) it to avoid uninitialized fields. For consistency, calloc(3) all the places where umode_t's (the wrapper structure for XRRModeInfo) are allocated. Signed-off-by: Andy Ritger arit...@nvidia.com Tested-by: Nikhil Mahale nmah...@nvidia.com Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com Pushed to ssh://git.freedesktop.org/git/xorg/app/xrandr eb17ad8..ace5e2b master - master -- 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
Re: [PATCH] xrandr: allow disconnecting of offload and outputs
Maybe use None instead of 0 for the XIDs? I'm not too offended by the
zeros there, so
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
Tested-by: Aaron Plattner aplatt...@nvidia.com
Thanks for sending this out -- sorry I didn't get around to it last week.
On 05/02/2013 05:05 PM, Dave Airlie wrote:
Before the lookup code passing a 0 XID would disconnect,
this fixes it backup.
Signed-off-by: Dave Airlie airl...@redhat.com
---
xrandr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 305308c..d5727b2 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -2446,6 +2446,8 @@ find_provider (name_t *name)
{
int i;
+if ((name-kind name_xid) name-xid == 0)
+ return NULL;
for (i = 0; i num_providers; i++) {
provider_t *p = providers[i];
name_kind_t common = name-kind p-provider.kind;
@@ -3228,7 +3230,7 @@ main (int argc, char **argv)
provider = find_provider (provider_name);
source = find_provider(output_source_provider_name);
- XRRSetProviderOutputSource(dpy, provider-provider.xid,
source-provider.xid);
+ XRRSetProviderOutputSource(dpy, provider-provider.xid, source ?
source-provider.xid : 0);
}
if (provsetoffsink)
{
@@ -3243,7 +3245,7 @@ main (int argc, char **argv)
provider = find_provider (provider_name);
sink = find_provider(offload_sink_provider_name);
- XRRSetProviderOffloadSink(dpy, provider-provider.xid,
sink-provider.xid);
+ XRRSetProviderOffloadSink(dpy, provider-provider.xid, sink ?
sink-provider.xid : 0);
}
if (setit_1_2)
{
--
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
Re: [PATCH] xfree86: detach scanout pixmaps when detaching output GPUs
On 05/05/2013 04:23 PM, Dave Airlie wrote: On Thu, May 2, 2013 at 5:55 AM, Aaron Plattner aplatt...@nvidia.com wrote: On 04/30/2013 11:30 PM, Dave Airlie wrote: On Wed, May 1, 2013 at 7:14 AM, Aaron Plattner aplatt...@nvidia.com wrote: Commit 8f4640bdb9d3988148e09a08d2c7e3bab1d538d6 fixed a bit of a chicken-and-egg problem by detaching GPU screens when their providers are destroyed, which happens before CloseScreen is called. However, this created a new problem: the GPU screen tears down its RandR crtc objects during CloseScreen and if one of them is active, it tries to detach the scanout pixmap then. This crashes because RRCrtcDetachScanoutPixmap tries to get the master screen's screen pixmap, but crtc-pScreen-current_master is already NULL at that point. It doesn't make sense for an unbound GPU screen to still be scanning out its former master screen's pixmap, so detach them first when the provider is destroyed. Any instructions on how to reproduce this? I've been trying to get it to happen here. 1. Start X on an Intel system with a DisplayLink device attached. 2. xrandr --setprovideroutputsource 1 0 3. xrandr --output DVI-0 --off (unless you apply xfree86: don't enable anything in xf86InitialConfiguration for GPU screens) 4. xrandr --auto 5. Terminate the X server. Program received signal SIGSEGV, Segmentation fault. 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc@entry=0x80259740) at ../../randr/rrcrtc.c:370 370 ../../randr/rrcrtc.c: No such file or directory. (gdb) bt #0 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc@entry=0x80259740) at ../../randr/rrcrtc.c:370 #1 0x8010bfab in RRCrtcDestroyResource (value=0x80259740, pid=63) at ../../randr/rrcrtc.c:678 #2 0x80062fbe in doFreeResource (res=0x8025bc58, skip=skip@entry=0) at ../../dix/resource.c:873 #3 0x8006415b in FreeClientResources (client=0x8023f350) at ../../dix/resource.c:1139 #4 0x800641fc in FreeAllResources () at ../../dix/resource.c:1154 #5 0x8002b556 in main (argc=3, argv=0xb704, envp=0xb714) at ../../dix/main.c:321 (gdb) p crtc-pScreen-current_master $1 = (ScreenPtr) 0x0 (gdb) p crtc-pScreen-myNum $2 = 256 I did notice that xrandr is now broken for detach? how are you detaching btw? xrandr --setoutputprovidersource 0x67 0x0 should detach I would think, but it fails now. Yeah, I noticed that too, and hacked it up to allow me to test it. I'll try to clean up the change for review. The crash doesn't occur at detach time or if I pull the USB cable. I'm having absolutely no luck reproducing this with the X server master + my for-keithp tree pulled in. I'm not sure what I could be doing different than you are, I've even valgrinded it. That's really weird. I wonder if stuff is initializing in a different order on your system for some reason. I just rebuilt at commit 2746c681639f9512e6e45fb8d0151b996b6aff7f and verified that the problem still occurs. -- 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
Re: (Crowd funded) fix for SiS 671/771 video cards
On 06/05/13 10:25 AM, pan...@users.sourceforge.net wrote: Hi all, Since a few months the driver for SiS 671/771 video cards is no longer working in main stream distributions such as Ubuntu. This is affecting many users and I would like to ask the development community of Xorg who would like to fix this issue. For the details please see these bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=15190 and: https://bugs.launchpad.net/debian/+source/xserver-xorg-video-sis/+bug/301958 Since the number of users waiting for a fix is in the thousands, I am sure that some sort of crowd funding such as: https://www.catincan.com/proposal/altdrag/altdrag-10 might be possible. I am more than happy to make a financial contribution in order to not having to write off some still good hardware. I am sure many others are willing to chip in. Who would be interested in taking this on? Regards, Pander Those bug reports started in 2008 and seem to just track the stability of the SiS driver in general. Nowhere do I see a description about the specific problem that has arisen in 2013 with the proper information (terminal output, dmesg output, lspci output, xorg.conf file, backtrace, etc). As suggested on the Launchpad bug report, I would try compiling xf86-video-sisimedia with the Archlinux patches applied: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/xf86-video-sisimedia They have put a large amount of effort into keeping this driver working and have updated the patches in 2013. If those still don't work, get your hands dirty... if any particular strings appear in error messages, find those strings in the source and figure out what function is failing. Then compare the execution of the broken copy to the last working copy you remembered. If the API of some dependency changed, use git bisect to repeatedly compile the kernel or the Xserver until you find the exact line of code in the dependency that made the difference. Hacking the driver might sound hard, but it's not so hard that you have to pay someone to do it. signature.asc Description: OpenPGP digital 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
Re: (Crowd funded) fix for SiS 671/771 video cards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/06/2013 10:36 PM, Connor Behan wrote: On 06/05/13 10:25 AM, pan...@users.sourceforge.net wrote: Hi all, Since a few months the driver for SiS 671/771 video cards is no longer working in main stream distributions such as Ubuntu. This is affecting many users and I would like to ask the development community of Xorg who would like to fix this issue. For the details please see these bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=15190 and: https://bugs.launchpad.net/debian/+source/xserver-xorg-video-sis/+bug/301958 Since the number of users waiting for a fix is in the thousands, I am sure that some sort of crowd funding such as: https://www.catincan.com/proposal/altdrag/altdrag-10 might be possible. I am more than happy to make a financial contribution in order to not having to write off some still good hardware. I am sure many others are willing to chip in. Who would be interested in taking this on? Regards, Pander Those bug reports started in 2008 and seem to just track the stability of the SiS driver in general. Nowhere do I see a description about the specific problem that has arisen in 2013 with the proper information (terminal output, dmesg output, lspci output, xorg.conf file, backtrace, etc). As suggested on the Launchpad bug report, I would try compiling xf86-video-sisimedia with the Archlinux patches applied: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/xf86-video-sisimedia They have put a large amount of effort into keeping this driver working and have updated the patches in 2013. My experience with building drivers for Xorg is relatively small. As I recall, this one compiles but crashed Xorg and I don't know exactly what to submit exactly. It is better if the people working on that driver or other Xorg experts give it a try and write a proper analysis of the specific work that needs to be done (probably restoring support that has been removed but that might not be trivial). If those still don't work, get your hands dirty... if any particular strings appear in error messages, find those strings in the source and figure out what function is failing. Then compare the execution of the broken copy to the last working copy you remembered. If the API of some dependency changed, use git bisect to repeatedly compile the kernel or the Xserver until you find the exact line of code in the dependency that made the difference. Hacking the driver might sound hard, but it's not so hard that you have to pay someone to do it. Well, I don't mind getting my hands dirty but I am already involved in too many other open source project myself at the moment. With so many users of this hardware out there and people getting used to chipping in for applications or features via small donations such as Google Play for Android, I think it is a nice way to show appreciation for their efforts. But if someone would like to start working on it nevertheless-simply because to support users with this kind of hardware-that is also fine. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGIKeIACgkQ0YurwYIk8CJ3fwCeOAuxcMZS+GUv/YCks2tt5Tia FHAAniQB+WTyLAF1O70O09WqLU5V3fgw =Hbqg -END 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
Re: [PATCH] xfree86: detach scanout pixmaps when detaching output GPUs
On Tue, May 7, 2013 at 6:17 AM, Aaron Plattner aplatt...@nvidia.com wrote: On 05/05/2013 04:23 PM, Dave Airlie wrote: On Thu, May 2, 2013 at 5:55 AM, Aaron Plattner aplatt...@nvidia.com wrote: On 04/30/2013 11:30 PM, Dave Airlie wrote: On Wed, May 1, 2013 at 7:14 AM, Aaron Plattner aplatt...@nvidia.com wrote: Commit 8f4640bdb9d3988148e09a08d2c7e3bab1d538d6 fixed a bit of a chicken-and-egg problem by detaching GPU screens when their providers are destroyed, which happens before CloseScreen is called. However, this created a new problem: the GPU screen tears down its RandR crtc objects during CloseScreen and if one of them is active, it tries to detach the scanout pixmap then. This crashes because RRCrtcDetachScanoutPixmap tries to get the master screen's screen pixmap, but crtc-pScreen-current_master is already NULL at that point. It doesn't make sense for an unbound GPU screen to still be scanning out its former master screen's pixmap, so detach them first when the provider is destroyed. Any instructions on how to reproduce this? I've been trying to get it to happen here. 1. Start X on an Intel system with a DisplayLink device attached. 2. xrandr --setprovideroutputsource 1 0 3. xrandr --output DVI-0 --off (unless you apply xfree86: don't enable anything in xf86InitialConfiguration for GPU screens) 4. xrandr --auto 5. Terminate the X server. Program received signal SIGSEGV, Segmentation fault. 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc@entry=0x80259740) at ../../randr/rrcrtc.c:370 370 ../../randr/rrcrtc.c: No such file or directory. (gdb) bt #0 0x8010be62 in RRCrtcDetachScanoutPixmap (crtc=crtc@entry=0x80259740) at ../../randr/rrcrtc.c:370 #1 0x8010bfab in RRCrtcDestroyResource (value=0x80259740, pid=63) at ../../randr/rrcrtc.c:678 #2 0x80062fbe in doFreeResource (res=0x8025bc58, skip=skip@entry=0) at ../../dix/resource.c:873 #3 0x8006415b in FreeClientResources (client=0x8023f350) at ../../dix/resource.c:1139 #4 0x800641fc in FreeAllResources () at ../../dix/resource.c:1154 #5 0x8002b556 in main (argc=3, argv=0xb704, envp=0xb714) at ../../dix/main.c:321 (gdb) p crtc-pScreen-current_master $1 = (ScreenPtr) 0x0 (gdb) p crtc-pScreen-myNum $2 = 256 I did notice that xrandr is now broken for detach? how are you detaching btw? xrandr --setoutputprovidersource 0x67 0x0 should detach I would think, but it fails now. Yeah, I noticed that too, and hacked it up to allow me to test it. I'll try to clean up the change for review. The crash doesn't occur at detach time or if I pull the USB cable. I'm having absolutely no luck reproducing this with the X server master + my for-keithp tree pulled in. I'm not sure what I could be doing different than you are, I've even valgrinded it. That's really weird. I wonder if stuff is initializing in a different order on your system for some reason. I just rebuilt at commit 2746c681639f9512e6e45fb8d0151b996b6aff7f and verified that the problem still occurs. Can you attach a full Xorg log where it happens? 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
Re: [PULL] unreviewed patches
On Mon, May 06, 2013 at 11:26:10AM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: Xi: fix comment - XI2 grabs aren't keysym grabs Reviewed-by: Keith Packard kei...@keithp.com dix: send the current axis value in DeviceChangedEvents (#62321) Reviewed-by: Keith Packard kei...@keithp.com Xi: always return BadMatch for XTest devices ChangeDeviceControl requests (this appears to cover all of the DDX entry points to avoid passing XTest devices to them) Reviewed-by: Keith Packard kei...@keithp.com If neither HAL nor udev backends are enabled, warn the user Reviewed-by: Keith Packard kei...@keithp.com xkb: free XkbRulesUsed and XkbRulesDflt on extension cleanup I think this should be done in CloseDownDevices -- XkbDeleteRulesDflts is already called there, adding a call to your new XkbDeleteRulesUsed (which looks fine, btw) seems like the right plan. moved there. I assumed your rev-by, I don't want to do another revision. let me know if it's not to your liking. Delete callbacks when extension are closed dix: delete all callbacks before reset Looks like the second patch makes the first unnecessary? yes, but tbh I do like the idea of extensions cleaning up after themselves instead of leaving it to some other piece of code. I can drop the patch though, I don't care either way tbh. Cheers, Peter dix: reset the registry before quitting Reviewed-by: Keith Packard kei...@keithp.com os: support pnprintf length modifiers for integers Reviewed-by: Keith Packard kei...@keithp.com os: support %% in pnprintf Reviewed-by: Keith Packard kei...@keithp.com os: support %c in pnprintf Reviewed-by: Keith Packard kei...@keithp.com os: complain about unsupported pnprintf directives Reviewed-by: Keith Packard kei...@keithp.com os: Use ErrorFSigSafe from FatalError and it's friends Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com ___ 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] misc input fixes, pnprintf improvements
The following changes since commit 2746c681639f9512e6e45fb8d0151b996b6aff7f: Merge remote-tracking branch 'alanc/master' (2013-05-06 10:52:40 -0700) are available in the git repository at: git://people.freedesktop.org/~whot/xserver for-keith for you to fetch changes up to 6993f8b459e25b1a7a0a03e209688a28ce6c2c56: Xi: free barrier code at reset time (2013-05-07 09:41:19 +1000) Peter Hutterer (12): Xi: fix comment - XI2 grabs aren't keysym grabs dix: send the current axis value in DeviceChangedEvents (#62321) Xi: always return BadMatch for XTest devices ChangeDeviceControl requests If neither HAL nor udev backends are enabled, warn the user xkb: free XkbRulesUsed and XkbRulesDflt on extension cleanup dix: reset the registry before quitting os: support pnprintf length modifiers for integers os: support %% in pnprintf os: support %c in pnprintf os: complain about unsupported pnprintf directives os: Use ErrorFSigSafe from FatalError and it's friends Xi: free barrier code at reset time Xi/chgdctl.c | 6 +++ Xi/exevents.c | 3 +- Xi/extinit.c | 2 + Xi/setdval.c | 3 ++ Xi/setmode.c | 4 ++ Xi/xibarriers.c | 12 ++ Xi/xibarriers.h | 4 +- configure.ac | 8 dix/devices.c | 1 + dix/eventconvert.c| 4 +- dix/getevents.c | 1 + dix/main.c| 2 + dix/registry.c| 25 glx/glxdri.c | 2 +- glx/glxdri2.c | 2 +- include/eventstr.h| 1 + include/registry.h| 1 + include/xkbsrv.h | 3 ++ os/log.c | 111 ++ test/signal-logging.c | 95 ++ xkb/xkbInit.c | 15 +++ 21 files changed, 270 insertions(+), 35 deletions(-) pgpPSf8_uaHQE.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
Re: (Crowd funded) fix for SiS 671/771 video cards
On 06/05/13 04:44 PM, pan...@users.sourceforge.net wrote: My experience with building drivers for Xorg is relatively small. As I recall, this one compiles but crashed Xorg and I don't know exactly what to submit exactly. It is better if the people working on that driver or other Xorg experts give it a try and write a proper analysis of the specific work that needs to be done (probably restoring support that has been removed but that might not be trivial). That's the point, there are no people working on that driver. By looking at the git logs, xf86-video-intel received 1904 commits in 2012, xf86-video-sis received 16. I'm sure the people who made those 16 commits would be happy to fix a bug but that requires detailed information about what the bug is. Here is exactly what you should submit (for starters). The file /etc/X11/xorg.conf, the file /var/log/Xorg.0.log, a text file containing whatever gets printed out when you run startx and a text file containing whatever gets printed out when you run dmesg. Well, I don't mind getting my hands dirty but I am already involved in too many other open source project myself at the moment. With so many users of this hardware out there and people getting used to chipping in for applications or features via small donations such as Google Play for Android, I think it is a nice way to show appreciation for their efforts. But if someone would like to start working on it nevertheless-simply because to support users with this kind of hardware-that is also fine. Yes, debugging can be a big time commitment and that's why there are only three Xorg drivers being actively developed (two of which are paid for by the manufacturer). Don't get me wrong... I think it's a shame that the other 20+ drivers get such little attention and that's why I started to learn driver hacking last year. The problem here is not that some gigantic reverse engineering effort is needed. The problem is that a few tiny janatorial fixes were required. And it's easy to miss one when the developer implementing the fixes doesn't have a SiS card on which to test. Maybe you'll find someone who has a SiS card lying around and say I'll pay you $100 to put that card in your computer, write an xorg.conf file for it, figure out why it won't start and then change 2 or 3 lines to make it start again but it won't be worth it. Because a similar problem will just come up the next year. Unless you can make the popularity of SiS skyrocket to the point where it is as widely used as ATI, gaining some basic familiarity with the code is the only viable strategy in the long run. signature.asc Description: OpenPGP digital 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
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/ 6/13 06:22 PM, Connor Behan wrote: Maybe you'll find someone who has a SiS card lying around and say I'll pay you $100 to put that card in your computer, write an xorg.conf file for it, figure out why it won't start and then change 2 or 3 lines to make it start again but it won't be worth it. Especially when you can buy 2 or 3 new ATI or Nvidia cards for that $100 and get much better performance support than trying to make an old card limp along forever. http://www.newegg.com/Product/ProductList.aspx?Submit=ENEN=17709%204025IsNodeId=1bop=AndOrder=PRICEPageSize=20 The lack of maintainers for many old cards is in large part because the cost of a new card with a well-maintained driver is less than people think their time is worth for the many hours it takes to bring the old drivers up to snuff and test on all the different models. -- -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: [PULL 1.14] input fixes for 1.14.2
Acked. On 05/05/2013 06:42 PM, Peter Hutterer wrote: The following changes since commit f5796f98dadccf67c04f601178966614dd51a1b4: xserver 1.14.1 (2013-04-17 16:12:00 +1000) are available in the git repository at: git://people.freedesktop.org/~whot/xserver server-1.14-branch for you to fetch changes up to a11cf8dd68275ba4676888e5957bff13efbfbb3d: dix: copy event in TouchConvertToPointerEvent correctly (2013-05-06 10:20:18 +1000) Keith Packard (1): Xi: Use correct destination when swapping barrier events Knut Petersen (1): Never try to execute BellProcPtr NULL. Maarten Lankhorst (2): Xi: Do not handle ET_TouchOwnership in ProcessTouchEvent dix: copy event in TouchConvertToPointerEvent correctly Peter Hutterer (2): dix: don't set non-exisiting flags on touch events xfree86: change a log message Rui Matos (1): Xi: fix swapped grab mode args for keyboard devices in XIGrabDevice Xi/devbell.c | 3 ++- Xi/exevents.c | 42 -- Xi/extinit.c | 36 - Xi/xigrabdev.c | 15 +-- dix/eventconvert.c | 19 +++--- dix/touch.c| 4 +-- hw/xfree86/os-support/linux/lnx_platform.c | 3 +-- 7 files changed, 68 insertions(+), 54 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
