I have an am3517 EVM that I am working with. Everything worked great while I was using the small LCD and touchscreen that comes with it.
Then I needed to move on to a product intent larger LCD and touchscreen. It was pretty painful, so I thought I would record some notes about what I did, it might help someone else, and I'll be able to find them later.
Caveat: I am pretty clueless in the whole linux-embedded/Qt/tslib world, so take this all with a grain of salt.
My touchscreen supposedly emulates a USB HID mouse. When I plugged a real Logitech USB mouse into my USB, it worked fine. The touchscreen, not so fine.
First, I looked at /dev/input to see what's there. I figured out that "cat /dev/input/event1 | hexdump" would output lots of vaguely sensible looking stuff as I poked the screen.
Then I discovered evtest. This little linux utility parses input events. I had to find the source and cross-compile it for arm, of course.
But now I could see that I was getting absolute position and sync events. I could also see that my presses were BTN_LEFT not BTN_TOUCH, and that instead of ABS_X and ABS_Y position, I got ABS_RY and ABS_RZ.
Diving into tslib, I found that the input-raw.c module used very similar events, just with the more sensible and expected codes. It was obvious why it could not understand panjit events. I considered hacking input-raw but decided it would be better to add a new module based on it.
Tslib is built with the customary automake infrastructure, generating a configure script. Normally you get a source project with a configure script prebuilt. Then do the usual ./configure, make, make install routine. I decided that I could try adding new sources to the plugins dir and just run automake but that wasn't a very good idea. I maimed my tslib source, and had to get new source and start over. But now it didn't have configure so I was still stuck with running automake. Eventually I found that running autoreconf would produce a working configure. I went back to the tslib git and looked at other plugin additions to see what needed to be changed, besides adding the new plugin source.
It looks like there are just a couple of files that have to be modified in addition. I didn't do it this way, I actually hented through the whole of tslib for input-raw references and copied those sections, substituting my plugin. I'll have to go back and do it right sometime.
After a bit of struggling with cross compiling, I got tslib building with my new module. Now I could run ts_test and get output. But not ts_calibrate.
Which brings me to my list of pitfalls.
1. Watch out how you install stuff like tslib. I wasn't always consistent in my use of -prefix (and I didn't understand what it did very well). So I ended up with multiple tslib installations in different places, and, for example, would have my plugin not found because I had another plugins directory that things pointed to that didn't have the plugin.
2. Along with (1) check your environment variables carefully. Find out what environment variables are used and how they are used. TSLIB_PLUGINDIR (which I had incorrectly as TSLIB_PLUGINS_DIR), TSLIB_TSDEVICE, QWS_MOUSE_PROTO were among the ones that I had problems with. As I changed my environment from using TI's linux-devkit toolchain to Code Sourcery toolchain, and back, changes to the environment that went along with those sometimes fouled things up.