Date: Thu, 16 Aug 2001 13:16:42 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach) Message-ID: <200108160416.NAA08677@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Sun, 12 Aug 2001 01:49:27 MST." <3B764317.4334A0F6@mindspring.com> References: <200108112351.AAA26897@banks.cogsci.ed.ac.uk> <200108120422.f7C4MY150223@harmony.village.org> <3B764317.4334A0F6@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108160416.NAA08677>