New Wacom Bamboo not working

[ehfortin]

I going to guess that the segfault only provides the typical "segmentation fault (core dumped)" message.

It would have been too useful to get a detailed error message

Yes, it is the typical message.

BTW, I can confirm that once I reconnect the tablet (or boot with it connected), I'll be able to use the "eraser" input device once in gimp. As soon as I change back to the stylus, even if I try to go back to the eraser, gimp stays on the stylus input device so I have 2 stylus input devices

Don't know if it is related to the driver or gimp as I don't have a tablet that is fully working yet. Do you get the same result in gimp?

The other (maybe related) interesting thing is that xinput --list --short always shows 2 of each input device (eraser, stylus, touch, I removed the pad and the cursor for now) as below:

"eraser"    id=2    [XExtensionKeyboard]
"touch"    id=3    [XExtensionKeyboard]
"stylus"    id=4    [XExtensionKeyboard]
"eraser"    id=5    [XExtensionKeyboard]
"touch"    id=6    [XExtensionKeyboard]
"stylus"    id=7    [XExtensionKeyboard]

Gimp is showing me two of each as well. It's hard to know which one is the correct stylus or eraser. I often activated both stylus, both eraser but... didn't get better results. But maybe gimp is getting lost because of this.

I've managed to see those in wacomcpl (again, everything in double) by using Favux .fdi file that I've modified (I was not getting the stylus).

@Favux, here is my .fdi once modified. It seems to work just about all the time (boot and plug&play). I don't have anything in my xorg.conf anymore which is great. Freedom! Well I may have exagerated a little bit. It is just a little more dynamic and less cumbersome this way.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- this is probably a bit imprecise -->
<deviceinfo version="0.2">
  <device>
    <match key="info.category" contains="input">
      <match key="info.product" contains_outof="Wacom">
    <merge key="input.x11_driver" type="string">wacom</merge>
    <merge key="input.x11_options.Type" type="string">stylus</merge>
    <merge key="info.product" type="string">stylus</merge>
    <merge key="input.x11_options.DebugLevel" type="string">12</merge>
    <append key="info.callouts.add" type="strlist">hal-setup-wacom</append>
    <append key="wacom.types" type="strlist">eraser</append>
    <append key="wacom.types" type="strlist">touch</append>
      </match>
    </match>
  </device>
  <device>
    <match key="input.x11_options.Type" contains="eraser">
      <merge key="info.product" type="string">eraser</merge>
    </match>
  </device>
  <device>
    <match key="input.x11_options.Type" contains="touch">
      <merge key="info.product" type="string">touch</merge>
    </match>
  </device>
</deviceinfo>

That's about it for now. Hope somebody will have "THE" great idea and we will resolve this in the next few hours

ehfortin

[ehfortin]

More information regarding the eraser. As previously said, I noticed the issue with the eraser in gimp where I can only have gimp to recognized it as an eraser the first time after I connect the tablet. Now, I was playing with CellWriter and it is the same thing. I was able to reset a letter by pressing the eraser on the box but since... it's not available anymore.

Log is clearly showing pen when I'm on the pen side and eraser when I'm on the eraser side. So why the apps like CellWriter and Gimp are recognizing the eraser on first usage ever but... not after that? I can only think about the code in the driver. Maybe there is some set/unset or reset that is not handled correctly and once it has been used, there is no state change recognized by the apps.

I'll let that to those who know what they are talking about

Just thought it could be useful to know.

ehfortin

[Favux]

Hi ehfortin,

Thanks for updating on the .fdi. Interestingly it was the other way around with marek_online, using:

    <match key="info.category" contains="input">

broke stylus for him, whereas:

    <match key="input.originating_device" contains="if0">

worked. See his post #340.

Gali98 checked out adding libhal1-dev and it didn't break xorg.conf. Unfortunately neither of us is getting 0.8.5 to work even with it added.

Ehfortin the double entries from HAL and then xorg.conf is one of the things 0.8.5 is suppose to fix.

Does anyone know if the new Bamboo's are suppose to support the Wacom mouse? I know some have pad.

[Ayuthia]

Don't know if it is related to the driver or gimp as I don't have a tablet that is fully working yet. Do you get the same result in gimp?

I wish I could help answer this one, but I don't have any Wacom devices and my N-Trig tablet only came with a stylus that has no eraser.

The other (maybe related) interesting thing is that xinput --list --short always shows 2 of each input device (eraser, stylus, touch, I removed the pad and the cursor for now) as below:

I am guessing that you are getting two entries because of how the .fdi file is currently defined. If you look at lshal, you will see that there are two entries there that have an info.category = 'input'. You will also see that the current .fdi rule will satisfy both entries. If the entry fulfills the match rules, it will use them. What you might be able to do is define one of them as a stylus and the other as the eraser and see if it will work. Of course, this would just be a workaround if it does work because I am pretty sure that is not how it was designed.

EDIT: Looks like Favux beat me in responding. Sorry for the duplicate response.

[Ayuthia]

More information regarding the eraser. As previously said, I noticed the issue with the eraser in gimp where I can only have gimp to recognized it as an eraser the first time after I connect the tablet. Now, I was playing with CellWriter and it is the same thing. I was able to reset a letter by pressing the eraser on the box but since... it's not available anymore.

Log is clearly showing pen when I'm on the pen side and eraser when I'm on the eraser side. So why the apps like CellWriter and Gimp are recognizing the eraser on first usage ever but... not after that? I can only think about the code in the driver. Maybe there is some set/unset or reset that is not handled correctly and once it has been used, there is no state change recognized by the apps.

I'll let that to those who know what they are talking about

Just thought it could be useful to know.

ehfortin

