Summary: | Can't disable touchpad by tapping on hot-area on touchpad | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Bryce Harrington <bryce> | ||||||||||||
Component: | Input/synaptics | Assignee: | Peter Hutterer <peter.hutterer> | ||||||||||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||||||||||
Severity: | minor | ||||||||||||||
Priority: | medium | CC: | 321942, dadreggors, freedesktop.org, mafioso67, peter.hutterer, stefan.nagy, svalx | ||||||||||||
Version: | 7.7 (2012.06) | Keywords: | patch | ||||||||||||
Hardware: | All | ||||||||||||||
OS: | Linux (All) | ||||||||||||||
See Also: |
http://bugs.debian.org/609903 http://bugs.debian.org/683762 https://bugs.freedesktop.org/show_bug.cgi?id=105923 |
||||||||||||||
Whiteboard: | 2011BRB_Reviewed | ||||||||||||||
i915 platform: | i915 features: | ||||||||||||||
Bug Depends on: | 38303 | ||||||||||||||
Bug Blocks: | |||||||||||||||
Attachments: |
|
Description
Bryce Harrington
2011-07-07 19:53:28 UTC
Created attachment 48874 [details]
BootDmesg.txt
Created attachment 48875 [details]
CurrentDmesg.txt
Created attachment 48876 [details]
peripherals.txt
Created attachment 48877 [details]
xinput.txt
Created attachment 48878 [details]
XorgLog.txt
AFAIK, this is part of the clickpad series of touchpads for which we don't have upstream support yet. Patches circulated on the list a while ago, but they need finishing Well, it _does_ work with OpenSuse 11.4. So why can't you implement the same patch, that is used in OpenSuse 11.4? Time. Please feel free to grab those patches and upstream them to the list. The last set of patches I've seen was not ready. http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches *** Bug 42867 has been marked as a duplicate of this bug. *** I'm pretty sure the suse support for this depends on an LED being available in the touchpad. I have been maintaining this support on Arch Linux. Does anyone have a touchpad with a disable area _without_ an led? Would a patch be less likely to be accepted if it doesn't separate the LED support from the disable support? (In reply to comment #10) > Would a patch be less likely to be accepted if it doesn't separate the LED > support from the disable support? yes. I don't want crazy in-driver functionality for touchpads that don't need it. There should be discovery of that feature and it should only be exposed when the LED is available. note that we'll likely need to query the LED state as well to avoid getting the touchpad into an inconsistent state (disabled, when it's actually enabled etc.) looking through linux/input.h, we should send KEY_TOUCHPAD_ON/OFF when that button is pressed. The clients can then decide what to do, rather than having this behaviour enforced in the driver. I add links to two related bugs in the debian BTS: - debian bug 609903 (HP G62 laptop): LED indicator in the upper left corner of the touchpad itself. - debian bug 683762 (HP Folio 13-2000 laptop): LED indicator between the touchpad and the keyboad. Apart from that I thought it might be a good idea to add links to the unfinished patch sent upstream by Takashi Iwai a while ago (review by Peter Hutterer): - http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/13437 (patch) - http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/13607 (review) I'm affected by this bug on the HP Folio 13-2000 laptop. I'd be glad to provide more information and/or test revised patches. I created bug #42867 which is now marked as a duplicate of this bug. I am glad to see some more movement on this. My laptop (HP Pavilion G6) as a tiny LED above the mouse pad as well. It is between the mouse pad and the keyboard. Neither work in all versions of Fedora I have tested it on (Fedora 16 & 17). The mouse pad works as expected, you just can't turn it on or off via the hot spot button at the top left corner of the mouse pad. The version of the synaptics driver I currently have installed is: xorg-x11-drv-synaptics-1.6.2-2.fc17.x86_64 Also, below is the hardware information I posted in the original bug I created in case it helps. Hardware info: My laptop is an HP Pavilion G6 (G6-1B50US). AMD Phenom(tm) II P650 Dual-Core Processor 4GB Ram [ DMIDECODE INFO ] Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Hewlett-Packard Product Name: HP Pavilion g6 Notebook PC Version: 0593110000204610000620100 Serial Number: 5CG1221MYF UUID: 579C58E8-B265-06E7-3163-8DDE56E7D88D Wake-up Type: Power Switch SKU Number: QF761UA#ABA Family: 103C_5335KV G=N L=CON B=HP S=PAV Handle 0x000C, DMI type 21, 7 bytes Built-in Pointing Device Type: Touch Pad Interface: PS/2 Buttons: 4 I'm affected by this bug on HP Pavilion G6-2137SR, hope it will be fixed soon. we currently have no plans of fixing this, sorry. (In reply to Peter Hutterer from comment #15) > we currently have no plans of fixing this, sorry. I have this issue with HP ProBook 4525s with LED on left up cover. Maybe now it's possible to fix it? I am ready to provide any information about the hardware, logs and more. I can take part in testing. And I can test it on openSUSE Leap. Theoretically, this feature could be put into libinput provided the LED is exposed by the kernel. But google suggests that the 4525 is around 8 years old, I won't add any extra features to libinput for hardware that's at the end of their life and may die before the feature ever gets into a distribution, sorry. Almost all HP ProBooks and EliteBooks use similar models of touchpads, with LED in the upper left corner and a double-tap disconnect. For example, the new HP EliteBook (https://www.youtube.com/watch?v=VwOeYeZfhWQ) or the latest HP ProBook 650 (https://www.youtube.com/watch?v=Sb1xdsX3J4Q). So do not worry that the work will be done in vain. Oh, good do know, thanks. Though for synaptics this won't happen, it's in maintenance mode. Please file a bug against libinput (in product Wayland) and we can take it from there. Note that this feature will require kernel-level support too for the LED to be controlled. Unless we have that, we can't (well, won't) do much in libinput. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.