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);
