Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
Daniel Stone wrote: > Can you not just ship a null cursor theme or something if your apps > insist on setting a cursor? We considered that, but it is unreliable (how about hard coded cursor for exemple), need in-depth testing/validating, and as a consequence eat lot of time. On the other side, you have a 20 lines patch that is easy to apply/validate. I can live with this small patch out of tree, but there is a real need here. Olivier. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Extra pointer motion with current git xf86-input-synaptics
On Monday 29 September 2008, Peter Hutterer wrote:
> On Sun, Sep 28, 2008 at 07:26:06PM +0200, Simon Thum wrote:
> >> The screen coords are used to move the cursor and the scaling is done
> >> based on the axis ranges. Hence the different acceleration when you
> >> change the axis range to 0,-1 (in which case the screen coords are
> >> used as axis ranges).
> >
> > To me, this case sounds like a rounding error piling up.
> >
> > What about:
> >
> > rescaleValuatorAxis(int coord, AxisInfoPtr from, AxisInfoPtr to,
> > int defmax)
> > {
> > [...]
> > return (int)(((float)(coord - fmin) + 0.5f) * (tmax - tmin + 1) /
> > (fmax - fmin + 1)) + tmin;
>
> The patch below should fix another issue, the scaling from device -> core
> -> device. With the patch below, x/y is now used as it is reported by the
> device (unless a screen cross happens).
>
> diff --git a/dix/getevents.c b/dix/getevents.c
> index 166ab4e..f2086e8 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -919,17 +919,22 @@ GetPointerEvents(EventList *events, DeviceIntPtr
> pDev, int type, int buttons, master->last.valuators[1] =
> pDev->last.valuators[1];
> }
>
> +/* Crossed screen? Scale back to device coordiantes */
> if(cx != pDev->last.valuators[0])
> +{
> +scr = miPointerGetScreen(pDev);
> +x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
> +pDev->valuator->axes + 0, scr->width);
> cx = pDev->last.valuators[0];
> +}
> if(cy != pDev->last.valuators[1])
> +{
> +scr = miPointerGetScreen(pDev);
> cy = pDev->last.valuators[1];
> +y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
> +pDev->valuator->axes + 1, scr->height);
> +}
>
> -/* scale x/y back to device coordinates */
> -scr = miPointerGetScreen(pDev);
> -x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
> -pDev->valuator->axes + 0, scr->width);
> -y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
> -pDev->valuator->axes + 1, scr->height);
>
> updateMotionHistory(pDev, ms, first_valuator, num_valuators,
> &pDev->last.valuators[first_valuator]);
> @@ -938,7 +943,6 @@ GetPointerEvents(EventList *events, DeviceIntPtr
> pDev, int type, int buttons, &pDev->last.valuators[first_valuator]);
>
> /* Update the valuators with the true value sent to the client*/
> -/* FIXME: we lose subpixel precision here. */
> if(v0) *v0 = x;
> if(v1) *v1 = y;
Thanks, Peter. Your patch solves my original problem as well. No more
unwanted pointer movement seen on my machine. Can you please commit this to
the xserver?
Regards,
Magnus
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [patch 2/4] Update for changes in mieq API
On Mon, Sep 29, 2008 at 11:01:43PM +0100, [EMAIL PROTECTED] wrote:
> @@ -221,19 +220,21 @@ winMouseWheel (ScreenPtr pScreen, int iD
> void
> winMouseButtonsSendEvent (int iEventType, int iButton)
> {
> - xEvent xCurrentEvent;
> + EventList *events = InitEventList(GetMaximumEventsNum());
> + int i, nevents;
InitEventList should only be called once and that's done in the DIX anyway.
Use GetEventList() instead here.
> + nevents = GetPointerEvents(events, inputInfo.pointer, iEventType, iButton,
> + POINTER_RELATIVE, 0, 0, NULL);
No, you can't do that. Calling GPE for the VCP probably won't work correctly
(at least not in all cases). You need a slave device that generates the
events, and it must be attached to the VCP.
> +/**
> + * Enqueue a motion event.
> + *
> + * XXX: miPointerMove does exactly this, but is static :-( (and uses a
> static buffer)
> + *
> + */
> +void winEnqueueMotion(int x, int y)
I don't think this one is needed. use miPointerSetPosition instead.
> Index: xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmultiwindowwndproc.c
> +++ xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> @@ -535,9 +535,9 @@ winTopLevelWindowProc (HWND hwnd, UINT m
> }
>
>/* Deliver absolute cursor position to X Server */
> - miPointerAbsoluteCursor (ptMouse.x - s_pScreenInfo->dwXOffset,
> -ptMouse.y - s_pScreenInfo->dwYOffset,
> -g_c32LastInputEventTime = GetTickCount ());
> + winEnqueueMotion(ptMouse.x - s_pScreenInfo->dwXOffset,
> +ptMouse.y - s_pScreenInfo->dwYOffset);
> +
as above, miPointerSetPosition.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [patch 3/4] Update for MPX changes
On Mon, Sep 29, 2008 at 11:01:44PM +0100, [EMAIL PROTECTED] wrote:
> @@ -79,7 +79,7 @@ miPointerScreenFuncRec g_winPointerCurso
>
>
> static void
> -winPointerWarpCursor (ScreenPtr pScreen, int x, int y)
> +winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
> {
>winScreenPriv(pScreen);
>RECT rcClient;
> @@ -119,7 +119,7 @@ winPointerWarpCursor (ScreenPtr pScreen,
> }
>
>/* Call the mi warp procedure to do the actual warping in X. */
> - miPointerWarpCursor (pScreen, x, y);
> + miPointerWarpCursor (inputInfo.pointer, pScreen, x, y);
That should be miPointerWarpCursor(pDev, pScreen, x, y);
Not that it matters much if you have only one cursor anyway, but still.
Rest looks ok, though I didn't even compile-tested it.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
.pc files for input drivers
Just to get a general opinion: with each driver having their own properties,
it's a good idea to let the driver install a .h file listing all property
names. see synaptics-properties.h, evdev-properties.h and probably more to
come.
Anyone opposed to a follow-up patch to install the .pc file?
If not, xorg-.pc or just.pc?
Cheers,
Peter
>From 0351d0aad80b6400381b8e32a73228987fb38ab9 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Fri, 26 Sep 2008 10:42:05 +0930
Subject: [PATCH] Add evdev.pc for compiler flags if compiling with
evdev-properties.h included.
---
Makefile.am |7 +--
configure.ac | 13 -
evdev.pc.in |7 +++
3 files changed, 24 insertions(+), 3 deletions(-)
create mode 100644 evdev.pc.in
diff --git a/Makefile.am b/Makefile.am
index 11064e0..7c85f00 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,9 +19,12 @@
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
AUTOMAKE_OPTIONS = foreign
-SUBDIRS = src man
+SUBDIRS = src man include
-EXTRA_DIST = ChangeLog autogen.sh
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = evdev.pc
+
+EXTRA_DIST = ChangeLog autogen.sh evdev.pc.in
MAINTAINERCLEANFILES=ChangeLog
diff --git a/configure.ac b/configure.ac
index 5a29874..c048059 100644
--- a/configure.ac
+++ b/configure.ac
@@ -52,6 +52,13 @@ AC_ARG_WITH(xorg-module-dir,
inputdir=${moduledir}/input
AC_SUBST(inputdir)
+AC_ARG_WITH(xorg-sdk-dir,
+AC_HELP_STRING([--with-xorg-sdk-dir=DIR],
+ [Default xorg SDK directory
[[default=$includedir/xorg]]]),
+[includedir="$withval"],
+[includedir="$includedir/xorg"])
+AC_SUBST([includedir])
+
# Checks for extensions
XORG_DRIVER_CHECK_EXT(XINPUT, inputproto)
@@ -70,4 +77,8 @@ AC_HEADER_STDC
XORG_MANPAGE_SECTIONS
XORG_RELEASE_VERSION
-AC_OUTPUT([Makefile src/Makefile man/Makefile])
+AC_OUTPUT([Makefile
+ src/Makefile
+ man/Makefile
+ include/Makefile
+ evdev.pc])
diff --git a/evdev.pc.in b/evdev.pc.in
new file mode 100644
index 000..a8de102
--- /dev/null
+++ b/evdev.pc.in
@@ -0,0 +1,7 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+Name: evdev
+Description: X.Org evdev input driver.
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
On Mon, Sep 29, 2008 at 11:08:04PM +0200, Olivier Guerrier wrote: > Ray Strode wrote: > > As already mentioned on this thread, -nocursor type behavior is the > > default now. > > > > There is no need for any out of tree patch. X starts up without a cursor. > > The point (at least Barry's and mine) is not having X starting with or > without a cursor. It is about _permanently_ disabling X cursor drawing, > at root and application level, and even if/when application request a > cursor change. Hmm, that seems a little odd. Seems like there are three camps here: * People writing display drivers (let's call them 'the minority') want a stipple and cursor. -> -retro * People starting regular desktop environments want the default behaviour. (Though I have slight doubts. I'd fall back on the default cursor being a NULL cursor unless forced otherwise, and IIRC the behaviour here is to suppress cursor realisation, which means you come back to an ugly root cursor, but that's fixable.) * People running consumer/embedded systems who can't trust their apps not to try to change the cursors want to silently drop all cursor rendering. -> patch required if deemed useful Can you not just ship a null cursor theme or something if your apps insist on setting a cursor? Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[patch 1/4] Fixes to build machinery
Hmm.. I wonder what went wrong then...
Original Message
From [EMAIL PROTECTED] Mon Sep 29 23:08:44 2008
Message-Id: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
User-Agent: quilt/0.46-1
Date: Mon, 29 Sep 2008 23:08:35 +0100
From: [EMAIL PROTECTED]
To: xorg@lists.freedesktop.org
Cc: [EMAIL PROTECTED]
Subject: [patch 1/4] Fixes to build machinery
Content-Disposition: inline; filename=build-fixes.patch
---
xserver/configure.ac |6 --
xserver/hw/xwin/Makefile.am| 19 ++-
xserver/hw/xwin/winerror.c | 11 +--
xserver/hw/xwin/winmultiwindowwm.c |9 +
xserver/hw/xwin/winprocarg.c |4 ++--
xserver/hw/xwin/winscrinit.c |1 -
6 files changed, 22 insertions(+), 28 deletions(-)
Index: xorg-git/xserver/configure.ac
===
--- xorg-git.orig/xserver/configure.ac
+++ xorg-git/xserver/configure.ac
@@ -1470,12 +1470,14 @@ if test "x$XWIN" = xauto; then
mingw*) XWIN="yes" ;;
*) XWIN="no" ;;
esac
- XWIN_LIBS="$FB_LIB $XEXT_LIB $CONFIG_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB
$COMPOSITE_LIB $DAMAGE_LIB $LAYER_LIB $XPSTUBS_LIB $SHADOW_LIB"
+ XWIN_LIBS="$FB_LIB $MI_LIB $FIXES_LIB $XEXT_LIB $CONFIG_LIB $RANDR_LIB
$RENDER_LIB $XTRAP_LIB $DBE_LIB $RECORD_LIB $GLX_LIBS $XKB_LIB $XKB_STUB_LIB
$COMPOSITE_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB
$MIEXT_LAYER_LIB $LAYER_LIB $XPSTUBS_LIB $SHADOW_LIB $OS_LIB"
AC_SUBST([XWIN_LIBS])
fi
AC_MSG_RESULT([$XWIN])
if test "x$XWIN" = xyes; then
+ AC_DEFINE_UNQUOTED(XORG_VERSION_CURRENT, [$VENDOR_RELEASE], [Current
Xorg version])
+ AC_CHECK_TOOL(WINDRES, windres)
case $host_os in
cygwin*)
XWIN_SERVER_NAME=XWin
@@ -1492,7 +1494,7 @@ if test "x$XWIN" = xyes; then
XWIN_SYS_LIBS=-lwinsock2
;;
esac
- XWIN_SYS_LIBS="$XWIN_SYS_LIBS $(XWINMODULES_LIBS)"
+ XWIN_SYS_LIBS="$XWIN_SYS_LIBS $XWINMODULES_LIBS"
AC_SUBST(XWIN_SERVER_NAME)
AC_SUBST(XWIN_SYS_LIBS)
Index: xorg-git/xserver/hw/xwin/Makefile.am
===
--- xorg-git.orig/xserver/hw/xwin/Makefile.am
+++ xorg-git/xserver/hw/xwin/Makefile.am
@@ -119,8 +119,10 @@ SRCS = InitInput.c \
winpriv.h \
winresource.h \
winwindow.h \
+ XWin.rc \
+ $(top_srcdir)/Xi/stubs.c \
$(top_srcdir)/mi/miinitext.c \
- $(top_srcdir)/fb/fbcmap.c \
+ $(top_srcdir)/fb/fbcmap_mi.c \
$(SRCS_CLIPBOARD) \
$(SRCS_GLX_WINDOWS) \
$(SRCS_MULTIWINDOW) \
@@ -141,15 +143,13 @@ SRCS =InitInput.c \
XWin_SOURCES = $(SRCS)
-INCLUDES = -I$(top_srcdir)/miext/rootless \
- -I$(top_srcdir)/miext/rootless/safeAlpha
-
-XWIN_LIBS = \
- $(top_builddir)/fb/libfb.la \
- $(XSERVER_LIBS)
+INCLUDES = -I$(top_srcdir)/miext/rootless
XWin_DEPENDENCIES = $(XWIN_LIBS)
-XWin_LDADD = $(XWIN_LIBS) $(XSERVER_SYS_LIBS) $(XWIN_SYS_LIBS)
+XWin_LDADD = $(XWIN_LIBS) $(XSERVER_LIBS) $(XSERVER_SYS_LIBS) $(XWIN_SYS_LIBS)
XWin.o
+
+.rc.o:
+ $(WINDRES) --use-temp-file -i $< --input-format=rc -o $@ -O coff
-DPROJECT_NAME=\"$(VENDOR_STRING_SHORT)\"
XWin_LDFLAGS = -mwindows -static
@@ -162,7 +162,8 @@ CLEANFILES = $(BUILT_SOURCES)
AM_YFLAGS = -d
AM_LFLAGS = -i
AM_CFLAGS = -DHAVE_XWIN_CONFIG_H $(DIX_CFLAGS) \
-$(XWINMODULES_CFLAGS)
+$(XWINMODULES_CFLAGS) \
+-DXFree86Server
dist_man1_MANS = XWin.man XWinrc.man
Index: xorg-git/xserver/hw/xwin/winerror.c
===
--- xorg-git.orig/xserver/hw/xwin/winerror.c
+++ xorg-git/xserver/hw/xwin/winerror.c
@@ -33,10 +33,9 @@
#endif
#ifdef XVENDORNAME
#define VENDOR_STRING XVENDORNAME
-#define VERSION_STRING XORG_RELEASE
#define VENDOR_CONTACT BUILDERADDR
#endif
-
+#include <../xfree86/common/xorgVersion.h>
#include "win.h"
/* References to external symbols */
@@ -80,7 +79,6 @@ OsVendorVErrorF (const char *pszFormat,
*
* Attempt to do last-ditch, safe, important cleanup here.
*/
-#ifdef DDXOSFATALERROR
void
OsVendorFatalError (void)
{
@@ -93,7 +91,6 @@ OsVendorFatalError (void)
"Please open %s for more information.\n",
MB_ICONERROR, (g_pszLogFile?g_pszLogFile:"the logfile"));
}
-#endif
/*
@@ -117,13 +114,15 @@ winMessageBoxF (const char *pszError, UI
#define MESSAGEBOXF \
"%s\n" \
"Vendor: %s\n" \
- "Release: %s\n" \
+ "Release: %d.%d.%d.%d (%d)\n" \
"Contact: %s\n" \
"XWin was started with the following command-line:\n\n" \
"%s\n"
pszMsgBox = Xprintf (MESSAGEBOXF,
- pszErrorF, VENDOR_STRING, VERSION_STRING, VENDOR_CONTACT,
+ pszErrorF, VENDOR_ST
[patch 4/4] Update for changes to shadow framebuffer
---
xserver/hw/xwin/win.h |3 +++
xserver/hw/xwin/winscrinit.c | 32 +++-
xserver/hw/xwin/winshaddd.c |2 +-
xserver/hw/xwin/winshadddnl.c |2 +-
xserver/hw/xwin/winshadgdi.c |2 +-
5 files changed, 33 insertions(+), 8 deletions(-)
Index: xorg-git/xserver/hw/xwin/win.h
===
--- xorg-git.orig/xserver/hw/xwin/win.h
+++ xorg-git/xserver/hw/xwin/win.h
@@ -314,6 +314,7 @@ typedef Bool (*winReleasePrimarySurfaceP
typedef Bool (*winFinishCreateWindowsWindowProcPtr)(WindowPtr pWin);
+typedef Bool (*winCreateScreenResourcesProc)(ScreenPtr);
/* Typedef for DIX wrapper functions */
typedef int (*winDispatchProcPtr) (ClientPtr);
@@ -564,6 +565,8 @@ typedef struct _winPrivScreenRec
winCreatePrimarySurfaceProcPtr pwinCreatePrimarySurface;
winReleasePrimarySurfaceProcPtr pwinReleasePrimarySurface;
+ winCreateScreenResourcesProc pwinCreateScreenResources;
+
#ifdef XWIN_MULTIWINDOW
/* Window Procedures for MultiWindow mode */
winFinishCreateWindowsWindowProcPtr pwinFinishCreateWindowsWindow;
Index: xorg-git/xserver/hw/xwin/winscrinit.c
===
--- xorg-git.orig/xserver/hw/xwin/winscrinit.c
+++ xorg-git/xserver/hw/xwin/winscrinit.c
@@ -244,6 +244,25 @@ winScreenInit (int index,
return TRUE;
}
+static Bool
+winCreateScreenResources(ScreenPtr pScreen)
+{
+ winScreenPriv(pScreen);
+ Bool result;
+
+ result = pScreenPriv->pwinCreateScreenResources(pScreen);
+
+ /* Now the screen bitmap has been wrapped in a pixmap,
+ add that to the Shadow framebuffer */
+ if (!shadowAdd(pScreen, pScreen->devPrivate,
+pScreenPriv->pwinShadowUpdate, NULL, 0, 0))
+{
+ ErrorF ("winCreateScreenResources - shadowAdd () failed\n");
+ return FALSE;
+}
+
+ return result;
+}
/* See Porting Layer Definition - p. 20 */
Bool
@@ -427,15 +446,18 @@ winFinishScreenInitFB (int index,
)
{
#if CYGDEBUG
- winDebug ("winFinishScreenInitFB - Calling shadowInit ()\n");
+ winDebug ("winFinishScreenInitFB - Calling shadowSetup ()\n");
#endif
- if (!shadowInit (pScreen,
- pScreenPriv->pwinShadowUpdate,
- NULL))
+ if (!shadowSetup(pScreen))
{
- ErrorF ("winFinishScreenInitFB - shadowInit () failed\n");
+ ErrorF ("winFinishScreenInitFB - shadowSetup () failed\n");
return FALSE;
}
+
+ /* Wrap CreateScreenResources so we can add the screen pixmap
+ to the Shadow framebuffer after it's been created */
+ pScreenPriv->pwinCreateScreenResources = pScreen->CreateScreenResources;
+ pScreen->CreateScreenResources = winCreateScreenResources;
}
#ifdef XWIN_MULTIWINDOWEXTWM
Index: xorg-git/xserver/hw/xwin/winshaddd.c
===
--- xorg-git.orig/xserver/hw/xwin/winshaddd.c
+++ xorg-git/xserver/hw/xwin/winshaddd.c
@@ -508,7 +508,7 @@ winShadowUpdateDD (ScreenPtr pScreen,
{
winScreenPriv(pScreen);
winScreenInfo*pScreenInfo = pScreenPriv->pScreenInfo;
- RegionPtrdamage = &pBuf->damage;
+ RegionPtrdamage = shadowDamage(pBuf);
HRESULT ddrval = DD_OK;
RECT rcDest, rcSrc;
POINTptOrigin;
Index: xorg-git/xserver/hw/xwin/winshadddnl.c
===
--- xorg-git.orig/xserver/hw/xwin/winshadddnl.c
+++ xorg-git/xserver/hw/xwin/winshadddnl.c
@@ -584,7 +584,7 @@ winShadowUpdateDDNL (ScreenPtr pScreen,
{
winScreenPriv(pScreen);
winScreenInfo*pScreenInfo = pScreenPriv->pScreenInfo;
- RegionPtrdamage = &pBuf->damage;
+ RegionPtrdamage = shadowDamage(pBuf);
HRESULT ddrval = DD_OK;
RECT rcDest, rcSrc;
POINTptOrigin;
Index: xorg-git/xserver/hw/xwin/winshadgdi.c
===
--- xorg-git.orig/xserver/hw/xwin/winshadgdi.c
+++ xorg-git/xserver/hw/xwin/winshadgdi.c
@@ -498,7 +498,7 @@ winShadowUpdateGDI (ScreenPtr pScreen,
{
winScreenPriv(pScreen);
winScreenInfo*pScreenInfo = pScreenPriv->pScreenInfo;
- RegionPtrdamage = &pBuf->damage;
+ RegionPtrdamage = shadowDamage(pBuf);
DWORDdwBox = REGION_NUM_RECTS (damage);
BoxPtr pBox = REGION_RECTS (damage);
int x, y, w, h;
--
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[patch 3/4] Update for MPX changes
---
xserver/hw/xwin/InitInput.c |5 ++---
xserver/hw/xwin/wincursor.c | 33 -
2 files changed, 26 insertions(+), 12 deletions(-)
Index: xorg-git/xserver/hw/xwin/InitInput.c
===
--- xorg-git.orig/xserver/hw/xwin/InitInput.c
+++ xorg-git/xserver/hw/xwin/InitInput.c
@@ -94,7 +94,6 @@ ProcessInputEvents (void)
#endif
mieqProcessInputEvents ();
- miPointerUpdate ();
#if 0
ErrorF ("ProcessInputEvents - returning\n");
@@ -145,8 +144,8 @@ InitInput (int argc, char *argv[])
}
#endif
- pMouse = AddInputDevice (winMouseProc, TRUE);
- pKeyboard = AddInputDevice (winKeybdProc, TRUE);
+ pMouse = AddInputDevice (serverClient, winMouseProc, TRUE);
+ pKeyboard = AddInputDevice (serverClient, winKeybdProc, TRUE);
RegisterPointerDevice (pMouse);
RegisterKeyboardDevice (pKeyboard);
Index: xorg-git/xserver/hw/xwin/wincursor.c
===
--- xorg-git.orig/xserver/hw/xwin/wincursor.c
+++ xorg-git/xserver/hw/xwin/wincursor.c
@@ -62,7 +62,7 @@ extern Bool g_fSoftwareCursor;
*/
static void
-winPointerWarpCursor (ScreenPtr pScreen, int x, int y);
+winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y);
static Bool
winCursorOffScreen (ScreenPtr *ppScreen, int *x, int *y);
@@ -79,7 +79,7 @@ miPointerScreenFuncRec g_winPointerCurso
static void
-winPointerWarpCursor (ScreenPtr pScreen, int x, int y)
+winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
{
winScreenPriv(pScreen);
RECT rcClient;
@@ -119,7 +119,7 @@ winPointerWarpCursor (ScreenPtr pScreen,
}
/* Call the mi warp procedure to do the actual warping in X. */
- miPointerWarpCursor (pScreen, x, y);
+ miPointerWarpCursor (inputInfo.pointer, pScreen, x, y);
}
static Bool
@@ -437,7 +437,7 @@ winLoadCursor (ScreenPtr pScreen, Cursor
* Convert the X cursor representation to native format if possible.
*/
static Bool
-winRealizeCursor (ScreenPtr pScreen, CursorPtr pCursor)
+winRealizeCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor)
{
if(pCursor == NULL || pCursor->bits == NULL)
return FALSE;
@@ -453,7 +453,7 @@ winRealizeCursor (ScreenPtr pScreen, Cur
* Free the storage space associated with a realized cursor.
*/
static Bool
-winUnrealizeCursor(ScreenPtr pScreen, CursorPtr pCursor)
+winUnrealizeCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor)
{
return TRUE;
}
@@ -464,7 +464,7 @@ winUnrealizeCursor(ScreenPtr pScreen, Cu
* Set the cursor sprite and position.
*/
static void
-winSetCursor (ScreenPtr pScreen, CursorPtr pCursor, int x, int y)
+winSetCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor, int x,
int y)
{
POINT ptCurPos, ptTemp;
HWND hwnd;
@@ -538,20 +538,35 @@ winSetCursor (ScreenPtr pScreen, CursorP
/*
- * QuartzMoveCursor
+ * winMoveCursor
* Move the cursor. This is a noop for us.
*/
static void
-winMoveCursor (ScreenPtr pScreen, int x, int y)
+winMoveCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
{
}
+static Bool
+winDeviceCursorInitialize(DeviceIntPtr pDev, ScreenPtr pScr)
+{
+ winScreenPriv(pScr);
+ return pScreenPriv->cursor.spriteFuncs->DeviceCursorInitialize(pDev, pScr);
+}
+
+static void
+winDeviceCursorCleanup(DeviceIntPtr pDev, ScreenPtr pScr)
+{
+ winScreenPriv(pScr);
+ return pScreenPriv->cursor.spriteFuncs->DeviceCursorCleanup(pDev, pScr);
+}
static miPointerSpriteFuncRec winSpriteFuncsRec = {
winRealizeCursor,
winUnrealizeCursor,
winSetCursor,
- winMoveCursor
+ winMoveCursor,
+ winDeviceCursorInitialize,
+ winDeviceCursorCleanup
};
--
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[patch 2/4] Update for changes in mieq API
---
xserver/hw/xwin/InitInput.c | 10 --
xserver/hw/xwin/win.h |3 +
xserver/hw/xwin/winkeybd.c| 22 +++--
xserver/hw/xwin/winmouse.c| 50 ++
xserver/hw/xwin/winmultiwindowwndproc.c |6 +--
xserver/hw/xwin/winwin32rootlesswndproc.c |6 +--
xserver/hw/xwin/winwndproc.c |8 +---
7 files changed, 71 insertions(+), 34 deletions(-)
Index: xorg-git/xserver/hw/xwin/InitInput.c
===
--- xorg-git.orig/xserver/hw/xwin/InitInput.c
+++ xorg-git/xserver/hw/xwin/InitInput.c
@@ -102,6 +102,13 @@ ProcessInputEvents (void)
}
+void DDXRingBell(int volume, int pitch, int duration)
+{
+ /* winKeybdBell is used instead */
+ return;
+}
+
+
int
TimeSinceLastInputEvent ()
{
@@ -144,8 +151,7 @@ InitInput (int argc, char *argv[])
RegisterPointerDevice (pMouse);
RegisterKeyboardDevice (pKeyboard);
- miRegisterPointerDevice (screenInfo.screens[0], pMouse);
- mieqInit ((DevicePtr)pKeyboard, (DevicePtr)pMouse);
+ mieqInit ();
/* Initialize the mode key states */
winInitializeModeKeyStates ();
Index: xorg-git/xserver/hw/xwin/win.h
===
--- xorg-git.orig/xserver/hw/xwin/win.h
+++ xorg-git/xserver/hw/xwin/win.h
@@ -1004,6 +1004,9 @@ winMouseButtonsHandle (ScreenPtr pScreen
int iEventType, int iButton,
WPARAM wParam);
+void
+winEnqueueMotion(int x, int y);
+
#ifdef XWIN_NATIVEGDI
/*
* winnativegdi.c
Index: xorg-git/xserver/hw/xwin/winkeybd.c
===
--- xorg-git.orig/xserver/hw/xwin/winkeybd.c
+++ xorg-git/xserver/hw/xwin/winkeybd.c
@@ -580,8 +580,6 @@ winKeybdReleaseKeys ()
void
winSendKeyEvent (DWORD dwKey, Bool fDown)
{
- xEvent xCurrentEvent;
-
/*
* When alt-tabing between screens we can get phantom key up messages
* Here we only pass them through it we think we should!
@@ -590,14 +588,20 @@ winSendKeyEvent (DWORD dwKey, Bool fDown
/* Update the keyState map */
g_winKeyState[dwKey] = fDown;
-
- ZeroMemory (&xCurrentEvent, sizeof (xCurrentEvent));
- xCurrentEvent.u.u.type = fDown ? KeyPress : KeyRelease;
- xCurrentEvent.u.keyButtonPointer.time =
-g_c32LastInputEventTime = GetTickCount ();
- xCurrentEvent.u.u.detail = dwKey + MIN_KEYCODE;
- mieqEnqueue (&xCurrentEvent);
+ EventList *events = InitEventList(GetMaximumEventsNum());
+ int i, nevents;
+ nevents = GetKeyboardEvents(events, inputInfo.keyboard, fDown ? KeyPress :
KeyRelease, dwKey + MIN_KEYCODE);
+
+ for (i = 0; i < nevents; i++)
+mieqEnqueue(inputInfo.keyboard, events[i].event);
+
+ FreeEventList(events, GetMaximumEventsNum());
+
+#if CYGDEBUG
+ ErrorF("winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n",
+ dwKey, fDown, nevents);
+#endif
}
BOOL winCheckKeyPressed(WPARAM wParam, LPARAM lParam)
Index: xorg-git/xserver/hw/xwin/winmouse.c
===
--- xorg-git.orig/xserver/hw/xwin/winmouse.c
+++ xorg-git/xserver/hw/xwin/winmouse.c
@@ -100,7 +100,6 @@ winMouseProc (DeviceIntPtr pDeviceInt, i
InitPointerDeviceStruct (pDevice,
map,
lngMouseButtons + lngWheelEvents,
- GetMotionHistory,
winMouseCtrl,
GetMotionHistorySize(),
2);
@@ -221,19 +220,21 @@ winMouseWheel (ScreenPtr pScreen, int iD
void
winMouseButtonsSendEvent (int iEventType, int iButton)
{
- xEvent xCurrentEvent;
+ EventList *events = InitEventList(GetMaximumEventsNum());
+ int i, nevents;
- /* Load an xEvent and enqueue the event */
- xCurrentEvent.u.u.type = iEventType;
-#if defined(XFree86Server)
- if (g_winMouseButtonMap)
-xCurrentEvent.u.u.detail = g_winMouseButtonMap[iButton];
- else
+ nevents = GetPointerEvents(events, inputInfo.pointer, iEventType, iButton,
+POINTER_RELATIVE, 0, 0, NULL);
+
+ for (i = 0; i < nevents; i++)
+mieqEnqueue(inputInfo.pointer, events[i].event);
+
+ FreeEventList(events, GetMaximumEventsNum());
+
+#if CYGDEBUG
+ ErrorF("winMouseButtonsSendEvent: iEventType: %d, iButton: %d, nEvents %d\n",
+ iEventType, iButton, nevents);
#endif
- xCurrentEvent.u.u.detail = iButton;
- xCurrentEvent.u.keyButtonPointer.time
-= g_c32LastInputEventTime = GetTickCount ();
- mieqEnqueue (&xCurrentEvent);
}
@@ -339,3 +340,28 @@ winMouseButtonsHandle (ScreenPtr pScreen
return 0;
}
+
+/**
+ * Enqueue a motion event.
+ *
+ * XXX: miPointerMove does exactly this, but is static :-( (and uses a static
buffer)
+ *
+ */
+void winEnqueueMotion(int x, int y)
+{
+ int i, nevents;
+ int valuators[2];
[patch 0/4] Patches for Cygwin/X
A series of patches to bring Cygwin/X up to date so it at least builds and minimally works Any comments on their correctness appreciated Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bus types other than PCI not yet isolable
On Mon, Sep 29, 2008 at 14:34:41 -0300, Tiago Vignatti wrote: > (I'm not sure what version of Xorg is in Debian Sid but I presume is 7.4 > or newer) > 7.3, actually. (plus some updated bits, but the server is 1.4.2) Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
Ray Strode wrote: > As already mentioned on this thread, -nocursor type behavior is the > default now. > > There is no need for any out of tree patch. X starts up without a cursor. The point (at least Barry's and mine) is not having X starting with or without a cursor. It is about _permanently_ disabling X cursor drawing, at root and application level, and even if/when application request a cursor change. Olivier. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Having a two displays with driver "intel" (e.g. :0.0 and :0.1)
Steven J Newbury wrote, On 09/29/2008 05:22 AM: > On Sun, 2008-09-28 at 12:31 -0700, Romain Chossart wrote: >> Hi, >> >> I would like to know if there was a possibility to use "intel" drivers >> (not i810) with *two displays* (e.g. :0.0 and :0.1) but only *one X >> server*. > Your terminology isn't quite correct, what you're calling displays, are > actually "screens". When supported a driver controlling multiple > outputs from a single display adaptor it's called "Zaphod mode". (After > Zaphod Beeblebrox - the guy from "Hitchhiker's Guide to the Galaxy" with > two heads!) > >> I could do it with i810 drivers, but then I switched to the "intel" >> one, which is better in many ways, but not for my dual screen purpose >> ! >> I'm currently using a xrandr-like conf, but it has many issues, like : >> - No possibility to put 2 different isntances of window managers > This is possible with multiple screens and multiple displays. Some > window managers, however, support multiple screens by default, so a > single window manager instance will control both screens. On the other > hand, each display must have it's own window manager. > >> - Maximizing takes whole "virtual" screen > As replied separately, this is due to your window manager either lacking > or not being complied with "Xinerama" support. > >> - Mouse can be in "emptyness" part of the screen (because i have 2 >> different monitor resolutions) > I don't know about this; it hasn't been my experience in the past > though. >> I am really getting mad about this, because I spent days (*really*) >> seeking a configuration like that. > Unfortunately the current intel driver doesn't support Zaphod mode. I had the same problem as OP, until I figured out Xinerama. Xinerama will extend your desktop over two physical monitors, providing only ":0.0". But Xinerama-aware applications and window-managers ensures that applications pops up on the correct physical monitor, and also makes 'fullscreen' imply 'cover the current physical monitor'. The bonus, compared to Zaphod-mode is that you can move windows freely over the entire desktop. I noticed one minor snag with icewm, though. If you use xrandr to change some aspect of your desktop layout, you may have to restart icewm in order to move windows over the entire desktop. I no longer miss Zaphod-mode. OP may have other use-cases than mine, though. Dag B ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
Hi, On Sun, Sep 28, 2008 at 2:46 PM, Olivier Guerrier <[EMAIL PROTECTED]> wrote: > Barry Scott wrote: >> We would love to have a -nocursor that got ride of the cursor from the >> screen added to Xorg. >> >> We have a patch to do this that we use. > > Maybe a little off-topic here, but I back this proposal of totally > disabling cursor at X level. As already mentioned on this thread, -nocursor type behavior is the default now. There is no need for any out of tree patch. X starts up without a cursor. --Ray ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bus types other than PCI not yet isolable
Hugo Vanwoerkom escreveu: > I run a 2-seater (2 videocards/servers/mice/keyboards/monitors) on Debian Sid. > That works successfully with xorg 1:7.2-5 (that's Debian's designation). So > that's an installation that has not been upgraded recently. > > Under the recent upgrades with xorg 1:7.3+10 that doesn't work anymore and I > get 'Bus types other than PCI not yet isolable'. > > The relevant isolatedevice's are: > > command=/usr/bin/X1 :0 -layout X1 -dpi 110 -deferglyphs 16 -isolateDevice > \"PCI:1:0:0\" vt7 > > command=/usr/bin/X0 :1 -layout X0 -dpi 110 -deferglyphs 16 -isolateDevice > \"PCI:0:8:0\" -sharevts > > Can anybody shed light on the reason for that error message that now appears > but used to work OK? (I'm not sure what version of Xorg is in Debian Sid but I presume is 7.4 or newer) Since Xorg started to use libpciaccess (introduced in 7.4), we don't build a method to post secondary cards on server. Sigh. I'll try to adventure on this issue soon -- after my other pending work [0]. Cheers, [0] server's input threadification. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman with and without SSE2 benchmarks?
On Mon, Sep 29, 2008 at 01:53:08PM -0300, André Tupinambá wrote: > Hi Matthias, > > What is the pixman version that you are using? It has been reported against pixman 0.11.10. > This bug looks like a > this one (https://bugs.freedesktop.org/show_bug.cgi?id=17477) and it > is already fixed in pixman 0.12.0. > > I'll check this anyway. Thanks, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany - SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman with and without SSE2 benchmarks?
On Mon, Sep 29, 2008 at 06:17:53PM +0200, Matthias Hopf wrote: > On Sep 28, 08 16:53:05 +0200, Roland Scheidegger wrote: > > On 28.09.2008 11:52, Clemens Eisserer wrote: > > >> I'd bet against that :-). Core 2 has magnificent SSE performance indeed, > > >> but that's true for MMX just as well. > > > Well, Core2 (and AMD K10) got support for 128bit operations per clock, > > > whereas previous processors only supported 64bit at once, and took 2 > > > cycles for 128 bit operations. > > > MMX is just 64-bit, so it should't matter much there. > > Ah yes you're right. Somehow I thought it would execute mmx twice as > > fast as well - clearly that's not true. Should indeed be much closer on > > older cpus. > > OTOH pixman w/ SSE does have some severe rendering issues - read > bugzilla.novell.org, #426370. bugzilla.novell.com Best regards, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany - SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: accessing legacy(?) VGA input status register 1 on 945GM/xf86-video-intel
On Monday, September 29, 2008 4:52 am Theo Veenker wrote: > Jesse Barnes wrote: > > On Friday, September 26, 2008 1:36 am Theo Veenker wrote: > >> Jesse Barnes wrote: > >>> On Thursday, September 25, 2008 6:00 am Theo Veenker wrote: > Hi, > > I have an application that presents audio-visual stimuli to subjects. > To be able to precisely synchronize the audio and graphics the > application needs to know when a vsync occurs. My application (from > 1994) doesn't yet use libdrm. I'm using a real-time module which > (among other things) monitors the vretrace bit in the VGA input status > register 1 at 0x3DA and signals the application on each vsync event. > It works fine on most graphics hardware. > > Now I need to make this application work on a laptop with an Intel > 945GM. The vretrace bit at IO address 0x3DA doesn't work (under X) > unless I connect an external VGA display. Then it works, but it > reflects the retrace of the external monitor and not that of the > laptop's LCD screen. > > Since also drmWaitVBlank() didn't work for me on this system, I > applied the change hinted in > http://lists.freedesktop.org/archives/xorg/2007-June/025166.html to > the xf86-video-intel driver (2.4.2). That makes drmWaitVBlank() work > (but only after I briefly run a GL application like glxgears first). > >>> > >>> There's some code in the xf86-video-intel driver to disable vblank > >>> interrupts when no 3D client is running (look for > >>> want_vblank_interrupts in i830_dri.c, you can either remove the code > >>> from > >>> I830DRISetVBlankInterrupt or make that field unconditionally true). > >>> Maybe that's what you already did. > >> > >> Yes that's what I did. With the stock driver drm vblank would only work > >> while running, for instance, glxgears. After the 'fix' I just need to > >> run glxgears once and after that it works. I can live with that. > >> > I understand the LCD screen is on pipe B and the VGA screen on pipe A. > Can I somehow swap current behaviour so that when I monitor IO address > 0x3DA I can detect vretraces for pipe B instead of for pipe A? That > would save me the trouble of hacking DRM into this legacy aplication. > >>> > >>> I think the status bit in 0x3da will correspond to the pipe VGA is > >>> assigned to in VGACNTRL (the headers should have the info you need, if > >>> not check out the docs at http://www.intellinuxgraphics.org). > >> > >> Thanks for the info. Here is what I did. In i830_driver.c I830PreInit() > >> below RestoreHWState() I added this: > >>xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "HACK: setting > >> VGA_PIPE_B_SELECT.\n"); OUTREG(VGACNTRL, pI830->saveVGACNTRL | > >> VGA_PIPE_B_SELECT); > >> > >> Unfortunately the VGA input status register 1 bit 3 still reflects the > >> retraces for the external VGA monitor, instead of the laptop's display > >> panel. So this is problably not correct or I missed something. > >> > >> In Xorg.0.log I read "Output VGA is connected to pipe A" and "Output > >> LVDS is connected to pipe B". Is there a way to swap them, how? And if > >> so would it make a differrence; I mean is it actually possible to have > >> the VGA input status register 1 connected to the LVDS? > > > > I think so, but given that we disable VGA mode during normal operation, > > it may be that you need to have pipe B selected at some point *while* VGA > > mode is active. OTOH there may be other bits you need to set as well. > > You could try searching the docs for the string "VGA" :) > > I'm afraid I'm clueless here as I am not comfortable with the internals of > the driver. Do you mean I need to be running in VGA mode all the time, or > do the VGA_PIPE_B_SELECT while temporarily in VGA mode? > How would one achive that? I'm not sure, you'd have to play around with it. > > But if you just want to poll, there's also a bit in the PIPE*STAT regs > > that indicates whether vblank is active, iirc. > > Thanks. I'm going to check that as well. From kernel space do I need to > call mmap or pci_request_regions etc to gain access to these registers, or > can I just access them at the MMIO base address + register offset? They're part of the regular MMIO BAR on this chip, so if you already have that region mapped you can just offset into it to get at the reg. If you haven't already ioremap'd, then yeah you'd have to do that (or just use pci_iomap to get at the right BAR), then use the readX/writeX accessor functions on the resulting pointer. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Hi, I run such a 2-seater under Debian Sid. 2 cards/monitors/keyboards/mice/servers. But the recent xorg (1:7.3+10) gives an error message: Bus types other than PCI not yet isolable Yet I did it for years with older versions (1:7.2-5) Anyone shed light on the appearance of that message? Hugo Vanwoerkom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pixman with and without SSE2 benchmarks?
On Sep 28, 08 16:53:05 +0200, Roland Scheidegger wrote: > On 28.09.2008 11:52, Clemens Eisserer wrote: > >> I'd bet against that :-). Core 2 has magnificent SSE performance indeed, > >> but that's true for MMX just as well. > > Well, Core2 (and AMD K10) got support for 128bit operations per clock, > > whereas previous processors only supported 64bit at once, and took 2 > > cycles for 128 bit operations. > > MMX is just 64-bit, so it should't matter much there. > Ah yes you're right. Somehow I thought it would execute mmx twice as > fast as well - clearly that's not true. Should indeed be much closer on > older cpus. OTOH pixman w/ SSE does have some severe rendering issues - read bugzilla.novell.org, #426370. I haven't created an upstream bug yet, I can do that if that sounds reasonable. Bottom line is that fbCompositeSolid_nxsse2 is broken. It renders stripes, 4 pixels with the correct alpha, 4 pixels with 1-alpha, repeating. We have seen this on 16bpp as well, but I assume that the source always was 32bpp. So the repeating pattern is 32 bytes or 128 bits... looking familiar? The other rendering paths haven't been extensively tested from our side. Is there a pixman validation tool? I don't know of any, maybe rendertest could be used, but so far it apparently didn't hit this case. Maybe it doesn't do solid rendering, haven't looked at the code. I have close to no experience with SSE2, so I cannot really fix this issue myself. Andre, I CC'ed you because you committed the SSE2 implementation. Thanks Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Bus types other than PCI not yet isolable
Hi, I run a 2-seater (2 videocards/servers/mice/keyboards/monitors) on Debian Sid. That works successfully with xorg 1:7.2-5 (that's Debian's designation). So that's an installation that has not been upgraded recently. Under the recent upgrades with xorg 1:7.3+10 that doesn't work anymore and I get 'Bus types other than PCI not yet isolable'. The relevant isolatedevice's are: command=/usr/bin/X1 :0 -layout X1 -dpi 110 -deferglyphs 16 -isolateDevice \"PCI:1:0:0\" vt7 command=/usr/bin/X0 :1 -layout X0 -dpi 110 -deferglyphs 16 -isolateDevice \"PCI:0:8:0\" -sharevts Can anybody shed light on the reason for that error message that now appears but used to work OK? Hugo Vanwoerkom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
On Mon, Sep 29, 2008 at 03:25:26PM +0200, Simon Thum wrote: > Søren Hauberg wrote: > > This stuff seems to only be in git. It's not in any releases, right? > Yes. It needs a current server also. > > > The information I seem to get from the kernel is (BTN_TOUCH, 1) when > > the stylus is pressed to the screen, and (BTN_TOUCH, 0) when the > > stylus is removed. When I move the stylus around (when its pressed > > onto the screen), I don't get any BTN_TOUCH's. > Then you don't need any hysteresis :) I'd guess the HW does that > internally then. > > If you're curious anyway, from wikipedia: Hysteresis represents states, > and the characteristic curve shape is sometimes remiscent of a two-value > state, also called a bistable state. The hysteresis curve really > contains infinitely many states, but a simple application is to let the > threshold regions (usually to the left and to the right) represent > respectively the on and off states. In this way, the system can be > regarded as bistable. In practical terms it means that if you get a range of pressure values, you set two watermarks on it: a low one and a high one. When the pressure rises above the high watermark, you interpret it as a touch, when the pressure drops below the low watermark, you interpret it as a release. This way if the pressure fluctuates only slightly, you won't get a series of unintentional presses and releases. Marius Gedminas -- This sentence contradicts itself -- no actually it doesn't. -- Douglas Hofstadter signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Søren Hauberg <[EMAIL PROTECTED]>: >> Or - even better, you hook into the default case of the switch statement for >> BTN_TOUCH and let the already existing code handle buttons, draglock, etc. >> (right now you're missing out on this). > > I tried only to break from the switch statement if we're not using a > touch screen. That way, BTN_TOUCH should be handled by the default > case if we're on a touch screen. This, however, seemed to kill the X > server. I haven't had the time to debug it. Just a quick follow-up. I can actually make this work, by setting ev.code = BTN_LEFT. This is fine with me, as I think a touch should be treated like a left button press. However, it might be worth figuring out why the X server dies when the default case has to handle BTN_TOUCH. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Peter Hutterer <[EMAIL PROTECTED]>:
> a few comments to your patch:
>
> @@ -208,14 +224,23 @@
> break;
>
>case EV_ABS:
> +abs = 1;
>
> this is the problem here. You may be defining abs even if we don't have
> absolute x/y axes. Just leave that bit as it is.
Yes, this was just me putting my stupidity on display :-)
>case BTN_TOOL_FINGER:
>case BTN_TOOL_MOUSE:
>case BTN_TOOL_LENS:
> + was_touched = 1;
>pEvdev->tool = value ? ev.code : 0;
>break;
>
> why set was_touched for BTN_TOOL_LENS, etc? It'd be better to move this line
> up to BTN_TOUCH.
Agreed.
> Also - maybe you can find a way to work around was_touched and use
> pEvdev->tool to indicate if a touch is active?
Yeah, I don't like introducing yet another variable either. I'll look
into doing this with pEvdev->tool instead.
> Or - even better, you hook into the default case of the switch statement for
> BTN_TOUCH and let the already existing code handle buttons, draglock, etc.
> (right now you're missing out on this).
I tried only to break from the switch statement if we're not using a
touch screen. That way, BTN_TOUCH should be handled by the default
case if we're on a touch screen. This, however, seemed to kill the X
server. I haven't had the time to debug it.
> Not 100% sure myself if devices like wacom send BTN_TOUCH and if that would
> then interfere with your code. Something to look at I guess.
I don't have such hardware, so I can't be of much assistance here.
> +} else if (pEvdev->flags & EVDEV_TOUCHSCREEN) {
> +if (was_touched) {
> +xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2,
> + pEvdev->abs_x, pEvdev->abs_y);
>
> Maybe only send a motion event when the coordinates actually have changed?
This requires that I keep track of the position of the cursor manually
, right? pEvdev has old_x and old_y for this, so it's fairly easy to
do this.
>> Also, I've hardcoded my own calibration parameters into the patch to
>> ease testing. This is obviously not usable in general. If I want to
>> use device properties (that's what I've been told they're called) to
>> set these parameters, how would I go about doing that?
>
> evdev already has the code for device properties in e.g. draglock.c. Best to
> just check it but maybe wait a day or so, I have changes in the pipe that
> restructure the use of DP in evdev. The API is the same, but the handler
> registration is a bit different.
Okay, I'm leaving the office in a few minutes anyway, so I'll check
things tomorrow.
Thanks,
Søren
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
Søren Hauberg wrote: > This stuff seems to only be in git. It's not in any releases, right? Yes. It needs a current server also. > The information I seem to get from the kernel is (BTN_TOUCH, 1) when > the stylus is pressed to the screen, and (BTN_TOUCH, 0) when the > stylus is removed. When I move the stylus around (when its pressed > onto the screen), I don't get any BTN_TOUCH's. Then you don't need any hysteresis :) I'd guess the HW does that internally then. If you're curious anyway, from wikipedia: Hysteresis represents states, and the characteristic curve shape is sometimes remiscent of a two-value state, also called a bistable state. The hysteresis curve really contains infinitely many states, but a simple application is to let the threshold regions (usually to the left and to the right) represent respectively the on and off states. In this way, the system can be regarded as bistable. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
On Mon, Sep 29, 2008 at 03:08:00PM +0200, Søren Hauberg wrote: > > Look at EvdevInitProperties(). Touchscreen-specifics should be only > > available on > > touchscreens, of course. > > This stuff seems to only be in git. It's not in any releases, right? Yes, it's only in git. The property API was moving around until last week and only just settled (hopefully anyway). For new features it's generally best to look at the git driver, the differences between 2.0 and git are quite significant in some ways. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
Søren:
On Mon, Sep 29, 2008 at 01:29:35PM +0200, Søren Hauberg wrote:
> > Sorry, I wanted to suggest that in reply but missed it. Anyway, be aware
> > that as your patch is now, you're also triggering on absolute axes you can't
> > handle/don't know. I'd consider that a regression.
>
> Ahh, I (think I) see. The attached patch should handle this.
a few comments to your patch:
@@ -208,14 +224,23 @@
break;
case EV_ABS:
+abs = 1;
this is the problem here. You may be defining abs even if we don't have
absolute x/y axes. Just leave that bit as it is.
case BTN_TOOL_FINGER:
case BTN_TOOL_MOUSE:
case BTN_TOOL_LENS:
+ was_touched = 1;
pEvdev->tool = value ? ev.code : 0;
break;
why set was_touched for BTN_TOOL_LENS, etc? It'd be better to move this line
up to BTN_TOUCH.
Also - maybe you can find a way to work around was_touched and use
pEvdev->tool to indicate if a touch is active?
Or - even better, you hook into the default case of the switch statement for
BTN_TOUCH and let the already existing code handle buttons, draglock, etc.
(right now you're missing out on this).
Not 100% sure myself if devices like wacom send BTN_TOUCH and if that would
then interfere with your code. Something to look at I guess.
+} else if (pEvdev->flags & EVDEV_TOUCHSCREEN) {
+if (was_touched) {
+xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2,
+ pEvdev->abs_x, pEvdev->abs_y);
Maybe only send a motion event when the coordinates actually have changed?
> Also, I've hardcoded my own calibration parameters into the patch to
> ease testing. This is obviously not usable in general. If I want to
> use device properties (that's what I've been told they're called) to
> set these parameters, how would I go about doing that?
evdev already has the code for device properties in e.g. draglock.c. Best to
just check it but maybe wait a day or so, I have changes in the pipe that
restructure the use of DP in evdev. The API is the same, but the handler
registration is a bit different.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Simon Thum <[EMAIL PROTECTED]>:
> Søren Hauberg wrote:
>> Ahh, I (think I) see. The attached patch should handle this. It also
>> adds support for clicking the screen, and for my setup it works quite
>
> I meant this:
>
>case EV_ABS:
> +abs = 1;
>switch (ev.code) {
>case ABS_X:
> - pEvdev->abs_x = value;
> - abs = 1;
>
> you're assigning abs = 1 even if none of the absolute axes the device
> advertises has a meaning to the driver. Given you later rely on it, that's
> going to bust someone. Or is that intentional?
Ohh, that? That's just me being stupid :-) I've changed it back to the
way it was. This stuff is new to me, so I'm doing this by trial and
error, to get to know the system.
>> use device properties (that's what I've been told they're called) to
>> set these parameters, how would I go about doing that?
>
> Look at EvdevInitProperties(). Touchscreen-specifics should be only
> available on
> touchscreens, of course.
This stuff seems to only be in git. It's not in any releases, right?
> Regarding BTN_TOUCH: If you're getting a range here, you're better off with
> a hysteresis to decide a button press/release. Synaptics does that, for
> example.
I don't quite understand (to me 'hysteresis' is part of the Canny edge
detector in image processing -- I have no idea what it means here).
The information I seem to get from the kernel is (BTN_TOUCH, 1) when
the stylus is pressed to the screen, and (BTN_TOUCH, 0) when the
stylus is removed. When I move the stylus around (when its pressed
onto the screen), I don't get any BTN_TOUCH's.
Søren
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: accessing legacy(?) VGA input status register 1 on 945GM/xf86-video-intel
Jesse Barnes wrote: > On Friday, September 26, 2008 1:36 am Theo Veenker wrote: >> Jesse Barnes wrote: >>> On Thursday, September 25, 2008 6:00 am Theo Veenker wrote: Hi, I have an application that presents audio-visual stimuli to subjects. To be able to precisely synchronize the audio and graphics the application needs to know when a vsync occurs. My application (from 1994) doesn't yet use libdrm. I'm using a real-time module which (among other things) monitors the vretrace bit in the VGA input status register 1 at 0x3DA and signals the application on each vsync event. It works fine on most graphics hardware. Now I need to make this application work on a laptop with an Intel 945GM. The vretrace bit at IO address 0x3DA doesn't work (under X) unless I connect an external VGA display. Then it works, but it reflects the retrace of the external monitor and not that of the laptop's LCD screen. Since also drmWaitVBlank() didn't work for me on this system, I applied the change hinted in http://lists.freedesktop.org/archives/xorg/2007-June/025166.html to the xf86-video-intel driver (2.4.2). That makes drmWaitVBlank() work (but only after I briefly run a GL application like glxgears first). >>> There's some code in the xf86-video-intel driver to disable vblank >>> interrupts when no 3D client is running (look for want_vblank_interrupts >>> in i830_dri.c, you can either remove the code from >>> I830DRISetVBlankInterrupt or make that field unconditionally true). >>> Maybe that's what you already did. >> Yes that's what I did. With the stock driver drm vblank would only work >> while running, for instance, glxgears. After the 'fix' I just need to run >> glxgears once and after that it works. I can live with that. >> I understand the LCD screen is on pipe B and the VGA screen on pipe A. Can I somehow swap current behaviour so that when I monitor IO address 0x3DA I can detect vretraces for pipe B instead of for pipe A? That would save me the trouble of hacking DRM into this legacy aplication. >>> I think the status bit in 0x3da will correspond to the pipe VGA is >>> assigned to in VGACNTRL (the headers should have the info you need, if >>> not check out the docs at http://www.intellinuxgraphics.org). >> Thanks for the info. Here is what I did. In i830_driver.c I830PreInit() >> below RestoreHWState() I added this: >>xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "HACK: setting >> VGA_PIPE_B_SELECT.\n"); OUTREG(VGACNTRL, pI830->saveVGACNTRL | >> VGA_PIPE_B_SELECT); >> >> Unfortunately the VGA input status register 1 bit 3 still reflects the >> retraces for the external VGA monitor, instead of the laptop's display >> panel. So this is problably not correct or I missed something. >> >> In Xorg.0.log I read "Output VGA is connected to pipe A" and "Output LVDS >> is connected to pipe B". Is there a way to swap them, how? And if so would >> it make a differrence; I mean is it actually possible to have the VGA input >> status register 1 connected to the LVDS? > > I think so, but given that we disable VGA mode during normal operation, it > may > be that you need to have pipe B selected at some point *while* VGA mode is > active. OTOH there may be other bits you need to set as well. You could try > searching the docs for the string "VGA" :) I'm afraid I'm clueless here as I am not comfortable with the internals of the driver. Do you mean I need to be running in VGA mode all the time, or do the VGA_PIPE_B_SELECT while temporarily in VGA mode? How would one achive that? > > But if you just want to poll, there's also a bit in the PIPE*STAT regs that > indicates whether vblank is active, iirc. Thanks. I'm going to check that as well. From kernel space do I need to call mmap or pci_request_regions etc to gain access to these registers, or can I just access them at the MMIO base address + register offset? Theo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Simon Thum <[EMAIL PROTECTED]>: > Søren Hauberg wrote: >> >> 2008/9/29 Peter Hutterer <[EMAIL PROTECTED]>: >>> >>> I'd say that most if not all touchpads have a physical button too, so no >>> button would probably be a good indicator for a touchscreen. >> >> Thanks! So, I guess something like the attached patch could be used to >> handle the two types of devices differently. > > Sorry, I wanted to suggest that in reply but missed it. Anyway, be aware > that as your patch is now, you're also triggering on absolute axes you can't > handle/don't know. I'd consider that a regression. Ahh, I (think I) see. The attached patch should handle this. It also adds support for clicking the screen, and for my setup it works quite well. I'm quite sure if the code is structured in the best way, as I just put the code where ever it seemed to work. Also, I've hardcoded my own calibration parameters into the patch to ease testing. This is obviously not usable in general. If I want to use device properties (that's what I've been told they're called) to set these parameters, how would I go about doing that? Thanks, Søren evdev.patch4 Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
Søren Hauberg wrote: > 2008/9/29 Peter Hutterer <[EMAIL PROTECTED]>: >> I'd say that most if not all touchpads have a physical button too, so no >> button would probably be a good indicator for a touchscreen. > > Thanks! So, I guess something like the attached patch could be used to > handle the two types of devices differently. Sorry, I wanted to suggest that in reply but missed it. Anyway, be aware that as your patch is now, you're also triggering on absolute axes you can't handle/don't know. I'd consider that a regression. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Extra pointer motion with current git xf86-input-synaptics
Peter Hutterer wrote:
> On Sun, Sep 28, 2008 at 07:26:06PM +0200, Simon Thum wrote:
>> rescaleValuatorAxis(int coord, AxisInfoPtr from, AxisInfoPtr to,
>> int defmax)
>> {
>> [...]
>> return (int)(((float)(coord - fmin) + 0.5f) * (tmax - tmin + 1) /
>> (fmax - fmin + 1)) + tmin;
>
>
> The patch below should fix another issue, the scaling from device -> core ->
> device. With the patch below, x/y is now used as it is reported by the device
> (unless a screen cross happens).
Great, that's fixing what my patch merely conceals. However, I'm in
favor of applying both. With translation in place, rounding to nearest
is simply avoiding errors.
Cheers,
Simon
> diff --git a/dix/getevents.c b/dix/getevents.c
> index 166ab4e..f2086e8 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -919,17 +919,22 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev,
> int type, int buttons,
> master->last.valuators[1] = pDev->last.valuators[1];
> }
>
> +/* Crossed screen? Scale back to device coordiantes */
> if(cx != pDev->last.valuators[0])
> +{
> +scr = miPointerGetScreen(pDev);
> +x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
> +pDev->valuator->axes + 0, scr->width);
> cx = pDev->last.valuators[0];
> +}
> if(cy != pDev->last.valuators[1])
> +{
> +scr = miPointerGetScreen(pDev);
> cy = pDev->last.valuators[1];
> +y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
> +pDev->valuator->axes + 1, scr->height);
> +}
>
> -/* scale x/y back to device coordinates */
> -scr = miPointerGetScreen(pDev);
> -x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
> -pDev->valuator->axes + 0, scr->width);
> -y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
> -pDev->valuator->axes + 1, scr->height);
>
> updateMotionHistory(pDev, ms, first_valuator, num_valuators,
> &pDev->last.valuators[first_valuator]);
> @@ -938,7 +943,6 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev,
> int type, int buttons,
> &pDev->last.valuators[first_valuator]);
>
> /* Update the valuators with the true value sent to the client*/
> -/* FIXME: we lose subpixel precision here. */
> if(v0) *v0 = x;
> if(v1) *v1 = y;
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xephyr, DRI, and compiz
Am Freitag, den 26.09.2008, 13:42 -0700 schrieb Yan Seiner: > I am trying to get Xephyr running with compiz. The following was > generated with xserver 1.5.0 and xephyr 1.5.0. I've had the same results > with 1.5.1. Why not using Xglx ? (I know it's a bit rusted now, but it was specially designed to run compiz, and does layer itself above an existing X server) > -- Thomas Ilnseher <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Getting xorg-7.4 from git ?
Donnie Berkholz <[EMAIL PROTECTED]> writes: > On 08:27 Fri 26 Sep , Carl Worth wrote: >> On Fri, 2008-09-26 at 01:14 -0700, David Sharp wrote: >> > this could be made easier by tagging releases for the katamari with a >> > common tag, like "Xorg-7.4" >> >> And even easier with a super-module repository that would just need one >> tag. Didn't Zack even prototype such a thing once? Has anyone looked >> into how reasonable it would be to use such a thing for releases? >> >> I've heard some claim that the supermodule approach wouldn't work well >> for just tracking the latest development at the tip of all the master >> branches, but it sounds perfect for tracking releases. > > When git folks added submodule support, somehow they managed to miss the > (obvious to me) use case of tracking all the submodule HEADs instead of > sticking to specific commits. It was even discussed in the thread where > the patch was proposed, and an early version of the patch did track > HEADs. If this is a blocker, it shouldn't be much work to add a flag for > it. > I thought it was strange at first, too. But once I had thought about it, I came to the conclusion that the current behaviour is what you want. What you'll realize when you understand the various use cases is that there is no truly correct behaviour. And the current one is probably the one with the least nasty surprises. For example, in the "correct" case where all the submodules are truly independent projects, you don't want magic dependencies between the tags/branches in those (independent) projects. It's just nasty. Consider checking out "master" of the supermodule. If you get the revisions of the submodule that was actually used when "master" on the supermodule was checked in, it works as intended. But if you instead get the "master" branches of the submodules, all bets are off. The alternative, making special branches in the submodule for the supermodule, is obviously getting the dependencies between modules turned the wrong way around (the submodule should not need to know that it is used by the supermodule). The use case for doing it differently is when the git repos are not independent projects, but a single project split into small pieces. I guess in the case of X, many of the modules makes little sense outside of X. But that is not the use case that git submodule support is designed to solve. And I would say it is not the most important use case to handle. The submodule support in git has many problems. Everybody knows it, but I think the git people are worried about breaking it beyond repair. Which seems to be a sensible approach right now. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
2008/9/29 Peter Hutterer <[EMAIL PROTECTED]>: > I'd say that most if not all touchpads have a physical button too, so no > button would probably be a good indicator for a touchscreen. Thanks! So, I guess something like the attached patch could be used to handle the two types of devices differently. Søren evdev.patch3 Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does touchpads have buttons?
On Mon, Sep 29, 2008 at 09:42:22AM +0200, Søren Hauberg wrote: > I'm trying to differentiate touchpads from touchscreens in the evdev > driver. Both types of devices has absolute axis, and emit the > BTN_TOUCH signal. So, I need something else to tell them apart. > Unfortunately, I don't have access to a touchpad (the only one I have > is broken), so I can't figure out if such a device has other > interesting properties. So, my question is: does touchpads have > buttons, i.e. do they emit BTN_LEFT? Touchscreens don't (at least the > ones using the 'usbtouchscreen' kernel module doesn't), so I might be > able to use this as a differentiator. Here's the output of my touchpad, it advertises LMR button. I'd say that most if not all touchpads have a physical button too, so no button would probably be a good indicator for a touchscreen. [EMAIL PROTECTED]:~$ sudo ./evtest /dev/input/event5 Input driver version is 1.0.0 Input device ID: bus 0x11 vendor 0x2 product 0x7 version 0x81b1 Input device name: "SynPS/2 Synaptics TouchPad" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 325 (ToolFinger) Event code 330 (Touch) Event code 333 (Tool Doubletap) Event code 334 (Tool Tripletap) Event type 3 (Absolute) Event code 0 (X) Value 1 Min 1472 Max 5472 Event code 1 (Y) Value 5855 Min 1408 Max 4448 Event code 24 (Pressure) Value 0 Min0 Max 255 Event code 28 (Tool Width) Value 0 Min0 Max0 Testing ... (interrupt to exit) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Does touchpads have buttons?
Hi, I'm trying to differentiate touchpads from touchscreens in the evdev driver. Both types of devices has absolute axis, and emit the BTN_TOUCH signal. So, I need something else to tell them apart. Unfortunately, I don't have access to a touchpad (the only one I have is broken), so I can't figure out if such a device has other interesting properties. So, my question is: does touchpads have buttons, i.e. do they emit BTN_LEFT? Touchscreens don't (at least the ones using the 'usbtouchscreen' kernel module doesn't), so I might be able to use this as a differentiator. Thanks, Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
