o Change the motion calculation to result in
a more reasonable speed of motion
This should fix the 'aiming' problems people have reported. It also
mitigates (but doesn't completely solve) the 'stalling' problems at
very low speeds.
Tested by: many subscribers to -current
Approved by: njl
o Catch 'taps' as button presses
o One finger sends button1, two fingers send button3,
three fingers send button2 (double-click)
Tested by: many subscribers to -current
Approved by: njl
o Handle the 'up/down' buttons some touchpads have as
a z-axis (scrollwheel) as recommended by the specs
o Report the buttons as button4 and button5 instead
of button2 and button4, button2 can be emulated by
pressing button1 and button3 simultaneously. This
allows one to use the two extra buttons for other
purposes if one so desires.
Tested by: many subscribers to -current
Approved by: njl
o Clean up whitespace and comments in the
enable_synaptics() probing function
o Only use (and rely on) the extended capability
bits when we are told they actually exist
o Partly ignore the (possibly dated?) part of the
specification about the mode byte so that we
can support 'guest devices' too.
Tested by: many subscribers to -current
Approved by: njl
submitted version with style cleanups and changes to comments. I also
modified the ioctl interface. This version only has one ioctl (to get
the Synaptics-specific config parameters) since this is the only
information a user might want.
Submitted by: Arne Schwabe <arne -at- rfc2549.org>
a problem that could also be fixed differently without reverting previous
attempts to fix DELAY while the debugger is active (rev 1.204). The bug
was that the i8254 implements a countdown timer, while for (k)db_active
a countup timer was implemented. This resulted in premature termination
and consequently the breakage of DELAY. The fix (relative to rev 1.211)
is to implement a countdown timer for the kdb_active case. As such the
ability to step clock initialization is preserved and DELAY does what is
expected of it.
Blushed: bde :-)
Submitted by: bde
debugger is not active. The fixes breakages of DELAY() when
running in the debugger, because not calling getit() when the
debugger is active yields a DELAY that doesn't.
repocopied. Soon there will be additional bus attachments and
specialization for isa, acpi and pccard (and maybe pc98's cbus).
This was approved by nate, joerg and myself. bde dissented on the new
location, but appeared to be OK after some discussion.
correct interrupt source.
- Cache a pointer to the i8254_intsrc's pending method to avoid several
pointer indirections in i8254_get_timecount().
Reported by: bde
scenario into #ifdef DEBUG. This makes my cluster with Belkin
KVM switch completely usable, even if the KVM switch and mouse
get a bit confused sometimes.
Without this, when the mouse gets confused, all sorts of crud
gets spammed all over the screen. With this, the mouse may appear
dead for a second or three, but it recovers silently.
Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
Free approx 86 major numbers with a mostly automatically generated patch.
A number of strategic drivers have been left behind by caution, and a few
because they still (ab)use their major number.
resources. (Note that the correct range is 0x3f7,0x3f0-0x3f5.) Such
devices will be detected as follows:
fdc0: <Enhanced floppy controller (i82077, NE72065 or clone)> port
0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0
To do this, we find the minimum and maximum start addresses for the
resources and use them as the base for the IO and control ports.
Help from: jhb
when using a KVM.
There is no actual solution possible, but this gets us pretty close.
Typically when switching back to a FreeBSD box and moving the mouse
wild data is produced, because the protocol's validation/checksum
system is extremely weak it is impossible to determine that we're
out of sync before dropping several bogus packets to user land.
The actual solution that appears to offer the best clamping of
jitter is to buffer the mouse packets if we've not seen mouse
activity for more than .5 seconds. Then waiting to flush that data
for 1/20th of a second. If within that 20th of a second we get any
packets that do fail the weak test we drop the entire queue and
back off accepting data from the mouse for 2 seconds and then repeat
the whole deal.
You can still get _some_ jitter, notably if you switch to the FreeBSD
box, then move the mouse just enough to generate one or two packets.
Those packets may be bogus, but may still pass the validity check.
One way to finally kill the problem once and for all is to check
the initial packets for "wild" values. Typically one sees packets
in the +/-60 range during normal operation, however when bogus data
is generated it's typically near the outer range of +/-120 or more,
those packets would be a good candidate for dropping or clamping.
I've been running with this for several weeks now and it has
significantly helped me stay sane even with a piece of junk Belkin
KVM causing wild jitter each and every time I switch.
Lastly I'd like to note that my experience with Windows shows me that
somehow the Microsoft PS/2 driver typically avoids this problem, but
that may only be possible when running the mouse in a dumb-ed down PS/2
mode that Belkin recommends on their site.
thread being waken up. The thread waken up can run at a priority as
high as after tsleep().
- Replace selwakeup()s with selwakeuppri()s and pass appropriate
priorities.
- Add cv_broadcastpri() which raises the priority of the broadcast
threads. Used by selwakeuppri() if collision occurs.
Not objected in: -arch, -current
- The apic interrupt entry points have been rewritten so that each entry
point can serve 32 different vectors. When the entry is executed, it
uses one of the 32-bit ISR registers to determine which vector in its
assigned range was triggered. Thus, the apic code can support 159
different interrupt vectors with only 5 entry points.
- We now always to disable the local APIC to work around an errata in
certain PPros and then re-enable it again if we decide to use the APICs
to route interrupts.
- We no longer map IO APICs or local APICs using special page table
entries. Instead, we just use pmap_mapdev(). We also no longer
export the virtual address of the local APIC as a global symbol to
the rest of the system, but only in local_apic.c. To aid this, the
APIC ID of each CPU is exported as a per-CPU variable.
- Interrupt sources are provided for each intpin on each IO APIC.
Currently, each source is given a unique interrupt vector meaning that
PCI interrupts are not shared on most machines with an I/O APIC.
That mapping for interrupt sources to interrupt vectors is up to the
APIC enumerator driver however.
- We no longer probe to see if we need to use mixed mode to route IRQ 0,
instead we always use mixed mode to route IRQ 0 for now. This can be
disabled via the 'NO_MIXED_MODE' kernel option.
- The npx(4) driver now always probes to see if a built-in FPU is present
since this test can now be performed with the new APIC code. However,
an SMP kernel will panic if there is more than one CPU and a built-in
FPU is not found.
- PCI interrupts are now properly routed when using APICs to route
interrupts, so remove the hack to psuedo-route interrupts when the
intpin register was read.
- The apic.h header was moved to apicreg.h and a new apicvar.h header
that declares the APIs used by the new APIC code was added.
be gone in FreeBSD 6, so put BURN_BRIDGES around it. The TRB also
felt that if something better comes along sooner, it can be used to
replace this code.
Delayed by: BSDcon and subsequent disk crash.
This commit puts the relevant code snippets under #ifdef GONE_IN_5
(rather than #ifndef BURN_BRIDGES) thereby disabling the code now.
The code wil be entirely removed before 5.2 unless we find reasons
why this would be a bad idea.
Approach suggested by: imp
Quick fix for calling DELAY() for ddb input in some (atkbd-based)
console drivers. ddb must not use any normal locks, but DELAY()
normally calls getit() which needs clock_lock. One problem with using
normal locks in ddb is that deadlock is possible, but deadlock on
clock_lock is unlikely becaluse clock_lock is bogusly recursive,
apparently just to hide the problem of ddb using it. The i8254 clock
hardware has mostly write-only registers so it is important for it to
use a lock that gives exclusive access. (atkbd hardware is also
unfriendly to reentrant software but that problem is more local and
already solved.) I mostly saw the symptoms of the bug caused by
unlocking in getit() running cpu_unpend(). cpu_unpend() should not
be called while in ddb and Debugger() calls for failing assertions
about this caused a breakpoint within ddb.
ddb must also not call getit() because ddb may be being used to step
through clock initialization code that has stopped or otherwise mangled
the clock. If the clock is stopped, then getit() always returns the
same value and DELAY() takes forever if it trusts getit().
The quick fix is implement DELAY(n) as (n * timer_freq / 1000000)
inb(0x84)'s if ddb is active.
machdep.c:
Don't permit recursion on clock_lock.
For the floppy driver, use fdcontrol to manipulate density selection.
For the CD drivers, the 'a' and 'c' suffix is without actual effect and
any applications insisting on it can be satisfied with a symlink:
ln -s /dev/cd0 /dev/cd0a
Ongoing discussion may result in these pieces of code being removed before
the 5-stable branch as opposed to after.
A timecounter will be selected when registered if its quality is
not negative and no less than the current timecounters.
Add a sysctl to report all available timecounters and their qualities.
Give the dummy timecounter a solid negative quality of minus a million.
Give the i8254 zero and the ACPI 1000.
The TSC gets 800, unless APM or SMP forces it negative.
Other timecounters default to zero quality and thereby retain current
selection behaviour.
- Move isa/ppc* to sys/dev/ppc (repo-copy)
- Add an attachment method to ppc for puc
- In puc we need to walk the chain of parents.
Still to do, is to make ppc(4) & puc(4) work on other platforms. Testers
wanted.
PR: 38372 (in spirit done differently)
Verified by: Make universe (if I messed up a platform please fix)
- Factor out code common to all ISA bridge drivers attach methods into a
isab_attach() function.
- Rename the PCI-ISA bridge driver's attach function to pci_isab_attach()
and have it call isab_attach().
disabled.
- Change the apm driver to match the acpi driver's behavior by checking to
see if the device is disabled in the identify routine instead of in the
probe routine. This way if the device is disabled it is never created.
Note that a few places (ips(4), Alpha SMP) used "disable" instead of
"disabled" for their hint names, and these hints must be changed to
"disabled". If this is a big problem, resource_disabled() can always be
changed to honor both names.
Previously, any normal I/O on an fdc(4) device would fail with ENXIO
if the device had been opened in non-blocking mode and then closed
prior to the conventional access; that would last until the floppy
disk was ejected and re-inserted to raise the unit attention condition.
Add a clarifying comment.
as should every block device strategy routine.
There was at least one evil consequence of not doing so:
Some errors returned by fdstrategy() could be lost (EAGAIN,
in particular.)
PR: kern/52338 (in the audit-trail)
Discussed with: bde
to access floppy parameters through it.
Note: The DIOCGSECTORSIZE and DIOCGMEDIASIZE handlers withing
fdioctl() couldn't be just moved to below the existing check
for blocking mode because fd->ft can be non-NULL while still
in non-blocking mode (fd->ft can be set with the FD_STYPE ioctl.)
PR: kern/52338
No MFC: Not applicable to STABLE
have to use it since all AMD64 machines are supposed to have acpi etc,
I'm using it during development so I can avoid the acpi code for now.
Yes, this is cheating.
Retain the mistake of not updating the devstat API for now.
Spell bioq_disksort() consistently with the remaining bioq_*().
#include <geom/geom_disk.h> where this is more appropriate.
where physical addresses larger than virtual addresses, such as i386s
with PAE.
- Use this to represent physical addresses in the MI vm system and in the
i386 pmap code. This also changes the paddr parameter to d_mmap_t.
- Fix printf formats to handle physical addresses >4G in the i386 memory
detection code, and due to kvtop returning vm_paddr_t instead of u_long.
Note that this is a name change only; vm_paddr_t is still the same as
vm_offset_t on all currently supported platforms.
Sponsored by: DARPA, Network Associates Laboratories
Discussed with: re, phk (cdevsw change)
branches:
Initialize struct cdevsw using C99 sparse initializtion and remove
all initializations to default values.
This patch is automatically generated and has been tested by compiling
LINT with all the fields in struct cdevsw in reverse order on alpha,
sparc64 and i386.
Approved by: re(scottl)
- Get rid of the useless atop() / pmap_phys_address() detour. The
device mmap handlers must now give back the physical address
without atop()'ing it.
- Don't borrow the physical address of the mapping in the returned
int. Now we properly pass a vm_offset_t * and expect it to be
filled by the mmap handler when the mapping was successful. The
mmap handler must now return 0 when successful, any other value
is considered as an error. Previously, returning -1 was the only
way to fail. This change thus accidentally fixes some devices
which were bogusly returning errno constants which would have been
considered as addresses by the device pager.
- Garbage collect the poorly named pmap_phys_address() now that it's
no longer used.
- Convert all the d_mmap_t consumers to the new API.
I'm still not sure wheter we need a __FreeBSD_version bump for this,
since and we didn't guarantee API/ABI stability until 5.1-RELEASE.
Discussed with: alc, phk, jake
Reviewed by: peter
Compile-tested on: LINT (i386), GENERIC (alpha and sparc64)
Runtime-tested on: i386
prevent the compiler from optimizing assignments into byte-copy
operations which might make access to the individual fields non-atomic.
Use the individual fields throughout, and don't bother locking them with
Giant: it is no longer needed.
Inspired by: tjr
statclock based on profhz when profiling is enabled MD, since most platforms
don't use this anyway. This removes the need for statclock_process, whose
only purpose was to subdivide profhz, and gets the profiling clock running
outside of sched_lock on platforms that implement suswintr.
Also changed the interface for starting and stopping the profiling clock to
do just that, instead of changing the rate of statclock, since they can now
be separate.
Reviewed by: jhb, tmm
Tested on: i386, sparc64
expectation.
This solves the problem, where in a constellation with two (or more)
drives, an attempt is made to access a device name for that device
using a historic partition letter, like /dev/fd1c. This is supposed
to create a symlink to the master device, but previously, the link was
always created to /dev/fd0, even if the request was for fd1*.
The correct range is [1...7] with Sunday=1, but we have been writing
[0...6] with Sunday=0.
The Soekris computers flagged the zero, zapped the date, so if you
rebooted your soekris on a sunday, it would come up with a wrong
date.
Bruce has a more extensive rework of this code, but we will stick with
the minimalist fix for now.
Spotted by: Soren Kristensen <soren@soekris.com>
Thanks to: Michael Sierchio <kudzu@tenebras.com>.
Confirmed by: bde
Approved by: re
2. Update a comment. We now restore much more than RTC updates and
interrupts.
3. Order change. Stop interrupts by writing to RTC_STATUSB,
restore rate bits for the interrupts by writing to RTC_STATUSA,
then enable interrupts again.
This seems to be done perfectly backwards in startrtclock().
Otherwise, the idea for this change was obtained from
startrtclock().
4. Don't stop the clock (RTCB_HALT). We only program some control bits
and don't want to stop the clock.
5. (Not really related.) Add caveats to the comment about timer_restore().
The update is non-atomic since locking is not done.
On locking:
6. rtcin() and writertc() are locked() adequately by splhigh() in RELENG_4,
but this locking is null in -current.
7. Doing things in the correct order in (3) combined with (6) is probably
enough locking for rtcrestore() in RELENG_4. In -current, the
writertc()'s race with rtcintr() unless the BIOS disables RTC interrupts.
Submitted by: bde (including commit message)
MFC after: 1 week
