serial port discovery on a motion computing tablet

I am evaluating a motion computing LE1600 tablet for possible use with linux using Centos 4.4 since that is what we use for several servers and had the installation media handy. This device uses a TouchKO serial touchscreen that has been used by linux in the past but the issue I am facing is that the bios does not expose the serial ports. I spoke with an engineer at TouchKO familiar with the LE1600 project an he told me I would have to access the serial port via acpi. Hmm says I, I guess I have some reading to do. DO after a day or so of trying to get up to speed, I feel I can ask a fairly decent question or two.

I found a lot of wacom references but as this touchscreen has ELO and Microtouch emulations I am hard pressed to figure out where to separate the detection of the port from the driver of the device.

What I need to do is get a connection to the serial port send a couple of commands to it to set the baud rate and emulation mode and then start X where the MuTouch Driver should work.

So. Is this where I need to be asking acpi serial port questions? I found a tc1100 prog somewhere but could not get it to compile correctly, pacpidump compiled ok and I have the output of of acpidump if that helps.

Is this a doable deal? I dled the current (2.6.9-42xxx I think) kernel tree from Centos as the last thing I did before leaving work today and will look at both how Centos (and the upstream provider) configure the kernel and if there are options that look like it might work.

Googling today turned up several references to a 8250_acpi module and then I found a patch somewhere that indicated that it was no longer needed. I wish I had looked at the kernel tree before leaving today but I thought i would ask for some tips to get me going and possibly add some known good hardware to the list before I am done.

Am I correct in thinking that I should be able to get a reference to the serial port through acpi on this box? Any tips ? Any testing that you guys would like done while I have this hardware?

TIA

Bret

It sounds like it ought to be exposed via ACPIPNP. If you do cat /sys/bus/pnp/devices/*/id, do any of them look plausibly linked to the tablet device? If so, add the id to drivers/serial/8250_pnp.c, build it, see if that binds and gives you a serial port and if so send a patch.

Matthew Garrett | [email protected]

Thanks for the help.

nothing there:
[root@localhost serial]# ls -a /sys/bus/pnp/devices/ . ..

nothing loaded in drivers either:
[root@localhost serial]# ls -Ra /sys/bus/pnp/drivers/ /sys/bus/pnp/drivers/:
. .. ide parport_pc serial system

/sys/bus/pnp/drivers/ide:
. ..

/sys/bus/pnp/drivers/parport_pc:
. ..

/sys/bus/pnp/drivers/serial:
. ..

/sys/bus/pnp/drivers/system:
. ..

Is there a module I should load before this works? perhaps a kernel recompile with some additional modules are needed?

Now that I am back at the office and looking at the kernel .config via make xconfig I see that 8250/16550 device discovery via ACPI namespace (SERIAL_8250_ACPI) is not enabled. Is is safe to assume that it should be (go ahead and groan, I probably would) anything else that should be included?

I am going to enable it and start a compile. I guess we will see what kind of horsepower this little dude has.

Thanks again,

Bret

That's, uh, surprising - is CONFIG_PNPACPI set?

Hm. How old is this kernel? SERIAL_8250_ACPI was merged into SERIAL_8250_PNP a while back.

Matthew Garrett | [email protected]

not there:

[root@localhost linux-2.6.9]# grep PNPACPI .config [root@localhost linux-2.6.9]#

2.6.9-42 Latest Centos kernel. Too old?

Bret

Ok. You'll certainly need that.

Ouch. Life will probably be easier if you can use anything newer - I don't have any trees anywhere near that old now.

Matthew Garrett | [email protected]

Woo hoo! I see my device it's id is TKO0001 just like the engr told me it would be. At the time I had little to no idea what he was talking about.

On to look at the code and see how that works.

Bret

Something like the following should work, if you haven't already got it figured:

index d3d6b82..c7b019b 100644
@@ -340,6 +340,8 @@ static const struct pnp_device_id pnp_dev_table[] = {
 	{       "FUJ02B8",              0 },
 	{       "FUJ02B9",              0 },
 	{       "FUJ02BC",              0 },
+	/* TouchKO touchscreen */
+	{       "TKO0001",              0 },
 	/* Rockwell's (PORALiNK) 33600 INT PNP */
 	{	"WCI0003",		0	},
 	/* Unkown PnP modems */

and then just make sure that you have CONFIG_8250_PNP enabled. After that, it should just appear as a touchscreen. You may still need to perform some handshaking in the protocol interaction to get it working, but ideally that would be done in the X driver.

Matthew Garrett | [email protected]

[root@localhost serial]# diff 8250_pnp.c.orig 8250_pnp.c 326,327c326,329

< /* Wacom tablets */

< { "WACF004", 0 },

---

As you can see, that is almost exactly what I did. Once I recompiled, the device came up attached to ttyS0 irq5 just like the windows side does. I am struggling a bit to get to where I can send the command to place the controller into Microtouch mode. There is a little perl prog I got from the TouchKo site to do that and I thought I could make it work but it is kicking my butt. The controller comes up at 38400 and if my notes are correct, going into MT mode should drop it to 9600 and a reconfig of the port needs to occur to continue talking to it. Right now I cannot get any response back in perl at all.

I CAN use minicom to ping the controller and I get the expected response 'Pass' but can't figure out how to send 0x0D 0x01 FMT 0x0D. IIRC this only has to happen once and the controller will remember what mode its in. Once get it working in linux I bet it will be broken in Windows until it gets reset. Hmm have to think about that. I have a feeling I am going to have to write something to toggle this dude so we can switch back and forth.

I'll dig in tomorrow and get the engineer back on the horn to see if he can help. Is this something that this driver could/should do? Is there some other place that the kernel or a module can set this up so the user does not have to worry about it or is that beyond the scope of what is done in kernel space?

Once I get it working I'll post again with final details just so those that come behind me will have a chance of not reinventing the wheel but I think as far as the acpi side goes you got me going.

Thanks again.

Bret

It would be possible to do it in the kernel, but I think that would effectively require a new serial driver. It's probably easier to do it in userspace, either in an X driver or gpm or whatever's being used to accept input. Beyond that, I'm afraid I'm not sure what the problem is right now!

Matthew Garrett | [email protected]