OK, I need help with a Wacom Bamboo (Solved for one person)

[Toolfox]

My, my, my...we have been busy, haven't we? 

So far, we know that the new kernel module is a go, so let's not touch that. We've also seen that the HAL and udev config files are working because the wacom-touch and wacom links are correctly created and point to the right events. If you unplug and replug the tablet, HAL and udev will make sure that the links are always pointing to the correct events, no matter how many times they might switch around. Or at least, that's what's SUPPOSED to happen...

I'm thinking that the XWindows driver might not be working correctly; we can take a look at the log file to see whats going on during graphical startup. The file is located at:

/var/log/Xorg.0.log

If something's going wrong there, the additional devices we're creating in xorg.conf won't show up in the GIMP...or Inkscape...or anywhere else. Looking at the log will only help if we're back with the xorg.conf additions for the wacom devices and the udev rules are creating links to the event nodes.

On to the PCLOS packages. Here's the contents of linuxwacom 0.8.2-1:

/etc/udev/rules.d/41-wacom.rules
/usr/bin/wacdump
/usr/bin/xidump
/usr/bin/xsetwacom
/usr/lib/libwacomcfg.so.0
/usr/lib/libwacomcfg.so.0.0.1
/usr/lib/xorg/modules/input/wacom_drv.so

I left out the documentation files, most of which are missing because the package hasn't been updated since I installed the 2007 LiveCD on my machine.

Here's the contents of linuxwacom-controlpanel:

/usr/bin/wacomcpl
/usr/bin/wacomcpl-exec
/usr/lib/tcl8.4/TkXinput
/usr/lib/tcl8.4/TkXinput/libwacomxi.a
/usr/lib/tcl8.4/TkXinput/libwacomxi.la
/usr/lib/tcl8.4/TkXinput/libwacomxi.so
/usr/lib/tcl8.4/TkXinput/libwacomxi.so.0
/usr/lib/tcl8.4/TkXinput/libwacomxi.so.0.0.0
/usr/lib/tcl8.4/TkXinput/pkgIndex.tcl
/usr/share/applications/pclinuxos-wacomcpl.desktop

Let's take a look at the xorg log with the kernel module creating the event nodes, the udev rules creating the links to the event nodes, and xorg.conf trying to create the four devices.




Toolfox

[Meemaw]

I was just hoping that all my fooling around wouldn't fry my system... and wondered if there would be any conflicts between the newer driver and the older control panel stuff.... but I guess not.

OK, I've attached 2 text files.... xorgconf.txt,  xorglog.txt.... and  41-xserver-xorg-input-wacom.rules will be in the next post.......

When I was following the Linux Wacom Project how-to and the guy from the project mailing list that was helping, he said to put the rules in /lib/udev/rules.d (and I used one they had designed with that long name)..... but Synaptic installs a rules file to /etc/udev/rules.d....(so I have both at the moment.) The rules file Synaptic installs doesn't include my model......so instead of leaving both, I should delete the one I added and replace/edit the one that Synaptic installs, right?

I wasn't sure how much of the xorg.0.log you might need so I included most of it.....

You listed /usr/share/applications/pclinuxos-wacomcpl.desktop - it's there but it won't start.

I don't know about busy, but I've sure spent a lot of time at this desk today!

Thanks!
              (Back to work tomorrow..... if the roads are clear......we had more snow last night.)

[attachment deleted by admin]

[Meemaw]

Last file

[attachment deleted by admin]

[Toolfox]

First critique: xorg.conf

Code:

Section "InputDevice"
  Driver        "wacom"
  Identifier    "stylus"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "stylus"
  Option        "USB"           "on"                  # USB ONLY
EndSection

Section "InputDevice"
  Driver        "wacom"
  Identifier    "eraser"
  Option        "Device"        "/dev/input/wacom"   # USB ONLY
  Option        "Type"          "eraser"
  Option        "USB"           "on"                  # USB ONLY
EndSection

So far, so good.

Code:

