Hi,
I notice that since kernel 2.6.13 that the /devfs system has been moved over to sysfs

previously the touchscreen on linux was under /dev/ts
with a potential link to /dev/h3600_ts

with the new kernel 2.6.23, that i have just ported to a new board

my touchscreen is sitting at:

input: ADS784x Touchscreen as /devices/platform/atmel_spi.0/spi0.0/input/input0

I can go into the kernel and "undo" this , but that is hardly the correct way to handle kernel upgrades.

Is there something i am missing in the kernel that will 'link' my touch screen back over to /dev/ts


code.

What kind of interface are you using? Event device? Then the touchscreen is still at /dev/input/eventx (x is device number). If you don't like that, make your own device node with mknod (or configure udev if you are using that) to /dev with the name you want and with the same major/minor number as the ts event device.
If your ts does not show up as event device, then check your kernel configuration to enable event device interface for input devices.

Hi,
the TS is actually an SPI device , but I have the event device "checked" in the kernel

just looking over the kernel code in 6.2.23 for the major/minor numbers for the
ADS7846 , there does nto seem to be one when the driver is set up.

code

The ads7846 USES spi interface (an available SPI controller driver). The ads7846 PROVIDES event device interface. The event device is a generic layer supporting buttons (keyboards), switches, relative analog devices (mice), absolute analog devices (touchscreens) etc. All drivers are automatically enumerated as event0...eventx and given respective major/minor numbers, for example on one of my systems:

Then your application goes through all event devices and asks their capabilities. My applications are looking for ABS_X and ABS_Y capable driver. Then, the max and min values are read for each parameter and so the app autodetects your touchscreen, whatever type the controller is.

Thanks AntiSullin,

it's all new to me , never been in the kernel before, and I do really appreciate your help.

Basically I have a board running 2.6.13, with some crappy hacks to run Qutopia.( konqueror qt-2.3.7 qtopia-free-1.7.0)

Qutopia listens via /dev/ts for it's touchscreen

in the 2.6.13 kernel the ads7846 was hacked to provide a character device 254 1

I took the kernel to 2.6.23 and cleaned up the code for this board, which at some point i want to roll back into the Arm public release, but i know people are gonna cry because the TS is no longer working with "old" versions of qtopia.

Ideally I need "something" to sit between the SPI and /dev/ts

So if you consider I'm in the position of taking 2.6.13 with /devfs support & trying to turn it into a "udev" supported system.
currently I have nothing showing up under "/dev/input", but if i do a "dirty "hack"
ls /dev/ts -la
crw-rw---- 1 root root 13, 64 Jan 1 1970 ts
setting a character device to 13 64 ,which is the major/minor of my spi device, as below


/sys # cd /sys/devices/platform/atmel_spi.0/spi0.0/input/input0
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0 # ls
capabilities id name uevent
device modalias phys uniq
event0 mouse0 subsystem
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0 # cd event0
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0/event0 # ls
dev device subsystem uevent
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0/event0 # cat dev
13:64
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0/event0 #

/sys/devices/platform/atmel_spi.0/spi0.0/input/input0 # cat uevent
PRODUCT=0/0/0/0
NAME="ADS784x Touchscreen"
PHYS="spi0.0/input0"
EV=b
KEY=400 0 0 0 0 0 0 0 0 0 0
ABS=1000003
MODALIAS=input:b0000v0000p0000e0000-e0,1,3,k14A,ra0,1,18,mlsfw
/sys/devices/platform/atmel_spi.0/spi0.0/input/input0 #

I can altleast cat /dev/ts |hexdump, which shows my spi device is atleast working

0000000 dd63 34aa a850 0003 0001 014a 0001 0000
0000010 dd63 34aa a8ca 0003 0003 0018 1d4c 0000
0000020 dd63 34aa a907 0003 0000 0000 0000 0000
0000030 dd63 34aa 8b04 0004 0001 014a 0000 0000
0000040 dd63 34aa 8b7e 0004 0003 0018 0000 0000
0000050 dd63 34aa 8bbb 0004 0000 0000 0000 0000
0000060 dd64 34aa 615f 0003 0001 014a 0001 0000
0000070 dd64 34aa 61d9 0003 0003 0018 1d4c 0000
0000080 dd64 34aa 6216 0003 0000 0000 0000 0000
0000090 dd64 34aa b97b 0004 0001 014a 0000 0000
00000a0 dd64 34aa ba14 0004 0003 0018 0000 0000
00000b0 dd64 34aa ba51 0004 0000 0000 0000 0000
00000c0 dd64 34aa f0fa 000b 0001 014a 0001 0000
00000d0 dd64 34aa f174 000b 0003 0018 1d4c 0000


but under kernel 2.6.13, the data coming back from the TS appears to be different.

/dev # cat /dev/ts |hexdump
0000000 0001 0751 0649 c293 0001 0767 06d4 c293
0000010 0001 076c 06d0 c293 0001 0774 06c4 c293
0000020 0001 076a 06dd c293 0001 0761 0591 c293
0000030 0001 0767 055d c293 0001 07e8 06ce c293
0000040 0001 0776 06cd c293 0001 0760 06d7 c293
0000050 0001 0765 06ed c293 0001 0775 06de c293
0000060 0001 076b 06c9 c293 0001 0765 06d6 c293
0000070 0001 0766 06d9 c293 0001 0771 05de c293
0000080 0001 0771 0590 c293 0001 0742 06d9 c293
0000090 0001 0761 06cb c293 0001 0771 06e6 c293
00000a0 0001 0760 06e9 c293 0001 076d 06cf c293
00000b0 0001 076c 06cc c293 0001 075c 07bf c293
00000c0 0001 0774 06cc c293 0001 0759 061f c293
00000d0 0001 0761 05ff c293 0001 079d 06d1 c293
00000e0 0001 0746 06d7 c293 0001 075a 06d3 c293
00000f0 0001 077d 06e1 c293 0001 0769 06c7 c293
0000100 0001 0777 06c5 c293 0001 075a 06cd c293
0000110 0001 076a 06da c293 0001 0767 0669 c293
0000120 0001 07a4 0639 c293 0001 075e 06d7 c293
0000130 0001 075f 06df c293 0001 0776 06e1 c293
0000140 0001 0771 06cc c293 0001 075f 06d2 c293
0000150 0001 0774 06de c293 0001 0774 06d3 c293
0000160 0001 0769 06d2 c293 0001 0773 0680 c293
0000170 0001 0762 06cd c293 0001 078e 06c5 c293
0000180 0001 0764 06c3 c293 0001 0767 06d7 c293


Obviously i am still missing something.

Code.