Re: setting evdev properties from HAL?
Peter Hutterer wrote:
On Sat, Jul 04, 2009 at 02:32:09PM +0200, Simon Thum wrote:
Asbjørn Sannes wrote:
But for Evdev Axis Calibration I have not found anything that works ..
Any hints and suggestions are welcome :)
One could probably do a patch which adds property manipulation to
config/hal, but it didn't surface yet.
I remember to have heard hal can be configured to invoke scripts like
yours on device add/remove. Not sure of it, though.
I started that once but I'm being told HAL is on its way out so I decided
not to finish them. If you want to pick it up - be my guest, patches below.
Having said that, it is questionable whether they will go upstream if you do
finish them. There is quite a push away from HAL and adding new HAL-only
functionality is not the way to go. Especially for things like this that can
be set at runtime.
What I had in mind wasn't actually hal-only. AFAIK we already merge hal
keys into config. Likely, a udev-based solution would have to offer
something similar anyway. So if we pick up config items which e.g. start
with Input Property and then modify props accordingly, that might be
a more sustainable approach.
Thoughts?
Cheers,
Simon
Time is possibly better spent investigating libudev and finding out how to
automatically port current fdi configurations so they work on a udev-only
system.
Cheers,
Peter
From 74c05685e47586f70e0d7b324a1e29eac44e59b9 Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Thu, 26 Mar 2009 14:23:09 +1000
Subject: [PATCH] config: rename LIBHAL_... defines for better namespacing.
---
config/hal.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/config/hal.c b/config/hal.c
index 36fa839..782fbb5 100644
--- a/config/hal.c
+++ b/config/hal.c
@@ -40,8 +40,8 @@
#include os.h
-#define LIBHAL_PROP_KEY input.x11_options.
-#define LIBHAL_XKB_PROP_KEY input.xkb.
+#define LIBHAL_OPTIONS_KEY input.x11_options.
+#define LIBHAL_XKB_OPTIONS_KEY input.xkb.
struct config_hal_info {
@@ -273,7 +273,7 @@ device_added(LibHalContext *hal_ctx, const char *udi)
if (psi_key){
/* normal options first (input.x11_options.propname) */
-if (!strncasecmp(psi_key, LIBHAL_PROP_KEY,
sizeof(LIBHAL_PROP_KEY)-1)){
+if (!strncasecmp(psi_key, LIBHAL_OPTIONS_KEY,
sizeof(LIBHAL_OPTIONS_KEY)-1)){
char* tmp;
/* only support strings for all values */
@@ -319,7 +319,7 @@ device_added(LibHalContext *hal_ctx, const char *udi)
} else
{
/* all others */
-add_option(options, psi_key +
sizeof(LIBHAL_PROP_KEY)-1, tmp_val);
+add_option(options, psi_key +
sizeof(LIBHAL_OPTIONS_KEY)-1, tmp_val);
xfree(tmp_val);
}
} else
@@ -335,15 +335,15 @@ device_added(LibHalContext *hal_ctx, const char *udi)
xkb_opts.options = strdup(tmp_val);
}
}
-} else if (!strncasecmp(psi_key, LIBHAL_XKB_PROP_KEY,
sizeof(LIBHAL_XKB_PROP_KEY)-1)){
+} else if (!strncasecmp(psi_key, LIBHAL_XKB_OPTIONS_KEY,
sizeof(LIBHAL_XKB_OPTIONS_KEY)-1)){
char* tmp;
/* only support strings for all values */
tmp_val = get_prop_string(hal_ctx, udi, psi_key);
-if (tmp_val strlen(psi_key) =
sizeof(LIBHAL_XKB_PROP_KEY)) {
+if (tmp_val strlen(psi_key) =
sizeof(LIBHAL_XKB_OPTIONS_KEY)) {
-tmp = psi_key[sizeof(LIBHAL_XKB_PROP_KEY) - 1];
+tmp = psi_key[sizeof(LIBHAL_XKB_OPTIONS_KEY) - 1];
if (!strcasecmp(tmp, layout))
{
@@ -371,9 +371,9 @@ device_added(LibHalContext *hal_ctx, const char *udi)
{
/* server 1.4 had xkb options as strlist */
tmp_val = get_prop_string_array(hal_ctx, udi, psi_key);
-if (tmp_val strlen(psi_key) =
sizeof(LIBHAL_XKB_PROP_KEY))
+if (tmp_val strlen(psi_key) =
sizeof(LIBHAL_XKB_OPTIONS_KEY))
{
-tmp = psi_key[sizeof(LIBHAL_XKB_PROP_KEY) - 1];
+tmp = psi_key[sizeof(LIBHAL_XKB_OPTIONS_KEY) - 1];
if (!strcasecmp(tmp, .options)
(!xkb_opts.options))
xkb_opts.options = strdup(tmp_val);
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: remove Xgl leftover
Would someone please review this?
Thanks,
Kristof
On Mon, Jun 29, 2009 at 15:23, RALOVICH,
Kristófkristof.ralov...@gmail.com wrote:
Compile tested and grep found no references.
Please review and apply.
Thanks,
Kristof
From 21c6b89d0bba8efff847b6e88cbb76dc1d05d598 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Mon, 29 Jun 2009 15:18:56 +0200
Subject: [PATCH] glx: remove Xgl leftover
GlxSetRenderTables was only used by the long gone Xgl.
---
glx/glxcmds.c | 6 --
glx/glxserver.h | 3 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index d4ff7da..f5632d1 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -51,12 +51,6 @@
#include indirect_table.h
#include indirect_util.h
-void
-GlxSetRenderTables (struct _glapi_table *table)
-{
- _glapi_set_dispatch (table);
-}
-
static int
validGlxScreen(ClientPtr client, int screen, __GLXscreen
**pGlxScreen, int *err)
{
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 3e44b71..46c9382 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -94,9 +94,6 @@ void GlxExtensionInit(void);
void GlxSetVisualConfigs(int nconfigs,
void *configs, void **privates);
-struct _glapi_table;
-void GlxSetRenderTables (struct _glapi_table *table);
-
void __glXScreenInitVisuals(__GLXscreen *screen);
/*
--
1.6.3.3
From 21c6b89d0bba8efff847b6e88cbb76dc1d05d598 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Mon, 29 Jun 2009 15:18:56 +0200
Subject: [PATCH] glx: remove Xgl leftover
GlxSetRenderTables was only used by the long gone Xgl.
---
glx/glxcmds.c |6 --
glx/glxserver.h |3 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index d4ff7da..f5632d1 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -51,12 +51,6 @@
#include indirect_table.h
#include indirect_util.h
-void
-GlxSetRenderTables (struct _glapi_table *table)
-{
-_glapi_set_dispatch (table);
-}
-
static int
validGlxScreen(ClientPtr client, int screen, __GLXscreen **pGlxScreen, int *err)
{
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 3e44b71..46c9382 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -94,9 +94,6 @@ void GlxExtensionInit(void);
void GlxSetVisualConfigs(int nconfigs,
void *configs, void **privates);
-struct _glapi_table;
-void GlxSetRenderTables (struct _glapi_table *table);
-
void __glXScreenInitVisuals(__GLXscreen *screen);
/*
--
1.6.3.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: damage is only used with DRI
Would someone please review this?
Thanks,
Kristof
On Mon, Jun 29, 2009 at 16:08, RALOVICH,
Kristófkristof.ralov...@gmail.com wrote:
Compile tested.
Please review and apply.
Thanks,
Kristof
From 903dcd1692d4857e50f7ac6b073092d952a251ac Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Mon, 29 Jun 2009 15:52:06 +0200
Subject: [PATCH 2/2] glx: damage is only used with DRI
---
glx/glxdrawable.h | 2 --
glx/glxdri.c | 1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 0215b3b..3f165ed 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -35,8 +35,6 @@
* Silicon Graphics, Inc.
*/
-#include damage.h
-
/* We just need to avoid clashing with DRAWABLE_{WINDOW,PIXMAP} */
enum {
GLX_DRAWABLE_WINDOW,
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 5fb75a4..c9d226b 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -38,6 +38,7 @@
#include windowstr.h
#include os.h
+#include damage.h
#define _XF86DRI_SERVER_
#include drm_sarea.h
--
1.6.3.3
From 7f2bb27aec3fdcf9de8369e48fe424689530b9aa Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Sun, 5 Jul 2009 16:42:54 +0200
Subject: [PATCH] glx: damage is only used with DRI
---
glx/glxdrawable.h |2 --
glx/glxdri.c |1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 0215b3b..3f165ed 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -35,8 +35,6 @@
* Silicon Graphics, Inc.
*/
-#include damage.h
-
/* We just need to avoid clashing with DRAWABLE_{WINDOW,PIXMAP} */
enum {
GLX_DRAWABLE_WINDOW,
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 5fb75a4..c9d226b 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -38,6 +38,7 @@
#include windowstr.h
#include os.h
+#include damage.h
#define _XF86DRI_SERVER_
#include drm_sarea.h
--
1.6.3.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Artifacts on Radeon 4850
I have a Radeon 4850, and I get artifacts all over the screen in X. I'm using Gentoo Linux with xf86-video-ati git (also tried 6.12.2), xorg 1.6.1.902, mesa 7.5rc4, and linux 2.6.31 rc2 (also tried 2.6.30) I don't know if this is a bug in the radeon driver, or if I don't have things configured correctly. I'm thinking it's a bug in the driver itself; since X works correctly. If it matters at all, according to Xorg.0.log r600_dri.so failed to load. (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: cannot open shared object file: No such file or directory) (EE) AIGLX: reverting to software rendering If any more information is needed, just ask; I didn't want to send a bunch of unneeded crap. Thanks. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
Please see http://jbridgman.livejournal.com/945.html ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
A screenshot or something might help. But this is probably not related to mesa, unless you are running compiz or something like that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
On Sun, Jul 5, 2009 at 4:11 PM, Casey Jonesjonescas...@gmail.com wrote: Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. No, the radeon-rewrite branch (which has been merged recently) wouldn't change anything, as it doesn't support R6/700. If it's happening with 2D, it's not a problem with Mesa anyway -- unless you're using compiz, then it may be. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. Yes, XAA is also available. More info such as kernel, drm, xserver, and ddx versions might help. Does dmesg or Xorg.0.log show anything interesting when the corruption happens? What kind of corruption are you seeing? Matt ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
Nope, this happens in KDM, KDE 4.2, and in a default config of Openbox. Sorry if these images are a bit large, but it makes it a bit easier to see the artifacts. KDM: http://img168.imageshack.us/img168/1706/kdm.jpg KDE 4.2: http://img219.imageshack.us/img219/1530/kde.jpg Openbox: http://img504.imageshack.us/img504/3527/openbox.jpg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
evdev+hal = Too many input devices.
I have a Kingston BT mouse, which works pretty well with my Linux laptop. At least it has worked so far, becouse this is what I'm getting in log files right now, when I turn it on: (II) config/hal: Adding input device Primax Corp. (3) Button Mouse (**) Primax Corp. (3) Button Mouse: always reports core events (**) Primax Corp. (3) Button Mouse: Device: /dev/input/event10 (II) Primax Corp. (3) Button Mouse: Found 3 mouse buttons (II) Primax Corp. (3) Button Mouse: Found x and y relative axes (II) Primax Corp. (3) Button Mouse: Found scroll wheel(s) (II) Primax Corp. (3) Button Mouse: Found keys (II) Primax Corp. (3) Button Mouse: Configuring as mouse (II) Primax Corp. (3) Button Mouse: Configuring as keyboard (**) Primax Corp. (3) Button Mouse: YAxisMapping: buttons 4 and 5 (**) Primax Corp. (3) Button Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse (II) UnloadModule: evdev (EE) config/hal: NewInputDeviceRequest failed (11) And the mouse is not working. What can I do in such a situation, instead of restarting X? Maybe I should check something? I have never ever had such situation for many months of using this mouse. I have not changed anything in my system for many days. -- Łukasz Maśko GG: 2441498_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające Nie umiem zainstalować Debiana ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
On Sun, Jul 5, 2009 at 3:20 PM, Matt Turnermatts...@gmail.com wrote: On Sun, Jul 5, 2009 at 4:11 PM, Casey Jonesjonescas...@gmail.com wrote: Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. No, the radeon-rewrite branch (which has been merged recently) wouldn't change anything, as it doesn't support R6/700. If it's happening with 2D, it's not a problem with Mesa anyway -- unless you're using compiz, then it may be. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. Yes, XAA is also available. Only EXA is available on r6xx/r7xx hardware. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
On Sunday 05 July 2009, Alex Deucher wrote: On Sun, Jul 5, 2009 at 3:20 PM, Matt Turnermatts...@gmail.com wrote: On Sun, Jul 5, 2009 at 4:11 PM, Casey Jonesjonescas...@gmail.com wrote: Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. No, the radeon-rewrite branch (which has been merged recently) wouldn't change anything, as it doesn't support R6/700. If it's happening with 2D, it's not a problem with Mesa anyway -- unless you're using compiz, then it may be. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. Yes, XAA is also available. Only EXA is available on r6xx/r7xx hardware. Alex Can we expect that to change eventually? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp In case of injury notify your superior immediately. He'll kiss it and make it better. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal = Too many input devices.
On 07/05/2009 01:41 PM, Łukasz Maśko wrote: I have a Kingston BT mouse, which works pretty well with my Linux laptop. At least it has worked so far, becouse this is what I'm getting in log files right now, when I turn it on: (II) config/hal: Adding input device Primax Corp. (3) Button Mouse (**) Primax Corp. (3) Button Mouse: always reports core events (**) Primax Corp. (3) Button Mouse: Device: /dev/input/event10 (II) Primax Corp. (3) Button Mouse: Found 3 mouse buttons (II) Primax Corp. (3) Button Mouse: Found x and y relative axes (II) Primax Corp. (3) Button Mouse: Found scroll wheel(s) (II) Primax Corp. (3) Button Mouse: Found keys (II) Primax Corp. (3) Button Mouse: Configuring as mouse (II) Primax Corp. (3) Button Mouse: Configuring as keyboard (**) Primax Corp. (3) Button Mouse: YAxisMapping: buttons 4 and 5 (**) Primax Corp. (3) Button Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse (II) UnloadModule: evdev Do you have the mouse driver in your xorg.conf? Identifier Mouse1 Driver mouse === This is not needed if you use evdev. (Same for the keyboard driver.) Try commenting out the entire Input section if you have one. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: setting evdev properties from HAL?
On Sun, Jul 05, 2009 at 03:00:32PM +0200, Simon Thum wrote: Peter Hutterer wrote: On Sat, Jul 04, 2009 at 02:32:09PM +0200, Simon Thum wrote: Asbjørn Sannes wrote: But for Evdev Axis Calibration I have not found anything that works .. Any hints and suggestions are welcome :) One could probably do a patch which adds property manipulation to config/hal, but it didn't surface yet. I remember to have heard hal can be configured to invoke scripts like yours on device add/remove. Not sure of it, though. I started that once but I'm being told HAL is on its way out so I decided not to finish them. If you want to pick it up - be my guest, patches below. Having said that, it is questionable whether they will go upstream if you do finish them. There is quite a push away from HAL and adding new HAL-only functionality is not the way to go. Especially for things like this that can be set at runtime. What I had in mind wasn't actually hal-only. AFAIK we already merge hal keys into config. Likely, a udev-based solution would have to offer something similar anyway. So if we pick up config items which e.g. start with Input Property and then modify props accordingly, that might be a more sustainable approach. So, thinking about the whole problem again: the whole reason for properties is that they are run-time configurable and not just available at server startup. So - yes - we could add more logic to the server to parse the options at device init time. We need to ensure this configuration and parsing happens with a pure HAL configuration, a xorg.conf and libudev. Which means we have one more API to maintain (that is possibly not even going to be used that much). And this API has some overlap with the Options parsing stuff from the config file. So we're left with two independent parsing APIs, users possibly mixing both of them into their configurations, making support quite interesting. For example, if you can set the same option through properties and through a traditional Options flag, it comes down to the driver implementation which one has precedence. I think we should just encourage the development of client applications that provide user-configurable property setting mechanisms instead. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
On 07/05/2009 02:49 PM, Gene Heskett wrote: On Sunday 05 July 2009, Alex Deucher wrote: On Sun, Jul 5, 2009 at 3:20 PM, Matt Turnermatts...@gmail.com wrote: On Sun, Jul 5, 2009 at 4:11 PM, Casey Jonesjonescas...@gmail.com wrote: Would using the radeon-rewrite branch of mesa actually fix this? AFAIK, this isn't a 3D/OpenGL problem. Whenever Xorg is running it happens, including 2D. No, the radeon-rewrite branch (which has been merged recently) wouldn't change anything, as it doesn't support R6/700. If it's happening with 2D, it's not a problem with Mesa anyway -- unless you're using compiz, then it may be. Oh, and I am using EXA. Are there any other AccelMethods like XAA? And it isn't the hardware because it worked fine with fglrx. Yes, XAA is also available. Only EXA is available on r6xx/r7xx hardware. Alex Can we expect that to change eventually? If your question is actually, XAA for r600+? then the answer is never. XAA is just not a good fit for these cards. Additionally, XAA is kind of on the way out, and with recent EXA improvements, there's really no reason to stick with it. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal = Too many input devices.
On Sun, Jul 05, 2009 at 10:41:26PM +0200, Łukasz Maśko wrote: I have a Kingston BT mouse, which works pretty well with my Linux laptop. At least it has worked so far, becouse this is what I'm getting in log files right now, when I turn it on: (II) config/hal: Adding input device Primax Corp. (3) Button Mouse (**) Primax Corp. (3) Button Mouse: always reports core events (**) Primax Corp. (3) Button Mouse: Device: /dev/input/event10 (II) Primax Corp. (3) Button Mouse: Found 3 mouse buttons (II) Primax Corp. (3) Button Mouse: Found x and y relative axes (II) Primax Corp. (3) Button Mouse: Found scroll wheel(s) (II) Primax Corp. (3) Button Mouse: Found keys (II) Primax Corp. (3) Button Mouse: Configuring as mouse (II) Primax Corp. (3) Button Mouse: Configuring as keyboard (**) Primax Corp. (3) Button Mouse: YAxisMapping: buttons 4 and 5 (**) Primax Corp. (3) Button Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse (II) UnloadModule: evdev (EE) config/hal: NewInputDeviceRequest failed (11) And the mouse is not working. What can I do in such a situation, instead of restarting X? Maybe I should check something? I have never ever had such situation for many months of using this mouse. I have not changed anything in my system for many days. Please attach the whole log, this snippet is not really useful for finding the root of the problem. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal = Too many input devices.
On Sun, Jul 05, 2009 at 03:03:17PM -0700, walt wrote: On 07/05/2009 01:41 PM, Łukasz Maśko wrote: I have a Kingston BT mouse, which works pretty well with my Linux laptop. At least it has worked so far, becouse this is what I'm getting in log files right now, when I turn it on: (II) config/hal: Adding input device Primax Corp. (3) Button Mouse (**) Primax Corp. (3) Button Mouse: always reports core events (**) Primax Corp. (3) Button Mouse: Device: /dev/input/event10 (II) Primax Corp. (3) Button Mouse: Found 3 mouse buttons (II) Primax Corp. (3) Button Mouse: Found x and y relative axes (II) Primax Corp. (3) Button Mouse: Found scroll wheel(s) (II) Primax Corp. (3) Button Mouse: Found keys (II) Primax Corp. (3) Button Mouse: Configuring as mouse (II) Primax Corp. (3) Button Mouse: Configuring as keyboard (**) Primax Corp. (3) Button Mouse: YAxisMapping: buttons 4 and 5 (**) Primax Corp. (3) Button Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse (II) UnloadModule: evdev Do you have the mouse driver in your xorg.conf? Identifier Mouse1 Driver mouse === This is not needed if you use evdev. (Same for the keyboard driver.) Try commenting out the entire Input section if you have one. FTR, unrelated to this issue. 'Too many input devices' is an error message the server spits out when the internal limit of input devices (20 in 1.6, 40 in git master) is reached. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