Section "InputDevice"
  Driver        "wacom"
  Identifier    "touch"
  Option        "Device"        "/dev/input/event2"   # USB ONLY
  Option        "Type"          "touch"
  Option        "USB"           "on"                  # USB ONLY
EndSection

Hmmm...why point to the event node directly? I thought the symlinks were being created correctly, with a "wacom-touch" pointing to the touchpad event. Using the symlinks is always preferred incase the tablet gets unplugged after bootup; the event interface will shift to the next available slots and the old ones will simply go zombie. Udev and HAL update the links as part of the hotplugging process.

Anyway, on to the XWindows log:

Code:

(II) LoadModule: "wacom"                                                               
(II) Loading /usr/lib/xorg/modules/input//wacom_drv.so                                 
(II) Module wacom: vendor="X.Org Foundation"                                           
        compiled for 4.3.99.902, module version = 1.0.0                                 
        Module class: X.Org XInput Driver                                               
        ABI class: X.Org XInput driver, version 2.0                                     
(II) Wacom driver level: 47-0.8.2 $                                                     

The (II) means informational reports from XWindows itself. well, the wacom XWindows driver loaded.

Compare that to the same snippit from MY log:

Code:

(II) LoadModule: "wacom"
(II) Loading /usr/lib/xorg/modules/input//wacom_drv.so
(II) Module wacom: vendor="X.Org Foundation"
compiled for 4.3.99.902, module version = 1.0.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.0
(II) Wacom driver level: 47-0.8.2 $

Why are both drivers at the same driver level (47-0.8.2)? If I were a suspicious sort, I might think that the XWindows driver on the suspect system is not the 0.8.5 just compiled driver, but the old 0.8.2 version that in the PCLOS Repositories. Something's not quite right...

Code:

(**) Option "SendCoreEvents"                                                           
(**) stylus: always reports core events                                                 
(**) stylus device is /dev/input/wacom                                                 
(**) stylus is in absolute mode                                                         
(**) WACOM: suppress value is 2                                                         
(**) Option "USB" "on"                                                                 
(**) stylus: reading USB link                                                           
(**) Option "BaudRate" "9600"                                                           
(**) Option "SendCoreEvents"                                                           
(**) eraser: always reports core events                                                 
(**) eraser device is /dev/input/wacom                                                 
(**) eraser is in absolute mode                                                         
(**) WACOM: suppress value is 2                                                         
(**) Option "USB" "on"                                                                 
(**) eraser: reading USB link                                                           
(**) Option "BaudRate" "9600"                                                           
(**) Option "SendCoreEvents"                                                           
(**) touch: always reports core events                                                 
(**) touch device is /dev/input/event2                                                 
(**) touch is in absolute mode                                                         
(**) WACOM: suppress value is 2                                                         
(**) Option "USB" "on"                                                                 
(**) touch: reading USB link                                                           
(**) Option "BaudRate" "9600"                                                           
(II) evaluating device (touch)                                                         
(II) XINPUT: Adding extended input device "touch" (type: Wacom Touch)                   
(II) evaluating device (eraser)                                                         
(II) XINPUT: Adding extended input device "eraser" (type: Wacom Eraser)                 
(II) evaluating device (stylus)                                                         
(II) XINPUT: Adding extended input device "stylus" (type: Wacom Stylus)                 

Hey cool! Everything's going swimmingly!!

Code:

(**) Option "Device" "/dev/input/event2"                                               
touch Wacom X driver grabbed event device                                               
WACOM: unable to ioctl max values

Uh-oh! That doesn't look too healthy. That's that odd entry I pointed out before, too.

Code:

(**) Option "Device" "/dev/input/wacom"                                                 
(EE) xf86OpenSerial: Cannot open device /dev/input/wacom                               
        No such file or directory.                                                     
Error opening /dev/input/wacom : Invalid argument                                       
(**) Option "Device" "/dev/input/wacom"                                                 
(EE) xf86OpenSerial: Cannot open device /dev/input/wacom                               
        No such file or directory.                                                     
Error opening /dev/input/wacom : Invalid argument                                       

