Samuel Rodríguez Pérez
42c5c30bc7
v4 - HEAD packet: Handling of finger id 0 only Process finger id 0 keeping code separated handling preparing for multifinger support. Add extra checks with hardware limits. Keep separated event and cookie position handling. Improve tracing. v4 - Improved pressure handling Do not provide pressure when there are not fingers touching and set a default pressure valud pressuming it will be taken into account for tapping on the user space on packets where pressure information is not provided by hardware. v4 - Hardcode fingerWitdh to defaut value Always provide default finger width value which is not a Synaptics w flag to enable tapping getting rid of previous 0 value which is the Synaptics flag for 2-fingers on that variable. This gives the chance to decide from the user space when to issue tapping or scrolling instead of being hardcoded on the kernel driver. At the same time it makes MOTION packets that contain information of 2 fingers on the same packet to be taken into account for cursor movement if applicable for instance when two-finger scroll is disabled. v4 - Fix tracing text and comment The value provided is not the number of fingers or fingers map but a finger id number. Move comment to the next line as that applies to next if condition and not to the trace instruction. v4 - MOTION packet: Fix getting finger 0 info Sometimes the information on MOTION packet which contains 2 finger positions could come on descending order by id. For insteance finger 1 on the first location of the packet and finger 0 coming on the second one. Get finger 0 values from first or second finger information location in the packet if available instead of checking for the first position only. Report to ignore packet otherwise. Provide extra checks and improve tracing. The set of changes of this commit fixes suttle cursor jumps caused by missing finger 0 information when that is provided on the second location of the MOTION packet instead of coming from the first location. On that scenario, if a following HEAD packet containing absulute positioning for finger 0 is comming the issue was reproduced. v4 - MOTION limit positions to boundaries This fixes cursor jumps and cursor disapearing among other misbehaviours when relative positions for the movement added up to the expected previous absolute position of the finger id on touchpad coordinates result on underflow or overflow. v4 - Manipulate finger bitmap computation based on previous packets with TODO There is no consensus on BSDs and Linux drivers, nor even clear documented behaviour for this so this is implemented based on experimentation. FreeBSD considers STATUS packet comes first prividing the list of fingers detected following a sequence of HEAD packets prividing absolute positioning for fingers that hadn't prevously been tracked and MOTION packets for relative positions for subsequent movement packing 2 finger information per packet until interation with the touch area stops so a final STATUS packet with no fingers detected and filled out with zeroes for other fields signals the end of movement. Motion packets with fingers ids not mapped form the HEAD are discarted as invalid data. On Linux there is not such restriction so HEAD or STATUS packets are taking into account regardless fingers on STATUS information matches with next packet. So that, the implementation here uses the STATUS information as informative for the following events. For instance if a status packet signals that two-fingers are pressed and the next packet is a HEAD packet, the latter only can provide information for one finger only, then the number of fingers reported is 2 on the head packet if the id of the finger overlaps with the ones from the HEAD packet or 3 fingers in case the id is a new one. Same logic applies to MOTION packets. This makes the asumption that a started event can only retain or increment the number of fingers until a movement action is finished providing continuity for dragging actions and scrolling actions. A TODO is added to investigate which should be the right behaviour for this and check if differnt v4 hardware and firmware match. v4 - Implement hardware palm detection as compile option disabled by default Fixed hardware palm detection to be taken into account on a separate field instead of being a hack messing with the number of fingers reported on STATUS packet and complete the conditions propagating the palm detected value on HEAD and MOTION packets fixing some previous non-accurated conditions. This fixes incorrect reports for taps among others on both cases whether the compile option is enabled or not. Apart from that a TODO is added from completeness to encourage looking for software palm detection instead that will benefit other devices as well. Palm detection will be more accurate to do by software so is is disabled by default. Some posible options are: - Improvements on padblocker input filter. - Improvements in user mode input_server device. - General input_server modifications. - Other inprovements on this driver. v4 - Initialise event structure so that new or unasigend fields will be zeroed This prevents potential misbehavious by dealing with incorrect data in case the event structure is modified in the future with new fields after recompiling this driver with unchanged code. At least those field will be zeroed with usually mean that they are at least initialised. Change-Id: Iccfdd356ff2834e5dea64481259fd890dd95406b Reviewed-on: https://review.haiku-os.org/c/haiku/+/10013 Reviewed-by: Adrien Destugues <[email protected]>
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our web-based source code browsers:
- https://grok.nikisoft.one/opengrok/ (OpenGrok, provided by Niklas Poslovski)
- https://git.haiku-os.org/ (git, provided by Haiku, Inc.)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.