linux/drivers/input/mouse/psmouse-base.c

2035 lines
50 KiB

Input: psmouse - add support for 2nd wheel on A4Tech Dual-Scroll wheel mice This Far-Eastern company's PS/2 mice use a deviant format for the data relating to movement of the scroll wheels for, at least, their dual wheel mice, such as their "Optical GreatEye Wheelmouse" model "WOP-35". This product has five "buttons" (one of which is the click action on the first wheel) and TWO scroll wheels. However for a byte comprising d0-d7 instead of setting one of d6-7 in the forth byte of the mouse data packet and a twos complement number of scroll steps in the remaining d5-d0 (or d3-d0 should there be a fourth (BTN_SIDE - d4) or fifth (BTN_EXTRA - d5) button to report; they only report a single +/- event for each wheel and use a bit pattern that corresponds to +/-1 for the first wheel and +/- 2 for the second in the lower nibble of the fourth byte. The effect with existing code is that the second mouse wheel merely repeats the effect of the first but providing two steps per click rather than the one of the first wheel - so there is no HORIZONTAL scroll wheel movement detected from the device as far as the rest of the kernel sees it. This patch, if enabled by the "a4tech_workaround" module parameter modifies the handling just for mice of type PSMOUSE_IMEX so that the second scroll wheel movement gets correctly reported as REL_HWHEEL events. Should this module parameter be activated for other mice of the same PSMOUSE_IMEX type then it is possible that at the point where the mouse reports more than a single movement step the user may start seeing horizontal rather than vertical wheel events, but should the movement steps get to be more than two at a time the hack will get immediately deactivated and the behaviour will revert to the past code. This was discussed around *fifteen* *years* *ago* on the LKML and the best summary is in post https://lkml.org/lkml/2002/7/18/111 "Re: PS2 Input Core Support" by Vojtech Pavlik. I was not able to locate any discussion later than this on this topic. Given that most users of the "psmouse" module will NOT want this additional feature enabled I have taken the apparently erroneous step of defaulting the module parameter that enables it to be "disabled" - this functionality may interfere with the operation of "normal" mice of this type (until a large enough scroll wheel movement is detected) so I cannot see how it would want to be enabled for "normal" users - i.e. everyone without this brand of mouse. I am using this patch at the moment and I can confirm that it is working for me as both a module and compiled into the kernel for my mouse that is of the type (WOP-35) described - I note that it is still available from certain on-line retailers and that the manufacturers site does not list GNU/Linux as being supported on the product page - this patch however does enable full use of this product: http://www.a4tech.com/product.asp?cid=3D1&scid=3D8&id=3D22 Signed-off-by: Stephen Lyons <slysven@virginmedia.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2017-03-22 23:20:54 -07:00
Input: synaptics - add support for Relative mode Currently, the synaptics driver puts the device into Absolute mode. As explained in the synaptics documentation section 3.2, in this mode, the device sends a continuous stream of packets at the maximum rate to the host when the user's fingers are near or on the pad or pressing buttons, and continues streaming for 1 second afterwards. These packets are even sent when there is no new information to report, even when they are duplicates of the previous packet. For embedded systems this is a bit much - it results in a huge and uninterrupted stream of interrupts at high rate. This patch adds support for Relative mode, which can be selected as a new psmouse protocol. In this mode, the device does not send duplicate packets and acts like a standard PS/2 mouse. However, synaptics-specific functionality is still available, such as the ability to set the packet rate, and rather than disabling gestures and taps at the hardware level unconditionally, a 'synaptics_disable_gesture' sysfs attribute has been added to allow control of this functionality. This solves a long standing OLPC issue: synaptics hardware enables tap to click by default (even in the default relative mode), but we have found this to be inappropriate for young children and first time computer users. Enabling the synaptics driver disables tap-to-click, but we have previously been unable to use this because it also enables Absolute mode, which is too "spammy" for our desires and actually overloads our EC with its continuous stream of packets. Now we can enable the synaptics driver, disabling tap to click while retaining the less noisy Relative mode. Signed-off-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-11-08 00:00:35 -08:00
Input: psmouse - add support for 2nd wheel on A4Tech Dual-Scroll wheel mice This Far-Eastern company's PS/2 mice use a deviant format for the data relating to movement of the scroll wheels for, at least, their dual wheel mice, such as their "Optical GreatEye Wheelmouse" model "WOP-35". This product has five "buttons" (one of which is the click action on the first wheel) and TWO scroll wheels. However for a byte comprising d0-d7 instead of setting one of d6-7 in the forth byte of the mouse data packet and a twos complement number of scroll steps in the remaining d5-d0 (or d3-d0 should there be a fourth (BTN_SIDE - d4) or fifth (BTN_EXTRA - d5) button to report; they only report a single +/- event for each wheel and use a bit pattern that corresponds to +/-1 for the first wheel and +/- 2 for the second in the lower nibble of the fourth byte. The effect with existing code is that the second mouse wheel merely repeats the effect of the first but providing two steps per click rather than the one of the first wheel - so there is no HORIZONTAL scroll wheel movement detected from the device as far as the rest of the kernel sees it. This patch, if enabled by the "a4tech_workaround" module parameter modifies the handling just for mice of type PSMOUSE_IMEX so that the second scroll wheel movement gets correctly reported as REL_HWHEEL events. Should this module parameter be activated for other mice of the same PSMOUSE_IMEX type then it is possible that at the point where the mouse reports more than a single movement step the user may start seeing horizontal rather than vertical wheel events, but should the movement steps get to be more than two at a time the hack will get immediately deactivated and the behaviour will revert to the past code. This was discussed around *fifteen* *years* *ago* on the LKML and the best summary is in post https://lkml.org/lkml/2002/7/18/111 "Re: PS2 Input Core Support" by Vojtech Pavlik. I was not able to locate any discussion later than this on this topic. Given that most users of the "psmouse" module will NOT want this additional feature enabled I have taken the apparently erroneous step of defaulting the module parameter that enables it to be "disabled" - this functionality may interfere with the operation of "normal" mice of this type (until a large enough scroll wheel movement is detected) so I cannot see how it would want to be enabled for "normal" users - i.e. everyone without this brand of mouse. I am using this patch at the moment and I can confirm that it is working for me as both a module and compiled into the kernel for my mouse that is of the type (WOP-35) described - I note that it is still available from certain on-line retailers and that the manufacturers site does not list GNU/Linux as being supported on the product page - this patch however does enable full use of this product: http://www.a4tech.com/product.asp?cid=3D1&scid=3D8&id=3D22 Signed-off-by: Stephen Lyons <slysven@virginmedia.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2017-03-22 23:20:54 -07:00
Input: psmouse - add support for 2nd wheel on A4Tech Dual-Scroll wheel mice This Far-Eastern company's PS/2 mice use a deviant format for the data relating to movement of the scroll wheels for, at least, their dual wheel mice, such as their "Optical GreatEye Wheelmouse" model "WOP-35". This product has five "buttons" (one of which is the click action on the first wheel) and TWO scroll wheels. However for a byte comprising d0-d7 instead of setting one of d6-7 in the forth byte of the mouse data packet and a twos complement number of scroll steps in the remaining d5-d0 (or d3-d0 should there be a fourth (BTN_SIDE - d4) or fifth (BTN_EXTRA - d5) button to report; they only report a single +/- event for each wheel and use a bit pattern that corresponds to +/-1 for the first wheel and +/- 2 for the second in the lower nibble of the fourth byte. The effect with existing code is that the second mouse wheel merely repeats the effect of the first but providing two steps per click rather than the one of the first wheel - so there is no HORIZONTAL scroll wheel movement detected from the device as far as the rest of the kernel sees it. This patch, if enabled by the "a4tech_workaround" module parameter modifies the handling just for mice of type PSMOUSE_IMEX so that the second scroll wheel movement gets correctly reported as REL_HWHEEL events. Should this module parameter be activated for other mice of the same PSMOUSE_IMEX type then it is possible that at the point where the mouse reports more than a single movement step the user may start seeing horizontal rather than vertical wheel events, but should the movement steps get to be more than two at a time the hack will get immediately deactivated and the behaviour will revert to the past code. This was discussed around *fifteen* *years* *ago* on the LKML and the best summary is in post https://lkml.org/lkml/2002/7/18/111 "Re: PS2 Input Core Support" by Vojtech Pavlik. I was not able to locate any discussion later than this on this topic. Given that most users of the "psmouse" module will NOT want this additional feature enabled I have taken the apparently erroneous step of defaulting the module parameter that enables it to be "disabled" - this functionality may interfere with the operation of "normal" mice of this type (until a large enough scroll wheel movement is detected) so I cannot see how it would want to be enabled for "normal" users - i.e. everyone without this brand of mouse. I am using this patch at the moment and I can confirm that it is working for me as both a module and compiled into the kernel for my mouse that is of the type (WOP-35) described - I note that it is still available from certain on-line retailers and that the manufacturers site does not list GNU/Linux as being supported on the product page - this patch however does enable full use of this product: http://www.a4tech.com/product.asp?cid=3D1&scid=3D8&id=3D22 Signed-off-by: Stephen Lyons <slysven@virginmedia.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2017-03-22 23:20:54 -07:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00