cursor (CHAR_CURSOR)
1. Reduced the number of calls to set_destructive_cursor(). The
destructive cursor produced noticeable overhead on the system. It was
caused by draw_cursor_image() calling set_destructive_cursor() every
so often.
set_destructive_cursor() absolutely needs to be called when
a) the character code under the cursor has changed either because
the cursor moved or because the screen was updated or the mouse
pointer overlapped the cursor.
b) Or a new font has been loaded,
c) or the video mode has been changed,
d) or the cursor shape has been changed,
e) or the user switched virtual consoles.
2. Turn off the configuration flag CHAR_CURSOR (destructive cursor) in
scattach() if we have a non-VGA card. The destructive cursor works
only for VGA.
3. Removed redundant calls to set_destructive_cursor() in some places.
4. Fixed the "disappearing mouse pointer" problem. The mouse pointer
looked hidden under the destructive cursor when it overlaped the cursor.
A slightly different version of the patch was reviewd and OKed by
sos and ache.
If the configuration option PSM_HOOKAPM is defined and the APM device
is available, the psm driver will issue the ENABLE command to the
pointing device at the resume APM event if the device was open when
the system went into suspended mode. If the option
PSM_RESETAFTERSUSPEND is specified in addition to PSM_HOOKAPM, the
driver will try to reset the pointing device before sending the
ENABLE command.
Built-in PS/2-type pointing devices in some laptops (all the reports I
heard were about Toshiba models) sometimes don't work immediately
after the system is resumed. The device MAY become available after a
while. The system may exhibit the same symptom in other OS's too
(no, FreeBSD is not the only OS that is suffering :-).
I don't know the correct way of solving this yet, but it's been
reported that issuing the ENABLE command after resumption wakes up the
pointing device.
Without PSM_HOOKAPM, the psm driver behaves in the same way as before.
Problem reported in the bsd-nomads mailing list in Japan.
Add a new configuration flag, KBD_NORESET (0x20) to tell scprobe() not
to reset the keyboard.
IBM ThinkPad 535 has the `Fn' key with which the user can perform
certain functions in conjunction with other keys. For example, `Fn' +
PageUP/PageDOWN adjust speaker volume, `Fn' + Home/End change
brightness of LCD screen. It can also be used to suspend the system.
It appears that these functions are implemented at the keyboard level
or the keyboard controller level and totally independent from BIOS or
OS. But, if the keyboard is reset (as is done in scprobe()), they
become unavailable. (There are other laptops which have similar
functions associated with the `Fn' key. But, they aren't affected by
keyboard reset.)
ThinkPad 535 doesn't have switches or buttons to adjust brightness and
volume, or to put the system into the suspend mode. Therefore, it is
essential to preserve these `Fn' key functions in FreeBSD. The new
flag make scprobe() skip keyboard reset.
If this flag is not set, scprobe() behaves in the same say as before.
(If we only knew a way to detect ThinkPad 535, we could skip keyboard
reset automatically, but...)
- added Xcpustop IPI code to support stop_cpus()/restart_cpus().
it is off by default, enable via smptests.h:TEST_CPUSTOP
intr_machdep.h:
- moved +ICULEN to lower level.
- added entry for Xcpustop.
This eliminates a lot of #ifdef SMP type code. Things like _curproc reside
in a data page that is unique on each cpu, eliminating the expensive macros
like: #define curproc (SMPcurproc[cpunumber()])
There are some unresolved bootstrap and address space sharing issues at
present, but Steve is waiting on this for other work. There is still some
strictly temporary code present that isn't exactly pretty.
This is part of a larger change that has run into some bumps, this part is
standalone so it should be safe. The temporary code goes away when the
full idle cpu support is finished.
Reviewed by: fsmp, dyson
adapter during the system boot. It always assumes there is at least a
monochrome adapter.
This is rather strange assumption. If there is no dispaly adapter, the
console driver cannot be any good...
In this patch, scinit() is split into two parts; the first part is
now called scvidprobe() which will detect the presence of video card
at the CGA or MONO buffer address and returns TRUE if found. It is
called during sccnprobe() and scprobe(). Both will fail if no video
card is found.
The second part, whose name stays the same as before, scinit(), is
called from sccninit() and scattach() to complete initialization of
the found video card.
The keyboard probe code is moved from scprobe() to sckbdprobe();
scprobe() now calls scvidprobe() and sckbdprobe() to carry out device
probe. (This is rather a cosmetic change, but it sure makes the code
look better organized.)
The problem pointed out by Joerg.
speed using the boot blocks, instead of a hardcoded value stuck in the
kernel. This way, you can have systems using the same kernel but different
console speeds.
Add a sysctl entry for changing the system console speed.
Lock the user tty speed to match the system console speed.
Nuke CONSPEED.
Reviewed by: bde
that lkm's can use them for fiddling the masks without being dependent on
which mode the kernel is compiled in (SMP or UP). This is particularly
for ppp_tty.c which has some domain crossing between the net and tty
subsystems. The values are not used in the spl code, they are for
reference only (ie: the compiled code uses immediate values rather than
an indirect 32 bit address and 32 bit data fetch).
top of the hardware interrupt handlers. Apparently this is slightly
faster with the bit scanning instruction that looks these up - this set of
changes reverts the original change.
Reviewed by: bde
rather than inlines. These are compiled with -fomit-frame-pointer and
work out pretty close to the original routines, but it might be a fraction
slower. The reason for doing this is to prevent the SWI_* and HWI_* values
from being compiled into drivers and lkms etc which is one of the things
that prevents the same lkm from being used on both SMP and UP kernels.
This gives us a lot more scope for experimenting with the splxxx
implementaton for SMP parallelism etc.
Reviewed by: bde
Hopefully I've done the proper magic to merge changes between 1.17 and
1.17.2.1 into the main trunk. Description of those changes follows:
Brought in changes sent to me in late 1995 by Rich Murphey.
I cleaned up a few things and am currently running these under
2.2-970205-GAMMA.
The changes deal with software debouncing apparently necessary on
todays faster hardware, and also some problems with the use of the -Select
line for the TW-523 sync. This driver allows use of +PaperEnd as an
alternative.
Adjust the data port address by adding the two low order bits of
the register number. The address port takes only a word address
(i.e. ignores the two low order bits written to it).
mode 1. Omission of this bit makes all config register accesses fail in
on recent chip sets ...
(The problem was reported and debug output provided by: Steve Passe)
- vector.s <- stub called by i386/exception.s
- icu_vector.s <- UP
- apic_vector.s <- SMP
Split icu.s into UP and SMP specific files:
- ipl.s <- stub called by i386/exception.s (formerly icu.s)
- icu_ipl.s <- UP
- apic_ipl.s <- SMP
This was done in preparation for massive changes to the SMP INTerrupt
mechanisms. More fine tuning, such as merging ipl.s into exception.s,
may be appropriate.
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
be (eventually) architecture independent. It provides an emulation
of the ISA interrupt registration function register_intr(), but that
function does no longer manipulated the interrupt controller and
interrupt descriptor table, but calls the architecture dependent
function setup_icu() for that purpose.
After the ISA/EISA bus code has been modified to directly call the new
interrupt registartion functions (intr_create() and intr_connect()),
the emulation of register_intr() should be dropped.
The C level interrupt handler function should take a (void*) argument,
and the function pointer type (inthand2_t) should defined in some other
place than isa_device.h.
This commit is a pre-requisite for the removal of the PCI specific shared
interrupt code.
Reviewed by: dfr,bde
