ThinkPad input device IDs

ThinkPad input device IDs

[Shem Multinymous]

Hi Dmitry and Henrique,

We seem to have a bit of a mess in regard to input device
identification on ThinkPad-specific devices.

thinkpad-acpi does essentially the following (Henrique's commit
7f5d1cd62 from July 2007, after macro expansion):

        tpacpi_inputdev->name = "ThinkPad Extra Buttons";
        tpacpi_inputdev->phys = "thinkpad_acpi/input0";
        tpacpi_inputdev->id.bustype = BUS_HOST;
        tpacpi_inputdev->id.vendor = PCI_VENDOR_ID_IBM or PCI_VENDOR_ID_LENOVO;
        tpacpi_inputdev->id.product = 0x5054 /* "TP" */;
        tpacpi_inputdev->id.version = 0x4101;

But mainline hdaps uses a different convention (Dmitry's commit
d2fc60d692 from May 2008):

        idev->name = "hdaps";
        idev->phys = "isa1600/input0";
        idev->id.bustype = BUS_ISA;

What's the rationale for the different bus and phys convention?
Also, where does the "isa1600" come from, and why BUS_ISA? As far as I
can tell, the input device polls the ThinkPad embedded controller via
the LPC bus interface of the chipset, so no ISA-like bus is involved.

More concretely:
The out-of-tree tp_smapi version of hdaps followed the thinkpad-acpi
convention so it now conflicts with mainline hdaps. Which should I
follow?

  Shem

Re: ThinkPad input device IDs

[Henrique de Moraes Holschuh]

On Wed, 08 Oct 2008, Shem Multinymous wrote:
> We seem to have a bit of a mess in regard to input device
> identification on ThinkPad-specific devices.

Heh :-)

> thinkpad-acpi does essentially the following (Henrique's commit
> 7f5d1cd62 from July 2007, after macro expansion):
> 
>         tpacpi_inputdev->name = "ThinkPad Extra Buttons";
>         tpacpi_inputdev->phys = "thinkpad_acpi/input0";
>         tpacpi_inputdev->id.bustype = BUS_HOST;
>         tpacpi_inputdev->id.vendor = PCI_VENDOR_ID_IBM or PCI_VENDOR_ID_LENOVO;
>         tpacpi_inputdev->id.product = 0x5054 /* "TP" */;
>         tpacpi_inputdev->id.version = 0x4101;
> 
> But mainline hdaps uses a different convention (Dmitry's commit
> d2fc60d692 from May 2008):
> 
>         idev->name = "hdaps";
>         idev->phys = "isa1600/input0";
>         idev->id.bustype = BUS_ISA;

I am not too surprised, mainline HDAPS is a ugly hack with no thought on
design.

HDAPS:

I guess it used "isa1600" because it talks to the EC over LPC3B port IO, and
the ports are in the 1600-161F range, over the LPC bus.  LPC is considered
to be ISA (mostly because it exists to emulate a restricted set of ISA, just
enough to get IRQs, port I/O and mem I/O). That also explains BUS_ISA.

Now, for thinkpad-acpi:

thinkpad-acpi talks to the ACPI interpretor and the ACPI EC (through the
standard Linux ACPI/ACPICA API), which are considered platform devices (thus
BUS_HOST).  In that case, the phys designator is sort of arbitrary.  I used
thinkpad_acpi/input#, and I will keep that constant as if it were an ABI,
even if I break thinkpad_acpi into various modules later.

> More concretely:
> The out-of-tree tp_smapi version of hdaps followed the thinkpad-acpi
> convention so it now conflicts with mainline hdaps. Which should I
> follow?

I think it is better to use the BUS_HOST convention for this, since HDAPS
really is just one of the services on LPC3B even if LPC3B really *is*
BUS_ISA, ports 1600-161F.  Dmitry would know better, though.  Dmitry?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: ThinkPad input device IDs

[Shem Multinymous]

On Wed, Oct 8, 2008 at 9:44 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> I guess it used "isa1600" because it talks to the EC over LPC3B port IO, and
> the ports are in the 1600-161F range, over the LPC bus.

I see... But this is an ad-hoc port assignment by IBM and other
machines may map different devices to port 1600h. Is it presently
possible to write a udev rule that will match the (mainline) hdaps
input device but not random junk at port 1600 on other machines?


>> The out-of-tree tp_smapi version of hdaps followed the thinkpad-acpi
>> convention so it now conflicts with mainline hdaps. Which should I
>> follow?
>
> I think it is better to use the BUS_HOST convention for this, since HDAPS
> really is just one of the services on LPC3B even if LPC3B really *is*
> BUS_ISA, ports 1600-161F.  Dmitry would know better, though.  Dmitry?

For what it's worth, I should note that tp_smapi's hdaps input IDs
were introduced in July 2007 [1] and are by now in widespread use by
udev rules since they're needed for the reduced-interrupts mode of
hdaps+hdapsd [2].

  Shem

[1] http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1040
[2] http://www.thinkwiki.org/wiki/HDAPS#Userspace_daemon)

Re: ThinkPad input device IDs

[Dmitry Torokhov]

On Wednesday 08 October 2008, Shem Multinymous wrote:
> On Wed, Oct 8, 2008 at 9:44 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > I guess it used "isa1600" because it talks to the EC over LPC3B port IO, and
> > the ports are in the 1600-161F range, over the LPC bus.
> 
> I see... But this is an ad-hoc port assignment by IBM and other
> machines may map different devices to port 1600h. Is it presently
> possible to write a udev rule that will match the (mainline) hdaps
> input device but not random junk at port 1600 on other machines?
>

'Phys' is supposed to be stable identifier within a box, not unique
ID across all boxes in existence, we'd need UUID for that. I wonder
if udev rule could match based on the name of the parent device
("hdaps")?
 
> 
> >> The out-of-tree tp_smapi version of hdaps followed the thinkpad-acpi
> >> convention so it now conflicts with mainline hdaps. Which should I
> >> follow?
> >
> > I think it is better to use the BUS_HOST convention for this, since HDAPS
> > really is just one of the services on LPC3B even if LPC3B really *is*
> > BUS_ISA, ports 1600-161F.  Dmitry would know better, though.  Dmitry?
> 
> For what it's worth, I should note that tp_smapi's hdaps input IDs
> were introduced in July 2007 [1] and are by now in widespread use by
> udev rules since they're needed for the reduced-interrupts mode of
> hdaps+hdapsd [2].
>

I modeled hdaps after i8042 which claims to be BUS_ISA with phys
"isa0060/serioX" after its data register (0x60). I don't particularly
care if you want to switch it to something else... Did we already have a
full release with hdaps marked as BUS_ISA? If so we may just have to use
2 rules, to cover both versions of hdaps.
  
-- 
Dmitry