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

Danny Kukawka danny.kukawka at web.de
Wed Aug 17 21:23:36 PDT 2005


On Thursday 18 August 2005 03:51, David Zeuthen wrote:
> On Wed, 2005-08-17 at 22:05 +0200, Danny Kukawka wrote:
> > 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",

sounds good to me, I take a look at this for irq and the first port.

> should probably just be pnp.irq.

o.k.

> 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)?

> > 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.

> > 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.

> 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.)

> 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.

Cheers,

Danny


More information about the hal mailing list