New Wacom Bamboo not working

[Favux]

Hi kgingeri,

wacom_drv.so is the wacom driver translating data to Xinput: http://linuxwacom.sourceforge.net/in...p/howto/theory

Try getting eraser set up right by adding the by-path or changing both stylus and eraser to the symlink"

	Option		"Device"	"/dev/input/wacom"

I think the symlink for .rules you showed a while ago looked ok. And removing the comment in "ServerLayout" or else commenting the section out.

Also try commenting out all the extra lines in stylus:

	Option 		"Mode"        "Absolute"	# ...in relation to screen (default is abs)
	Option 		"KeepShape"   "on"		# ...conform to screen size
	Option		"Button1"     "1"
	Option		"Button2"     "3"		# ...seems my buttons are mixed?
	Option		"Button3"     "2"
	Option		"Threshold"   "1"		# ...presure required for event button1

My guess it's the same circuitry as for the ones with touch, just a different (non-touch) digitizer. Which is where they saved the money.

[ehfortin]

I have made a change to the wcm2_patch so that it might detect the pen leaving the pad. The previous version was not clearing out the data properly.

This hopefully will fix the cursor problem. I will need to check into how the eraser works to see if we can get the eraser to work like an eraser instead of just another writing device.

Downloaded it and compiled it. I'm not sure if it is better or not. It may be as I don't remember trying this specifically but now, if I loose the cursor (while changing from pen point to eraser and back), I can get out of the tablet and come back from the side and the cursor is picking up. I didn't notice this behaviour before but... it may just be because I was not looking for it.

The eraser is still acting as another drawing tool but the log still show that it is reporting as eraser. So your code is picking up correctly but there is probably something wrong with assignment between X and the code.

Apart from the cursor problem, is there anything else you wanted me to try with this version of the patch?

ehfortin

[ehfortin]

Favux and Kgingeri,

I'm effectively using the .fdi coming from the 0.8.5 version of the linuxwacom package. It is only because it was simpler then getting back the ubuntu package and then purging it over. Anyway, the fdi is about the same except they added the touch type.

So, I don't use xorg.conf at all at this point. The initial reason was that the .rules file I had was creating symling for wacom and wacom-touch but it was always pointing to event7 and event8 even if the kernel/driver is reporting I'm at event12 or event19 or things like this. I've tried to delete the symlink and reconnect the tablet and the symlinks were recreated on the event7 and event8 files again showing that the .rules was picking the connect and was handling it correctly but it seems like there is no process that would create a /dev/input/eventXYZ as required so that the .rules could make the proper connection.

I'm not sure it is easy to read/understand. Basically, on my laptop, wacom and wacom-touch are always related to event7 and event8 event if in the /var/log/messages, I'm seeing that each disconnect/reconnect is incrementing event to a higher number until next reboot.

So, if somebody has an idea why or has a .rules that is more efficient then the one I have (which currently is the one from 0.8.5 as well), it would be great and I could try the xorg.conf modification that should give me my tablet back after a reboot (right now I have to disconnect/reconnect it once to have it working in X even if it is recognized by the boot process in /var/log/messages).

I hope this give the precision you were looking for. Thank you.

ehfortin

[Ayuthia]

Downloaded it and compiled it. I'm not sure if it is better or not. It may be as I don't remember trying this specifically but now, if I loose the cursor (while changing from pen point to eraser and back), I can get out of the tablet and come back from the side and the cursor is picking up. I didn't notice this behaviour before but... it may just be because I was not looking for it.

The eraser is still acting as another drawing tool but the log still show that it is reporting as eraser. So your code is picking up correctly but there is probably something wrong with assignment between X and the code.

Apart from the cursor problem, is there anything else you wanted me to try with this version of the patch?

ehfortin

Does the cursor move when the pen is not touching the pad?

Also, can you attach the Xorg.0.log results as a .tar.bz2 file:

cp /var/log/Xorg.0.log $HOME/xorg.results
cd
tar -cvjf xorg.results.tar.bz2 xorg.results

You can then just attach the xorg.results.tar.bz2 file to your post. I would like to review the data and see what I am missing.

[ehfortin]

Does the cursor move when the pen is not touching the pad?

Also, can you attach the Xorg.0.log results as a .tar.bz2 file:

