Ok, here is another topic for discussion.
>0x4000 is PSM_CONFIG_INITAFTERSUSPEND
>Under what circumstances would you _not_ want to call the
>function "reinitialize()" on the unit at resume time, such
>that this flag is not default?
To date, the flags PSM_CONFIG_HOOKRESUME and
PSM_COFIG_INITAFTERSUSPEND have been absolutely required by only few
machines, and are not necessary in most cases. They were provided
as a fix/kludge for those few cases.
When the machine wakes up from the suspend mode by the APM (and ACPI?)
BIOS, it is considered the BIOS's responsibility to restore the
peripheral devices' state. And in fact most laptop machines are able
to restore their internal pointing devices correctly. The only
exceptions which I know of, to date, are some early models of Toshiba
Librette and some models from Sony VAIO which has VersaPad.
Librette needed PSM_CONFIG_HOOKRESUME, but not
PSM_CONFIG_INITAFTERSUSPEND. Somehow Librette doesn't seem to fully
restore its mouse (actually it is a stick, which is like ThinkPad)
after the suspend mode. By tickling the mouse port via few harmless
I/O commands, the mouse will become operational quickly. (Even if we
don't have PSM_CONFIG_HOOKRESUME for Librette, its mouse will
eventually become operational after prolonged period since you resume
the machine, though.)
Some Sony VAIO models totally fail to restore VersaPad. So, it needs
both flags to re-initialize the device. (This is documented in
the man page for psm(4).)
In general, the laptop computer's APM BIOS knows a lot about its
built-in pointing device, thus, is able to put it back to the state
before it went into sleep/suspend.
In contrast, the desktop computer's APM BIOS knows almost nothing
about special features of the hooked mouse. (The BIOS vender cannot
know beforehand which mouse you will use with your motherboard :-)
So, in theory, we need the above two flags if you sleep/suspend your
desktop computers. But, it appears that many APM BIOSes on desktop
machines just do not cut power to the mouse even in sleep/suspend
mode, in order to let the user to wake up the machine by moving the
mouse! If the power to the mouse has not been cut, we don't need to
reinitialize the mouse.
>Even assuming it causes problems on some hardware (it appears
>to be _required_ to handle undocking from a docking station
>with an external mouse!), shouldn't this flag be inverted,
Is it required for the internal mouse to be operational? Or, is it for
the external mouse? How the docking station or the external mouse
(whether it is directly connected to the laptop or via the docking
station) are handled is vender-dependent, I think. Even if you need
these flags for your laptop and docking station, it doesn't
necessarily mean other vendors' laptop machines and docking stations
need them too.
I don't know a way, whether vender dependent or standard, for OS to
know if there are actually two mice connected behind the PS/2 mouse
port, and to direct commands to internal and external mice separately.
In short, when we send any command to the mouse port, you don't know
if it is sent the internal mouse only, or it is also forwarded to the
external mouse in addition to the internal mouse, or it is sent to the
external mouse only.
This problem is not FreeBSD-specific. Other OSes, including Windows,
have this problem too. If you buy a mouse with wheel and/or additional
buttons, its manual often say that the wheel may not function if you
use the mouse with laptop computers. This is particularly true when
you hook a wheel mouse to a laptop whose pointing device has no wheel;
our psm driver, or Windows mouse driver for this mouse, sends
initialization command sequence to enable the wheel, the commands are
interpreted by the internal mouse's firmware and are ignored, because
it has no wheel.
(I know Logitech at some point made a proposal to implement a software
interface in which OS mouse drivers can talk to internal and external
mouse selectively. I don't know if mouse and laptop vendors have
reached any agreement upon this.)
>instead? I.e.: on by default, with the ability to force it
>off if it caused trouble?
I made these flags optional for few cases they are absolutely needed.
I didn't made them default for the other systems, because I
followed the wisdom: "When it's not broken, don't fix it" :-)
If we have evidence that they are needed for many more machines
these days, it's worthwhile to make them default.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message