[PATCH] add detection of Tablet PCs with WACOM tablet devices

[David Zeuthen]

On Wed, 2005-08-17 at 22:05 +0200, Danny Kukawka wrote:
> > > The problem: if we do only a match from a fdi-file for pnp.id, we don't
> > > get the informtation about the serial irq and port to use setserial. Them
> > > are all different for every manufacturer of Tablet PCs and sometimes
> > > between models from one manufacturer (e.g ACER: 0x93f8/4 and 0x06f8/6,
> > > FSC:0x0220/4, HP/Compaq: 0x0300/4 and 0x0200/6 ...) so we can't add this
> > > to a fdi-file for all machines. I collected data about many different
> > > Tablet PCs for my diploma thesis (but not for all) and I think it's also
> > > complicated to collect this data (irq/port/pnp.id and dmimatch) for all
> > > and keep the information up-to-date. Since the kernel provides the
> > > information to sysfs HAL is the perfect place to parse this information.
> >
> > Well, yea, I see your point but I'm not sure there is big difference
> > whether this is in hald or in a helper invoked by hald?
> 
> I would prefer to povide the information about irq and port directly from HAL. 
> Also I would prefer to add any kind of string to know that this is a 
> tablet/tablet pc. This would make it easier to match this also for upcomming 
> other tablets. I would probose this keys:
> 
> pnp.serial.port=string
> pnp.serial.irq=int

Ah, OK, I see.. I think it's totally cool to add more pnp.* properties
for all PNP devices.. so the code in tablet_pc_add should probably be
moved into pnp_add() and tweaked. For example

+       hal_util_set_int_elem_from_file (d, "pnp.serial.irq",
sysfs_path, "resources",

should probably just be pnp.irq. 

Might also take a systematic approach and take 'dma', 'io' (put in a
string list? uhhh.. maybe we need a int list? I think we do), 'state'
and 'irq'... Should put this in the spec too...

> info.category="tabletPC"

This I'm not so sure about - see below..

> > > This is a internal serial device. The information about the device come
> > > from the bios/dsdt. I tested if you get a hotplug event: no event if you
> > > use setserial. Also not from e.g. /dev/ttyS0.
> >
> > oh.. so there is no Linux Input Event device file, eg. /dev/input/event3
> > for the abstraction for this physical device? There really needs to be..
> > that's what ppl expect from a hal device object of capability input. If
> > there isn't maybe the kernel driver needs to get updated?
> 
> There is IMO no special driver for this device. It directly serial device, you 
> don't need to load a special module and can use /dev/ttyS0 directly for your 
> X server. 

How do you know it's /dev/ttyS0 btw?

> You get a event interface for this only if you add a USB-Tablet.

Because the USB input driver works with the Linux kernel device driver
model I presume. The point I'm getting at is that for this to work well,
there ought to be a Wacom input driver in the kernel that attaches to
the pnp physical device and exports an input class device with a device
link to the pnp device.. Then it would "just work" with hal today..

> The only way I currently see is:
> - add fdi file to merge callout and to add needed info:
>   - pnp.set.dev="/dev/ttyS0" (can differ for special machines)
> - add a helper to call out if info.category="tabletPC" is set
> - helper: 
>    - read irq and port from HAL
>    - call: 'setserial "pnp.set.dev" port "pnp.serial.port" irq 
>                      "pnp.serial.irq" autoconfigure'
>    - add the /dev/ttyS* input device to HAL as new device if 
>      setserial was successful
> 
> Any other ideas?

I think just having the info.callouts.add helper check the pnp.id and
then use the (to be introduced) pnp.irq etc. properties will do the
trick? Said helper *could* construct 

Also, do you expect apps using HAL to pickup this device? E.g. do you
feel we should add 'tablet_pc' as a capability and export e.g.
tablet_pc.device with the device file? I suppose this would only work
well if the device file is accessed in a similar way across various
tablet PC's... Of course, writing kernel drivers for Linux that
integrates with the input subsystem and driver core is much to prefer as
the interface will be the same as other input devices....

What do you think?

Cheers,
David