New Wacom Bamboo not working

[Ayuthia]

I'm afraid the updated patch crashes X on startup, unless I've done something wrong. It did that "try to start three or four times" thing, sometimes getting as far as the KDE splash screen, before hanging and requiring a SysRq reboot.

Hi Favux, before I tried the new patch I tried this in the fdi:

<match key="info.product" contains="Wacom">

It works fine. Having a look at /var/log/messages afterward it looked like the stylus was more reliablly reporting as pen and eraser when switched (though I don't really know what I was looking at there - would the fdi affect the output in /var/log/messages?).

Edit: I've attached the /var/log/messages, which I think includes information both from the working change in the fdi and, beneath it, the problem with the new wcm2 patch (there are a number of segfaults reported there for Xorg.

Thanks for checking this. I have put the pad data back and added some debug messages to see when it is sending pad data. Can someone test this version and see if we can figure out what is being sent through the pad data? Right now I know that it is not sending the correct information over, but there is something that the system needs from it that we need to figure out. As usual, the patch is in post 144.

[marek_online]

Thanks for checking this. I have put the pad data back and added some debug messages to see when it is sending pad data. Can someone test this version and see if we can figure out what is being sent through the pad data? Right now I know that it is not sending the correct information over, but there is something that the system needs from it that we need to figure out. As usual, the patch is in post 144.

This latest patch produces the same X crash, unfortunately.

Just to confirm I'm doing it correctly, these are the steps I'm using.

tar -xjvf linuxwacom-8.4.3.tar.bz2
tar -xjvf wcm2_patch.tar.bz2
cp wcm2_patch/* linuxwacom-8.4.3/
cd linuxwacom-8.4.3
patch -p1 < wacomcpl-exec.patch
patch -p1 < wacom_sys.c.patch
patch -p1 < wacom_wac.c.patch
patch -p1 < wacom_wac.h.patch
patch -p1 < wactablet.h.patch
patch -p1 < wacusb.c.patch
patch -p1 < wcmUSB.c.patch
make clean
./configure --enable-wacom --prefix=/usr
make # Forgot this first time, but I do of course run it normally.
sudo make install
sudo cp src/2.6.28/wacom.ko /lib/modules/$(uname -r)/kernel/drivers/input/tablet/
sudo rmmod wacom
sudo insmod src/2.6.28/wacom.ko   #Note, X crashes immediately.
sudo depmod -e #I would do this if everything else up to this point had worked.

[Ayuthia]

This latest patch produces the same X crash, unfortunately.

Just to confirm I'm doing it correctly, these are the steps I'm using.

tar -xjvf linuxwacom-8.4.3.tar.bz2
tar -xjvf wcm2_patch.tar.bz2
cp wcm2_patch/* linuxwacom-8.4.3/
cd linuxwacom-8.4.3
patch -p1 < wacomcpl-exec.patch
patch -p1 < wacom_sys.c.patch
patch -p1 < wacom_wac.c.patch
patch -p1 < wacom_wac.h.patch
patch -p1 < wactablet.h.patch
patch -p1 < wacusb.c.patch
patch -p1 < wcmUSB.c.patch
make clean
./configure --enable-wacom --prefix=/usr
sudo make install
sudo cp src/2.6.28/wacom.ko /lib/modules/$(uname -r)/kernel/drivers/input/tablet/
sudo rmmod wacom
sudo insmod src/2.6.28/wacom.ko   #Note, X crashes immediately.
sudo depmod -e #I would do this if everything else up to this point had worked.

Usually I do a make before the sudo make install, but I am not for sure if it will do the make automatically or not when you just call sudo make install.

Would you mind trying to recompile it with the make and sudo make install? This one should not have crashed X because I put the code back and just added a couple of simple print statements.

If it does crash again, can you please attach the Xorg.0.log that has the crash information (if there are any)?

[marek_online]

Sorry, I do of course run 'make' before 'make install', silly omission.

Recompiled just to check, and at first thought all was well as 'depmod -e' ran without a hitch, but then realised that I'd plugged out the tablet. Plugging it in immediately caused the crash again. There's nothing in either Xorg.0.log or /var/log/messages about the crash, either, unfortunately.

[Ayuthia]

Sorry, I do of course run 'make' before 'make install', silly omission.

Recompiled just to check, and at first thought all was well as 'depmod -e' ran without a hitch, but then realised that I'd plugged out the tablet. Plugging it in immediately caused the crash again. There's nothing in either Xorg.0.log or /var/log/messages about the crash, either, unfortunately.

Before I revert the code back, can you try compiling the wcm_working_patch instead of the wcm2_patch just to be sure that we are not running into something strange?

I did a comparison between the working patch and the wcm2 patch and the main differences are the pressure changes, the data[1] check, the the logic to print out the data fields. All of those were working before the patch. The remaining are just print statements.

If it does not crash with the wcm_working_patch, then I will revert the code back. Thanks for doing this for me.

[marek_online]

Okay, another crash. It didn't crash as soon as I plugged in the tablet though (and this may actually be the same as the last time), but rather as soon as I brought the pen near the tablet.

Would this be a problem with either hal-setup-wacom or the .fdi file?

[Favux]

Did you change the .fdi line that has 'DebugLevel' to 'CommonDBG'? If so try changing it back.

[marek_online]

Hi Favux,

Did you change the .fdi line that has 'DebugLevel' to 'CommonDBG'? If so try changing it back.

I didn't, but I've just realised that I've got two relevant fdi files:

/usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi
/usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi

Possible culprit there? One is the same fdi posted by ehfortin a while ago, the other the most recent one posted by yourself. I'll try getting rid of one of them.

EDIT: Okay, it looks like the second fdi file was the problem. Sorry about that. The 10.-wacom.fdi file you most recently posted, Favux, doesn't seem to play nice with the wcm2_patch driver, with my hardware. Wish I could say why, but there's no useful information in the log files.

[Favux]

Hi marek_online,

I assume you used the test2 not the alt.touch_test2? Are you using Jaunty?

That's too bad. If there was some info. it would help. I looked at it and don't see a problem. Maybe you could try removing the touch section?:

  <device>
    <match key="input.x11_options.Type" contains="touch">
      <merge key="info.product" type="string">touch</merge>
    </match>
  </device>

And if that doesn't work the append touch line?

[marek_online]

I assume you used the test2 not the alt.touch_test2? Are you using Jaunty?

Yeah, it was the test2, and I am using Jaunty (though perhaps not for much longer! Roll on Thursday).

I'll try the edit.

EDIT: Okay, it seems I've been sloppy in my observations again I'm afraid. Apologies. The test2.fdi file you posted above, Favus, works fine, without edits. I'm not sure what was causing the problem earlier, but having both fdi files in the same folder seems to have been the problem, rather than either one by itself.