CF-73 Touchscreen
 

I am trying to make my touchscreen on Panasonic CF73 work under ubuntu edgy..
but i've no clue where to start from..
could someone help?
Thanks

probably a bit late for a reply. just had a quick look on google but cant find anything on what type of touchscreen the cf-73 uses. if you have or had window$ running on it, can you find which driver it was using and if any other makes or models use the same driver. also have a look through the output of dmesg, lspci, lsusb ect for anything that might be relevant. also check in the bios if you can change irq's ect.
good luck

instead was very useful!
I found that the driver of the touchscreen is branded SMK and not gunze...
but there are no SMK drivers available...

Just had a quick look around, the tatung tx-2000 uses an smk touchscreen and is advertised with a choice of window$ or linux.
Might not be the same type panel or driver but it is worth looking in to.
Will post back if I find anything.

thanks stan, it will be superinteresting!

just to revive this post
i've been searching desperately, contacting the author of gunzets drivers, but i was unable to make it work on linux.
Is really a pity, i have a nice touchscreen, and is totally unusable in linux.
PANASONIC SHAME RELEASE THE INFORMATIONS ARE NEEDED TO MAKE A LINUX DRIVER!

You have probably already seen this monstrosity:

http://www.linuxquestions.org/questi...3&goto=newpost

It would be worth trying some of the steps in there (recompile with lifebook.c modified with info for the cf-73). That driver gets its info from DMI, if you install dmidecode it will give the machine specific code in the 'system information' section.
Can you post back the output of 'dmesg', 'lspci', 'dmidecode' and 'uname -a'?
cheers

I got a CF-73 as well. SMK touchscreen, works fine in winxp.

I disabled modem and serial in Bios, so that the only serial device left is the touchscreen. It appears as serial, not PS/2.

Here's the relevant DMI info:

Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: Matsushita Electric Industrial Co.,Ltd.
Product Name: CF-73JCQTXKM
Version: 002

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Matsushita Electric Industrial Co.,Ltd.
Product Name: CF73-2
Version: 001
Serial Number: None

Handle 0x002A, DMI type 21, 7 bytes
Built-in Pointing Device
Type: Touch Pad
Interface: PS/2
Buttons: 2

Handle 0x002B, DMI type 21, 7 bytes
Built-in Pointing Device
Type: Touch Screen
Interface: Serial
Buttons: 0

/dev/ttyS4, UART: 16550A, Port: 0x0238, IRQ: 6. Windows device manager confirms the io and irq are used for TS.

dmesg:
00:08: ttyS4 at I/O 0x238 (irq = 6) is a 16550A

Hmmm, /proc/interrupts showed 6 used by serio, not anymore. Kernel: 2.6.23.8. Also had 2.6.21.5 (from Slack 12).

Fun stuff: initially od outputs nothing. After running minicom (-o) or trying to inputattach -fjt /dev/ttyS4 (which loops in read), od -tx1 shows a stream of apparent random 0x00 and 0x80, nothing else. Touching the screen doesn't influence the output. I'm inferring some setup codes must be sent to the controller. Setting the baud anywhere from 19200 to 115200 gets streams of 0x00.

at 9600:
0000000 00 00 80 00 00 00 80 80 00 80 80 80 80 80 80 80
0000020 80 80 00 00 00 00 00 00 80 00 00 00 80 00 80 80
0000040 80 80 80 80 80 80 80 80 80 80 80 00 80 80 80 00
0000060 80 00 80 00 80 80 00 80 80 80 80 80 80 80 80 80
0000100 00 00 80 00 00 00 80 00 00 80 80 80 00 80 00 00

at 4800:
0000000 00 00 78 00 80 78 80 78 f8 78 f8 78 78 80 00 80
0000020 00 80 78 80 00 78 78 f8 78 f8 78 78 f8 78 80 78
0000040 78 78 78 78 80 78 f8 78 f8 78 78 00 78 80 00 78
0000060 00 f8 78 00 78 00 78 78 78 80 78 f8 78 00 80 00
0000100 80 78 00 00 00 78 00 80 78 80 78 f8 78 f8 78 78

I contacted SMK and they replied with standard keywords "high volume" and "NDA". Found a PDF on their site with some basic info: chip QFP32, 7x7mm, 120S/s, 9600/1200 baud, half duplex. I opened up the laptop and such a chip is present on a board inside the LCD panel. The part numbers don't match, actually on the chip is just a number, indicating custom proprietary module. It's not guaranteed it's from SMK, it could be from any manufacturer.

The connection to the mainboard comes through the left hinge and is one of the two 7 or 8 wire cables. (the one that has one black wire)

The piece that covers the hinge and the connector on the mb comes off fairly easily. I have a scope and thirst for knowledge. I'll post as I have more info.