Oh, boy! Now we're really tanking! "No such file or directory" means that there's no symlink. No symlink means udev didn't make one. Udev didn't respond because there's no event to trigger it. That would happen if there's no tablet plugged in; that's the exact response I get when I start my system without my tablet plugged in.

Code:

eraser Wacom X driver grabbed event device                                             
(==) Wacom using pressure threshold of 15 for button 1                                 
(==) Wacom Unknown USB tablet speed=9600 (38400) maxX=740 maxY=500 maxZ=255 resX=1016 resY=1016  tilt=enabled                                                                   
(==) Wacom device "eraser" top X=0 top Y=0 bottom X=740 bottom Y=500 resol X=1016 resol Y=1016                                                                                 
(==) Wacom device "stylus" top X=0 top Y=0 bottom X=740 bottom Y=500 resol X=1016 resol Y=1016                                                                                 

Now we're getting some wisecrack about an "Unknown tablet." If the system doesn't think one is plugged in, that response makes perfect sense. Either that or the driver doesn't understand the response its getting from the hardware because the driver is too old and the hardware is too new.

The old wacom_drv.o driver, located in my /usr/lib/xorg/modules/input/ directory is 88.3 K in size, or 90,412 bytes. What says your Konqueror when you right-click on said file and select "Properties?"




Toolfox

[Meemaw]

It says the same as yours....  I guess I didn't understand....... I thought the driver is the wacom.ko that gets copied to /lib/modules/2.6.27.31.tex5/kernel/drivers/input/tablet.... so when I was uninstalling the 0.8.5-4 stuff, I needed to keep the wacom_drv.0 as well?

