(mail@janderson.ca): remove ieee80211_ibss_merge's TSFT argument.
Do the TSFT comparison in the drivers (ath, atw). Remove a lot of
extraneous debug statements from ieee80211_ibss_merge.
Set the ieee80211_node's state to IEEE80211_STA_BSS after it's been
copied to the ic_bss, not before.
In struct ieee80211_node, make the ni_tstamp field a union of a
uint64_t and the 8 TSF octets so that it's easier to compare a
neighbor's TSF with the local TSF.
Log IBSS merges (Greg Troxel's suggestion). Also log IBSS creation.
These are rare and important events that deserve to be logged.
received packet so that the checksum is not performed twice. Also,
tcp_respond() does not fill-in the m_pkthdr.csum_data, so a h/w checksum may
have the wrong offset.
OK from Jason Thorpe.
current directory.
The previous behaviour (of trusting the remote server's response when
retrieving the list of files to mget with prompting disabled) has been
in ftp ~forever, and has been a "known issue" for a long time.
Recently an advisory was published by D.J. Bernstein on behalf of
Yosef Klein warning of the problems with the previous behaviour, so
to alleviate concern I've fixed this with a sledgehammer.
Remember the local cwd after any operation which may change it.
Use "remotecwd" instead of "remotepwd".
Cosmetic: remove two short ladders from rtw_init. Fit the
NIC registers print-out onto one line using the RTW_PRINT_REGS
macro.
sys/dev/ic/rtwvar.h:
Add RTW_PRINT_REGS wrapper macro for rtw_print_regs. It
is a null op unless defined(RTW_DEBUG).
Use clue from rtk(4) and re(4) to fix the rtw(4) packet
filter. Previously, I was using the wrong CRC32 function
to hash multicast addresses; to compensate, I set the
multicast filter to all 1s. Now that I hash the addresses
correctly, I do not any longer set the filter to all 1s.
In rtw_ioctl, avoid gratuitous re-initialization when the
interface flags change. If a !IFF_UP -> IFF_UP transition,
call rtw_init(); otherwise, only reload the packet filter.
In sys/dev/ic/rtwreg.h:
Put useful combinations of Receiver Control Register flags
in RTW_RCR_PKTFILT_MASK, RTW_RCR_MONITOR, and
RTW_RCR_PKTFILT_DEFAULT. (XXX RTW_RCR_MONITOR should be
called RTW_RCR_PKTFILT_MONITOR.)
prompted by jittery and/or random movement during tap gestures, lack
of edge motion, and a general desire to make use of the extra features
available with the native protocol.
- Ditch the kernel thread; it was overkill for the small amount of
processing required to deal with touchpad events.
- If we fail to probe a Synaptics touchpad, issue a RESET command
to ensure that whatever device is out there is left in a sane
state (thanks to Reinoud Zandijk for the hint).
- Completely re-write gesture support.
- Put the touchpad in 80 packets per second mode and count them so
they can be used to time gesture durations (instead of using
mono_time).
- Enhance up/down button support with options to use them to emulate
the middle button or Z-axis events (like a traditional wheel mouse).
- Add 'edge motion'. If a drag gesture is in progress, and the reported
finger position moves to the touchpad's border region, continue
to report movement events at a fixed rate as if the finger carried
on moving in the same direction. This restores some functionality
usually provided by the touchpad's firmware in PS/2 mode.
- Filter successive movement events to reduce jitter. When scaling
movement events, fold the remainder into the next event to prevent
loss of information during slow/small finger movements. Pointer
movement is now much more refined.
- Add support for touchpads which can report more than one finger on
the pad simultaneously. Optionally use this feature for middle/right
button emulation (i.e. tap two fingers to emulate middle button).
This feature is disabled by default (for now) to avoid surprise
pasting of clipboard text. ;-)
card. It was using the same index as the Ethernet interface, but didn't
cause any problems until the new xcfb.c driver installed an interrupt
handler. Ethernet interrupts went to the xcfb.c interrupt handler and
hung machine.
is used as the RHS of a << operator. On machines where size_t is unsigned
long, and _LP64, we effectively get int32 << uint64 which is handled
differently in ansi c than K&R. In K&R the int32 would get promoted.
elric