Last edited by Ayuthia; October 22nd, 2009 at 06:46 PM.
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.
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.
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
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
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?
Is it a button or just an led that changes color when it is a finger/stylus?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.
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.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).
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?
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.Code:<merge key="input.x11_options.DebugLevel" type="string">12</merge>
Bookmarks