This will mean we automatically get two-finger scrolling on multitouch
pads.
This works, but the scrolling is janky. Why does it eventually move the
mouse cursor (only one finger detected, but two are still there), and why
does it jump up slightly?
- Fix a locking bug in pmap_pp_clear_attrs() and in pmap_pp_remove() do the
TLB shootdown while still holding the target pmap's lock.
Also:
- Finish PV list locking for x86 & update comments around same.
- Keep track of the min/max index of PTEs inserted into each PTP, and use
that to clip ranges of VAs passed to pmap_remove_ptes().
- Based on the above, implement a pmap_remove_all() for x86 that clears out
the pmap in a single pass. Makes exit() / fork() much cheaper.
functions: preempt_point() and preempt_needed().
- preempt(): if the LWP has exceeded its timeslice in kernel, strip it of
any priority boost gained earlier from blocking.
pmap is emptied. Pass UVM_FLAG_VAONLY when clearing out the map and avoid
needless extra work to tear down each mapping individually.
- uvm_map_lookup_entry(): remove the code to do a linear scan of map entries
for small maps, in preference to using the RB tree. It's questionable,
and I think the code is almost never triggered because the average number
of map entries has probably exceeded the hard-coded threshold for quite
some time.
- vm_map_entry: get it aligned on a cacheline boundary, and cluster fields
used during rbtree lookup at the beginning.
true, all mappings have been removed, the pmap is totally cleared out, and
UVM can then avoid doing the work to call pmap_remove() for each map entry.
If false, either nothing has been done, or some helpful arch-specific voodoo
has taken place.
This seems well written and basically all good, but currently doesn't enter
a low power state, and imposes a big performance penalty. Proposed on
port-i386 & port-amd64.
has been deleted. Otherwise VFS will try to write cached data "back to
disc", which in the case of a UAO means needless page deactivations and
the resulting TLB shootdowns.
On devices such as the Thinkpad X250, the clickpad can be pressed
to generate mouse button events 1 and 2. There are also additional
physical buttons which the pms(4) driver recognizes as "up/down" buttons
(mouse buttons 3 and 4). Allow these to be remapped to buttons 1 and 2
and used like normal touchpad buttons with the following sysctl:
# sysctl -w hw.synaptics.up_down_emulation=3
While here, adjust the existing "middle button emulation"
(hw.synaptics.up_down_emulation=1) so it works with single-button
clickpads.
XXX: 3 may be a more useful default than the current default,
depending on hardware availability of touchpads with "up/down buttons".
Update the documentation accordingly.
than IP payload
this fixes problem where checksum was not recomputed for short
packets coming from Windows DOMU on same physical host, seems Windows
does some padding; reported by sborrill@
XXX pullup-9
specific MIDI messages are formed, allowing their use from MIDI
input files, not just the device controls.
using this method, i can now control the voice mode type on my
new synth.
