- 01 12月, 2010 1 次提交
-
-
由 Yan Li 提交于
Lenovo S10-3t's ClickPad is a 2-button ClickPad that reports BTN_LEFT and BTN_RIGHT as normal touchpad, unlike the 1-button ClickPad used in HP mini 210 that reports solely BTN_MIDDLE. In 0xc0-cap response, the 1-button ClickPad has the 20-bit set while 2-button ClickPad has the 8-bit set. This patch makes the kernel only handle 1-button ClickPad specially, and treat 2-button ClickPad in the same fashion as regular touchpads. This fixes kernel bug #18122 and MeeGo bug #4807. Signed-off-by: NYan Li <yan.i.li@intel.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 13 10月, 2010 1 次提交
-
-
由 Dmitry Torokhov 提交于
There was too much knowledge about internals if serio in the pass-through handling, clean it up. Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 22 7月, 2010 1 次提交
-
-
由 Dmitry Torokhov 提交于
Older firmwares fixed the middle byte of the Synaptics capabilities query to 0x47, but starting with firmware 7.5 the middle byte represents submodel ID, sometimes also called "dash number". Reported-and-tested-by: NMiroslav Šulc <fordfrog@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 20 5月, 2010 1 次提交
-
-
由 Dmitry Torokhov 提交于
Newer Synaptics firmware allows to query maximim dimensions reported by device, let's use this data. Tested-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 20 4月, 2010 1 次提交
-
-
由 Takashi Iwai 提交于
The new type of touchpads can be detected via a new query command 0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits. When the device is detected, the driver now reports only the left button as the supported buttons so that X11 driver can detect that the device is Clickpad. A Clickpad device gives the button events only as the middle button. The kernel driver morphs to the left button. The real handling of Clickpad is done rather in X driver side. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 07 1月, 2010 1 次提交
-
-
由 Daniel Drake 提交于
For configurations where Synaptics hardware is present but the Synaptics extensions support is not compiled in, the mouse is reprobed and a new device is allocated on every suspend/resume. During probe, psmouse_switch_protocol() calls psmouse_extensions() with set_properties=1. This calls the dummy synaptics_init() which returns an error code, instructing us not to use the synaptics extensions. During resume, psmouse_reconnect() calls psmouse_extensions() with set_properties=0, in which case call to synaptics_init() is bypassed and PSMOUSE_SYNAPTICS is returned. Since the result is different from previous attempt psmouse_reconnect() fails and full re-probe happens. Fix this by tweaking the set_properties=0 codepath in psmouse_extensions() to be more careful about offering PSMOUSE_SYNAPTICS extensions. Signed-off-by: NDaniel Drake <dsd@laptop.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 04 12月, 2009 1 次提交
-
-
由 Dmitry Torokhov 提交于
DMI tables use considerable amount of memory. Mark them as __initconst so they will be discarded once module is loaded. Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 11 9月, 2009 1 次提交
-
-
由 Dmitry Torokhov 提交于
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 20 6月, 2009 1 次提交
-
-
由 Tero Saarni 提交于
Synaptics uses anisotropic coordinate system. On some wide touchpads vertical resolution can be twice as high as horizontal which causes unequal sensitivity on x/y directions. Add support for reading the resolution with EVIOCGABS ioctl. Signed-off-by: NTero Saarni <tero.saarni@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 10 3月, 2007 1 次提交
-
-
由 Andres Salomon 提交于
Allow ALPS, LOGIPS2PP, LIFEBOOK, TRACKPOINT and TOUCHKIT protocol extensions of psmouse to be disabled during compilation. This will allow users save some memory when they are sure that they will only use a certain type of mice. Signed-off-by: NAndres Salomon <dilinger@debian.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-