I was thinking about this also. I think that there is an issue with the eraser portion in the code. It was looking like 0x80 code was fixing the problem for the eraser, but I was not understanding why. I was going to look at it when I had a chance, but now this comes up. So if we can get this figured out, we can most likely fix the cursor from going to the upper left hand corner.

The workaround for the eraser issue was to move the stylus in and out of range twice and then the eraser worked again. I am not for sure if it will work this time or not.

[Favux]

Hi everyone,

I went to the Wacom site again, of the 5 (?) new models none seems to support the Wacom mouse (puck). The most expensive ($200), the Bamboo Fun, doesn't seem to have it. I'm pretty sure the previous Bamboo Fun did come with a puck.

So unless someone tells me different the next .fdi won't have cursor.

[Ayuthia]

I have decided to change line 174 in src/2.6.28/wacom_wac.c from:

    if (data[1] & 0x80) {

to:
[code[ if (data[1] != 0x80) {p/code]
So that the eraser will be reset. I am currently noticing that it does not get reset when the stylus gets flipped from eraser to pen.

However, this change might take us back to the issue where the eraser does not come back when you go from eraser, to pen, and back to eraser.

If you test this wcm2_patch, please try going from eraser, to pen, and back to eraser. Let me know if the cursor moves towards the upper left hand corner when the stylus is moved out of range of the pad and if the eraser still works or not. If it does not work, please try moving the stylus in pen mode in and out of pad range two times and see if the eraser works again. Also please attach the /var/log/messages and /var/log/Xorg.0.log files. Thanks!

[marek_online]

Right, thanks for the help. Things are working again (I had tried to use both patches, sorry).

ehfortin, hal-setup-wacom did indeed get put in /usr/lib/exec, but I have also copied it to /usr/lib/hal just in case.

I have attached my Xorg.0.log and, in case it might be of some interest the last few lines of my /var/log/messages. I made sure that the last couple of strokes were with the eraser, but I don't know how to parse the information in the file to make much sense of it.

Still no data from wacdump /dev/input/wacom, and no devices available in wacomcpl, though I haven't tried the latest wcm2 patch yet, and trying to do:
patch -p1 < wacomcpl-exec.patch
gave me a "no such file" error with the patch I did use.

marek@Childers:~$ xinput --list --short
"Virtual core pointer"  id=0    [XPointer]
"Virtual core keyboard" id=1    [XKeyboard]
"AT Translated Set 2 keyboard"  id=2    [XExtensionKeyboard]
"Wacom Bamboo P&T 4x5"  id=3    [XExtensionKeyboard]
"DELL DELL USB Keyboard"        id=4    [XExtensionKeyboard]
"Video Bus"     id=5    [XExtensionKeyboard]
"Wacom Bamboo P&T 4x5 pad"      id=6    [XExtensionKeyboard]
"Wacom Bamboo P&T 4x5 cursor"   id=7    [XExtensionKeyboard]
"Wacom Bamboo P&T 4x5 eraser"   id=8    [XExtensionKeyboard]
"Macintosh mouse button emulation"      id=9    [XExtensionPointer]
"ImExPS/2 Generic Explorer Mouse"       id=10   [XExtensionPointer]
"Logitech Optical USB Mouse"    id=11   [XExtensionPointer]
"Wacom Bamboo P&T 4x5"  id=12   [XExtensionPointer]

Oh, and finally, I tried ehfortin's fdi file as posted, to no avail - things stopped working completely, as they do if I use that alternate merge line.

Cheers.

[marek_online]

If you test this wcm2_patch, please try going from eraser, to pen, and back to eraser. Let me know if the cursor moves towards the upper left hand corner when the stylus is moved out of range of the pad and if the eraser still works or not. If it does not work, please try moving the stylus in pen mode in and out of pad range two times and see if the eraser works again. Also please attach the /var/log/messages and /var/log/Xorg.0.log files. Thanks!

Using the new wcm2 patch the upward-leftward movement of the cursor is fixed - the pointer stays just where I left it when I take the pen away.

Everything works as was though - eraser acts as a pen in the GIMP and in Xournal, no data from wacdump /dev/input/wacom, no devices listed in the wacomcpl (though the wacompl-exec patch worked this time).

The Xorg.0.log associated with the new wcm2 patch is attached, as is another excerpt from /var/log/messages. I noticed that the stylus switched from reporting as pen to reporting as eraser, and took the excerpt from around the transition. Once it switched to reporting as an eraser, it stayed that way, despite the fact that I switched from pen to eraser and back several times.

[Ayuthia]

Using the new wcm2 patch the upward-leftward movement of the cursor is fixed - the pointer stays just where I left it when I take the pen away.

Everything works as was though - eraser acts as a pen in the GIMP and in Xournal, no data from wacdump /dev/input/wacom, no devices listed in the wacomcpl (though the wacompl-exec patch worked this time).

The Xorg.0.log associated with the new wcm2 patch is attached, as is another excerpt from /var/log/messages. I noticed that the stylus switched from reporting as pen to reporting as eraser, and took the excerpt from around the transition. Once it switched to reporting as an eraser, it stayed that way, despite the fact that I switched from pen to eraser and back several times.

Thanks for the update and assistance. Would it be possible to see the entire messages log? The information that you posted does not show the switching back to pen because the log might have been cut short. It currently shows that the pen was just removed and the eraser was just reaching the pad but it never made contact. I would like to see the portion where the eraser makes the contact and is lifted out of contact. This is where the eraser somehow does not seem to be reporting correctly back to xorg. The data in the messages file is accurate in reporting the data line (so it should show the stylus flipping), but the rest of the information is based on what was done to the code change.

Also, can you verify that the DebugLevel is set in your .fdi file? The sample on how it should look like is in post 330.