very likely some sort of init should be sent to the touchscreen before it start working..

Tested the data rate: 9600 to 115200 baud: approx 280bytes/sec. 4800 baud: 180bytes/sec. This indicates 4800 is too low. 9600 is probably right, but doesn't explain the randomness.

Didn't get email notification for the last few posts.
Reading through the service manual at the mo. its here:
http://toughbook.wikispaces.com/CF-73
The touchscreen connector is on page 107 and confirms its a serial port. All serial ports end up at the superio about 30 pages up.
Best I can think of for now is throw some different baud rates at the port with setserial and od /dev/ttyS4 to see what comes out. setserial autoconfig will set the port to what it thinks is right, used to need that for the screen on a cf-27 so it may be worth a try first.
It may be worth trying a few random serial touchscreen drivers like elo and gunze on the node to see what they do.
Sending the output to a text file:
od /dev/ttyS4 > somefile.txt
may make it easier to read, trying a few of the output format options in od may make it readable. Using cat instead of od may give an easier to read output too.
My experience with the cf-27 suggests the output should be quite easy to decode once the port is set up correctly, that's only one type of screen though. I have no idea what other types use.
cheers

Thank you for the service manual link. Looking through it found on p107 the TS conn. Page 80 SuperIO. The following lines are used, on serial 3:

RXD (SIN)
DSR
DCD
DTR
RTS

TS_DETECT goes to pin62 of SuperIO, GP22/XCS2. Probably checked by BIOS.

SOUT (TXD) goes nowhere (I searched). So we can send data to this chip 'till the pretty little cows come home. It's now down to figuring out if the flow control lines need to be shmoozed a specific way, and figuring out the right baudrate. This also tells me calibration is done by software, not in chip.

Good news. I used a voltmeter on the lines to see what was going on in BIOS, Windows and Linux. The difference is that in Linux, both DTR and RTS get asserted, while in Windows only the RTS is. I couldn't figure out how to make Linux not assert DTR (combinations of clocal and crtscts had no effect), so I wrote a program that de-asserts DTR and ran it while od was running. Voila, data now comes in only when the screen is pressed, and it looks like it means something. Data keeps coming as long as the screen is pressed.

Here's the dump ("od -vtx1" meaning show duplicates, hex 1 byte). Screen was tapped shortly top left, top right, bottom right, bottom left. Approximately 5 lines of data resulted for each tap.

0000000 00 00 80 00 00 00 00 c0 af 80 88 81 c0 ac 80 89
0000020 81 c0 ac 80 89 81 c0 ac 80 89 81 c0 ac 80 8b 81
0000040 c0 ac 80 8b 81 c0 ac 80 8b 81 c0 ac 80 8b 81 c0
0000060 ab 80 8c 81 c0 a8 80 8c 81 e0 a8 80 8c 81 e0 a8
0000100 80 8c 81 e0 a8 80 8c 81 e0 a8 80 8c 81 e0 a8 80
0000120 8c 81 c0 82 8e 98 81 c0 82 8e 96 81 c0 83 8e 95
0000140 81 c0 86 8e 92 81 c0 88 8e 91 81 c0 88 8e 90 81
0000160 c0 88 8e 90 81 c0 88 8e 91 81 e0 88 8e 91 81 e0
0000200 88 8e 91 81 e0 88 8e 91 81 e0 88 8e 91 81 e0 88
0000220 8e 91 81 c0 b4 8d a2 8e c0 b3 8d 9f 8e c0 b4 8d
0000240 9e 8e c0 b6 8d 9e 8e c0 b7 8d 9e 8e c0 b7 8d 9e
0000260 8e c0 b7 8d 9e 8e c0 b7 8d 9d 8e c0 b7 8d 9d 8e
0000300 c0 b8 8d 9d 8e c0 b9 8d 9d 8e e0 b9 8d 9d 8e e0
0000320 b9 8d 9d 8e e0 b9 8d 9d 8e e0 b9 8d 9d 8e e0 b9
0000340 8d 9d 8e c0 89 81 86 8e c0 89 81 86 8e c0 89 81
0000360 86 8e c0 87 81 86 8e c0 86 81 87 8e c0 85 81 88
0000400 8e c0 84 81 89 8e c0 83 81 8a 8e c0 81 81 8a 8e
0000420 c0 81 81 8a 8e e0 81 81 8a 8e e0 81 81 8a 8e e0

Does this look familiar to anybody? I'm gonna try to figure out the packet format, back in a bit.

Ok, so, 5 byte really simple protocol.

Packet format: S XL XH YL YH

S: (start byte) 11P0 0000

P = 0 pen down, 1 pen up. For some reason, up to 5 pen up events are transmitted.

XL/YL: 10LL LLLL

L = low 6 bits

XH/YH: 1000 HHHH

H = high 4 bits