Forums

Hi,

Are you getting any events from touch driver.

$getevent

also see if touch driver is registered to input subsystem

$getevent -p

BR,

satish

Hello Satish,

Thanks for your reply. We tried executing this command and for $getevent we saw that the Touch device is registered to input sub-system. But whne we did $getevent -p and we touched the screen, we didn't get any events from the device. We tried to configure the SPI, using the link http://elinux.org/BeagleBoard/SPI#Configuring_Pinmux but we had no luck on this.

I have attached the board file and ads7846 driver code for your reference.

Can you please let us know what else we need to do to make the Touch Screen driver working?

Thanks,

Georgi.

Hi Georgi,

1. I can not find any attachment in the thread. Could you repost the same ?

2. Which kernel are you using ?

3. Are you calling - input_report_abs from your driver, to send events to input subsystem.

BR,

satish

Hi Satish,

Thanks for your quick response.

I have attached the board file and ads7846 driver code for your reference along with dmesg kernel log once again.

1016.files.zip

We are using 2.6.37 kernel.

Yes I can see that  input_report_abs call from ads7846 touch driver, to send events to input subsystem but in dmesg log I didn't find any log.

Please let me know i had done something wrong.

Regards

Georji

Hi Georji.

Are you getting any touchscreen interrupts?

Please post output of following command to debug this further.

#cat /proc/interrupts

Regards,

Pankaj Bharadiya

Hi guys!

I have exactly the same state. Could we figure out this thing because I have listed the touch controller in getvent -p, I can see it is recognized in dmesg but the getevent doesn't show any events... I think this is really close to work it out because if I remove the spi_register_board_info stuff then the ads7846 device is not recognized by the kernel so the SPI communication is ok.

Another thing about I'm not sure and an explanation from some skilled jedi would be very welcome :) is the display thing. If I understand right the current TI kernel branch for the android ics only has tv and dvi support  in board-omap3beagle.c file. However the video signal is still pushed to the LCD. I understand this as a fallback and that the resolution and the density can be still configured with kernel boot args, but the pro way will be to implement the lcd_enable init, disable stuff like at board-omap3evm.c, am I right? What is the proper way to drive a third party lcd and to use only lcd, is there a tutorial explaining this? The main reason why I don't understand this is that the board-omap3beagle.c file does not have any lcd related stuff and the panel is still working as I wrote it...

Guys please help work this out so we can make the patches available for all of you who need them.

Thanks in advance,

sodjas

Hi!

Some additional information.

• So the basis is that the SPI channel is established because we see:

spi3.0 supply vcc not found, using dummy regulator <---- Can this be a problem?!?!?!

ads7846 spi3.0: touchscreen, irq 317

input: ADS7846 Touchscreen as /devices/platform/omap2_mcspi.3/spi3.0/input/input1

• getevent dumps the following:

root@android:/ # getevent -p

could not get driver version for /dev/input/mice, Not a typewriter
add device 1: /dev/input/event1
name: "ADS7846 Touchscreen"
events:
KEY (0001): 014a
ABS (0003): 0000 : value 0, min 0, max 4095, fuzz 0, flat 0, resolution 0
0001 : value 0, min 0, max 4095, fuzz 0, flat 0, resolution 0
0018 : value 0, min 0, max 255, fuzz 0, flat 0, resolution 0
input props:
<not available

could not get driver version for /dev/input/mouse0, Not a typewriter
add device 2: /dev/input/event0
name: "gpio-keys"
events:
KEY (0001): 0114
input props:
<not available

add device 3: /dev/input/event2
name: "twl4030_pwrbutton"
events:
KEY (0001): 0074
input props:
<not available

I bet there is some problem with the interrupt system.

• Another interesting thing is the omap based gpio handling:

// omap_set_gpio_debounce(OMAP3_BEAGLE_TS_GPIO, 1);
// omap_set_gpio_debounce_time(OMAP3_BEAGLE_TS_GPIO, 0xa);
gpio_set_debounce(OMAP3_BEAGLE_TS_GPIO, 310);

The first two lines threw linking error with the beagle step. I googled and found out that the third line with common gpio lib is a workaround at panda board. Could it be possible that the common gpio differs from the platform specific one? I saw that the c files are there they're just simply not compiled? Can I check it in kernel config? If yes where?

Best Regards,

sodjas