cp /var/log/Xorg.0.log $HOME/xorg.results
cd
tar -cvjf xorg.results.tar.bz2 xorg.results

You can then just attach the xorg.results.tar.bz2 file to your post. I would like to review the data and see what I am missing.

The cursor move when the pen is not touching the pad (both with pen point and eraser). But if you mean once I'm loosing it, then no, it is not until I go out of the tablet and come back from a side. Note that the log is showing the tablet is picking the signal from the pen and show I'm moving even if the cursor is not.

I've included the Xorg.0.log as requested.

ehfortin

[TheguywholikesLINUX]

That's great! Can you check to see if there are any messages /var/log/messages? If there are messages found, we might be able to find out what the codes are and get them added. From what it sounds like, button0 is not defined or else not defined correctly. It could also be that we don't have the pad defined correctly also.

I have attacked my /var/log/messages compressed with bz2, it is very big!

I have not had time to read all the posts while I was away, I will have to catch up later.

[Ayuthia]

The cursor move when the pen is not touching the pad (both with pen point and eraser). But if you mean once I'm loosing it, then no, it is not until I go out of the tablet and come back from a side. Note that the log is showing the tablet is picking the signal from the pen and show I'm moving even if the cursor is not.

I've included the Xorg.0.log as requested.

ehfortin

Can you send me one of the Xorg.0.log files that contain some of the pen movements on it? If you did some pen movements and restarted, the file would be Xorg.0.log.old.

Are you having to reconnect your tablet to make it work? I am noticing that that the wacom module needed a couple of tries to connect.

[Ayuthia]

I have attacked my /var/log/messages compressed with bz2, it is very big!

I have not had time to read all the posts while I was away, I will have to catch up later.

Thanks! I am going to have to review yours a little more. From an initial glance at it, it looks like you have might have more data than others that is showing up. The other part of it is that it looks like the wcm2_patch might be able to work with your stylus also. Of course, the patch does need more work before it is fully operational.

EDIT:
I have updated wcm2_patch a little more. It should now be identifying all the 0xfN (N is any value 0-9)values and grouping them to the stylus or eraser. I also changed the button identification so it will hopefully send the button events when they are on pad. The patch is at the same location.

Just to summarize since there has been quite a bit of activity, the wcm_patch is currently being used to help gather some pen and finger events coming into the kernel module (wacom_wac.c). The wcm2_patch is the current fix that we are trying to apply to wacom_wac.c so that it will send the correct information to the xorg wacom module.

The stylus is the current focus. Most of the codes have been identified and we are currently trying to put them all in place. We have created another function inside of wacom_wac.c based on the wacom_graphire_irq to handle the Wacom Pen and Touch variations (0xd1, 0xd2, 0xd3, and 0xd4). The patches can be found on post 144 and we currently don't have an official xorg.conf and .fdi definition set up quite yet.

[ehfortin]

Can you send me one of the Xorg.0.log files that contain some of the pen movements on it? If you did some pen movements and restarted, the file would be Xorg.0.log.old.

Are you having to reconnect your tablet to make it work? I am noticing that that the wacom module needed a couple of tries to connect.

Well, I always have the pen movement working once I connect the tablet (except after initial reboot with tablet already connected). I loose the cursor movement when I switch from pen to eraser and back to pen but the driver is still picking the pen movement correctly. I can regain the cursor movement either by moving it with my USB mouse and click back on the app or either by moving the pen from the outside of the tablet to the working area coming from the side . Then, the cursor is restarting to move but... the log is always showing pen movement.

So, the Xorg.0.log that you already have is for a working situation (pen movement wise) while I'm always loosing it if I change from pen to eraser and back and regain it if I move the cursor with another device or move from the side of the tablet with the pen.

Does this make sense?

ehfortin

[Ayuthia]

So, the Xorg.0.log that you already have is for a working situation (pen movement wise) while I'm always loosing it if I change from pen to eraser and back and regain it if I move the cursor with another device or move from the side of the tablet with the pen.

Does this make sense?

ehfortin

The Xorg.0.log that you attached does not have any pen movements. However, I think I have enough information right now with TheguywholikesLINUX's Xorg.0.log data.

I did make the update to the patch to include all 0xfN stylus and eraser codes. The only missing ones are the 0xeN ones. When you have a chance, can you try that patch out and let me know if it is any different? Thanks for doing all this!