(I mapped to the event for touch because that's where I was getting output.....)

So, basically, I'm still messed up............?     

[Toolfox]

You're not completely messed up, only partly...the kernel part of the system is working, the udev part of the system is working, the HAL part of the system is working. That's an impressive record given what you had to go through learning more than you probably wanted to know about your hardware.

That was the Linux Experience back in the day; funny how it keeps poking its ugly head up now and again. Take heart in the fact that we've almost beaten it into submission.

The wacom_drv.o file is the driver for XWindows; it talks to the kernel driver, whose job is to talk to the hardware and act like a bent pipe in delivering information from the hardware. The XWindows driver takes that information and conforms it to what XWindows needs to present to the GUI.

Perhaps you can recompile the driver source code again, only don't do the final "make install" command. Just grab the compiled driver and copy it manually in place of the old driver (back up the old driver first just in case). See if the new driver is different in size than the old driver. Reboot the machine and take another look at the Xorg.log file to see if there's any change for the better.

On a somewhat related subject: Is the stylus double-ended? Older Wacom tablets have styli with both a pen end and an eraser end. In the GIMP, for example, the eraser is just another input device that can be assigned to any tool you choose; it doesn't have to be an eraser. If so, you might have to add the "eraser" info to xorg.conf to access this feature.



Toolfox

[Meemaw]

You're not completely messed up, only partly...the kernel part of the system is working, the udev part of the system is working, the HAL part of the system is working. That's an impressive record given what you had to go through learning more than you probably wanted to know about your hardware.

I think my problem is that I'm learning, but at this point there's so much I've read that it's starting to mix together (so I keep thinking which do I do.... which HAVE I done.... what's missing.... aaarrrgghh!)

That was the Linux Experience back in the day; funny how it keeps poking its ugly head up now and again. Take heart in the fact that we've almost beaten it into submission.

When I started with Big Daddy, my wireless driver wasn't recognized and I had to manually install it (was an rt61)... it wasn't nearly this hard!!!!  Understandable, I think - there are lots more settings for this - different settings for different actions...

The wacom_drv.o file is the driver for XWindows; it talks to the kernel driver, whose job is to talk to the hardware and act like a bent pipe in delivering information from the hardware. The XWindows driver takes that information and conforms it to what XWindows needs to present to the GUI.

Perhaps you can recompile the driver source code again, only don't do the final "make install" command. Just grab the compiled driver and copy it manually in place of the old driver (back up the old driver first just in case). See if the new driver is different in size than the old driver. Reboot the machine and take another look at the Xorg.log file to see if there's any change for the better.

I could probably do that.....

On a somewhat related subject: Is the stylus double-ended? Older Wacom tablets have styli with both a pen end and an eraser end. In the GIMP, for example, the eraser is just another input device that can be assigned to any tool you choose; it doesn't have to be an eraser. If so, you might have to add the "eraser" info to xorg.conf to access this feature.

Yes, there is a stylus on one end and an eraser on the other end..... I thought I had added "eraser" to my xorg.conf..... it's touch that I seem to be having trouble with, but reading on the Linux Wacom Project mailing list, that seems to be a problem for everyone on the new models....

Thanks!   

[Meemaw]

Well, I must be doing something wrong. I replaced the wacom.ko.gz in the kernel and in /usr/lib/xorg/modules/input it has wacpm_drv.so so I replaced that (the newer one is 123.7 Kib) but now when I restart it's not recognizing the driver. It says
[root@localhost ~]# ls -lh /dev/input
total 0
drwxr-xr-x  2 root root    100 Jan  7 20:10 by-id/
drwxr-xr-x  2 root root    120 Jan  7 20:10 by-path/
crw-r-----  1 root root 13, 64 Jan  7 20:10 event0
crw-rw----+ 1 pam  root 13, 65 Jan  7 20:10 event1
crw-r-----  1 root root 13, 66 Jan  7 20:10 event2
crw-r-----  1 root root 13, 67 Jan  7 20:10 event3
crw-r-----  1 root root 13, 68 Jan  7 20:10 event4
crw-r-----  1 root root 13, 63 Jan  7 20:10 mice
crw-r-----  1 root root 13, 32 Jan  7 20:10 mouse0

and

[root@localhost ~]# depmod -a
WARNING: Module /lib/modules/2.6.27.31.tex5/kernel/drivers/input/tablet/wacom.ko.gz is not an elf object

    I really messed it up now......

[root@localhost ~]# cat /var/log/Xorg.0.log
-------
(EE) PreInit returned NULL for "stylus"                                                             
(EE) PreInit returned NULL for "eraser"                                                             
(EE) PreInit returned NULL for "touch" 

 

[Toolfox]

As I said before (reply #45) the kernel module is (well, was...)a go, so don't touch that anymore.

Now you need to recompile what you did before back on page 3 of this thread with the another distro version driver. This time, make backup copies of the critical driver files (the kernel module and the XWindows driver) before proceeding. Let's get the kernel module and udev/HAL working again before continuing. Once you get something working, copy that file to a safe place and make notes of what it is and where it goes. If you have another accident, you can restore back to a known working configuration.



Toolfox

[Meemaw]

I actually think I backed up most of it to a file in my /home - I'll see what I can dig out tonight.....

Sorry!
 

[Meemaw]

Sorry it's taken me so long - I was ill earlier in the week and haven't been very energetic....

Let me send you a text file of what I've done today....   one thing that isn't in there is the wacom.rules - I haven't changed that from the one that Synaptice installs, but I still have the other one. Isn't that where the /dev/input events are determined?

I'm also kind of excited because I've gotten something in Inkscape (and Gimp) besides dots!

 

[attachment deleted by admin]

[Toolfox]

one thing that isn't in there is the wacom.rules - I haven't changed that from the one that Synaptice installs, but I still have the other one. Isn't that where the /dev/input events are determined?

Yes, it is. You need both the new wacom.ko kernel module and the newer wacom.rules for the kernel portion of the equation to both create the additional /dev/input links and to be able to pass the data stream from the Bamboo tablet.

Now...on to your text file.

BUILD OPTIONS:
            wacom.o - yes
            wacdump - yes
             xidump - yes
        libwacomcfg - yes
         libwacomxi - yes
          xsetwacom - yes
              hid.o - no
       wacom_drv.so - no /usr/lib/xorg/modules/input
        wacom_drv.o - no
  wacom*_drv quirks -

Oops! We're not building the XWindows drivers! wacom_drv.so and wacom_drv.o are marked as no build. These drivers are available in the "Prebuilt" directory of the source code so you don't have to build them; our libc and xorg is modern enough that it should be compatible.

First let's get the kernel module working. Remember, when working with wacdump, XWindows must not be trying to claim the device as its own, or you won't get any output. The Bamboo emulates a USB mouse, so if X is running, the tablet is owned (or should I type, "pwnd" ) by X, which will prevent wacdump from working. I detailed how to stop X from starting earlier in this thread (Reply #22).

Shutdown X, load the new kernel module, install the new version of the .fdi and .rules files in the appropriate places (Reply #36), and let's see if we get the expected results from

cat /proc/bus/usb/devices
cat /proc/bus/input/devices
ls /dev/input

Then try xxd and wacdump. We'll look into XWindows after we get the kernel side working again.



Toolfox

[Meemaw]

one thing that isn't in there is the wacom.rules - I haven't changed that from the one that Synaptice installs, but I still have the other one. Isn't that where the /dev/input events are determined?

Yes, it is. You need both the new wacom.ko kernel module and the newer wacom.rules for the kernel portion of the equation to both create the additional /dev/input links and to be able to pass the data stream from the Bamboo tablet.

OK..... I'll copy over the new rules and .fdi file.

Now...on to your text file.

BUILD OPTIONS:
            wacom.o - yes
            wacdump - yes
             xidump - yes
        libwacomcfg - yes
         libwacomxi - yes
          xsetwacom - yes
              hid.o - no
       wacom_drv.so - no /usr/lib/xorg/modules/input
        wacom_drv.o - no
  wacom*_drv quirks -

Oops! We're not building the XWindows drivers! wacom_drv.so and wacom_drv.o are marked as no build. These drivers are available in the "Prebuilt" directory of the source code so you don't have to build them; our libc and xorg is modern enough that it should be compatible.

After I did make uninstall of the 0.8.5-9 stuff and reinstalled the Synaptic pkgs, I copied the wacom.ko and the wacom_drv.so to the appropriate places.....

First let's get the kernel module working. Remember, when working with wacdump, XWindows must not be trying to claim the device as its own, or you won't get any output. The Bamboo emulates a USB mouse, so if X is running, the tablet is owned (or should I type, "pwnd" ) by X, which will prevent wacdump from working. I detailed how to stop X from starting earlier in this thread (Reply #22).

Shutdown X, load the new kernel module, install the new version of the .fdi and .rules files in the appropriate places (Reply #36), and let's see if we get the expected results from

cat /proc/bus/usb/devices
cat /proc/bus/input/devices
ls /dev/input

Then try xxd and wacdump. We'll look into XWindows after we get the kernel side working again.

OK, I'll report back. Thanks!
 

[Meemaw]

I need to go do some things, so I'll just post another 'diary'.......

Thanks!!!

[attachment deleted by admin]

[Toolfox]

Just to make sure I understand this correctly. When you say in your diary:

[root@localhost ~]# wacdump /dev/input/tablet-wacom-bamboo-pen_touch-stylus Webcam
(output with stylus & eraser)

[root@localhost ~]# wacdump /dev/input/tablet-wacom-bamboo-pen_touch-touch 
(output with finger)

[root@localhost ~]# wacdump /dev/input/wacom                           
(output with stylus & eraser)

[root@localhost ~]# wacdump /dev/input/wacom-touch                     
(output with finger)

wacdump gives this in failsafe and in X

xxd is the same.... in failsafe and in X

Are you saying that the kernel module is working and that you get proper output from both test programs? If that's the case, we're back to where we were before -- the kernel module working and we're ready to tackle XWindows!

But I'm back to 'dots' in Gimp......

That's because the tablet is no longer a usb mouse; the kernel driver has turned it into a tablet. XWindows right now only sees some sort of input device that it doesn't understand because it's not a mouse.

Can I also assume that the version of wacdump that you're using is the one that came with the new development source code? I thought that the older version that comes with PCLOS doesn't understand the new hardware data stream.

Verify my suppositions before we continue.






Toolfox