From: thaGod <th...@gm...> - 2007-10-21 16:22:20
|
Hello to all, Does anyone have any pertinent info. regarding the touchscreen on the Samsung 4.3" TFT from gumstix.com? At first glance there doesn't seem to be specific support built for the TI tsc2003 in either the linux kernel or tslib. I have found a tsc2003.c driver to be included in the linux kernel source, but this is for a 2.6.12 kernel and I haven't tried to compile it yet. My first step is obviously to try and get the driver built into a kernel module. If that doesn't work then I'll look up the rest of the touchscreen controllers from tslib/kernel source and hope for a direct replacement. I think at the very least, since these are all i2c controllers, there should be a driver that is close. Just for the errors record: When tslib from the gumstix buildroot is used with this controller you get a tsopen() error when ts_calibrate is run. I'll try and elaborate as I progress. thaGod -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13330634 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Philip B. <ph...@ba...> - 2007-10-22 13:06:39
|
I have been hacking at this in OE in my spare cycles. One of the OE guys gave me the attached (which may be close to what you found). We can't find the TS controller on the i@c buss though. Hopefully this helps. Philip thaGod wrote: > Hello to all, > > Does anyone have any pertinent info. regarding the touchscreen on the > Samsung 4.3" TFT from gumstix.com? At first glance there doesn't seem to be > specific support built for the TI tsc2003 in either the linux kernel or > tslib. I have found a tsc2003.c driver to be included in the linux kernel > source, but this is for a 2.6.12 kernel and I haven't tried to compile it > yet. > > My first step is obviously to try and get the driver built into a kernel > module. If that doesn't work then I'll look up the rest of the touchscreen > controllers from tslib/kernel source and hope for a direct replacement. I > think at the very least, since these are all i2c controllers, there should > be a driver that is close. > > Just for the errors record: > > When tslib from the gumstix buildroot is used with this controller you get a > tsopen() error when ts_calibrate is run. I'll try and elaborate as I > progress. > > thaGod |
From: Craig H. <cr...@gu...> - 2007-10-22 19:17:00
|
On Oct 22, 2007, at 6:06 AM, Philip Balister wrote: > I have been hacking at this in OE in my spare cycles. One of the OE =20= > guys gave me the attached (which may be close to what you found). =20 > We can't find the TS controller on the i@c buss though. Hmm, reading the datasheet for the TSC2003, it looks like there might =20= be some missing pull-up resistors on the I2C lines, unless those are =20 on the gumstix -- anyone know if there are I2C pullups on the =20 verdex? It also looks like the prescription at the top of page 6 in =20 the datasheet has not been followed -- there is no 1=C2=B5F cap near the = =20 TSC supply pin. There is C7 on the schematic which might be intended =20= to fill this role, but it's 0.1=C2=B5F and in the layout, far from the =20= supply pin. I'll check with Gordon... It's possible this layout is =20 preventing the TSC from coming up on I2C properly. C= |
From: Gordon K. <go...@gu...> - 2007-10-22 20:58:40
|
yes the verdex has the i2c pull-ups gordon Craig Hughes wrote: > On Oct 22, 2007, at 6:06 AM, Philip Balister wrote: > > >> I have been hacking at this in OE in my spare cycles. One of the OE >> guys gave me the attached (which may be close to what you found). >> We can't find the TS controller on the i@c buss though. >> > > Hmm, reading the datasheet for the TSC2003, it looks like there might > be some missing pull-up resistors on the I2C lines, unless those are > on the gumstix -- anyone know if there are I2C pullups on the > verdex? It also looks like the prescription at the top of page 6 in > the datasheet has not been followed -- there is no 1µF cap near the > TSC supply pin. There is C7 on the schematic which might be intended > to fill this role, but it's 0.1µF and in the layout, far from the > supply pin. I'll check with Gordon... It's possible this layout is > preventing the TSC from coming up on I2C properly. > > C > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@gu...> - 2007-10-22 22:09:13
|
On Oct 22, 2007, at 1:58 PM, Gordon Kruberg wrote: > yes the verdex has the i2c pull-ups Ok, and since those are pulling up to Vcc-on-gumstix, they should be high before the gumstix assets sys_enable, which then causes Vcc-on- daughtercard to come up. So the TSC should be fine wrt that "power on" stuff on page 6 of the datasheet. C |
From: thaGod <th...@gm...> - 2007-10-22 22:33:15
|
I'll give this source a try. Maybe something will jump out if I scope this bus. There shouldn't really be any other traffic, and it would be nice to whether or not there is SOMETHING happening here. I'm really beginning to wonder why this LCD/touchscreen combo was chosen by gumstix. It seems like it would have made more sense to go with a 24bit LCD and a touchscreen controller that is already supported in the kernel. It may just be easier to lay out a new expansion board with a UCB1400 and reroute the LCD signals to make use of a different TFT. thanks for the input, Erick Philip Balister wrote: > > I have been hacking at this in OE in my spare cycles. One of the OE guys > gave me the attached (which may be close to what you found). We can't > find the TS controller on the i@c buss though. > > Hopefully this helps. > > Philip > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13353959 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-23 00:07:20
|
Well pardon my ignorance then =) Gumstix provides a *very* cheap solution when it comes to this stuff. Cost isn't really a factor for me. I'm running a parallel project to one using the blackfin processor family (and trying to finish first after a REALLY late start). As you can imagine.. in the end that won't be a hard price tag to undercut. If I can keep development cost under $150,000 I should be set ;) I know it's off subject, but is there a reason that only 18 bits were routed? I'm still working through the best way to make use of this 18 bit interface, and routing the rest of the bits is certainly not out of the question if it would cut the software development time. I built DirectFB (from buildroot 0.9.24 i think) and qtopia-core 4.3.2 and the DirectFB drivers for qtopia today, but I think 18bit support was only added after DirectFB-1.0? Rebuild with newest DFB... try again. This display is just a little more trouble than I expected. Enough for today.. we all have lives *chuckle*. thanks guys, Erick Craig Hughes wrote: > > On Oct 22, 2007, at 3:33 PM, thaGod wrote: > >> I'm really beginning to wonder why this LCD/touchscreen combo was >> chosen by >> gumstix. It seems like it would have made more sense to go with a >> 24bit LCD >> and a touchscreen controller that is already supported in the >> kernel. It may >> just be easier to lay out a new expansion board with a UCB1400 and >> reroute >> the LCD signals to make use of a different TFT. > > The panel *is* a 24-bit panel. Only 18 bits are brought out on the > 60-pin connector from the gumstix though. We do have a new board > using the UCB1400 (working name audiostix III), but it'll have audio > jacks and other bits on it too, and will be more expensive than the > console board(s). The part cost just on the UCB1400 vs TSC2003 by > themselves is pretty significant. > > I have used Dave Hylands' I2C read/write program to talk to the TSC > on the console-lcd-vx before, so I know it can be made to work... > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13355197 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Craig H. <cr...@gu...> - 2007-10-23 16:21:43
|
On Oct 22, 2007, at 5:07 PM, thaGod wrote: > I know it's off subject, but is there a reason that only 18 bits were > routed? I'm still working through the best way to make use of this > 18 bit > interface, and routing the rest of the bits is certainly not out of > the > question if it would cut the software development time. I built > DirectFB > (from buildroot 0.9.24 i think) and qtopia-core 4.3.2 and the DirectFB > drivers for qtopia today, but I think 18bit support was only added > after > DirectFB-1.0? Rebuild with newest DFB... try again. This display is > just a > little more trouble than I expected. Enough for today.. we all > have lives > *chuckle*. The reason for 18/24 is that we were trying to stay "backward compatible" on the verdex with the 60-pin connector from the basix/ connex, which used the PXA255. That CPU only had 16 bit support in its LCD controller. We stole 2 extra pins from somewhere (maybe 2 of the UART pins which no longer exist on verdex?), but didn't have enough to bring the full 24-bits. C |
From: thaGod <th...@gm...> - 2007-10-23 17:11:56
|
Gotcha. Well then I guess i'll start a new thread here someday and document the procedure for getting the userspace apps working properly in 18bpp mode. Thanks for the info. Erick Craig Hughes wrote: > > On Oct 22, 2007, at 5:07 PM, thaGod wrote: > >> I know it's off subject, but is there a reason that only 18 bits were >> routed? I'm still working through the best way to make use of this >> 18 bit >> interface, and routing the rest of the bits is certainly not out of >> the >> question if it would cut the software development time. I built >> DirectFB >> (from buildroot 0.9.24 i think) and qtopia-core 4.3.2 and the DirectFB >> drivers for qtopia today, but I think 18bit support was only added >> after >> DirectFB-1.0? Rebuild with newest DFB... try again. This display is >> just a >> little more trouble than I expected. Enough for today.. we all >> have lives >> *chuckle*. > > The reason for 18/24 is that we were trying to stay "backward > compatible" on the verdex with the 60-pin connector from the basix/ > connex, which used the PXA255. That CPU only had 16 bit support in > its LCD controller. We stole 2 extra pins from somewhere (maybe 2 of > the UART pins which no longer exist on verdex?), but didn't have > enough to bring the full 24-bits. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13369087 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-28 17:00:06
|
Philip, Yep, that is the same code. I've recently moved past my LCD color problems and I'm ready to tackle this touchscreen driver. Did you compile this into your kernel, or as a module.. ? I think I did try dropping this in the kernel source and editing the K files to add it to the menuconfig. If I remember right it had errors? I didn't take the time then to address them. Just a couple more questions.. should be easy. Did you use tslib as well? and were you using any kind of window manager or directfb or qtopia or something? Just kinda trying to get an idea of the path you've already explored. thanks, Erick Philip Balister wrote: > > I have been hacking at this in OE in my spare cycles. One of the OE guys > gave me the attached (which may be close to what you found). We can't > find the TS controller on the i@c buss though. > > Hopefully this helps. > > Philip > > thaGod wrote: >> Hello to all, >> >> Does anyone have any pertinent info. regarding the touchscreen on the >> Samsung 4.3" TFT from gumstix.com? At first glance there doesn't seem to >> be >> specific support built for the TI tsc2003 in either the linux kernel or >> tslib. I have found a tsc2003.c driver to be included in the linux kernel >> source, but this is for a 2.6.12 kernel and I haven't tried to compile it >> yet. >> >> My first step is obviously to try and get the driver built into a kernel >> module. If that doesn't work then I'll look up the rest of the >> touchscreen >> controllers from tslib/kernel source and hope for a direct replacement. I >> think at the very least, since these are all i2c controllers, there >> should >> be a driver that is close. >> >> Just for the errors record: >> >> When tslib from the gumstix buildroot is used with this controller you >> get a >> tsopen() error when ts_calibrate is run. I'll try and elaborate as I >> progress. >> >> thaGod > > /* > * linux/drivers/i2c/chips/tsc2003.c > * > * Copyright (C) 2005 Bill Gatliff <bgat at billgatliff.com> > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > * > * Driver for TI's TSC2003 I2C Touch Screen Controller > */ > > #include <linux/module.h> > #include <linux/init.h> > #include <linux/slab.h> > #include <linux/i2c.h> > #include <linux/string.h> > #include <linux/bcd.h> > #include <linux/list.h> > #include <linux/device.h> > #include <linux/interrupt.h> > #include <linux/irq.h> > #include <linux/input.h> > #include <linux/platform_device.h> > #include <asm/delay.h> > #include <linux/delay.h> > > #include <asm/arch/gpio.h> > > #define DRIVER_NAME "tsc2003" > > enum tsc2003_pd { > PD_POWERDOWN = 0, /* penirq */ > PD_IREFOFF_ADCON = 1, /* no penirq */ > PD_IREFON_ADCOFF = 2, /* penirq */ > PD_IREFON_ADCON = 3, /* no penirq */ > PD_PENIRQ_ARM = PD_IREFON_ADCOFF, > PD_PENIRQ_DISARM = PD_IREFON_ADCON, > }; > > enum tsc2003_m { > M_12BIT = 0, > M_8BIT = 1 > }; > > enum tsc2003_cmd { > MEAS_TEMP0 = 0, > MEAS_VBAT1 = 1, > MEAS_IN1 = 2, > MEAS_TEMP1 = 4, > MEAS_VBAT2 = 5, > MEAS_IN2 = 6, > ACTIVATE_NX_DRIVERS = 8, > ACTIVATE_NY_DRIVERS = 9, > ACTIVATE_YNX_DRIVERS = 10, > MEAS_XPOS = 12, > MEAS_YPOS = 13, > MEAS_Z1POS = 14, > MEAS_Z2POS = 15 > }; > > #define TSC2003_CMD(cn,pdn,m) (((cn) << 4) | ((pdn) << 2) | ((m) << 1)) > > #define ADC_MAX ((1 << 12) - 1) > > struct tsc2003_data { > struct i2c_client *client; > struct input_dev *idev; > struct timer_list penirq_timer; > struct semaphore sem; > struct task_struct *tstask; > struct completion tstask_completion; > enum tsc2003_pd pd; > enum tsc2003_m m; > int vbat1; > int vbat2; > int temp0; > int temp1; > int in1; > int in2; > }; > > static int tsc2003_i2c_detect (struct i2c_adapter *adapter, int address, > int kind); > > static inline int tsc2003_command (struct tsc2003_data *data, > enum tsc2003_cmd cmd, > enum tsc2003_pd pd) > { > char c; > int ret; > down(&data->sem); > c = TSC2003_CMD(cmd, pd, data->m); > ret = i2c_master_send(data->client, &c, 1); > up(&data->sem); > return ret; > } > > static int tsc2003_read (struct tsc2003_data *data, > enum tsc2003_cmd cmd, > enum tsc2003_pd pd, > int *val) > { > char c; > char d[2]; > int ret; > > c = TSC2003_CMD(cmd, pd, data->m); > ret = i2c_master_send(data->client, &c, 1); > > udelay(20); > ret = i2c_master_recv(data->client, d, data->m == M_12BIT ? 2 : 1); > > if (val) > { > *val = d[0]; > *val <<= 4; > if (data->m == M_12BIT) > *val += (d[1] >> 4); > } > > #if defined(CONFIG_I2C_DEBUG_CHIP) > printk(KERN_ERR "%s: val[%x] = %d\n", > __FUNCTION__, cmd, (((int)d[0]) << 8) + d[1]); > #endif > > return 0; > if (!ret) ret = -ENODEV; > return ret; > } > > static inline int tsc2003_read_temp0 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_TEMP0, pd, t); > } > > static inline int tsc2003_read_temp1 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_TEMP1, pd, t); > } > > static inline int tsc2003_read_xpos (struct tsc2003_data *d, enum > tsc2003_pd pd, int *x) > { > return tsc2003_read(d, MEAS_XPOS, pd, x); > } > > static inline int tsc2003_read_ypos (struct tsc2003_data *d, enum > tsc2003_pd pd, int *y) > { > return tsc2003_read(d, MEAS_YPOS, pd, y); > } > > static inline int tsc2003_read_pressure (struct tsc2003_data *d, enum > tsc2003_pd pd, int *p) > { > return tsc2003_read(d, MEAS_Z1POS, pd, p); > } > > static inline int tsc2003_read_in1 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_IN1, pd, t); > } > > static inline int tsc2003_read_in2 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_IN2, pd, t); > } > > static inline int tsc2003_read_vbat1 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_VBAT1, pd, t); > } > > static inline int tsc2003_read_vbat2 (struct tsc2003_data *d, enum > tsc2003_pd pd, int *t) > { > return tsc2003_read(d, MEAS_VBAT2, pd, t); > } > > static inline int tsc2003_powerdown (struct tsc2003_data *d) > { > /* we don't have a distinct powerdown command, > so do a benign read with the PD bits cleared */ > return tsc2003_read(d, MEAS_IN1, PD_POWERDOWN, 0); > } > > void tsc2003_init_client (struct i2c_client *client) > { > struct tsc2003_data *data = i2c_get_clientdata(client); > > data->pd = PD_PENIRQ_DISARM; > data->m = M_8BIT; > return; > } > > static int tsc2003ts_thread (void *v) > { > struct tsc2003_data *d = v; > struct task_struct *tsk = current; > int pendown=0; > > d->tstask = tsk; > > daemonize(DRIVER_NAME "tsd"); > allow_signal(SIGKILL); > > complete(&d->tstask_completion); > > printk(KERN_INFO "%s: address 0x%x\n", > __FUNCTION__, d->client->addr); > > while (!signal_pending(tsk)) > { > unsigned int x, y, p; > > tsc2003_read_xpos(d, PD_PENIRQ_DISARM, &x); > tsc2003_read_ypos(d, PD_PENIRQ_DISARM, &y); > tsc2003_read_pressure(d, PD_PENIRQ_DISARM, &p); > > /* non-X-Y driver read to avoid glitch in penirq (errata?) */ > if (p > 100) { > pendown = 1; > input_report_abs(d->idev, ABS_X, x); > input_report_abs(d->idev, ABS_Y, y); > input_report_abs(d->idev, ABS_PRESSURE, p); > input_report_key(d->idev, BTN_TOUCH, 1); > input_sync(d->idev); > } else if (pendown == 1) { > pendown = 0; > input_report_key(d->idev, BTN_TOUCH, 0); > input_report_abs(d->idev, ABS_PRESSURE, 0); > input_sync(d->idev); > } > schedule_timeout_interruptible(msecs_to_jiffies(10)); > } > > d->tstask = NULL; > complete_and_exit(&d->tstask_completion, 0); > } > > static int tsc2003_idev_open (struct input_dev *idev) > { > struct tsc2003_data *d = idev->private; > int ret = 0; > > if (down_interruptible(&d->sem)) > return -EINTR; > > if (d->tstask) > panic(DRIVER_NAME "tsd already running (!). abort."); > > init_completion(&d->tstask_completion); > > ret = kernel_thread(tsc2003ts_thread, d, CLONE_KERNEL); > if (ret >= 0) { > wait_for_completion(&d->tstask_completion); > ret = 0; > } > > up(&d->sem); > > return ret; > } > > static void tsc2003_idev_close (struct input_dev *idev) > { > struct tsc2003_data *d = idev->private; > down_interruptible(&d->sem); > if (d->tstask) > { > send_sig(SIGKILL, d->tstask, 1); > wait_for_completion(&d->tstask_completion); > } > up(&d->sem); > return; > } > > #if defined(CONFIG_SYSFS) && defined(CONFIG_SENSORS_TSC2003_SYSFS) > static ssize_t show_addr (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->client.addr); > } > static DEVICE_ATTR(addr, S_IRUGO, show_addr, NULL); > > static ssize_t show_vbat1 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->vbat1); > } > static DEVICE_ATTR(vbat1, S_IRUGO, show_vbat1, NULL); > > static ssize_t show_vbat2 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->vbat2); > } > static DEVICE_ATTR(vbat2, S_IRUGO, show_vbat2, NULL); > > static ssize_t show_in1 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->in1); > } > static DEVICE_ATTR(in1, S_IRUGO, show_in1, NULL); > > static ssize_t show_in2 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->in2); > } > static DEVICE_ATTR(in2, S_IRUGO, show_in2, NULL); > > static ssize_t show_temp0 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->temp0); > } > static DEVICE_ATTR(temp0, S_IRUGO, show_temp0, NULL); > > static ssize_t show_temp1 (struct device *dev, char *buf) > { > struct tsc2003_data *d = container_of(dev->driver, struct > tsc2003_data, driver); > return sprintf(buf, "%d\n", d->temp1); > } > static DEVICE_ATTR(temp1, S_IRUGO, show_temp1, NULL); > > #warning "TODO: this daemon sometimes hangs the touchscreen daemon" > #warning "TODO: under periods of heavy touch screen activity." > #warning "TODO: Use with caution until the bug is squashed." > static int tsc2003s_thread (void *v) > { > struct tsc2003_data *d = v; > > daemonize(DRIVER_NAME "sd"); > allow_signal(SIGKILL); > > printk(KERN_INFO "%s: address 0x%x\n", > __FUNCTION__, d->client.addr); > > while (!signal_pending(current)) > { > if (!down_interruptible(&d->sem)) > { > if (!timer_pending(&d->penirq_timer)) > { > tsc2003_read_vbat1(d, d->pd, &d->vbat1); > tsc2003_read_vbat2(d, d->pd, &d->vbat2); > tsc2003_read_in1(d, d->pd, &d->in1); > tsc2003_read_in2(d, d->pd, &d->in2); > tsc2003_read_temp0(d, d->pd, &d->temp0); > tsc2003_read_temp1(d, d->pd, &d->temp1); > } > up(&d->sem); > } > set_task_state(current, TASK_INTERRUPTIBLE); > schedule_timeout(5 * HZ); > } > do_exit(0); > } > #endif > > static int tsc2003_driver_register (struct tsc2003_data *data) > { > int ret = 0; > > init_MUTEX(&data->sem); > > data->idev = input_allocate_device(); > if(!data->idev) > { > return -ENOMEM; > } > data->idev->private = data; > data->idev->name = DRIVER_NAME; > data->idev->evbit[0] = BIT(EV_ABS); > data->idev->open = tsc2003_idev_open; > data->idev->close = tsc2003_idev_close; > data->idev->absbit[LONG(ABS_X)] = BIT(ABS_X); > data->idev->absbit[LONG(ABS_Y)] = BIT(ABS_Y); > data->idev->absbit[LONG(ABS_PRESSURE)] = BIT(ABS_PRESSURE); > input_set_abs_params(data->idev, ABS_X, 0, ADC_MAX, 0, 0); > input_set_abs_params(data->idev, ABS_Y, 0, ADC_MAX, 0, 0); > > ret = input_register_device(data->idev); > if(ret) > { > input_free_device(data->idev); > return ret; > } > return ret; > } > > /* Magic definition of all other variables and things */ > static unsigned short normal_i2c[] = {0x48, 0x49, 0x4a, 0x48b, > I2C_CLIENT_END }; > > I2C_CLIENT_INSMOD; > > static int tsc2003_i2c_attach_adapter(struct i2c_adapter *adapter) > { > return i2c_probe(adapter, &addr_data, tsc2003_i2c_detect); > } > > static int tsc2003_i2c_detach_client(struct i2c_client *client) > { > struct tsc2003_data *data=i2c_get_clientdata(client); > int err; > > input_unregister_device(data->idev); > > err = i2c_detach_client(client); > if (err) { > dev_err(&client->dev, "Client deregistration failed, " > "client not detached.\n"); > return err; > } > > return 0; > } > > static struct i2c_driver tsc2003_i2c_driver = { > .driver = { > .owner = THIS_MODULE, > .name = DRIVER_NAME, > }, > .attach_adapter = tsc2003_i2c_attach_adapter, > .detach_client = tsc2003_i2c_detach_client, > .command = NULL > }; > > static struct i2c_client client_template = { > .name = "TSC2003", > .driver = &tsc2003_i2c_driver, > }; > > static int tsc2003_i2c_detect (struct i2c_adapter *adap, int addr, > int kind) > { > struct i2c_client *i2c; > int ret; > struct tsc2003_data *data; > > client_template.adapter = adap; > client_template.addr = addr; > > printk(KERN_INFO "tsc2003 i2c touch screen controller\n"); > printk(KERN_INFO "Bill Gatliff <bgat at billgatliff.com>\n"); > > i2c = kmemdup(&client_template, sizeof(client_template), GFP_KERNEL); > if (i2c == NULL){ > return -ENOMEM; > } > > data = kcalloc(1, sizeof(*data), GFP_KERNEL); > if (!data) { > ret = -ENOMEM; > goto err; > } > data->client = i2c; > i2c_set_clientdata(i2c, data); > > ret = i2c_attach_client(i2c); > > if (ret < 0) { > printk("failed to attach codec at addr %x\n", addr); > goto err; > } > > tsc2003_init_client(i2c); > > tsc2003_powerdown(data); > > ret = tsc2003_driver_register(data); > if(ret < 0) { > printk("driver_register failed\n"); > goto err; > } > > return ret; > > err: > kfree(i2c); > return ret; > } > > #define tsc2003_suspend NULL > #define tsc2003_resume NULL > > static int __devinit tsc2003_probe(struct platform_device *dev) > { > int ret; > > ret=i2c_add_driver(&tsc2003_i2c_driver); > if(ret) > return ret; > > #if defined(CONFIG_SYSFS) && defined(CONFIG_SENSORS_TSC2003_SYSFS) > ret = kernel_thread(tsc2003s_thread, d, CLONE_KERNEL); > if (ret >= 0) > ret = 0; > > device_create_file(dev, &dev_attr_addr); > device_create_file(dev, &dev_attr_vbat1); > device_create_file(dev, &dev_attr_vbat2); > device_create_file(dev, &dev_attr_in1); > device_create_file(dev, &dev_attr_in2); > device_create_file(dev, &dev_attr_temp0); > device_create_file(dev, &dev_attr_temp1); > #endif > return 0; > } > > static int __devexit tsc2003_remove(struct platform_device *dev) > { > i2c_del_driver(&tsc2003_i2c_driver); > return 0; > } > > static struct platform_driver tsc2003_driver = { > .probe = tsc2003_probe, > .remove = __devexit_p(tsc2003_remove), > .suspend = tsc2003_suspend, > .resume = tsc2003_resume, > .driver = { > .name = "tsc2003", > }, > }; > > static int __init tsc2003_init(void) > { > return platform_driver_register(&tsc2003_driver); > } > > static void __exit tsc2003_exit(void) > { > platform_driver_unregister(&tsc2003_driver); > } > > MODULE_AUTHOR("Bill Gatliff <bgat at billgatliff.com>"); > MODULE_DESCRIPTION("TSC2003 Touch Screen Controller driver"); > MODULE_LICENSE("GPL"); > > module_init(tsc2003_init); > module_exit(tsc2003_exit); > > --- /tmp/Kconfig 2007-10-07 14:13:14.000000000 +0200 > +++ linux-2.6.21/drivers/i2c/chips/Kconfig 2007-10-07 14:13:56.902045000 > +0200 > @@ -125,4 +125,18 @@ > This driver can also be built as a module. If so, the module > will be called max6875. > > +config SENSORS_TSC2003 > + tristate "TI TSC2003" > + depends on I2C && EXPERIMENTAL > + default n > + help > + Driver for TI tsc2003 touchscreen and sensor chip/ > + > +config SENSORS_TSC2003_SYSFS > + tristate "TI TSC2003 sysfs interface > + depends on SENSORS_TSC2003 > + default n > + help > + Enabled the sysfs interface for tsc2003 > + > endmenu > --- /tmp/Makefile 2007-10-07 14:14:14.000000000 +0200 > +++ linux-2.6.21/drivers/i2c/chips/Makefile 2007-10-07 14:14:20.072045000 > +0200 > @@ -12,6 +12,7 @@ > obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o > obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o > obj-$(CONFIG_TPS65010) += tps65010.o > +obj-$(CONFIG_SENSORS_TSC2003) += tsc2003.o > > ifeq ($(CONFIG_I2C_DEBUG_CHIP),y) > EXTRA_CFLAGS += -DDEBUG > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13455371 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bill G. <bg...@bi...> - 2007-10-29 11:56:19
|
thaGod wrote: > Philip, > > Yep, that is the same code. I've recently moved past my LCD color problems > and I'm ready to tackle this touchscreen driver. Did you compile this into > your kernel, or as a module.. ? I think I did try dropping this in the > kernel source and editing the K files to add it to the menuconfig. If I > remember right it had errors? I didn't take the time then to address them. > > Just a couple more questions.. should be easy. Did you use tslib as well? > and were you using any kind of window manager or directfb or qtopia or > something? Just kinda trying to get an idea of the path you've already > explored. > > I'd be happy to help you get that code running on the latest kernels. I wrote it back in the 2.6.12 days, and a lot of the APIs have changed since then... and I just haven't had time to keep up! Regards, b.g. -- Bill Gatliff bg...@bi... |
From: Bill G. <bg...@bi...> - 2007-10-29 14:22:19
|
thaGod wrote: > Bill, > > That would be great. I'm going to try and get my footing today so we can > have an intelligent dialogue about your code =) > Great! In retrospect, I think I kinda over-engineered the thing in a few spots, but the chip has so much stuff on it that I was using at the time... And there are a few errata, too. The details of all seem to escape me at the moment. In general, the way it works is that when the device is in use, there's a worker thread that looks at the ADCs whenever the pen is down, and feeds the results to an input device (which is later handled by TSLIB). The worker thread tries to scan the glass semi-periodically, rather than on each PENIRQ, because the latter is incredibly noisy as you might expect. Basically, the kernel thread is a state machine that, on the first pen interrupt, starts sampling the glass periodically until the pen interrupts have "gone away". I use timeouts and completions to help determine when the pen interrupt is still happening, but don't do the actually sampling inside of the interrupt handler. Also, I noted somewhere that I think there's an initialization race in tsc2003_idev_open. It didn't seem to come up in 2.6.12, but I think in later kernels you'll get an OOPS because I set up the interrupt handler before the completion for the penirq is initialized. Questions, comments welcome. b.g. -- Bill Gatliff bg...@bi... |
From: Bill G. <bg...@bi...> - 2007-10-29 18:22:40
|
thaGod wrote: > Ok, I've got it worked in where I want it and I've started working on getting > it to compile. The first hurdle appears to be some changes in i2c.h: > Yes, i2c underwent some major changes in the later kernels. Not sure the nature of them, since I haven't looked at anything i2c-connected in serveral months... > drivers/i2c/chips/tsc2003.c:337: warning: implicit declaration of function > 'set_irq_type' > drivers/i2c/chips/tsc2003.c:337: error: 'IRQ_TYPE_EDGE_FALLING' undeclared > (first use in this function) > This could be genirq-related. > drivers/i2c/chips/tsc2003.c:471: warning: implicit declaration of function > 'to_platform_device' > Interesting. Could be perhaps that i2c headers used to include the necessary additional files, but don't now. > I'm comparing the old version of i2c.h (which I believe is the one you have > used) with the latest version and it seems to have changed fairly > significantly. I doubt I can get away with replacing the new with the old, > but I will try it just to rule it out. I'll do this first and then get to > work on tracing all the changes and getting things updated. > Yes. The code you have was written against 2.6.12. > Also, I think the use of linux/config.h is depreciated? I simply added a > symlink to autoconf.h. i2c-sensors.h was not included in the 2.6.21 kernel > that gumstix is using. That's as far as I've gotten. > I don't know if it's deprecated, or not. Seems like you'd need to get CONFIG_* macros from somewhere... b.g. -- Bill Gatliff bg...@bi... |
From: thaGod <th...@gm...> - 2007-10-29 18:32:26
|
>Yes, i2c underwent some major changes in the later kernels. Not sure >the nature of them, since I haven't looked at anything i2c-connected in >serveral months... Solved by changing in tsc2003.c: static unsigned short normal_i2c[] = {0x48, 0x49, 0x4a, 0x4b, I2C_CLIENT_ISA_END }; static unsigned int normal_isa[] = { I2C_CLIENT_END }; to static unsigned short normal_i2c[] = {0x48, 0x49, 0x4a, 0x4b, I2C_CLIENT_END }; static unsigned int normal_isa[] = { I2C_CLIENT_END }; This is using the latest i2c.h. I found an intermediate version of i2c-sensor.h that worked for me. http://developer.osdl.org/dev/robustmutexes/REPOS/fusyn.hg/?cmd=file;file=include/linux/i2c-sensor.h;filenode=7041b1a90249bf1e72154493f3e2632d708eaef1;style=raw Everything related to i2c ranges was removed in the newer versions. moving right along... Erick Bill Gatliff wrote: > > thaGod wrote: >> Ok, I've got it worked in where I want it and I've started working on >> getting >> it to compile. The first hurdle appears to be some changes in i2c.h: >> > > Yes, i2c underwent some major changes in the later kernels. Not sure > the nature of them, since I haven't looked at anything i2c-connected in > serveral months... > > >> drivers/i2c/chips/tsc2003.c:337: warning: implicit declaration of >> function >> 'set_irq_type' >> drivers/i2c/chips/tsc2003.c:337: error: 'IRQ_TYPE_EDGE_FALLING' >> undeclared >> (first use in this function) >> > > This could be genirq-related. > >> drivers/i2c/chips/tsc2003.c:471: warning: implicit declaration of >> function >> 'to_platform_device' >> > > Interesting. Could be perhaps that i2c headers used to include the > necessary additional files, but don't now. > >> I'm comparing the old version of i2c.h (which I believe is the one you >> have >> used) with the latest version and it seems to have changed fairly >> significantly. I doubt I can get away with replacing the new with the >> old, >> but I will try it just to rule it out. I'll do this first and then get to >> work on tracing all the changes and getting things updated. >> > > Yes. The code you have was written against 2.6.12. > >> Also, I think the use of linux/config.h is depreciated? I simply added a >> symlink to autoconf.h. i2c-sensors.h was not included in the 2.6.21 >> kernel >> that gumstix is using. That's as far as I've gotten. >> > > I don't know if it's deprecated, or not. Seems like you'd need to get > CONFIG_* macros from somewhere... > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13473825 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bill G. <bg...@bi...> - 2007-10-29 22:00:40
|
thaGod wrote: > drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': > drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of > 'request_irq' from incompatible pointer type > Interrupt handlers have a different signature now. b.g. -- Bill Gatliff bg...@bi... |
From: thaGod <th...@gm...> - 2007-10-29 22:13:22
|
I've started working on this problem... I'm at home now so I don't have my code in front of me. I think I changed the input_dev idev declaration to input_dev * idev and that seemed to break me into the rest of the errors I'll need to get it reworked. All-in-all though this hasn't been too painful. Philip have you already done all this? This seems to be required stuff in order to compile this driver. Maybe you'll have some insight into getting this compiled initially. thanks, Erick Bill Gatliff wrote: > > thaGod wrote: >> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >> 'request_irq' from incompatible pointer type >> > > Interrupt handlers have a different signature now. > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13478182 Sent from the Gumstix mailing list archive at Nabble.com. |
From: nchen <nc...@cs...> - 2007-10-30 00:12:59
|
So I've posted my copy here: http://www.cs.umd.edu/~nchen/gumstix/tsc2003.c One of the bigger workarounds I had to do was fix the interrupt request. The old probing method didn't seem to work. Looking through my code I remembered that I hardcoded the IRQ to detect on the PWM0 line on my Gumstix Basix. Ideally, this should be fixed to do auto detection. Nick nchen wrote: > > I've been hacking at this as well. I actually have a semi-working TSC2003 > driver (i.e. sort of works with the tslib test programs and also works in > Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it > builds on gumstix build 1432 (2.6.20 kernel?). > > I've noticed some strange behavior when running ts_test in that it reports > spurious coordinates (cursor seems to jump to a position off screen > intermittently). I don't know if this is from my changes or if this was > happening originally. > > In any case, I think it might be a starting point for a more stable and > bug free version. I can post a copy if you think it will be helpful. > > Nick > > > thaGod wrote: >> >> I've started working on this problem... I'm at home now so I don't have >> my code in front of me. I think I changed the input_dev idev declaration >> to input_dev * idev and that seemed to break me into the rest of the >> errors I'll need to get it reworked. >> >> All-in-all though this hasn't been too painful. Philip have you already >> done all this? This seems to be required stuff in order to compile this >> driver. Maybe you'll have some insight into getting this compiled >> initially. >> >> thanks, >> Erick >> >> >> Bill Gatliff wrote: >>> >>> thaGod wrote: >>>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >>>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >>>> 'request_irq' from incompatible pointer type >>>> >>> >>> Interrupt handlers have a different signature now. >>> >>> >>> b.g. >>> >>> -- >>> Bill Gatliff >>> bg...@bi... >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13479593 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-30 00:49:01
|
Nick, Your code is much cleaner than mine ;) Mine looks like code that has been torn apart for 1 day. I can tell already though that you've fixed the things I was having problems with. Thanks for helping. Erick nchen wrote: > > So I've posted my copy here: > http://www.cs.umd.edu/~nchen/gumstix/tsc2003.c > > One of the bigger workarounds I had to do was fix the interrupt request. > The old probing method didn't seem to work. Looking through my code I > remembered that I hardcoded the IRQ to detect on the PWM0 line on my > Gumstix Basix. Ideally, this should be fixed to do auto detection. > > Nick > > > nchen wrote: >> >> I've been hacking at this as well. I actually have a semi-working TSC2003 >> driver (i.e. sort of works with the tslib test programs and also works in >> Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it >> builds on gumstix build 1432 (2.6.20 kernel?). >> >> I've noticed some strange behavior when running ts_test in that it >> reports spurious coordinates (cursor seems to jump to a position off >> screen intermittently). I don't know if this is from my changes or if >> this was happening originally. >> >> In any case, I think it might be a starting point for a more stable and >> bug free version. I can post a copy if you think it will be helpful. >> >> Nick >> >> >> thaGod wrote: >>> >>> I've started working on this problem... I'm at home now so I don't have >>> my code in front of me. I think I changed the input_dev idev declaration >>> to input_dev * idev and that seemed to break me into the rest of the >>> errors I'll need to get it reworked. >>> >>> All-in-all though this hasn't been too painful. Philip have you already >>> done all this? This seems to be required stuff in order to compile this >>> driver. Maybe you'll have some insight into getting this compiled >>> initially. >>> >>> thanks, >>> Erick >>> >>> >>> Bill Gatliff wrote: >>>> >>>> thaGod wrote: >>>>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >>>>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >>>>> 'request_irq' from incompatible pointer type >>>>> >>>> >>>> Interrupt handlers have a different signature now. >>>> >>>> >>>> b.g. >>>> >>>> -- >>>> Bill Gatliff >>>> bg...@bi... >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Splunk Inc. >>>> Still grepping through log files to find problems? Stop. >>>> Now Search log events and configuration files using AJAX and a browser. >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13480419 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-30 21:06:12
|
I guess I'm missing something here as I try to make use of the driver. I've modprobed the tsc2003 driver and exported my TSLIB_TSDEVICE variable to /dev/input/event0, and I've set up ts.conf for module_raw input. I guess my problem is with my mknod step. Maybe I just can't seem to pick the right major/minor combo or something. The only way I can get ts_* programs to do anything besides give me a ts_open: device not found error is to mknod /dev/input/event0 p as a pipe, but then the test apps just hang. Any ideas? thanks, Erick nchen wrote: > > So I've posted my copy here: > http://www.cs.umd.edu/~nchen/gumstix/tsc2003.c > > One of the bigger workarounds I had to do was fix the interrupt request. > The old probing method didn't seem to work. Looking through my code I > remembered that I hardcoded the IRQ to detect on the PWM0 line on my > Gumstix Basix. Ideally, this should be fixed to do auto detection. > > Nick > > > nchen wrote: >> >> I've been hacking at this as well. I actually have a semi-working TSC2003 >> driver (i.e. sort of works with the tslib test programs and also works in >> Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it >> builds on gumstix build 1432 (2.6.20 kernel?). >> >> I've noticed some strange behavior when running ts_test in that it >> reports spurious coordinates (cursor seems to jump to a position off >> screen intermittently). I don't know if this is from my changes or if >> this was happening originally. >> >> In any case, I think it might be a starting point for a more stable and >> bug free version. I can post a copy if you think it will be helpful. >> >> Nick >> >> >> thaGod wrote: >>> >>> I've started working on this problem... I'm at home now so I don't have >>> my code in front of me. I think I changed the input_dev idev declaration >>> to input_dev * idev and that seemed to break me into the rest of the >>> errors I'll need to get it reworked. >>> >>> All-in-all though this hasn't been too painful. Philip have you already >>> done all this? This seems to be required stuff in order to compile this >>> driver. Maybe you'll have some insight into getting this compiled >>> initially. >>> >>> thanks, >>> Erick >>> >>> >>> Bill Gatliff wrote: >>>> >>>> thaGod wrote: >>>>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >>>>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >>>>> 'request_irq' from incompatible pointer type >>>>> >>>> >>>> Interrupt handlers have a different signature now. >>>> >>>> >>>> b.g. >>>> >>>> -- >>>> Bill Gatliff >>>> bg...@bi... >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Splunk Inc. >>>> Still grepping through log files to find problems? Stop. >>>> Now Search log events and configuration files using AJAX and a browser. >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13495692 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Chris D. <chr...@gm...> - 2007-10-30 21:09:52
|
Is the 'evdev' module loaded? Its also required iirc for tslib... Chris On 10/30/07, thaGod <th...@gm...> wrote: > > I guess I'm missing something here as I try to make use of the driver. I've > modprobed the tsc2003 driver and exported my TSLIB_TSDEVICE variable to > /dev/input/event0, and I've set up ts.conf for module_raw input. I guess my > problem is with my mknod step. Maybe I just can't seem to pick the right > major/minor combo or something. The only way I can get ts_* programs to do > anything besides give me a ts_open: device not found error is to mknod > /dev/input/event0 p as a pipe, but then the test apps just hang. Any ideas? > > thanks, > Erick > > > > nchen wrote: > > > > So I've posted my copy here: > > http://www.cs.umd.edu/~nchen/gumstix/tsc2003.c > > > > One of the bigger workarounds I had to do was fix the interrupt request. > > The old probing method didn't seem to work. Looking through my code I > > remembered that I hardcoded the IRQ to detect on the PWM0 line on my > > Gumstix Basix. Ideally, this should be fixed to do auto detection. > > > > Nick > > > > > > nchen wrote: > >> > >> I've been hacking at this as well. I actually have a semi-working TSC2003 > >> driver (i.e. sort of works with the tslib test programs and also works in > >> Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it > >> builds on gumstix build 1432 (2.6.20 kernel?). > >> > >> I've noticed some strange behavior when running ts_test in that it > >> reports spurious coordinates (cursor seems to jump to a position off > >> screen intermittently). I don't know if this is from my changes or if > >> this was happening originally. > >> > >> In any case, I think it might be a starting point for a more stable and > >> bug free version. I can post a copy if you think it will be helpful. > >> > >> Nick > >> > >> > >> thaGod wrote: > >>> > >>> I've started working on this problem... I'm at home now so I don't have > >>> my code in front of me. I think I changed the input_dev idev declaration > >>> to input_dev * idev and that seemed to break me into the rest of the > >>> errors I'll need to get it reworked. > >>> > >>> All-in-all though this hasn't been too painful. Philip have you already > >>> done all this? This seems to be required stuff in order to compile this > >>> driver. Maybe you'll have some insight into getting this compiled > >>> initially. > >>> > >>> thanks, > >>> Erick > >>> > >>> > >>> Bill Gatliff wrote: > >>>> > >>>> thaGod wrote: > >>>>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': > >>>>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of > >>>>> 'request_irq' from incompatible pointer type > >>>>> > >>>> > >>>> Interrupt handlers have a different signature now. > >>>> > >>>> > >>>> b.g. > >>>> > >>>> -- > >>>> Bill Gatliff > >>>> bg...@bi... > >>>> > >>>> > >>>> ------------------------------------------------------------------------- > >>>> This SF.net email is sponsored by: Splunk Inc. > >>>> Still grepping through log files to find problems? Stop. > >>>> Now Search log events and configuration files using AJAX and a browser. > >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >>>> _______________________________________________ > >>>> gumstix-users mailing list > >>>> gum...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > -- > View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13495692 > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: thaGod <th...@gm...> - 2007-10-31 00:05:31
|
nope... it wasn't loaded as far as i remember. Judging from the wiki it's important too =) thanks Chris, Erick Chris Dollar wrote: > > Is the 'evdev' module loaded? Its also required iirc for tslib... > > Chris > On 10/30/07, thaGod <th...@gm...> wrote: >> >> I guess I'm missing something here as I try to make use of the driver. >> I've >> modprobed the tsc2003 driver and exported my TSLIB_TSDEVICE variable to >> /dev/input/event0, and I've set up ts.conf for module_raw input. I guess >> my >> problem is with my mknod step. Maybe I just can't seem to pick the right >> major/minor combo or something. The only way I can get ts_* programs to >> do >> anything besides give me a ts_open: device not found error is to mknod >> /dev/input/event0 p as a pipe, but then the test apps just hang. Any >> ideas? >> >> thanks, >> Erick >> >> >> >> nchen wrote: >> > >> > So I've posted my copy here: >> > http://www.cs.umd.edu/~nchen/gumstix/tsc2003.c >> > >> > One of the bigger workarounds I had to do was fix the interrupt >> request. >> > The old probing method didn't seem to work. Looking through my code I >> > remembered that I hardcoded the IRQ to detect on the PWM0 line on my >> > Gumstix Basix. Ideally, this should be fixed to do auto detection. >> > >> > Nick >> > >> > >> > nchen wrote: >> >> >> >> I've been hacking at this as well. I actually have a semi-working >> TSC2003 >> >> driver (i.e. sort of works with the tslib test programs and also works >> in >> >> Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it >> >> builds on gumstix build 1432 (2.6.20 kernel?). >> >> >> >> I've noticed some strange behavior when running ts_test in that it >> >> reports spurious coordinates (cursor seems to jump to a position off >> >> screen intermittently). I don't know if this is from my changes or if >> >> this was happening originally. >> >> >> >> In any case, I think it might be a starting point for a more stable >> and >> >> bug free version. I can post a copy if you think it will be helpful. >> >> >> >> Nick >> >> >> >> >> >> thaGod wrote: >> >>> >> >>> I've started working on this problem... I'm at home now so I don't >> have >> >>> my code in front of me. I think I changed the input_dev idev >> declaration >> >>> to input_dev * idev and that seemed to break me into the rest of the >> >>> errors I'll need to get it reworked. >> >>> >> >>> All-in-all though this hasn't been too painful. Philip have you >> already >> >>> done all this? This seems to be required stuff in order to compile >> this >> >>> driver. Maybe you'll have some insight into getting this compiled >> >>> initially. >> >>> >> >>> thanks, >> >>> Erick >> >>> >> >>> >> >>> Bill Gatliff wrote: >> >>>> >> >>>> thaGod wrote: >> >>>>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >> >>>>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >> >>>>> 'request_irq' from incompatible pointer type >> >>>>> >> >>>> >> >>>> Interrupt handlers have a different signature now. >> >>>> >> >>>> >> >>>> b.g. >> >>>> >> >>>> -- >> >>>> Bill Gatliff >> >>>> bg...@bi... >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------- >> >>>> This SF.net email is sponsored by: Splunk Inc. >> >>>> Still grepping through log files to find problems? Stop. >> >>>> Now Search log events and configuration files using AJAX and a >> browser. >> >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> >>>> _______________________________________________ >> >>>> gumstix-users mailing list >> >>>> gum...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13495692 >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13500461 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bill G. <bg...@bi...> - 2007-10-31 03:17:53
|
thaGod wrote: > Hrmm... I'd have to agree, but Nick seems to be using this driver in > conjunction with tslib. I know the module doesn't spawn a dev node upon > loading, so is this something I should look at adding? > Yes, but it's somewhat more involved than it sounds. You have to create a sysfs entry in order for udev to catch on and create the node. In the meantime: $ ls -l /dev/input total 0 drwxr-xr-x 2 root root 100 2007-10-29 21:42 by-id drwxr-xr-x 2 root root 160 2007-10-30 15:10 by-path crw-rw---- 1 root root 13, 64 2007-10-29 21:42 event0 crw-rw---- 1 root root 13, 65 2007-10-29 21:42 event1 crw-rw---- 1 root root 13, 67 2007-10-29 21:42 event3 crw-rw---- 1 root root 13, 68 2007-10-29 21:42 event4 crw-rw---- 1 root root 13, 69 2007-10-29 21:42 event5 crw-rw---- 1 root root 13, 70 2007-10-29 21:42 event6 crw-rw---- 1 root root 13, 72 2007-10-30 15:10 event8 crw-rw---- 1 root root 13, 63 2007-10-29 21:42 mice crw-rw---- 1 root root 13, 32 2007-10-29 21:42 mouse0 crw-rw---- 1 root root 13, 128 2007-10-29 21:42 ts0 > It does compile just fine. I have little doubt that this driver is actually > doing what it is supposed to do... I just can't seem to get tslib to make > meaningful contact with it. I just don't understand the code yet :/ I > haven't had the pleasure of a touchscreen project before this one. > Trickiness of the part itself notwithstanding, the meat of the thing where tslib is concerned involves the driver calling input_report_abs(). At least that's the way the input device subsystem worked in 2.6.12. b.g. -- Bill Gatliff bg...@bi... |
From: thaGod <th...@gm...> - 2007-10-31 03:33:35
|
Hehe... of course I was hoping it would be easy. I think it would finish this whole driver off nicely though. We know it works, as is, up to 2.6.21. It's 90% done! Thanks for your ls... that'll keep me moving. Erick Bill Gatliff wrote: > > thaGod wrote: >> Hrmm... I'd have to agree, but Nick seems to be using this driver in >> conjunction with tslib. I know the module doesn't spawn a dev node upon >> loading, so is this something I should look at adding? >> > > Yes, but it's somewhat more involved than it sounds. You have to create > a sysfs entry in order for udev to catch on and create the node. > > In the meantime: > > $ ls -l /dev/input > total 0 > drwxr-xr-x 2 root root 100 2007-10-29 21:42 by-id > drwxr-xr-x 2 root root 160 2007-10-30 15:10 by-path > crw-rw---- 1 root root 13, 64 2007-10-29 21:42 event0 > crw-rw---- 1 root root 13, 65 2007-10-29 21:42 event1 > crw-rw---- 1 root root 13, 67 2007-10-29 21:42 event3 > crw-rw---- 1 root root 13, 68 2007-10-29 21:42 event4 > crw-rw---- 1 root root 13, 69 2007-10-29 21:42 event5 > crw-rw---- 1 root root 13, 70 2007-10-29 21:42 event6 > crw-rw---- 1 root root 13, 72 2007-10-30 15:10 event8 > crw-rw---- 1 root root 13, 63 2007-10-29 21:42 mice > crw-rw---- 1 root root 13, 32 2007-10-29 21:42 mouse0 > crw-rw---- 1 root root 13, 128 2007-10-29 21:42 ts0 > > >> It does compile just fine. I have little doubt that this driver is >> actually >> doing what it is supposed to do... I just can't seem to get tslib to make >> meaningful contact with it. I just don't understand the code yet :/ I >> haven't had the pleasure of a touchscreen project before this one. >> > > Trickiness of the part itself notwithstanding, the meat of the thing > where tslib is concerned involves the driver calling > input_report_abs(). At least that's the way the input device subsystem > worked in 2.6.12. > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13502354 Sent from the Gumstix mailing list archive at Nabble.com. |
From: nchen <nc...@cs...> - 2007-10-31 06:49:28
|
This is what I am currently doing to get everything working: I have the input-core module in my modules I manually insmod the tsc2003 module then I modprobe evdev I'm relatively new to the whole modules business so I don't know what it takes to correctly set up dependencies automatically. I then have the correct entry in my /dev/input/ Nick thaGod wrote: > > Hehe... of course I was hoping it would be easy. I think it would finish > this whole driver off nicely though. We know it works, as is, up to > 2.6.21. It's 90% done! Thanks for your ls... that'll keep me moving. > > Erick > > > Bill Gatliff wrote: >> >> thaGod wrote: >>> Hrmm... I'd have to agree, but Nick seems to be using this driver in >>> conjunction with tslib. I know the module doesn't spawn a dev node upon >>> loading, so is this something I should look at adding? >>> >> >> Yes, but it's somewhat more involved than it sounds. You have to create >> a sysfs entry in order for udev to catch on and create the node. >> >> In the meantime: >> >> $ ls -l /dev/input >> total 0 >> drwxr-xr-x 2 root root 100 2007-10-29 21:42 by-id >> drwxr-xr-x 2 root root 160 2007-10-30 15:10 by-path >> crw-rw---- 1 root root 13, 64 2007-10-29 21:42 event0 >> crw-rw---- 1 root root 13, 65 2007-10-29 21:42 event1 >> crw-rw---- 1 root root 13, 67 2007-10-29 21:42 event3 >> crw-rw---- 1 root root 13, 68 2007-10-29 21:42 event4 >> crw-rw---- 1 root root 13, 69 2007-10-29 21:42 event5 >> crw-rw---- 1 root root 13, 70 2007-10-29 21:42 event6 >> crw-rw---- 1 root root 13, 72 2007-10-30 15:10 event8 >> crw-rw---- 1 root root 13, 63 2007-10-29 21:42 mice >> crw-rw---- 1 root root 13, 32 2007-10-29 21:42 mouse0 >> crw-rw---- 1 root root 13, 128 2007-10-29 21:42 ts0 >> >> >>> It does compile just fine. I have little doubt that this driver is >>> actually >>> doing what it is supposed to do... I just can't seem to get tslib to >>> make >>> meaningful contact with it. I just don't understand the code yet :/ I >>> haven't had the pleasure of a touchscreen project before this one. >>> >> >> Trickiness of the part itself notwithstanding, the meat of the thing >> where tslib is concerned involves the driver calling >> input_report_abs(). At least that's the way the input device subsystem >> worked in 2.6.12. >> >> >> b.g. >> >> -- >> Bill Gatliff >> bg...@bi... >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13503729 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-31 13:24:57
|
I was wondering if I would have to combine the evdev suggestion with bill's list of device nodes. I'm definitely not a pro, but I think you can add the dependency modules to the Kconfig file and have it get loaded automatically. The i2c-core is auto-loaded for me because I copied one of the other i2c chips module definitions in the Kconfig file that listed I2C & experimental as dependencies. I'll get those kinks worked out too once I get a moment to go back through this process. Erick nchen wrote: > > This is what I am currently doing to get everything working: > I have the input-core module in my modules > I manually insmod the tsc2003 module > then I modprobe evdev > > I'm relatively new to the whole modules business so I don't know what it > takes to correctly set up dependencies automatically. > > I then have the correct entry in my /dev/input/ > > Nick > > > thaGod wrote: >> >> Hehe... of course I was hoping it would be easy. I think it would finish >> this whole driver off nicely though. We know it works, as is, up to >> 2.6.21. It's 90% done! Thanks for your ls... that'll keep me moving. >> >> Erick >> >> >> Bill Gatliff wrote: >>> >>> thaGod wrote: >>>> Hrmm... I'd have to agree, but Nick seems to be using this driver in >>>> conjunction with tslib. I know the module doesn't spawn a dev node upon >>>> loading, so is this something I should look at adding? >>>> >>> >>> Yes, but it's somewhat more involved than it sounds. You have to create >>> a sysfs entry in order for udev to catch on and create the node. >>> >>> In the meantime: >>> >>> $ ls -l /dev/input >>> total 0 >>> drwxr-xr-x 2 root root 100 2007-10-29 21:42 by-id >>> drwxr-xr-x 2 root root 160 2007-10-30 15:10 by-path >>> crw-rw---- 1 root root 13, 64 2007-10-29 21:42 event0 >>> crw-rw---- 1 root root 13, 65 2007-10-29 21:42 event1 >>> crw-rw---- 1 root root 13, 67 2007-10-29 21:42 event3 >>> crw-rw---- 1 root root 13, 68 2007-10-29 21:42 event4 >>> crw-rw---- 1 root root 13, 69 2007-10-29 21:42 event5 >>> crw-rw---- 1 root root 13, 70 2007-10-29 21:42 event6 >>> crw-rw---- 1 root root 13, 72 2007-10-30 15:10 event8 >>> crw-rw---- 1 root root 13, 63 2007-10-29 21:42 mice >>> crw-rw---- 1 root root 13, 32 2007-10-29 21:42 mouse0 >>> crw-rw---- 1 root root 13, 128 2007-10-29 21:42 ts0 >>> >>> >>>> It does compile just fine. I have little doubt that this driver is >>>> actually >>>> doing what it is supposed to do... I just can't seem to get tslib to >>>> make >>>> meaningful contact with it. I just don't understand the code yet :/ I >>>> haven't had the pleasure of a touchscreen project before this one. >>>> >>> >>> Trickiness of the part itself notwithstanding, the meat of the thing >>> where tslib is concerned involves the driver calling >>> input_report_abs(). At least that's the way the input device subsystem >>> worked in 2.6.12. >>> >>> >>> b.g. >>> >>> -- >>> Bill Gatliff >>> bg...@bi... >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13509168 Sent from the Gumstix mailing list archive at Nabble.com. |