summaryrefslogtreecommitdiffstats
path: root/sys/dev/atkbdc
Commit message (Collapse)AuthorAgeFilesLines
* Initialize mouse resolution to zero if converting frommjacob2007-06-171-0/+2
| | | | OLD to NEW.
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-232-2/+2
| | | | | | | | | | | | | bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
* Synaptics TouchPad seems to go back to Relative Mode after the calldumbbell2007-02-041-0/+10
| | | | | | | to set_controller_command_byte() call; by issueing a Read Mode Byte command, the touchpad is in Absolute Mode again. This problem occursed at least on Asus V6V laptops.
* Spell "Kensington Thinking Mouse" correctly.keramida2006-12-181-1/+1
|
* Fix LEDs not working when atkbd is an active keyboard and the physicalru2006-10-251-16/+16
| | | | | | | | | | | | | | | | | | | | keyboard is attached only after the system has already booted. If USB keyboard is also present, and there's no kbdmux(4), the problem has been hiding itself because as soon as we get to multi-user, the USB keyboard becomes an active keyboard (see devd.conf), thus marking atkbd inactive and letting the old code initialize the keyboard. With kbdmux(4), or if there's no USB keyboard, the atkbd keyboard is always active, whether it's physically attached or not, thus it never initialized itself properly on a physical attach. To fix this, move block that initialized the keyboard on attach upper so it doesn't depend on the (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd)) condition. Also move KBD_FOUND_DEVICE() a few lines upper so that KDSETLED and KDSETREPEAT that follow it propagate to the controller. MFC after: 3 days
* Fix our ioctl(2) implementation when the argument is "int". Newru2006-09-271-0/+33
| | | | | | | | | | | | | ioctls passing integer arguments should use the _IOWINT() macro. This fixes a lot of ioctl's not working on sparc64, most notable being keyboard/syscons ioctls. Full ABI compatibility is provided, with the bonus of fixing the handling of old ioctls on sparc64. Reviewed by: bde (with contributions) Tested by: emax, marius MFC after: 1 week
* Avoid an infinite loop in empty_both_buffers() by adding a timeout.dwhite2006-09-041-0/+11
| | | | | | | | | | | This helps systems that don't actually have atkbd controllers, such as the Intel SBX82 blade, boot without device.hints hacks. Hardware for this fix provided by iXsystems. PR: 94822 Submitted by: Devon H. O'Dell <devon.odell@coyotepoint.com> MFC After: 3 days
* Make sure command/data port (0x60) and status port (0x64) are in correctjkim2006-07-031-4/+10
| | | | order. Some brain-damaged ACPI BIOS has reversed resources.
* MFp4: need machine/bus.h here since we use bus space macros. It used toimp2006-06-121-0/+1
| | | | | | be brought in by name-space polluted sys/rman.h. Pointy hat to: imp
* Send the pcvt(4) driver off to retirement.phk2006-05-171-3/+0
|
* Remove various bits of conditional Alpha code and fixup a few comments.jhb2006-05-122-3/+1
|
* Use the same method for detecting actual presence of AT-style keyboardsobomax2006-04-263-5/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | controller as we use in boot blocks (querying status register until bit 1 goes off). If that doesn't happed during reasonable period assume that the hardware doesn't have AT-style keyboard controller. This makes FreeBSD working almost OOB on MacBook Pro (still there are issues with putting second CPU core on-line, but since installation CD comes with UP kernel with this change one should be able to install FreeBSD without playing tricks with hints). Other legacy-free hardware (e.g. IBM NetVista S40) should benefit from this as well, but since I don't have any I can't verify. It should make no difference on the ordinary i386 hardware (since in that case that hardware already would be having an issues with A20 routines in boot blocks). I don't know much about AT-style keyboard controller on other platforms (and don't have dedicated access to one), therefore, the code is restricted to i386 for now. I suspect that amd64 may need this as well, but I would rather leave this decision to someone who knows better about the platform(s) in question. I have tested this change on as many "ordinary i386 boxes" as I can get my hands on, and it doesn't create any false negatives on hardware with AT-style keyboard present. MFC after: 1 month
* Add ALPS glide point ID and some compatibility IDs.takawata2006-03-151-0/+3
| | | | PR: kern/75008
* Fix a bug in Synaptics Touchapd support where psm(4) will enter an infinitedumbbell2006-01-051-1/+2
| | | | | | | loop if it receives an out of sync packet. Reviewed by: mux (mentor) MFC after: 4 days
* Fix -Wundef.ru2005-12-042-2/+2
|
* - Hook up the new locations of the atkbdc(4), atkbd(4) and psm(4) sourcemarius2005-06-1011-453/+555
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | files after they were repo-copied to sys/dev/atkbdc. The sources of atkbdc(4) and its children were moved to the new location in preparation for adding an EBus front-end to atkbdc(4) for use on sparc64; i.e. in order to not further scatter them over the whole tree which would have been the result of adding atkbdc_ebus.c in e.g. sys/sparc64/ebus. Another reason for the repo-copies was that some of the sources were misfiled, e.g. sys/isa/atkbd_isa.c wasn't ISA-specific at all but for hanging atkbd(4) off of atkbdc(4) and was renamed to atkbd_atkbdc.c accordingly. Most of sys/isa/psm.c, i.e. expect for its PSMC PNP part, also isn't ISA-specific. - Separate the parts of atkbdc_isa.c which aren't actually ISA-specific but are shareable between different atkbdc(4) bus front-ends into atkbdc_subr.c (repo-copied from atkbdc_isa.c). While here use bus_generic_rl_alloc_resource() and bus_generic_rl_release_resource() respectively in atkbdc_isa.c instead of rolling own versions. - Add sparc64 MD bits to atkbdc(4) and atkbd(4) and an EBus front-end for atkbdc(4). PS/2 controllers and input devices are used on a couple of Sun OEM boards and occur on either the EBus or the ISA bus. Depending on the board it's either the only on-board mean to connect a keyboard and mouse or an alternative to either RS232 or USB devices. - Wrap the PSMC PNP part of psm.c in #ifdef DEV_ISA so it can be compiled without isa(4) (e.g. for EBus-only machines). This ISA-specific part isn't separated into its own source file, yet, as it requires more work than was feasible for 6.0 in order to do it in a clean way. Actually philip@ is working on a rewrite of psm(4) so a more comprehensive clean-up and separation of hardware dependent and independent parts is expected to happen after 6.0. Tested on: i386, sparc64 (AX1105, AXe and AXi boards) Reviewed by: philip
* Delete a file that was meant to be renamed while repo-copying it butmarius2005-06-101-180/+0
| | | | wasn't and now is superfluous.
* Remove bus_{mem,p}io.h and related code for a micro-optimization on i386nyan2005-05-293-5/+0
| | | | | | and amd64. The optimization is a trivial on recent machines. Reviewed by: -arch (imp, marcel, dfr)
* Backout previous diffs - this functionality is already provided by thesobomax2005-04-071-15/+0
| | | | | | | hints to the atkbd(4). PR: Submitted by: jhb
* Make previous commit actually working by replacing TUNABLE_INT() withsobomax2005-04-071-11/+11
| | | | | | | TUNABLE_INT_FETCH(). Apparently keyboard init is performed earlier in the boot process than fetching all static tunables. MFC after: 1 day
* Provide a new tunable hw.atkbdc.broken_kit_cmd, which if set to 1sobomax2005-04-071-0/+15
| | | | | | | | | | | | | | | instructs the driver to avoid using Keyboard Interface Test command. This command causes problems with some non-compliant hardware, resulting in machine being abruptly powered down early in the boot process. Particularly it's known that HP ZV5000 and Compaq R3000Z notebooks are affected by this problem. Due to popularity of those models this patch is good MFC5.4 candidate. PR: 67745 Submitted by: Jung-uk Kim jkim at niksun.com MFC after: 1 days
* plug memory leaksam2005-02-261-18/+37
| | | | Noticed by: Coverity Prevent analysis tool
* Make life for owners of Synaptics Touchpads more pleasant :-)philip2005-01-101-11/+207
| | | | | | | | | | | | | | | | | | | | | | | | | o Implement a shiny new algorithm to keep track of finger movement at slow speeds. This dramatically reduces the level of questionable language from users trying to resize windows. o Properly catch the many extra buttons and dials which manufacturers are known to screw onto Synaptics touchpad controllers. Currently, up to seven buttons are known to work, more should work too. o Add a number of sysctls allowing one to tune the driver to taste in a simple way: # Should the extra buttons act as axes or as middle button hw.psm.synaptics.directional_scrolls # These control the 'stickiness' at low speeds hw.psm.synaptics.low_speed_threshold hw.psm.synaptics.min_movement hw.psm.synaptics.squelch_level PR: kern/75725 Submitted by: Jason Kuri <jay@oneway.com> MFC after: 1 month
* Reduce diffs to work in progress before checking in serious changes.philip2005-01-031-19/+20
| | | | | | | | | | | | | | | | o Move the sysctls under debug.psm.* and hw.psm.* making them a bit clearer and more consistent with other drivers. o Remove the debug.psm_soft_timeout sysctl. It was introduced many moons ago in r1.64 but never referenced anywhere. o Introduce hw.psm.tap_threshold and hw.psm.tap_timeout to control the behaviour of taps on touchpads. People might like to fiddle with these if tapping seems to slow or too fast for them. o Add debug.psm.loglevel as a tunable so that verbosity can be set easily at boot-time (to watch probes and such) without having to compile a kernel with options PSM_DEBUG=N.
* Add a new flag to the atkbd(4) driver to disable testing the keyboardjhb2004-12-152-1/+3
| | | | | | | | | | | port during the device probe as this can cause hangs on some machines, specifically Compaq R3000Z series amd64 laptops. The flag is bit 3, or 0x8. PR: amd64/67745 Reported by: Neil Winterbauer newntrbr at ucla dot edu, many others Tested by: ade, astrodog at gmail dot com, many others MFC after: 1 week
* Remove local hacks to set flags now that the device probe does this for us.njl2004-10-142-4/+0
| | | | | | | Tested on every device except sio_pci and the pc98 fd.c. Perhaps something similar should be done for the "disabled" hints also. MFC after: 2 weeks
* Introduce a tunable to disable support for Synaptics touchpads. A number ofphilip2004-09-291-1/+11
| | | | | | | | | | | people have reported problems (stickyness, aiming difficulty) which is proving difficult to fix, so this will default to disable until sometime after 5.3R. To enable Synaptics support, set the 'hw.psm.synaptics_support=1' tunable. MT5 candidate. Approved by: njl
* Improve sync recovery algorithm:gibbs2004-08-271-97/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o Remove PSM_SYNCERR_THRESHOLD1. This value specified how many sync errors were required before the mouse is re-initialised. Re-initialisation is now done after (packetsize * 2) sync errors as things aren't likely to improve after that. o Reset lastinputerror when re-initialisation occurs. We don't want to continue to drop data after re-initialisation. o Count the number of failed packets independently of the syncerrors statistic. syncerrors is useful for recovering sync within a single packet. pkterrors allows us to detect when the mouse changes its packet mode due to some external event (e.g. KVM switch). o Reinitialize the mouse if we see more than psmpkterrthresh errors during the validation period. The validation period begins as soon as a sync error is detected and continues until psmerrsecs/msecs time has elapsed. The defaults for these two values force a reset if we see two packet errors in a 2 second period. This allows rapid detection of packet framing errors caused by the mouse changing packet modes. o Export psmpkterrthresh as a sysctl o Export psmloglevel as a sysctl. o Enable more debugging code to be enabled at runtime via psmloglevel. o Simplify verbose conditioned loging by using a VLOG macro. o Add several comments describing the sync recovery algorithm of this driver. Large Portions by: Brian Somers <brian@Awfulhak.org> Inspired and Frustrated by: Belkin KVMs Reviewed by: njl, philip
* Defer the capture of the "expected sync bits" until the first "normal"gibbs2004-08-171-20/+13
| | | | | | | | | | data packet is received from the mouse. In the case of many KVM's, this avoids a bug in their mouse emulation that sends back incorrect sync when you explicitly request a data packet from the mouse. Without this change, you must force the driver into stock PS/2 mode or be flooded with a never ending stream of "out of sync" messages on these KVMs. Approved by: re
* Don't initialize static variables to 0 (C should just take care of that).philip2004-08-161-2/+2
| | | | Spotted by: njl
* Update support for Synaptics Touchpads (Volume V)philip2004-08-161-5/+29
| | | | | | | o Add (long awaited) support for guest devices Submitted by: Arne Schwabe <arne@rfc2549.org> Approved by: njl (in a former revision)
* Assume a finger of regular width when no width value is reported byphilip2004-08-081-3/+10
| | | | | | | the touchpad (which happens when it has no extended capabilities). Spotted by: dhw Forgotten by: philip
* Update support for Synaptics Touchpads (Volume IV)philip2004-08-081-2/+2
| | | | | | | | | | | | 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
* Update support for Synaptics Touchpads (Volume III)philip2004-08-081-0/+26
| | | | | | | | | | 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
* Update support for Synaptics Touchpads (Volume II)philip2004-08-081-5/+26
| | | | | | | | | | | | | | 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
* Update support for Synaptics Touchpads (Volume I)philip2004-08-081-53/+64
| | | | | | | | | | | | | | | 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
* Add support for the Synaptics Touchpad mouse driver. I reworked thenjl2004-07-301-1/+213
| | | | | | | | | 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>
* Ignore more strange return values of the test_aux_port() function,mux2004-07-161-6/+10
| | | | | | | | | | because some notebooks (apparently Compaq, Toshiba and Acer ones) erroneously return 2 or 3 there. PR: kern/61482, kern/54188 Submitted by: Ulf Lilleengen <lulf@kerneled.org>, Victor Balada Diaz <victor@alf.dyndns.ws> MFC after: 3 days
* Do the dreaded s/dev_t/struct cdev */phk2004-06-161-7/+7
| | | | Bump __FreeBSD_version accordingly.
* Remove atdevbase and replace it's remaining uses with direct references tojhb2004-06-101-0/+1
| | | | KERNBASE instead.
* add missing #include <sys/module.h>phk2004-05-304-0/+4
|
* Don't check for device_get_softc() returning NULL, it can't happen.mux2004-04-171-3/+0
|
* Put a bunch of output that us really only useful in a debugmarkm2004-04-041-1/+13
| | | | | | | | | | 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.
* Convert callers to the new bus_alloc_resource_any(9) API.njl2004-03-175-32/+27
| | | | | Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
* Device megapatch 4/6:phk2004-02-211-0/+2
| | | | | | | | 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.
* Device megapatch 1/6:phk2004-02-211-2/+0
| | | | | | | 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.
* Significantly reduce the "jitter" that is typical for PS/2 micealfred2003-12-111-110/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* - Implement selwakeuppri() which allows raising the priority of atanimura2003-11-091-1/+1
| | | | | | | | | | | | | 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
* Assign keycodes for Power, Sleep and Wake keys.fjoe2003-10-071-0/+9
| | | | Submitted by: Eugene Grosbein <eugen@grosbein.pp.ru>
* Use __FBSDID().obrien2003-08-242-2/+6
| | | | Also some minor style cleanups.
OpenPOWER on IntegriCloud