[ANNOUNCE] xf86-input-evdev 2.0.6
Fix for Launchpad bug 276887: the X server still receives events even even when VT-switched away. These events are then partially replayed on the currently focused client when re-entering the VT. Thanks to bryce and mjg59 for their help fixing this. Peter Hutterer (2): Close fd on DEVICE_OFF. (LP #276887) evdev 2.0.6 git tag: xf86-input-evdev-2.0.6 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.6.tar.bz2 MD5: 499abf720b8c8ab0be1f3c0c62b2a399 xf86-input-evdev-2.0.6.tar.bz2 SHA1: fb84b919f2852fc345e62f7e17a209957e1304bc xf86-input-evdev-2.0.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.6.tar.gz MD5: 2f0ffbbe40418a615c80ba39da7da666 xf86-input-evdev-2.0.6.tar.gz SHA1: 39ec8a73a00b73542862b1ade4cc53a0fe2e3201 xf86-input-evdev-2.0.6.tar.gz signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
On Wed, 2008-10-01 at 21:39 -0300, Tiago Vignatti wrote: > A mutex is needed because the X event queue is a critical region. Though > the X event queue is re-entrant, we cannot guarantee the simultaneous > processing by both main and input threads. The input queue is written so that each user modifies only one of the two pointers (head and tail). There shouldn't be any need to have a mutex which protects both of these values together, and doing so prevents mouse motion while the server is processing events. Is there something fundamentally different between threaded input and SIGIO- or kernel-based input that I'm missing here? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/4] ddx (xfree86) implementation of the input-thread
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
>From ad5f1295fb2db4f978f44f54770c0e91cebc9fcd Mon Sep 17 00:00:00 2001
From: Tiago Vignatti <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 21:19:08 -0300
Subject: [PATCH] ddx (xfree86) implementation of the input-thread.
Signed-off-by: Tiago Vignatti <[EMAIL PROTECTED]>
---
hw/xfree86/common/xf86Events.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index 15dce9f..50ed0f5 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -321,7 +321,19 @@ xf86Wakeup(pointer blockData, int err, pointer pReadmask)
if (xf86VTSwitchPending()) xf86VTSwitch();
}
+#ifdef INPUT_THREAD
+/*
+ * xf86ThreadReadInput --
+ *signal handler for the input thread.
+ */
+static void
+xf86ThreadReadInput(void *closure)
+{
+InputInfoPtr pInfo = (InputInfoPtr) closure;
+pInfo->read_input(pInfo);
+}
+#else
/*
* xf86SigioReadInput --
*signal handler for the SIGIO signal.
@@ -339,6 +351,7 @@ xf86SigioReadInput(int fd,
xf86UnblockSIGIO(sigstate);
errno = errno_save;
}
+#endif
/*
* xf86AddEnabledDevice --
@@ -347,9 +360,13 @@ xf86SigioReadInput(int fd,
_X_EXPORT void
xf86AddEnabledDevice(InputInfoPtr pInfo)
{
+#ifdef INPUT_THREAD
+AddEnabledDeviceThreaded (pInfo->fd, xf86ThreadReadInput, pInfo);
+#else
if (!xf86InstallSIGIOHandler (pInfo->fd, xf86SigioReadInput, pInfo)) {
AddEnabledDevice(pInfo->fd);
}
+#endif
}
/*
@@ -359,9 +376,13 @@ xf86AddEnabledDevice(InputInfoPtr pInfo)
_X_EXPORT void
xf86RemoveEnabledDevice(InputInfoPtr pInfo)
{
+#ifdef INPUT_THREAD
+RemoveEnabledDeviceThreaded(pInfo->fd);
+#else
if (!xf86RemoveSIGIOHandler (pInfo->fd)) {
RemoveEnabledDevice(pInfo->fd);
}
+#endif
}
static int *xf86SignalIntercept = NULL;
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 3/4] dix implementation of the input-thread
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
>From 6414b27901b2d802ceb86b27adb066ff6f6357e5 Mon Sep 17 00:00:00 2001
From: Tiago Vignatti <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 21:18:07 -0300
Subject: [PATCH] dix implementation of the input-thread.
All stuff is wrapped by INPUT_THREAD macro. So is possible to use
--{disable, enable}-input-thread to {un,}set it. This is worth in the aspects
of debug (e.g. gdb is a really sh*t in multi-thread enviroments).
The input thread is enabled by default.
Signed-off-by: Tiago Vignatti <[EMAIL PROTECTED]>
---
configure.ac|8 ++
dix/main.c | 11 +
include/dix-config.h.in |3 ++
include/opaque.h|3 ++
include/os.h| 17 ++
os/Makefile.am |7 +-
os/WaitFor.c|8 ++
os/connection.c | 55 ++-
8 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index d768546..05ae3cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -495,6 +495,9 @@ AC_ARG_ENABLE(builtin-fonts, AS_HELP_STRING([--enable-builtin-fonts], [Use only
AC_ARG_ENABLE(null-root-cursor, AS_HELP_STRING([--enable-null-root-cursor], [Use an empty root cursor (default: use core cursor)]),
[NULL_ROOT_CURSOR=$enableval],
[NULL_ROOT_CURSOR=no])
+AC_ARG_ENABLE(input-thread, AS_HELP_STRING([--enable-input-thread], [Use a separate thread for input devices (default: yes)]),
+[INPUT_THREAD=$enableval],
+[INPUT_THREAD=yes])
dnl GLX build options
AC_ARG_WITH(mesa-source, AS_HELP_STRING([--with-mesa-source=MESA_SOURCE], [Path to Mesa source tree]),
@@ -933,6 +936,11 @@ if test "x$BUILTIN_FONTS" = xyes; then
FONTPATH="built-ins"
fi
+AM_CONDITIONAL(INPUT_THREAD, [test "x$INPUT_THREAD" = xyes])
+if test "x$INPUT_THREAD" = xyes; then
+ AC_DEFINE(INPUT_THREAD, 1, [Use a separate thread for input devices])
+fi
+
if test "x$XCALIBRATE" = xyes && test "$KDRIVE" = yes; then
AC_DEFINE(XCALIBRATE, 1, [Build XCalibrate extension])
REQUIRED_MODULES="$REQUIRED_MODULES xcalibrateproto"
diff --git a/dix/main.c b/dix/main.c
index 267aba5..ac8f010 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -281,6 +281,9 @@ int main(int argc, char *argv[], char *envp[])
config_init();
if(serverGeneration == 1)
{
+#ifdef INPUT_THREAD
+InitInputThread();
+#endif
CreateWellKnownSockets();
InitProcVectors();
for (i=1; i= 0; i--)
{
FreeScratchPixmapsForScreen(i);
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 06138c5..64c6f40 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -436,4 +436,7 @@
/* Define to 1 if you have the `ffs' function. */
#undef HAVE_FFS
+/* Define to 1 to use the input thread */
+#undef INPUT_THREAD
+
#endif /* _DIX_CONFIG_H_ */
diff --git a/include/opaque.h b/include/opaque.h
index 07a0715..0ba1a10 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -36,6 +36,9 @@ from The Open Group.
extern char *defaultTextFont;
extern char *defaultCursorFont;
extern int MaxClients;
+#ifdef INPUT_THREAD
+extern int MaxInputDevices;
+#endif
extern volatile char isItTimeToYield;
extern volatile char dispatchException;
diff --git a/include/os.h b/include/os.h
index bfe2363..26fc089 100644
--- a/include/os.h
+++ b/include/os.h
@@ -169,6 +169,23 @@ extern void MakeClientGrabPervious(ClientPtr /*client*/);
extern void ListenOnOpenFD(int /* fd */, int /* noxauth */);
#endif
+#ifdef INPUT_THREAD
+extern void InitInputThread(void);
+
+extern void CreateInputThread(void);
+
+extern void CloseInputThread(void);
+
+extern void AddEnabledDeviceThreaded(int /*fd*/, void (*f)(void *),
+ void *closure);
+
+extern void RemoveEnabledDeviceThreaded(int /*fd*/);
+
+extern int PipeRead(int /* fd */);
+
+extern void PipeWrite(int /* fd */);
+#endif
+
extern void AvailableClientInput(ClientPtr /* client */);
extern CARD32 GetTimeInMillis(void);
diff --git a/os/Makefile.am b/os/Makefile.am
index 16ecc15..5601d67 100644
--- a/os/Makefile.am
+++ b/os/Makefile.am
@@ -7,6 +7,10 @@ XDMCP_SRCS = xdmcp.c
STRLCAT_SRCS = strlcat.c strlcpy.c
XORG_SRCS = log.c
+if INPUT_THREAD
+INPUT_THREAD_SRC = inputthread.c
+endif
+
libos_la_SOURCES = \
WaitFor.c \
access.c \
@@ -23,7 +27,8 @@ libos_la_SOURCES = \
xdmauth.c \
xstrans.c \
xprintf.c \
- $(XORG_SRCS)
+ $(XORG_SRCS) \
+ $(INPUT_THREAD_SRC)
if SECURE_RPC
libos_la_SOURCES += $(SECURERPC_SRCS)
diff --git a/os/WaitFor.c b/os/WaitFor.c
index d6dd995..5d2a361 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -125,6 +125,9 @@ static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
static void CheckAllTimers(void);
static OsTimerPtr timers = NULL;
+#
[PATCH 2/4] X event queue mutex
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
>From 6e0692f6a5757b6d838d857bdb68596a5208c6e2 Mon Sep 17 00:00:00 2001
From: Tiago Vignatti <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 21:15:15 -0300
Subject: [PATCH] X event queue mutex.
A mutex is needed because the X event queue is a critical region. Though
the X event queue is re-entrant, we cannot guarantee the simultaneous
processing by both main and input threads.
Signed-off-by: Tiago Vignatti <[EMAIL PROTECTED]>
---
mi/mieq.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/mi/mieq.c b/mi/mieq.c
index 0a1b740..f9f9d8f 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -53,6 +53,10 @@ in this Software without prior written authorization from The Open Group.
# include "extinit.h"
# include "exglobals.h"
+#ifdef INPUT_THREAD
+#include
+#endif
+
#ifdef DPMSExtension
# include "dpmsproc.h"
# define DPMS_SERVER
@@ -81,6 +85,13 @@ typedef struct _EventQueue {
static EventQueueRec miEventQueue;
+#ifdef INPUT_THREAD
+/* We need mutex because the X event queue is a critical region.
+Though the X event queue is re-entrant, we cannot guarantee the
+simultaneous processing by both main and input threads. */
+pthread_mutex_t miEventQueueMutex = PTHREAD_MUTEX_INITIALIZER;
+#endif
+
Bool
mieqInit(void)
{
@@ -122,6 +133,9 @@ mieqResizeEvents(int min_size)
void
mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(&miEventQueueMutex);
+#endif
unsigned int oldtail = miEventQueue.tail, newtail;
EventListPtr evt;
intisMotion = 0;
@@ -146,6 +160,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (laste->nevents > 6) {
ErrorF("[mi] mieqEnqueue: more than six valuator events; dropping.\n");
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
return;
}
if (oldtail == miEventQueue.head ||
@@ -157,10 +174,16 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
((lastkbp->deviceid & DEVICE_BITS) !=
(v->deviceid & DEVICE_BITS))) {
ErrorF("[mi] mieqEnequeue: out-of-order valuator event; dropping.\n");
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
return;
}
memcpy((laste->events[laste->nevents++].event), e, sizeof(xEvent));
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
return;
}
@@ -176,6 +199,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (newtail == miEventQueue.head) {
ErrorF("[mi] EQ overflowing. The server is probably stuck "
"in an infinite loop.\n");
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
return;
}
miEventQueue.tail = newtail;
@@ -193,6 +219,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (!evt->event)
{
ErrorF("[mi] Running out of memory. Tossing event.\n");
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
return;
}
}
@@ -212,24 +241,43 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
miEventQueue.events[oldtail].pDev = pDev;
miEventQueue.lastMotion = isMotion;
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
}
void
mieqSwitchScreen(DeviceIntPtr pDev, ScreenPtr pScreen, Bool fromDIX)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(&miEventQueueMutex);
+#endif
+
EnqueueScreen(pDev) = pScreen;
if (fromDIX)
DequeueScreen(pDev) = pScreen;
+
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
}
void
mieqSetHandler(int event, mieqHandler handler)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(&miEventQueueMutex);
+#endif
+
if (handler && miEventQueue.handlers[event])
ErrorF("[mi] mieq: warning: overriding existing handler %p with %p for "
"event %d\n", miEventQueue.handlers[event], handler, event);
miEventQueue.handlers[event] = handler;
+
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
}
/**
@@ -304,6 +352,10 @@ mieqProcessInputEvents(void)
xEvent* event,
*master_event = NULL;
+#ifdef INPUT_THREAD
+pthread_mutex_lock(&miEventQueueMutex);
+#endif
+
while (miEventQueue.head != miEventQueue.tail) {
if (screenIsSaved == SCREEN_SAVER_ON)
dixSaveScreens (serverClient, SCREEN_SAVER_OFF, ScreenSaverReset);
@@ -390,5 +442,8 @@ mieqProcessInputEvents(void)
miPointerUpdateSprite(e->pDev);
}
}
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(&miEventQueueMutex);
+#endif
}
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
[PATCH 1/4] The input thread core file implementation
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
>From 856d2e3906a9a3f1ea55249f43e1ea1310f22d2d Mon Sep 17 00:00:00 2001
From: Tiago Vignatti <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 21:13:26 -0300
Subject: [PATCH] The input-thread core file implementation.
Signed-off-by: Tiago Vignatti <[EMAIL PROTECTED]>
---
os/inputthread.c | 280 ++
1 files changed, 280 insertions(+), 0 deletions(-)
create mode 100644 os/inputthread.c
diff --git a/os/inputthread.c b/os/inputthread.c
new file mode 100644
index 000..e2eb15f
--- /dev/null
+++ b/os/inputthread.c
@@ -0,0 +1,280 @@
+/* inputthread.c -- The input thread implementation.
+ *
+ * Copyright 2007-2008 Tiago Vignatti <[EMAIL PROTECTED]>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Except as contained in this notice, the name of the copyright holder(s)
+ * and author(s) shall not be used in advertising or otherwise to promote
+ * the sale, use or other dealings in this Software without prior written
+ * authorization from the copyright holder(s) and author(s).
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include
+#endif
+
+#include
+#include
+#include
+#include
+
+#include "inputstr.h"
+#include "opaque.h"
+
+
+static int WaitForInput(void* argument);
+
+typedef struct _InputDeviceFunc {
+void(*f) (void *);
+int fd;
+void*closure;
+} InputDeviceFunc;
+
+InputDeviceFuncDevFunc[MAX_DEVICES];
+
+fd_set InputThreadFd; /* Devices monitored by the input thread */
+int MainThreadReadPipe = -1;
+int MainThreadWritePipe = -1;
+int InputThreadReadPipe = -1;
+int InputThreadWritePipe = -1;
+
+pthread_t tid_input;
+
+
+void
+InitInputThread(void)
+{
+int i, main_to_input[2], input_to_main[2];
+
+/* The "communication channel" between the input and main thread in
+ * both ways.*/
+if (pipe(main_to_input) < 0) {
+perror("pipe");
+exit(1);
+}
+if (pipe(input_to_main) < 0) {
+perror("pipe");
+exit(1);
+}
+
+/* Make the pipes nonblocking */
+fcntl(main_to_input[0], F_SETFL, O_NONBLOCK);
+fcntl(main_to_input[1], F_SETFL, O_NONBLOCK);
+fcntl(input_to_main[0], F_SETFL, O_NONBLOCK);
+fcntl(input_to_main[1], F_SETFL, O_NONBLOCK);
+
+MainThreadReadPipe = main_to_input[0];
+MainThreadWritePipe = main_to_input[1];
+InputThreadReadPipe = input_to_main[0];
+InputThreadWritePipe = input_to_main[1];
+
+
+FD_ZERO(&InputThreadFd);
+
+for (i = 0; i < MAX_DEVICES; i++)
+DevFunc[i].fd = 0;
+}
+
+/*
+ * Called by the dix to create the input thread.
+ */
+void
+CreateInputThread (void)
+{
+pthread_t input_thread;
+pthread_attr_t attr;
+
+pthread_attr_init(&attr);
+
+/* In OSes that differentiates processes and threads this could have some
+ * sense. Linux uses 1:1 thread model. The scheduler handles every thread
+ * as if it were a process. Therefore this bellow have no meaning if your
+ * OS is Linux.
+ */
+if (pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM) != 0)
+perror("error setting input thread scope");
+
+if (pthread_attr_setstacksize(&attr, PTHREAD_STACK_MIN) != 0)
+perror("error setting input thread stack size");
+
+pthread_create(&input_thread, &attr, (void *)&WaitForInput, NULL);
+pthread_attr_destroy (&attr);
+}
+
+/*
+ * Called by the dix to close the input thread cleanly.
+ *
+ * TODO: This is a blinded implementation due X server regenaration
+ * is currently broken.
+ */
+void
+CloseInputThread (void)
+{
+RemoveEnabledDevice(MainThreadReadPipe);
+FD_ZERO(&InputThreadFd);
+
+pthread_kill(tid_input, SIGKILL);
+}
+
+/*
+ * Create connections in the input thread. Must be called by the
+ * DDX implementation.
+ */
+void
+AddEnabledDeviceThreaded(int fd, void (*f)(void *), void *closure)
+{
+int i;
+
+FD_S
[PATCH 0/4] X server's input thread (resending)
Hi, Here attached are the patches against the server to separate its input generation code in another thread. The main difference in this second try is the hook to put hotplug devices to work and the pthread consistency in all code. configure.ac |8 + dix/main.c | 11 + hw/xfree86/common/xf86Events.c | 21 +++ include/dix-config.h.in|3 include/opaque.h |3 include/os.h | 17 ++ mi/mieq.c | 55 os/Makefile.am |7 - os/WaitFor.c |8 + os/connection.c| 55 +++- os/inputthread.c | 280 + 11 files changed, 466 insertions(+), 2 deletions(-) Thanks, -- 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
[ANNOUNCE] xf86-input-mutouch 1.2.1
mutouch 1.2.0 has issues with the current X server as it does not handle inverted axes (or handles them as inverted even when they aren't). This is fixed now, and I have anecdotal evidence that it even works. Peter Hutterer (6): Check for XINPUT ABI 3. Remove trailing whitespaces. Handle axis inversion in the driver. Fix stupid typos from last patch. Remove pre-XFREE86_V4 cruft. mutouch 1.2.1 git tag: xf86-input-mutouch-1.2.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.2.1.tar.bz2 MD5: f28998cdfae2a4c41589299a4ee1f459 xf86-input-mutouch-1.2.1.tar.bz2 SHA1: c5883c2c5cc80186f711751e8847c9c07f2e4448 xf86-input-mutouch-1.2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.2.1.tar.gz MD5: d2690ccc09b86e81eaaeb5aa522fe8e0 xf86-input-mutouch-1.2.1.tar.gz SHA1: 528fa6d5b33fecfbc6ac0809601ae20fa7b1f302 xf86-input-mutouch-1.2.1.tar.gz signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Need PCI express 16 video card capable of 1680x1050 resolution
On Wed, 2008-10-01 at 12:37 -0700, Paul J. White wrote: > >G33 is supported in at least version 2.4.2 of the intel driver, and > >possibly earlier. > > I will check the Intel driver version later. What's the best way to > determine the version number? The intel driver puts its version number into the X log file when its module is loaded, so look there. For example: $ grep -A1 'Module intel' /var/log/Xorg.0.log (II) Module intel: vendor="X.Org Foundation" compiled for 1.5.99.1, module version = 2.5.96 -Carl ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Need PCI express 16 video card capable of 1680x1050 resolution
At 10:58 AM 10/1/2008, Adam Jackson wrote: >On Tue, 2008-09-30 at 07:49 -0700, Paul White wrote: >> I have a new Dell Inspiron computer with built-in Intel 82G33/G31 video. >> The Intel driver apparently doesn't recognize this specific chipset and >> defaults to using vesa, which doesn't support my monitor's native >> resolution of 1680x1050. >> >> Is there any work being done to support this 82G33 chipset? > >G33 is supported in at least version 2.4.2 of the intel driver, and >possibly earlier. I will check the Intel driver version later. What's the best way to determine the version number? >> If not, can anyone recommend a specific, currently available, X.org >> supported video card that will fit an available PCI express x16 (or PCI >> express x1) slot and work with my monitor? I don't need 3D graphics. > >Any given radeon or geforce. I tried this one (GeForce 8400 GS): http://www.newegg.com/Product/Product.aspx?Item=N82E16814121235&nm_mc=TEMC-RMA-Approvel&cm_mmc=TEMC-RMA-Approvel-_-Content-_-text-_- ... and the nv driver didn't work with it. Again, vesa worked, but only at the wrong screen resolution. -- Paul White >___ >xorg mailing list >xorg@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
Christian Pössinger wrote: > Now I used the latest siliconmotion driver from the XOrg GIT and removed > the PCI function calls to access the device via Local Plus Bus of the > TQM5200 board. > > I initialize the pSmi->MapBase and pSmi->FbBase fields with a mmap() call > to /dev/mem and the proper adresses. > > After the module started up I see the following output with "X -verbose 9" Does the kernel framebuffer work? In that case, there is a fallback option "UseFBDev", that will not attempt to program the hardware, other then the accel registers. > == > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in > (II) do I need RAC? No, I don't. > (II) resource ranges after preInit: > [0] 0 0 0xe3e0 - 0xe400 (0x21) MX[B] > [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) > [2] -1 0 0x000f - 0x000f (0x1) MX[B] > [3] -1 0 0x000c - 0x000e (0x3) MX[B] > [4] -1 0 0x - 0x0009 (0xa) MX[B] > [5] -1 0 0x8000 - 0x8003 (0x4) MX[B] > [6] -1 0 0x - 0x (0x1) IX[B] > [7] -1 0 0x - 0x00ff (0x100) IX[B] > (II) SMI(0): Physical MMIO at 0xE3E0 > (II) SMI(0): Logical MMIO at 0x48a4c000 - 0x48c4bfff > (II) SMI(0): DPR=0x48b4c000, VPR=0x48a4c000, IOBase=(nil) > (II) SMI(0): DataPort=0x48b5c000 - 0x48b6bfff > (II) SMI(0): Physical frame buffer at 0xE000 offset: 0x > (II) SMI(0): Logical frame buffer at 0x48c4c000 - 0x4944bfff > (II) SMI(0): Cursor Offset: 007FF800 > (II) SMI(0): Reserved: 007FF000 > (II) SMI(0): FrameBuffer Box: 0,480 - 640,6550 > (II) SMI(0):SMI_GEReset called from smi_accel.c line 131 > (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 > (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 > == This is completely illogical in the current sources, but it matches SMI sources I received, it just checks if PCIRetry is enabled in the WaitQueue() macro, see regsmi.h:195. I hope to investigate it soon, to understand why a macro that should be checking the fifo, just ignores it's argument, and does something completely different... > The driver doesn't display anything now, instead it calls the SMI_GEReset > function until I reset the device. When I set "pSmi->NoAccel = TRUE;" > there seems to be no call to SMI_GEReset, at least none is displayed on > the console, but the display is still black. > > I would appreciate it if anyone is able to supply me with a flash of > inspiration. Other then the UseFBDev option. I hope to have a more complete mode setting code soon, based on more recent information I received from SMI; information about the 502 clocks, and the differences with earlier releases, that are not clearly documented in the pdfs available at ftp.siliconmotion.com. > Best regards, > Christian Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Need PCI express 16 video card capable of 1680x1050 resolution
On Tue, 2008-09-30 at 07:49 -0700, Paul White wrote: > I have a new Dell Inspiron computer with built-in Intel 82G33/G31 video. > The Intel driver apparently doesn't recognize this specific chipset and > defaults to using vesa, which doesn't support my monitor's native > resolution of 1680x1050. > > Is there any work being done to support this 82G33 chipset? G33 is supported in at least version 2.4.2 of the intel driver, and possibly earlier. > If not, can anyone recommend a specific, currently available, X.org > supported video card that will fit an available PCI express x16 (or PCI > express x1) slot and work with my monitor? I don't need 3D graphics. Any given radeon or geforce. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xorg slowness [quite long]
Hi all, I'm not sure if it's the right list, in case it isn't feel free to point me to correct one :) I'm running a Slackware 12.1 on a Intel P4 3Ghz, 2Gb ram and a Intel 82865G Integrated graphics card (integrated on a Asus P4P800-MX motherboard). Here you are what returns lspci: 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Unknown device 2572 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f000 (32-bit, prefetchable) [size=128M] Memory at fe78 (32-bit, non-prefetchable) [size=512K] I/O ports at eff0 [size=8] Capabilities: [d0] Power Management version 1 Kernel modules: intelfb I'm also running KDE 3.5.9, and everythings goes slow. Very slow. On the top of the 'top' command (sorry for the word loop) there is always X: PID USERPR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2750 root 20 0 242m 20m 4400 S6 1.01:31.71 X So, I'm there asking if the problem is my xorg.conf!! Here you are: [EMAIL PROTECTED]:/home/g4b0# more /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/share/X11/rgb" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/TTF" FontPath "/usr/share/fonts/OTF" FontPath "/usr/share/fonts/Type1" FontPath "/usr/share/fonts/misc" FontPath "/usr/share/fonts/75dpi/:unscaled" FontPath "/usr/share/fonts/TrueType/" EndSection Section "Module" Load "glx" Load "extmod" Load "vnc" Load "xtrap" Load "record" Load "GLcore" Load "dbe" Load "dri" Load "freetype" Load "type1" #SubSection "extmod" # Option "omit XFree86-DGA" #EndSubSection EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 340 270 # mm Identifier "Monitor0" VendorName "PHL" ModelName"Philips 170S" ### Comment all HorizSync and VertRefresh values to use DDC: HorizSync30.0 - 83.0 VertRefresh 56.0 - 76.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "ColorKey" # #Option "CacheLines"# #Option "Dac6Bit" # [] Option "DRI" "true" # [] #Option "NoDDC" # [] #Option "ShowCache" # [] #Option "XvMCSurfaces" # #Option "PageFlip" # [] Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "82865G Integrated Graphics Controller" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Any help will be appreciated. Thanks a lot -- g4b0, linux user n. 369000 http://gabo.homelinux.com ___ 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
Keith Packard wrote: > On Tue, 2008-09-30 at 17:28 +0100, Barry Scott wrote: > > >> For example mozilla (mozembed). The -nocursor patch avoids the need to >> modify >> any app code at all to remove the unwanted cursors. >> > > Have you tried the XFixes HideCursor request yet? That disables the > cursor on a specific screen. > > I wrote a small program that does: XFixesHideCursor( dpy, DefaultRootWindow( dpy ) ); and that does not do what my -nocursor patch does. I still see the cursor over an applications window. Are you expecting that I have to hunt down every windows on the screen and call hide on it? Also When I call: XFixesShowCursor( dpy, DefaultRootWindow( dpy ) ); I get: xfixes example XFixesQueryExtension => 1 event_base: 113 error_base: 180 XFixesQueryVersion => 1 major_version: 4 minor_version: 0 XFixesShowCursor X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 153 (XFIXES) Minor opcode of failed request: 30 () Serial number of failed request: 9 Current serial number in output stream: 11 Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
On Wed, 2008-10-01 at 13:56 +0200, Søren Hauberg wrote: > I've found two calibration programs online. One came without a > license, making it non-free software, and the other one had a > non-so-nice gui, where you had to move your stylus all the way up the > corners of the screen (this one I couldn't present to a custumor). > These programs seems to have the problem that they require direct > access to the touchscreen device, which means X can't have access to > it (at least not when using evdev). i work around this by writing raw touch coordinates to a shared memory segment from within the X driver. the calibration program reads this memory segment and does its thing without direct access to the hardware. maybe not the cleanest way to do it, but i couldn't come up with a nicer idea. clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
2008/10/1 Clemens Kirchgatterer <[EMAIL PROTECTED]>: >> Everybody: does anybody have any thought on where I should host my >> calibration code? > > isn't there something in tslib already? I've found two calibration programs online. One came without a license, making it non-free software, and the other one had a non-so-nice gui, where you had to move your stylus all the way up the corners of the screen (this one I couldn't present to a custumor). These programs seems to have the problem that they require direct access to the touchscreen device, which means X can't have access to it (at least not when using evdev). Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
On Wed, 2008-10-01 at 11:45 +0200, Søren Hauberg wrote: > > instead of flip_x and flip_y you could just swap the min_* and max_* > > values and let the driver axis_validator function handle the flipping, > > works for me. > > Good point. Perhaps the recently added 'invert_[x|y]' options in the > evdev driver should be removed? Perhaps not, as such an option might > be generally usable. > > BTW, what driver are you using for your touchscreen? it is my own hacked up touchscreen driver for elo usb and 3M usb touchscreens. i have to support these two completly different touchscreens through one driver so, first there is no need to edit xorg.conf and second calibration works exactly the same. > Everybody: does anybody have any thought on where I should host my > calibration code? isn't there something in tslib already? best regards ... clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [sugar] rendering test
On Tue, 2008-09-30 at 21:30 +0200, Bernie Innocenti wrote: > Michel Dänzer wrote: > > On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: > >> > >> My performance tests with X 1.3 and 1.4 had shown that turning on EXA > >> makes many operations slower. It's hard to tell why, but it might have to > >> do with loosing XShmPut() (MIT shared memory), > > > > EXA does support XShmPutImage(), just not SHM pixmaps. > > I was remembering the code. > > As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer > being used. Shall I commit a cleanup? ShmPutImage is still accelerated though (also, that commit is only in 1.5, not 1.4). What kind of cleanup do you have in mind? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
2008/10/1 Clemens Kirchgatterer <[EMAIL PROTECTED]>: > On Tue, 2008-09-30 at 17:05 +0200, Søren Hauberg wrote: > >> I don't quite know where to publish this, so I figured this list >> would be a start. Attached is a program for calibrating a touch >> screen. It computes the following parameters: >> >> 'flip_x' >>a boolean parameter that determines if the x-coordinate should >> be flipped. >> >> 'flip_y' >>same as 'flip_x' except for the y-coordinate. > > instead of flip_x and flip_y you could just swap the min_* and max_* > values and let the driver axis_validator function handle the flipping, > works for me. Good point. Perhaps the recently added 'invert_[x|y]' options in the evdev driver should be removed? Perhaps not, as such an option might be generally usable. BTW, what driver are you using for your touchscreen? Everybody: does anybody have any thought on where I should host my calibration code? Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
On Thu, 25.09.2008, 22:53, Paulo Cesar Pereira de Andrade wrote: > > I am not an expert on SMI501, just worked on it, not full time, > for a bit more then one month now... I am working on it for an > alternate driver for http://www.gdium.com/ > > The kernel module I have, at least would probably need a few > tweaks, like enabling pci burst/retry, as I guess you need > fps for video play, and that is the major performance boost > I noticed, but there should be other optimizations, maybe > reprogramming the clocks, to get maximal output speed, or > playing with the other programmable system options. > > You can check the driver in git master. It is a work in > progress. But, if possible, after making it have sane > modesetting code, hopefully using randr1.2, I hope to > add more complete exa support... The specs says it supports > accelerated alpha, scaling, rotation, etc... > > Paulo Now I used the latest siliconmotion driver from the XOrg GIT and removed the PCI function calls to access the device via Local Plus Bus of the TQM5200 board. I initialize the pSmi->MapBase and pSmi->FbBase fields with a mmap() call to /dev/mem and the proper adresses. After the module started up I see the following output with "X -verbose 9" == (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xe3e0 - 0xe400 (0x21) MX[B] [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0x8000 - 0x8003 (0x4) MX[B] [6] -1 0 0x - 0x (0x1) IX[B] [7] -1 0 0x - 0x00ff (0x100) IX[B] (II) SMI(0): Physical MMIO at 0xE3E0 (II) SMI(0): Logical MMIO at 0x48a4c000 - 0x48c4bfff (II) SMI(0): DPR=0x48b4c000, VPR=0x48a4c000, IOBase=(nil) (II) SMI(0): DataPort=0x48b5c000 - 0x48b6bfff (II) SMI(0): Physical frame buffer at 0xE000 offset: 0x (II) SMI(0): Logical frame buffer at 0x48c4c000 - 0x4944bfff (II) SMI(0): Cursor Offset: 007FF800 (II) SMI(0): Reserved: 007FF000 (II) SMI(0): FrameBuffer Box: 0,480 - 640,6550 (II) SMI(0):SMI_GEReset called from smi_accel.c line 131 (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 == The driver doesn't display anything now, instead it calls the SMI_GEReset function until I reset the device. When I set "pSmi->NoAccel = TRUE;" there seems to be no call to SMI_GEReset, at least none is displayed on the console, but the display is still black. I would appreciate it if anyone is able to supply me with a flash of inspiration. Best regards, Christian ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
On Tue, 2008-09-30 at 17:05 +0200, Søren Hauberg wrote: > I don't quite know where to publish this, so I figured this list > would be a start. Attached is a program for calibrating a touch > screen. It computes the following parameters: > > 'flip_x' >a boolean parameter that determines if the x-coordinate should > be flipped. > > 'flip_y' >same as 'flip_x' except for the y-coordinate. instead of flip_x and flip_y you could just swap the min_* and max_* values and let the driver axis_validator function handle the flipping, works for me. best regards ... clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
