Bug#482826: [Linuxwacom-discuss] Bug#482826: xserver-xorg-input-wacom: Mouse device wrecks input system
On söndag 25 maj 2008, Ron wrote: [...] > Magnus, I saw some weirdness with this one too, that's not quite the > same as what is reported here, but it involved the mouse behaviour > becoming quite screwed up after a period of using the tablet stylus > with the patched 0.8.0 release we put together. It was _really_ weird, > the mouse would stop responding totally to button presses in the windows > for one application, until I did something with it in a different > application, then something else would fail to respond to them instead. > > At the time it was hard to say if the tablet, or just xorg (which I'd > just upgraded on the machine under test) was to blame for what was going > on, but I haven't used the tablet since (though it is plugged in with > the driver loaded) and I haven't seen this reoccur. > > I'm not sure if these two things are at all related, but it does sound > like something is still screwing up the device registration tables in > xorg at the moment... My experience with 1.4 is that there are a few regressions concerning the input drivers and the event reporting. Some are related to the fact that X.org is starting to catch up with the world regarding hotplugging (something the lw-driver did handle.. not in the best way, but still), and mixing these two approaches causes a few conflicts. Some are related to not having access to enough hardware so the aspects of an absolute reporting device was left out, but this is something that is starting to get corrected now. Anyway I think the lw-driver should benefit from a rewrite for xserver 1.4 (which is why I made the hotplug branch). But since Daniel had ideas for a new hotplug system that are quite different from today, I don't know where to start atm. Trying to patch the regressions or make it work in the long run... The few hours I can put on this won't be enough for both.. Cheers Magnus signature.asc Description: This is a digitally signed message part.
Bug#483494: [Linuxwacom-devel] Bug#483494: xserver-xorg-input-wacom: problems with multiple screens
On torsdag 29 maj 2008, Ron wrote: > Hi Jakob, > > I'm forwarding this to the linuxwacom list for confirmation and > discussion, but I suspect this may be related to trouble with > xorg 1.4 and the rescaling ... > > Magnus, is this just a misconfiguration issue, or a real problem? I think the problem is connected with the rescaling issue of xserver 1.4, as you also suspect. I think I've seen a bug report that the lw-driver doesn't honor the way the screens are laid out, but that would only explain why the pointer only moves on the left of the left and the right of the right, and not in the middle or on only one screen. > If the latter, is there a known workaround, or is this something > we are waiting on xorg 1.5 and the scaling code to be restored > before it can be fixed? Sorry, I don't know of a workaround.. What I would like would be to get the new Input API for the xserver defined and rewrite the driver from scratch (but other parts of my life keeps me a tad busy atm). The rescaling code is in both 1.5 and master (which now has MPX merged), so this could be a good starting point. However in 1.4 and 1.5 there are a few things that has changed and it is fully possible that changes that affect the behaviour of our driver are not aligned with all Xorg versions. Cheers Magnus > Cheers, > Ron > > On Wed, May 28, 2008 at 07:03:38PM -0700, Jakob wrote: > > Package: xserver-xorg-input-wacom > > Version: 0.8.0.2-2 > > Severity: important > > > > In my dual-headed setup, I run a single X session with two screens. > > When using a wacom tablet as a pointer, anything left of center on the > > tablet corresponds to the left half of my left monitor, and anything on > > the right half of the tablet points to the right half of the right > > monitor. > > > > So, if you were to number the halves of my monitors 1-4, left-to-right, > > I can only actually access halves 1 and 4, and not touch 2 or 3 (the > > insides). > > > > +-+-+ +-+-+ > > > > | 1 | 2 | | 3 | 4 | > > > > +-+-+ +-+-+ > > > > -- System Information: > > Debian Release: lenny/sid > > APT prefers unstable > > APT policy: (500, 'unstable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/bash > > > > Versions of packages xserver-xorg-input-wacom depends on: > > ii xserver-xorg-core 2:1.4.1~git20080517-1 Xorg X server - core server > > > > xserver-xorg-input-wacom recommends no packages. > > > > -- no debconf information > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Linuxwacom-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel signature.asc Description: This is a digitally signed message part.
Bug#481720: xserver-xorg-input-wacom: (EE) Failed to load module "wacom" (module does not exist, 0)
On söndag 18 maj 2008, Ron wrote: [...] > There was discussion and full rationale for this the last time we did it. > It should be in the linuxwacom-discuss archives if this isn't sufficient. Thanks, I'll search for it. > I don't know what else you were trying to change here, and the commit > message just says "rework" it, Mmm... I was making it more linear and readable (that was the intention).. Also added some options and parts that are available in 'modern' systems. > but I don't see anything that suggests a > need to change the option semantics from the code above, do you? No, the semantics was not something I wanted to change. > Oh wait, I see, you've moved WCM_OPTION_DLLOADER=yes to an unconditonal > test outside all of this... Ok, gotta sleep, but please let's start with > the above as a known working reference then try to figure out what it was > that you really wanted to change from that ... That's exactly what I did for this patch :) The default is to use the dlloader, --with-xmoduledir only overrides the path where the .so-file is put. Prior to this patch there was code that could automatically disable the dlloader, the patch remove this code so if you don't want an .so-file you will have to explicitly state that with the --disable-dlloader option. Before my rework the configure script could get a false negative on the dlloader option if the --with-xmoduledir was not defined and one of the default paths existed but wacom_drv.so was not previously installed. > Thanks for the quick response though ... > Ron Cheers Magnus signature.asc Description: This is a digitally signed message part.
Bug#481720: xserver-xorg-input-wacom: (EE) Failed to load module "wacom" (module does not exist, 0)
Hi, This is the patch for this issue I'll push for inclusion to the next release. If there's a possibility to test this outside my system I'd appreciated it. I'm sorry for not doing it right the first time. [PATCH] Fix configure misses when compiling on an incomplete installation. Use the argument to --with-xmoduledir before the default module installation directories, also remove all additional checks on the --enable-dlloader option so it can be forced. /Magnus V From 0d1b722597e9dc56c2cf12f621c545f0c3717d04 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Magnus=20Vigerl=C3=B6f?= <[EMAIL PROTECTED]> Date: Sun, 18 May 2008 13:37:07 +0200 Subject: [PATCH] Fix configure misses when compiling on an incomplete installation. Use the argument to --with-xmoduledir before the default module installation directories, also remove all additional checks on the --enable-dlloader option so it can be forced. --- configure.in | 13 +++-- 1 files changed, 3 insertions(+), 10 deletions(-) diff --git a/configure.in b/configure.in index af9ac0e..7978dda 100644 --- a/configure.in +++ b/configure.in @@ -837,12 +837,12 @@ WCM_MODDIR= AC_ARG_WITH(xmoduledir, AC_HELP_STRING([--with-xmoduledir], [Specify wacom_drv path explicitly. Implies --enable-dlloader]), WCM_MODDIR="$withval") -if test -d $WCM_XLIB_DIR/xorg/modules/input; then +if test -n "$WCM_MODDIR"; then + : +elif test -d $WCM_XLIB_DIR/xorg/modules/input; then WCM_MODDIR=$WCM_XLIB_DIR/xorg/modules/input elif test -d $WCM_XLIB_DIR/modules/input; then WCM_MODDIR=$WCM_XLIB_DIR/modules/input -elif -z "$WCM_MODDIR"; then - WCM_OPTION_DLLOADER=no fi AC_MSG_RESULT($WCM_MODDIR) @@ -852,13 +852,6 @@ AC_MSG_CHECKING(for dynamic driver loading support) AC_ARG_ENABLE(dlloader, AC_HELP_STRING([--enable-dlloader], [Use dlloader [[default=usually]]]), WCM_OPTION_DLLOADER=$enableval) -if test "$WCM_OPTION_DLLOADER" = yes; then - if test -f $WCM_MODDIR/evdev_drv.so -o -f $WCM_MODDIR/kbd_drv.so -o -f $WCM_MODDIR/mouse_drv.so; then - WCM_OPTION_DLLOADER=yes - else - WCM_OPTION_DLLOADER=no - fi -fi AC_MSG_RESULT($WCM_OPTION_DLLOADER) AM_CONDITIONAL(WCM_DLLOADER, test "$WCM_OPTION_DLLOADER" == "yes") -- 1.5.2.5 signature.asc Description: This is a digitally signed message part.
Bug#454568: [Linuxwacom-discuss] Bug#454568: xserver-xorg-input-wacom: additional data: X + wacom + gnome-session, but works started separately
On tisdag 18 december 2007, Magnus Vigerlöf wrote: [...] > > > I've got even more for you, maybe you can forward it to the appropriate > > > > > > thread. Further up, Magnus Vigerlöf mentioned: > > > | In XkbIndicatorsToUpdate (./xkb/xkbLEDs.c:56) the call to > > > | XkbFindSrvLedInfo can potentially return NULL, which is not an > > > | uncommon cause for a SEGV. > > > > > > My session starts up with numlock enabled. When using my workaround of > > > switching to console during session startup, I noticed that the numlock > > > LED on the keyboard is inverted. Apparantly the unavailability of the > > > keyboard to X when in console circumvents the initialization of the > > > LEDs and thus some bug in that code path. > > > > > > I am using the uim input method, if that matters. > > Try the following patch, it *is* the wrong place to fix this imho, but > it's the smallest part to recompile. If it doesn't crash, look for output > starting with 'Wacom: xf86WcmKbdLedCallback' in the log. If you find it > you had a Null-ptr deref and that should be considered a bug in the > xserver. [...] Hi, Linuxwacom 0.7.9-6 is now available. Included is a fix for this issue, it is the easiest place to change to avoid the crash it seems. I had a look at the place in the xserver source where the crash happened, but I could not see any recent changes that should cause the crash only in Xserver 1.4. I hope this solves this crash for everybody. Cheers Magnus
Bug#454568: [Linuxwacom-discuss] Bug#454568: xserver-xorg-input-wacom: additional data: X + wacom + gnome-session, but works started separately
On måndag 17 december 2007, Ron wrote:
[...]
> > I've got even more for you, maybe you can forward it to the appropriate
> > thread. Further up, Magnus Vigerlöf mentioned:
> > | In XkbIndicatorsToUpdate (./xkb/xkbLEDs.c:56) the call to
> > | XkbFindSrvLedInfo can potentially return NULL, which is not an uncommon
> > | cause for a SEGV.
> >
> > My session starts up with numlock enabled. When using my workaround of
> > switching to console during session startup, I noticed that the numlock
> > LED on the keyboard is inverted. Apparantly the unavailability of the
> > keyboard to X when in console circumvents the initialization of the LEDs
> > and thus some bug in that code path.
> >
> > I am using the uim input method, if that matters.
Try the following patch, it *is* the wrong place to fix this imho, but
it's the smallest part to recompile. If it doesn't crash, look for output
starting with 'Wacom: xf86WcmKbdLedCallback' in the log. If you find it
you had a Null-ptr deref and that should be considered a bug in the
xserver.
diff --git a/src/xdrv/xf86Wacom.c b/src/xdrv/xf86Wacom.c
index c1554af..540c3ff 100755
--- a/src/xdrv/xf86Wacom.c
+++ b/src/xdrv/xf86Wacom.c
@@ -99,6 +99,11 @@ WacomModule gWacomModule =
xf86WcmDevReverseConvert,
};
+static void xf86WcmKbdLedCallback(DeviceIntPtr di, LedCtrlProcPtr lcp)
+{
+ ErrorF("Wacom: xf86WcmKbdLedCallback called to avoid a null-ptr de-ref
in xserver\n");
+}
+
static int xf86WcmInitArea(LocalDevicePtr local)
{
WacomDevicePtr priv = (WacomDevicePtr)local->private;
@@ -551,6 +556,12 @@ static int xf86WcmRegisterX11Devices (LocalDevicePtr local)
}
}
+ if(InitLedFeedbackClassDeviceStruct (local->dev, xf86WcmKbdLedCallback)
== FALSE) {
+ ErrorF("unable to init led feedback device struct\n");
+ return FALSE;
+ }
+
+
#if defined WCM_XFREE86 || GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
/* allocate motion history buffer if needed */
xf86MotionHistoryAllocate(local);
Bug#454568: [Linuxwacom-discuss] Bug#454568: xserver-xorg-input-wacom + ksmserver = X crash
On torsdag 06 december 2007, Ron wrote: > This one I'm a bit less sure about... unless it's another manifestation > of the double unmapping bug (also in XServer and known upstream), you'll > probably have to talk this one through on the linux-wacom list. > I've forwarded it there for comment. If I read the xserver code correctly, there is a potential null-pointer de-ref that could cause this. Is this what you're thinking of Ron? In XkbIndicatorsToUpdate (./xkb/xkbLEDs.c:56) the call to XkbFindSrvLedInfo can potentially return NULL, which is not an uncommon cause for a SEGV. > Cheers, > Ron Cheers Magnus > On Thu, Dec 06, 2007 at 07:48:01PM +1000, Brendon Higgins wrote: > > Package: xserver-xorg-input-wacom > > Version: 0.7.9.3-2 > > Severity: normal > > > > > > (Wasn't sure whether to report here or to KDE devs. Here goes...) > > > > I've got a weird problem. If I have the wacom drivers enabled in > > Xorg.conf and login to KDE (4:3.5.8.dfsg.1-3) as normal the X server > > will crash near the end of the KDE splashscreen, and I'm sent back to > > the KDM login screen. This doesn't happen when I disable the wacom > > drivers in ServerLayout. > > > > What's weirder is that X does *not* crash if I switch to a console VT > > while KDE is booting, then switch back not long after booting has > > finished. Then everything seems fine. But if I leave the screen in X > > while KDE boots, crash happens. > > > > By going through the steps in startkde manually I've narrowed it down to > > some point inside the call to ksmserver. Something ksmserver starts > > seems to puke with the wacom driver for some reason. I'm not sure how > > to go about narrowing it down further than that, though I want to. > > Advice on an approach to take would be appreciated. > > > > Xorg.0.log that ends in such a crash is attached, but it doesn't appear > > to be very informative. > > > > > > -- System Information: > > Debian Release: lenny/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/bash > > > > Versions of packages xserver-xorg-input-wacom depends on: > > ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server > > > > xserver-xorg-input-wacom recommends no packages. > > > > -- no debconf information > > > > > > X.Org X Server 1.4.0 > > Release Date: 5 September 2007 > > X Protocol Version 11, Revision 0 > > Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20071119-1) > > Current Operating System: Linux phi 2.6.22-3-amd64 #1 SMP Sun Nov 4 > > 18:18:09 UTC 2007 x86_64 Build Date: 20 November 2007 02:55:16AM > > > > Before reporting problems, check http://wiki.x.org > > to make sure that you have the latest version. > > Module Loader present > > Markers: (--) probed, (**) from config file, (==) default setting, > > (++) from command line, (!!) notice, (II) informational, > > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 6 18:30:59 2007 > > (==) Using config file: "/etc/X11/xorg.conf" [...] > > pad Wacom X driver grabbed event device > > (==) Wacom USB Graphire4 tablet speed=9600 maxX=10208 maxY=7424 maxZ=511 > > resX=2032 resY=2032 tilt=enabled (==) Wacom device "pad" top X=0 top Y=0 > > bottom X=10208 bottom Y=6380 (==) Wacom device "cursor" top X=0 top Y=0 > > bottom X=10208 bottom Y=6380 (==) Wacom device "eraser" top X=0 top Y=0 > > bottom X=10208 bottom Y=6380 (==) Wacom device "stylus" top X=0 top Y=0 > > bottom X=10208 bottom Y=6380 (II) Configured Mouse: > > ps2EnableDataReporting: succeeded > > > > Backtrace: > > 0: /usr/bin/X(xf86SigHandler+0x6a) [0x47554a] > > 1: /lib/libc.so.6 [0x2af088c89040] > > 2: /usr/bin/X(XkbIndicatorsToUpdate+0x26) [0x5458b6] > > 3: /usr/bin/X(ProcXkbLatchLockState+0x25d) [0x53bf8d] > > 4: /usr/bin/X(Dispatch+0x2e2) [0x44e3d2] > > 5: /usr/bin/X(main+0x47c) [0x436bcc] > > 6: /lib/libc.so.6(__libc_start_main+0xf4) [0x2af088c751c4] > > 7: /usr/bin/X(FontFileCompleteXLFD+0x261) [0x435f09] > > > > Fatal server error: > > Caught signal 11. Server aborting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454570: [Linuxwacom-discuss] Bug#454570: xserver-xorg-input-wacom: KeepShape doesn't work properly
On torsdag 06 december 2007, Ron wrote: > Hi Brendon, > > I believe this is a known problem with scaling and the new XServer, > it isn't actually a bug in the wacom-driver, and is known to upstream > X maintainers and should be fixed in some future release of that. > > Magnus, can you confirm this sounds like the scaling issue that you > mentioned previously? There is a scaling issue with xserver 1.4, but I think this is actually a bug in the linuxwacom driver.. It seems that you can work around this problem by dropping KeepShape and adding the following option: Option "BottomY" "6380" This one is specifically tailored for a 16:10 screen and a Graphire4 (4x5), but the general formula is BottomY = TabletMaxX * ScreenMaxY / ScreenMaxX. I'll try to track this one down during the weekend.. The current scaling issue seems to stay until xserver 1.6 so we're stuck with this for a while... Cheers Magnus > Cheers, > Ron > > On Thu, Dec 06, 2007 at 07:50:30PM +1000, Brendon Higgins wrote: > > Subject: xserver-xorg-input-wacom: KeepShape doesn't work properly > > Package: xserver-xorg-input-wacom > > Version: 0.7.9.3-2 > > Severity: normal > > > > > > I have a largish 16:10 display and a smallish Graphire4 (4x5). I used to > > use the KeepShape option, however with the new version of the driver it > > does not work correctly. It seems the driver correctly determines the > > lower limit of the active area of the tablet, but it does not then scale > > the coordinates onscreen as it should. What this means is that, instead > > of cutting some of the bottom off the usuable area of the tablet so that > > the rest matches the entire area of the screen, the bottom of the usuable > > area of the tablet is cut, but the pointer on the screen will not go > > below a similar cutoff point on the screen. I can't click on, for > > example, the taskbar on the bottom of my screen. > > > > > > -- System Information: > > Debian Release: lenny/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/bash > > > > Versions of packages xserver-xorg-input-wacom depends on: > > ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server > > > > xserver-xorg-input-wacom recommends no packages. > > > > -- no debconf information > > > > -- System Information: > > Debian Release: lenny/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/bash > > > > Versions of packages xserver-xorg-input-wacom depends on: > > ii xserver-xorg-core 2:1.4.1~git20071119-1 Xorg X server - core server > > > > xserver-xorg-i > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Linuxwacom-discuss mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
