Howto: Get your Gateway (Or Finepoint Pen) Working
Linux - Laptop and NetbookHaving a problem installing or configuring Linux on your laptop? Need help running Linux on your netbook? This forum is for you. This forum is for any topics relating to Linux and either traditional laptops or netbooks (such as the Asus EEE PC, Everex CloudBook or MSI Wind).
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
For earlier questions. Rotation works fine for me. Both the i810 driver and the fpit driver have the rotation option available, you just set it in your xorg.conf and it works fine. For resolution, i've been using 1280x768 the whole time, only reason I can think that you were stuck lower in fedorah is fedorah doesnt pack any useful utilities with the distro so it probably doesnt have the 915resolution tool. Also, if your not using the i810 driver your probably missing direct rendering and 3d acceleration.
I got my widescreen to work now finally, but I still can't figure out the serial port thing. Is there anyway to figure out what I should configure them to? Kinda like an lspci for serial ports or something. And grepping dmesg for tty gives me
if that helps figure out the problem. A quick Google search says that that means that I have the address wrong, but I have no way of figuring out what the actual address is.
For earlier questions. Rotation works fine for me. Both the i810 driver and the fpit driver have the rotation option available, you just set it in your xorg.conf and it works fine. For resolution, i've been using 1280x768 the whole time, only reason I can think that you were stuck lower in fedorah is fedorah doesnt pack any useful utilities with the distro so it probably doesnt have the 915resolution tool. Also, if your not using the i810 driver your probably missing direct rendering and 3d acceleration.
would you mind posting your xorg.conf file, or just the parts with rotation. i could not get this working.
I got my widescreen to work now finally, but I still can't figure out the serial port thing. Is there anyway to figure out what I should configure them to? Kinda like an lspci for serial ports or something. And grepping dmesg for tty gives me
if that helps figure out the problem. A quick Google search says that that means that I have the address wrong, but I have no way of figuring out what the actual address is.
Any resolution on this serial port issue? I'm having trouble with my CX210S
Also, can someone post the ServerLayout portion of their xorg.conf? Thanks,
I wish. I've haven't seen or been able to think of any solution so far, so I've basically given up on it for now. Although it looks like someone on the Ubuntu forums got it working on the same laptop that I have, so maybe they can help solve our problem.
Setting the serial port to 0x06a8 made it sorta work on my CX210X. It knows when the pen is touching the screen, but the pointer just moves around randomly all over the screen even when holding the pen perfectly still. So if you try that and it happens to work for you please post your xorg.conf
Everything works now... except I'd like to know more about how clicking works since I don't have a huge amount of control (there are still spurious clicks every once in a while) and I would like to learn to get the pen button working for a second clicking option, perhaps right click.
I got a new CX2726 after my old laptop died.
Under Gentoo Linux Caeda's suggestions basically worked.
Notes:
1. The /etc/serial.conf line reads:
/dev/ttyS0 port 0x06A8 uart 16954 irq 4 baud_base 38400
(Needed to use 6A8 and add the uart bit. UART was pulled out of thin air; 6A8 can come from /proc/ioports or info reported by PnP.)
2. Rotation
I found it very useful to hack the xf86-input-fpit driver source code so that when the fpitSwapXY flag is true it exchanges the values of screen_width and screen_height.
That way the minX/minY/maxX/maxY values don't need to change for correct pointer tracking, even if you start X with normal orientation and want to use the pen while rotated.
3. Tablet buttons
Windows reports their existence as "Tablet PC Buttons" by "Quanta Computer Inc", with ports 0x0CD0--0x0CD7 and IRQ 11. This doesn't show up in /proc/ioports or /sys/devices/pnp0/*/resources. I can't get them to work. Any suggestions?
Sure. I don't want to send this to the maintainer since it's just a hack... it would be much cooler if the driver could be made RandR aware!
This is just a patch against the source code for version 1.1.0 of the xf86-input-fpit driver.
Code:
--- xf86Fpit_orig.c 2006-04-07 10:32:19.000000000 -0700
+++ xf86Fpit.c 2007-01-15 15:22:30.000000000 -0800
@@ -165,8 +165,9 @@
}
if (priv->fpitSwapXY != 0) {
- *x = xf86ScaleAxis(v1, 0, priv->screen_width, priv->fpitMinY, priv->fpitMaxY);
- *y = xf86ScaleAxis(v0, 0, priv->screen_height, priv->fpitMinX, priv->fpitMaxX);
+ /* Also swapping screen w/h: this is a hack. */
+ *x = xf86ScaleAxis(v1, 0, priv->screen_height, priv->fpitMinY, priv->fpitMaxY);
+ *y = xf86ScaleAxis(v0, 0, priv->screen_width, priv->fpitMinX, priv->fpitMaxX);
} else {
*x = xf86ScaleAxis(v0, 0, priv->screen_width, priv->fpitMinX, priv->fpitMaxX);
*y = xf86ScaleAxis(v1, 0, priv->screen_height, priv->fpitMinY, priv->fpitMaxY);
@@ -280,7 +281,6 @@
else buttons=0; /* We are in hover mode, so no buttons */
}
else { /* the active pen's buttons map directly to the mouse buttons */
- if (!prox) buttons=0; /* We are in hover mode, so no buttons */
}
/* DBG(2, ErrorF("%02d/%02d Prox=%d SW:%x Buttons:%x->%x (%d, %d)\n",
OK, I now have a patch that should make the driver RandR aware. =)
I'm not completely sure the implementation is kosher, but it works great for me.
Intent:
* xorg.conf options have same effect as before patch, if your screen is in normal orientation. (So I'd want InvertY.)
* If you change resolution or rotation, the driver will adjust immediately so that the cursor stays under where the pen is.
I would really appreciate some feedback from a user saying whether the patch usefully improved the driver, and worked as advertised.
If anyone else likes it I'll file a bug and work to get it included in Xorg.
It would be especially cool if somebody could test that it does the right thing with resolution changes and with reflections (xrandr -x, etc.).
Ok, I'm not much of a C programmer (yet) but I decided to mess around with the fpit driver code. Basically, it looks like my pointer spasm problem comes from these two lines:
The problem is I have no clue what half of that means. I know that the 0x7f has something to do with the bits that tell the drive the location of the pointer, but what exactly does it mean. What does the ampersand in front of it do? and what does the << 7 at the end do? If someone could help me figure out what this code is trying to do exactly, I think I might be able to modify it to solve my problem.
And I know the problem is in the fpit driver and not the serial driver because doing a cat /dev/ttyS0 | hexdump while just resting the pen on the screen shows that the output stays fairly the same and the numbers arn't jumping all over like my pointer does.
Also, what would be the easiest way for me to make this print info to help me debug? Cause printf and cout and everything obviously doesn't work.
These lines correspond to the comments above, which explains what the individual bits in each byte mean.
The binary (2-operand) & operator in C is "bitwise and". (x & y) is the binary (base-2) number with 1-bits in the positions where x and y both have 1-bits, and 0-bits in all other positions. Since 0x7f is the binary number 01111111, a bitwise AND with 0x7f just turns off the highest bit of a byte-sized character.
The array index just goes to the appropriate byte in the stream.
The binary (2-operand) << operator in C is "left shift". It shifts all the bits of a number to the left (meaning it makes them larger in the place-value system---you don't need to know/worry about big-endian vs. little-endian machines), inserting zeros after them. This won't overflow because the byte is type-cast to an int first.
So the overall effect of the first statement is to take bits 0-6 of byte #2 (=first byte + 1), and put bits 0--6 of byte #3 to the left of them, and interpret the result as the number x. Which is what the comment before the statement indicates is The Right Thing to Do.
For debug output, try uncommenting the DBG(2, ErrorF(..... statement.
I'm not sure where that output gets recorded though.
Also keep in mind that, say, the x value should jump by 9 units per pixel. (9 == binary 1001.) So it's OK if these numbers move fast!
I would really appreciate some feedback from a user saying whether the patch usefully improved the driver, and worked as advertised.
meekles, I installed the patched driver and it seems to work for most things. I have to say that the calibration (positionwise) works even better than in the tablet PC edition of WinXP.
There is still a problem!!! Even though the mouse position tracks correctly, it doesn't write in the correct position in the program xournal. (I'm running with an inverted screen and it writes the mirror image. Actually, it writes the mirror image in normal mode too!).
The only other problem I still see with this driver is the jitteryness of the clicking interface. If I hold the pen tip just off the top of the surface, it will send tens of click events in rapid succession. This is a problem because when I desire to touch the surface with the pen tip, it has to go through this jittery hover position. Or else if I pause in thought while writing, it will send erase events. When trying to use menus, it can have very undesired consequences.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
