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

[David Zeuthen]

On Thu, 2005-08-18 at 06:23 +0200, Danny Kukawka wrote:
> > 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...
> 
> not sure if it should be a int list. I think we can use string list. Need we 
> for the io the full value (e.g. 0x2e-0x2f) or only the startpoint (e.g. 
> 0x2e)?

OK, string list can work initially.. might be a 1.0 item to use an int
list... suggest to use ranges.

> > > info.category="tabletPC"
> >
> > This I'm not so sure about - see below..
> >
> [...]
> >
> > How do you know it's /dev/ttyS0 btw?
> 
> I currently only know a machine where it should be /dev/ttyS2 to prevent 
> conflicts (HP/Compaq TC4200) with other devices. I would add the tty path to 
> the fdi file. So the user/admin can change this if there are any problems.

Ugh.. this sounds somewhat fragile but I guess Table PC's are pretty
well-known when it comes to what hardware they are composed of...

> > > 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..
> 
> Yes I know, but there is currently such a driver.

Do you know if such a driver planned?

> > 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  a hal device object with
> > the table_pc properties and capability.. could also just merge them on
> > the existing device object with pnp.* properties (which is perfectly
> > valid with our device model and actually a design goal of hal).
> [merged the mails ;)]
> 
> O.k. sounds also good for me to add the /dev/tty input device to HAL through 
> the help, but we must merge the '/dev/ttyS0' to a key (which?) on the pnp 
> device to make the helper configurable by user. (If needed we can also remove 
> the key if the /dev/tty device was added.)

This should go into tablet_pc.* properties.. e.g. tablet_pc.input_device
or something...

> > Also, do you expect apps using HAL to pickup this device? 
> 
> Yes, we need this on SUSE currently for: 
> - YAST
> - SAX
> - if the *cruel* intel x.org drivers are ever fixed for XRandR and some other
>   things work, I plan to write some Tablet PC specific apps. For this it would 
>   very usefull to know if this is really a Tablet PC .... 
> 
> > E.g. do you feel we should add 'tablet_pc' as a capability and export e.g.
> > tablet_pc.device with the device file? 
> 
> yes 
> 
> > I suppose this would only work  well if the device file is accessed in a >
> > similar way across various tablet PC's... 
> 
> I know it sure currenty only for the wacom based tablet PCs.
> 
> - for FinePoint Innovations digitizer you maybe need a special kernel driver, 
> but not sure if this information is actual, but there it's the same (with 
> different x.org drivers) as for wacom: /dev/ttyS0.
> 
> - for penmount touchsreen (on Flybook) it should be IMO /dev/input/event2 so 
> there we don't need to call the helper. We need only to merge the capability.
> 
> > 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.... 
> Would be nice to get this exported by a kernel driver.

So.. it still seems somewhat backwards to me to put this in HAL.. I
mean.. there's no hotplugging of stuff and /dev/ttyS0 is hardcoded
anyway. But if you have a patch for .fdi files and the things we
discussed I suppose there is no harm in adding it..

Cheers,
David