headers
Shem Multinymous | 8 Oct 06:41

ThinkPad input device IDs

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
(Continue reading)

Permalink | Reply |
headers
Henrique de Moraes Holschuh | 8 Oct 15:44
Favicon

Re: ThinkPad input device IDs

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
(Continue reading)

Permalink | Reply |
headers
Shem Multinymous | 8 Oct 20:12

Re: ThinkPad input device IDs

On Wed, Oct 8, 2008 at 9:44 AM, Henrique de Moraes Holschuh
<hmh <at> 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)
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply |
headers
Dmitry Torokhov | 9 Oct 01:56

Re: ThinkPad input device IDs

On Wednesday 08 October 2008, Shem Multinymous wrote:
> On Wed, Oct 8, 2008 at 9:44 AM, Henrique de Moraes Holschuh
> <hmh <at> 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].
(Continue reading)

Permalink | Reply |

Gmane