New Wacom Bamboo not working

[kgingeri]

...
I will be creating another patch soon that will provide some detail about data[6] and data[7] (the two values being used for pressre) again. Am I correct that only the 0xD2 (johnny2K) and the 0xD3 (ehfortin) have the max pressure at 1024 and the other two have 512?

I think they all do. Mine is also 1024 - 0xD4 - so likely all the 0xD<n> series Ayuthia.

[Ayuthia]

I do use the patch und .fdi file you said...

Can you post the results of /var/log/Xorg.0.log? I am assuming that you have already found the stylus and defined the stylus in GIMP (Edit->Preferences->InputDevices). Is that correct?

[_Stefan_3_]

I am assuming that you have already found the stylus and defined the stylus in GIMP. Is that correct?

That was it. I finally found out how to enable it in Gimp. Now it works.

Ok, still one problem left:
If I move the pen towards the tablet, it results in scrolling up until touching the tablet.

[Ayuthia]

That was it. I finally found out how to enable it in Gimp. Now it works.

Ok, still one problem left:
If I move the pen towards the tablet, it results in scrolling up until touching the tablet.

I am glad to hear that it is working!

So when the pen is close to the tablet but not touching it, it is scrolling up? If that is the case, can you attach your /var/log/messages file? The current bug is that if the pen goes out of reach, the pointer might float towards the upper left hand corner. We are still looking into that one.

[_Stefan_3_]

I reattached the tablet and could recognize it is working correctly the first few seconds.

Then the scrolling effect appears when getting closer to the tablet.

[Ayuthia]

I reattached the tablet and could recognize it is working correctly the first few seconds.

Then the scrolling effect appears when getting closer to the tablet.

Can you describe what you mean by scrolling? Is the screen scrolling or is the cursor moving upward? From the data you sent, it does not seem like the cursor is moving too far in an upwards direction.

[ehfortin]

I just patch the latest version and tried it. Before talking about this, I just want to confirm that I don't have the issue of scrolling experienced by Stefan_3. Only the automatic movement upper-left. It move there directly (not scrolling) and stays there until I move the cursor again with any other device (stylus, eraser, mouse, trackpoint, etc).

So, for the new code. I've done a clean reboot before trying anything. The /var/log/Xorg.0.log is not having any debug info if the tablet is already connected at boot time. I can track change in /var/log/messages but not in Xorg.0.log. Once I disconnect/reconnect the tablet, I have debug info in both log. To me, it means that when we boot and X start using the xorg.conf file, the tablet object is not handled exactly the same way as when we do a hot-plug.

That being said, once I reconnect the tablet, I've tried to press all the tablet buttons (not the stylus one). Nothing showed. I've tried the touch area without any debug info either. I've then put the stylus on the tablet and move it a bit, tried all buttons again and touch the pad with a finger at the same time.

There is so much debug information coming in, that I can't say I saw something. But I'm under the impression there was nothing different.

The way I see this right now is the tablet seems to have 2 identities (as represented by the fact that /dev/input/wacom and /dev/input/wacom-touch) don't look at the same event. However, if I do a xxd on wacom-touch, nothing happens. So the driver is probably recognizing there is another ID but don't know what to do with it.

On the tablet, there is a led that is either orange (pen mode) or white (touch mode). On Windows, I can see that the tablet buttons seems to only work in touch mode while the stylus is the only one working in pen mode.

How to they manage the pen and touch on the TX2500 and other tabletPC that are known to work? I would think the CTH-661 (Pen & Touch) is probably implemented the same way (and that may be what they tried to achieve with code 0.8.5 but it is not looking for ID 0xD3 and I didn't try to add this yet).

Would it make sense? Anyway, I'm including my latest logs so that you can have a look at it for yourself.

ehfortin

[_Stefan_3_]

So that is what I mean by "scrolling":
Let's say your in the Mozilla-Browser and you have a scrollbar because the website does not fit on the screen. If I enter the browser with the mousecursor und push down the pen towards the tablet the website scrolls upwards. It happens always if there is a scrollbar (textboxes etc.). I can move the pen up and down until the page is scrolled up to the top.
The scrolling-effect just appears if I am getting closer. If I stop moving the pen scrolling stops.

I hope you can understand what I mean

[Ayuthia]

So, for the new code. I've done a clean reboot before trying anything. The /var/log/Xorg.0.log is not having any debug info if the tablet is already connected at boot time. I can track change in /var/log/messages but not in Xorg.0.log. Once I disconnect/reconnect the tablet, I have debug info in both log. To me, it means that when we boot and X start using the xorg.conf file, the tablet object is not handled exactly the same way as when we do a hot-plug.

It sounds like you don't have the DebugLevel set in the xorg.conf file. If you do, can you post your xorg.conf file?

On the tablet, there is a led that is either orange (pen mode) or white (touch mode). On Windows, I can see that the tablet buttons seems to only work in touch mode while the stylus is the only one working in pen mode.

Is it a button or just an led that changes color when it is a finger/stylus?

How to they manage the pen and touch on the TX2500 and other tabletPC that are known to work? I would think the CTH-661 (Pen & Touch) is probably implemented the same way (and that may be what they tried to achieve with code 0.8.5 but it is not looking for ID 0xD3 and I didn't try to add this yet).

They base it on the length of the data or based on what is in data[0]. I think that TheguywholikesLINUX's data might have the touch data there but right now the device is not connecting with the patches.

[Ayuthia]

So that is what I mean by "scrolling":
Let's say your in the Mozilla-Browser and you have a scrollbar because the website does not fit on the screen. If I enter the browser with the mousecursor und push down the pen towards the tablet the website scrolls upwards. It happens always if there is a scrollbar (textboxes etc.). I can move the pen up and down until the page is scrolled up to the top.
The scrolling-effect just appears if I am getting closer. If I stop moving the pen scrolling stops.

I hope you can understand what I mean

That makes sense. Can you tell me which model you have again? I was thinking that it was the same as kgingeri. From your description, a scroll event is being sent over. I think that we will need to look at the Xorg.0.log file. Do you have the DebugLevel set in the .fdi file?

<merge key="input.x11_options.DebugLevel" type="string">12</merge>

If the debug level is set, it should be able to let us know what button event is being sent and from there we can backtrack it to the kernel module.