Comment 8 for bug 1246215

In eventcomm.c:

static struct model_lookup_t model_lookup_table[] = {
    {0x0002, 0x0007, 0x0007, MODEL_SYNAPTICS},
    {0x0002, 0x0008, 0x0008, MODEL_ALPS},
    {0x05ac, PRODUCT_ANY, 0x222, MODEL_APPLETOUCH},
    {0x05ac, 0x223, PRODUCT_ANY, MODEL_UNIBODY_MACBOOK},
    {0x0002, 0x000e, 0x000e, MODEL_ELANTECH},
    {0x0, 0x0, 0x0, 0x0}
};

http://www.linux-usb.org/usb.ids lists 0x222 as the last "aluminum" keyboard and 0x223 forward are ostensibly fancier.

However, the Macbook 3,1 (which uses appletouch) reports as "0x5ac 0x229", which puts it in the MODEL_UNIBODY_MACBOOK range instead of MODEL_APPLETOUCH. (Also, the website above seems to think 0x229 indicates a Macbook Pro, which it is not. That might explain some of the confusion.)

Elsewhere on the internet I found a couple other values that ostensibly fall after 0x223 that loaded appletouch instead of bcm5974 - 0x22a a few times, but also a single reference to 0x30b. I'm not sure what 0x30b is. 0x22a looks like it's probably a Macbook ?,1.

Could we just look at what driver we're loading instead of trying to figure it out from the vendor/product id? Appletouch = old behavior, bcm5974 = new.

If not, I propose moving the cutoff to <=0x22b for MODEL_APPLETOUCH and >=0x230 for MODEL_UNIBODY_MACBOOK.