You are not logged in. Please login or register.
chumbysphere forum → Software → Chumby One touch screen device
The wiki says that you can access the touchscreen via /dev/ts and /proc/chumby/touchscreen/coordinates. On my new Chumby One, these devices don't exist. Is this a bug? I would like to access the touchscreen via C or Perl.
On the One, we use a standard input event structure. Open /dev/input/by-id/*-ts-* (I can't remember what it is at the moment) and do a series of read()s. In C, when you do a read() you'll get exactly one input_event per read. The struct is defined in linux/input.h.
In perl, you'll need to use unpack() to get at the data, but it'll be in the same format.
Chumby One /dev/input/by_id
Thanks for the pointer to to Open /dev/input/by-id/*-ts-*.
That helped, but I still have a problem.
Using hexdump it is easy to see how the top bar and the
volume control work, but I don't understand the touchscreen
output.
For the volume control:
chumby:/dev/input/by-id# hexdump soc-noserial-event-joystick
hexdump 1.02
soc-noserial-event-joystick
00000000: c72f0100 0ae70200 02000800 01000000
00000010: c82f0100 6b010900 02000800 01000000
00000020: c92f0100 8c0e0c00 02000800 01000000
00000030: cb2f0100 cc1b0f00 02000800 01000000
00000040: ce2f0100 2c600100 02000800 01000000
00000050: d02f0100 7cc40900 02000800 ffffffff
00000060: d22f0100 8a010900 02000800 ffffffff
00000070: d42f0100 9ab70600 02000800 ffffffff
00000080: d52f0100 dc3d0800 02000800 ffffffff
Turning the volume control clockwise:
The fourth word is 01000000, every other click.
Turning the volume control counter clockwise:
The fourth word is ffffffff, every other click.
For the top Bar:
chumby:/dev/input/by-id# hexdump soc-noserial-event-kbd
hexdump 1.02
soc-noserial-event-kbd
00000000: 06300100 cf100f00 01008200 01000000
00000010: 07300100 bc900200 01008200 00000000
00000020: 08300100 f3240200 01008200 01000000
00000030: 08300100 5cdd0400 01008200 00000000
00000040: 0a300100 46360900 01008200 01000000
00000050: 0e300100 225a0400 01008200 00000000
Depressing the bar causes the fourth word to be
01000000 while releasing it produces 00000000.
However I don't understand the two touchscreen devices.
To test the touchscreen I touched the 4 corners
starting at the upper left going clockwise and
got this:
chumby:/dev/input/by-id# hexdump soc-noserial-ts
hexdump 1.02
soc-noserial-ts
00000070: 74fa3988 812900d8 09010209 0200287f
00000080: ff080700 097f0119 fe000900 032802fc
00000090: 19f97f09 002f0900 05090001 2900fd38
000000a0: 88f91981 0119fa00 19ff0019 ff010900
000000b0: 0639fffe 2803fd39 fd812900 d72900fd
000000c0: 09010308 0200297f fd097f00 09060039
000000d0: fdfe0900 02080200 09027f09 002919fc
000000e0: 04090107 09000128 01f01981 07198100
I don't see any pattern other than you get one
set of 4 words per touch.
For soc-noserial-event-ts, I get a continus
stream of data when I do a touch, but I don't
see a pattern.
Any suggestions?
chumby:/dev/input/by-id# hexdump soc-noserial-event-ts
hexdump 1.02
soc-noserial-event-ts
00000000: 913e0100 c8420600 03001800 01000000 .>...B..........
00000010: 913e0100 2dde0600 03000000 1f030000 .>..-...........
00000020: 913e0100 4cde0600 03000100 ee0c0000 .>..L...........
00000030: 913e0100 6cde0600 01004a01 01000000 .>..l.....J.....
00000040: 913e0100 6cde0600 00000000 00000000 .>..l...........
00000050: 913e0100 8c7a0700 03000000 fd020000 .>...z..........
00000060: 913e0100 ea7a0700 03000100 b60c0000 .>...z..........
00000070: 913e0100 097b0700 00000000 00000000 .>...{..........
00000080: 913e0100 0f260800 03000000 1c030000 .>...&..........
00000090: 913e0100 4d260800 03000100 d10c0000 .>..M&..........
000000a0: 913e0100 4d260800 03001800 00000000 .>..M&..........
All of the files that have *-event-* in the name output a series of struct input_event structures that look like:
struct input_event {
__u32 tv_sec;
__u32 tv_usec;
__u16 type;
__u16 code;
__s32 value;
};So the first two words are a timestamp, and really can be ignored.
When you press the top button you get a type of EV_KEY, a code of 0x82 (which is just an arbitrary key it's simulating), and a value of 0 or 1 depending on whether it's getting pressed or not.
When you rotate the knob you get a type EV_REL, a code of REL_WHEEL, and the value that is signed that tells you how much the wheel has turned since the last event. Currently it only sends an event once every two clicks, but thanks to @inio, it'll send an event every click in the next firmware release.
When you touch the screen, you get three structs with an event of EV_ABS: One with a code of ABS_X, one with a code of ABS_Y, and one with an ABS_PRESSURE. You also get one with a type of EV_KEY and a code of BTN_TOUCH, and you'll know you've got a full packet when you get a code of EV_SYN and a type of EV_REPORT.
You'll need to calibrate the screen yourself, but there's an undocumented feature that you can activate by removing the stmp3xxx_ts module and reinserting it with the parameter scaled_touchscreen=1. It will use hardcoded values that worked fine with the unit I did development on, but may be slightly off depending on the unit. It may be helpful for what you're doing to not have to worry too much about scaling, so it may be something you'd want to try.
Very good information!
I'm not too familiar with the input system. How would I get the control panel listening to some new input device?
For example... If say... I were to write a new module that would take values from a proc entry and send an input_event with said X and Y coordinates, how would I get the control panel to listen to that without to many extensive hacks?
You may be able to write a series of events to that file and get it to work that way, but I'm not sure if that would work.
We may be able to add an extended event to simulate touchscreen clicks. That would end up being the most portable way to do it. Duane will have to chime in on that one.
But I'm curious: You say you wrote a proc entry. Was that a custom kernel module? The touchscreen is a loadable module that can be replaced, if you'd like to do the same thing for the chumby One.
What file are you talking about being able to write to for eventing? The actual /dev/input/* devices? Can they be opened read-write? and if so, by multiple processes (assuming the control panel has them open already)?
It would be much easier (less of a "stack" of hacks) if the current eventing system you have implemented for the control panel would take something for simulating touchscreen clicks. Like you said, then it would be extremely portable and not require kernel hacks as well as user space code to get something working.
Yes, the proc entries I wrote were custom kernel modules. I simply added my code (really small changes) to chumby_sense and tsc2100. I didn't check to see if the functions I needed were exported. If they were, I could instead of re-compiling existing modules, simply added a new module, which I may look into for all platforms. Then I might be asking if there's a way to roll in EXPORT_MODULE into your "official" kernel modules so it's easier to distribute my "control" hack.
Back to the original thread:
My problem was that I didn't know about input.h and the Linux input subsystem. Linux Journal explains it in http://www.linuxjournal.com/article/6429
Thanks
@Materdaddy: Yes, it turns out you can record and playback events that way. Try this: Run "cat /dev/input/by-id/soc-noserial-event-ts > /mnt/storage/ts", then open the controlpanel and tap on "Alarms". Then, hit Control-C to stop the cat.
You can now simulate clicking in the lower-left corner by running: cat /mnt/storage/ts > /dev/input/by-id/soc-noserial-event-ts
Hi,
I have downloaded source from : http://files.chumby.com/source/falconwi … .mx233.tgz
my screen size is x=480 y=272
I used your touch screen driver and i have changed the predefined values as like below.
#define X_MIN 0
#define X_MAX 4095
#define Y_MIN 0
#define Y_MAX 4095
#define SCREEN_W 480
//#define SCREEN_W 320
#define SCREEN_H 272
//#define SCREEN_H 240
Even though if i touch from top left it recognised in bottom left. The same behaviour from bottom of the screen.
how can i solve this problem.
Kindly guide me to solve this.
Thanks for your help.
Regards
Arun kumar, E-mail id: thangam.arunx@gmail.com
@Materdaddy: Yes, it turns out you can record and playback events that way. Try this: Run "cat /dev/input/by-id/soc-noserial-event-ts > /mnt/storage/ts", then open the controlpanel and tap on "Alarms". Then, hit Control-C to stop the cat.
You can now simulate clicking in the lower-left corner by running: cat /mnt/storage/ts > /dev/input/by-id/soc-noserial-event-ts
I haven't dug into why, but this doesn't work on a CC by catting /dev/input/ts0. I reviewed my code and stopped writing to the wring buffer with my proc entry and only send the input_report events with an input_sync at the end which works, but doesn't log my "presses" in the proc entry. I did that last weekend, but have been too busy this week to finally post my code, also I wanted to look at getting something working on the chumby one.
chumbysphere forum → Software → Chumby One touch screen device
Powered by PunBB, supported by Informer Technologies, Inc.