Re: keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach)
+ Kazutaka YOKOTA wrote:
> We can improve our current behavior of syscons and keyboard drivers
> in the following approaches.
> a) Remove the FAIL_IF_NO_KBD flag from /boot/device.hints.
>Leave the AUTO_DETECT_KBD as it is now for syscons, so that
>syscons searches for a keyboard periodically while it isn't using
>one. Add a script to /etc/usbd.conf to switch to the USB keyboard.
I use the following scripts. This /etc/usb_kbd was an improvement
version and became a topic with "-tech-jp ML" in Japan before a
little. When you use it, please do "chmod +x". And you can use
below four variables with rc.conf.
keymap_
keyrate_
keybell_
keychange_
is device name of an USB keyboard.
For example, when you use a "jp.106x" keymap with ukbd0, you add
keymap_ukbd0="jp.106x" line to /etc/rc.conf. And other variable are
similar, too.
However, a case to use several USB keyboards is a testing shortage.
And keyboard device will not accord with variable name of rc.conf by
order to connect an USB keyboard to.
> I always liked the idea b), but haven't designed it yet.
I like b) plan, too.
--
Toshihiko ARAI
-/etc/usbd.conf-
# This entry changes a console keyboard to an USB keyboard when connected it.
# And switch back to keyboard just before that when disconnected.
#
device "USB keyboard"
devname "ukbd[0-9]+"
attach "/etc/usb_kbd ${DEVNAME} start"
detach "/etc/usb_kbd ${DEVNAME} stop"
-/etc/usb_kbd-
#!/bin/sh -
#
# $FreeBSD$
#
# usb_kbd devname [start|stop]
#
# example: usb_kbd ukbd0 start
#
# Suck in the configuration variables
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
kbdhist=/var/run/usb_kbd.hist
kbddev=
ttydev=/dev/ttyv0
devname=$1
shift
startstop=$1
shift
case ${startstop} in
[Ss][Tt][Aa][Rr][Tt] | '')
# To change system console by insertion of USB keyboard.
#
# Acquire a keyboard device name from a message of
# "kbd1 at ukbd0" of dmesg command.
#
kbddev=`dmesg | sed -n -e "/at ${devname}\\$/h" \
-e '${ g
s///p
}'`
[ -z ${kbddev} ] && kbddev=kbd1 # XXX
kbdcontrol -k /dev/${kbddev} < ${ttydev} || exit
# Append pair of device name into history file.
echo "${kbddev} ${devname}" >> ${kbdhist}
# You can use following four variables.
# For example,
# keymap_ukbd0="jp.106x"
# and rc.conf(5) may be helpful for you.
#
eval keymap=\$keymap_${devname}
eval keyrate=\$keyrate_${devname}
eval keybell=\$keybell_${devname}
eval keychange=\$keychange_${devname}
# Reference from src/etc/rc.syscons
# keymap
#
case ${keymap} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -l ${keymap}
;;
esac
# keyrate
#
case ${keyrate} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -r ${keyrate}
;;
esac
# keybell
#
case ${keybell} in
[Nn][Oo] | '')
;;
*)
kbdcontrol < ${ttydev} -b ${keybell}
;;
esac
# change function keys
#
case ${keychange} in
[Nn][Oo] | '')
;;
*)
set - ${keychange}
while [ $# -gt 0 ]; do
kbdcontrol <${ttydev} -f "$1" "$2"
shift; shift
done
;;
esac
;;
*)
# To switch back to keyboard before one by removal of
# USB keyboard.
#
if [ -s ${kbdhist} ]; then
#
# Delete a current keyboard from history file
# and get a last keyboard device name.
#
kbddev=`sed -e "/ ${devname}\\$/d" -e "w ${kbdhist}.tmp" \
${kbdhist} | sed -n '$s/ .*$//p'`
mv ${kbdhist}.tmp ${kbdhist}
fi
[ -z ${kbddev} ] && kbddev=kbd0
kbdcontrol -k /dev/${kbddev} < ${ttydev}
;;
esac
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>Anyway, I am now considering the following experiment. > >- We make the psm driver count the number of the "out-of-sync" errors. >- When the error is detected for the first time, the psm driver will > throw few data bytes (up to entire packet size) and see if it can > get back to sync. >- If the error still persists, the psm driver disable/enable the mouse > and see if it works. >- If the error still persists and the count goes up to N (10 or 20?), > the psm driver reset and reinitialize the mouse. The counter > is reset to zero. > >Too complicated? > >Kazu Ok, here is an experimental patch. It tries to implement the above scheme. http://people.freebsd.org/~yokota/psm-out-of-sync.diff.gz It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds in this patch). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. Watch out for the followin messages: "psmintr: delay too long; resetting byte count" "psmintr: out of sync (%04x != %04x)" "psmintr: discard a byte (%d)" "psmintr: re-enable the mouse" "psmintr: reset the mouse" Please test if you are suffering from the out-of-sync errors! Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach)
I am entering a tricky part now :-) --- Keyboard reset Because there are so many complicated issues here, I will start with describing something I know about what BIOS and FreeBSD keyboard driver do. (Beware, this is a long message.) 1. What BIOS does During AT BIOS POST, things happen as follows. Step 1. It sends the reset command to the keyboard. Step 2. It waits for the result code. During this reset operation the embedded controller inside the keyboard will flash LEDs(*1). Step 3. If it doesn't receive the result code, it assumes there is no keyboard. Depending on your BIOS (and BIOS setup), you will get the error message "keyboard not present." Step 4. If it has received the result code, but it signifies an error, you will get an error message too. Step 5. If it has received the result code, and there was no error, the BIOS sends the send-ID command to the keyboard. Step 6. If the keyboard is 101/102 enhanced keyboard (or newer), it will respond with a 2 byte ID code(*2). The original AT 84 keyboard (and some old notebook computers too) doesn't support this command and will report error. Step 7. If the BIOS recognizes this ID code(*2), it will set the bit 4 in the keyboard status byte in the BIOS data area (0x496). Step 8. The BIOS then send the set-LED command. This is typically done to turn the NumLock LED on. Step 9. The BIOS optionally send set-repeat-rate command to set repeat delay and rate which you have specified in the BIOS setup menu. (The original IBM AT didn't have such menu, thus, didn't send this command.) Note *1: we can certainly see the LEDs flash. But, this is not caused by the set-LED command from the host computer. It is by the keyboard's internal routine. In addition, LED flash is not detectable from outside, in an electrical way by the host computer or KVM. There is no signal line in the keyboard cable associated with the LEDs! We should also remember there are some keyboard which doesn't have LEDs. Note *2: a typical ID code is 0x41ab for the US 101 keyboard. But other keyboards may send a different code. If the ID code is not one of those the BIOS knows about, the bit 4 at 0x496 won't be set. If the machine is in warm-boot sequence, the entire above keyboard probe may be skipped. It is also important to note that there is no BIOS service or status byte (or bit) in BIOS data area which tells us the presence or absence of the keyboard. As already pointed out in this mailing list by many people, we cannot rely on the bit 4 at the BIOS data area 0x496 for this purpose; this bit is set only when the keyboard identifies it self as one of enhanced type (12 function keys and separate cursor pad keys) AND the BIOS recognizes its ID code. 2. What FreeBSD atkbd driver does Step 1. the probe routine sends the echo command to the keyboard port. If a keyboard is present behind the keyboard port, it will respond. Step 2. If there was no response, the driver assumes that there is no keyboard and note as such. The driver will fail to install ONLY IF you set bit 0 (FAIL_IF_NO_KBD) in the flags for atkbd. Step 3. If the keyboard is present, then the attach routine first try to retrieve the ID code from the keyboard by issuing the send-ID command. (The returned ID code will be saved.) Step 4. Then the reset command is sent(*1), in order to put the keyboard in known state(*1). (If the keyboard returns error and the FAIL_IF_NO_KBD bit is set in the device flags, the atkbd will fail to install.) Step 5. The set-LED command is sent. It typically set the NumLock LED which was turned off reset in the step 4. Step 6. The set-repeat-rate command is sent. Note *1: if you really don't want to reset the keyboard, you may set the NO_RESET flags to skip it. Note *2: if you warm boot the machine after you used it under another OS, we need to reset the keyboard to put it in known state, in case the BIOS doesn't do so for us. It is true that there is not much room for the other OSes to configure the keyboard in arcane state/mode, but I have seen in some Linux mailing list that someone suggested that they should use the scan code set 3. The atkbd driver uses the scan code set 2 (this is the default after reset), or the set 1 for old ThinkPad keyboards (you need to set the ALT_SCANCODESET in the atkbd device flags for this). Note: all these FAIL_IF_NO_KBD, NO_RESET, and ALT_ACANCODESET flags are documented in the man page for atkbd(4). 3. Difference between the BIOS POST and atkbd Except that the atkbd driver uses the echo command first and that the order of the send-ID and reset commands is different, both do essentiall
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote: > >o You may want to implement a rate throttling mechanism; > > init will stop respawning a getty on a port, if it is > > exiting too rapidly, while inetd will rate limit the > > number of connection attempts a second, as well. I > > guess you probably don't want to disable it, ala init, > > but limiting the number of reinitialize/resets per > > interval would address the "too expensive" and "reset > > causes additional resync errors" cases. > > We are not running getty on the mouse port. So, we don't need > to worry about this. I wasn't clear, I guess. What I meant was that you might want to rate throttle the mouse resets, in case the mouse driver ends up getting into one of those loops that people are afraid it might. If the moust can only reset once a second, you can't get stuck in a tight loop resetting the mouse. If it can only do it 10 times before it backs off a minute, then this will prevent someone grabbing the mouse and wiggling it to make it work breaking it forever. In other words, you control the rate at which you reset the mouse. This keeps it from being a problem, even if the new code breaks horribly. The worst that can happen is that you reset once a second (or whatever you tune the timer for), and then only do that 10 times every two minutes (or whatever you set the second timer for). So the idea is to make it behave like init behaves with getty: init-> getty psm0-> mouse reset Does this make more sense? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach)
>Kazutaka YOKOTA wrote: >> 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. > >I have a VAIO PCG-XG29; basically, I've just been shrugging >my shoulders, alt-consoling the thing, and then restarting >moused to make things happy Send HUP to moused(8). I suspect that should just work. >but if >you want, the code I've been working on lately just passed off >its acceptance testing today, so I could go through and put >some comments in the code and send it off to you, and you can >edit it and use it for a future commit. Thank you. I am interested. >So... (1) Would this be useful, and (2) if so, do you prefer >diffs against -current or -stable? (all of my work systems are >-stable, but I could check out a -current work directory for >this specifically). psm.c in -CURRENT and -STABLE differ only slightly. Diffs against either of the two will be fine. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Chris Dillon wrote: [ ... Belkin OmniView firmware version ... ] > > Little square sticker with rounded corners on the bottom, about > > 1/2" by 1/4", with just the version, e.g. "1.9"... > > The 4-port OmniCube on my desk only has version 1.5, but that probably > doesn't matter (how would I upgrade it? I have a ROM burner). I don't know how you would upgrade; it isn't flashable. A quick look at their web site doesn't show new versions available; I rather think it would violate your warranty. > The only > caveat with these two KVM switches hooked together is that it is a > real PITA when I hit Scroll Lock twice to change consoles on the > remote KVM that sometimes the local KVM will see the same sequence and > think I want to change consoles on it instead. I wish there were a > way to disable the keyboard shortcuts on the OmniCube and just use the > front-panel button. There's actually a way to do the cascade correctly; you can see the product manuals on line. They have a "magic" keyboard cable that you *must* use, and then they have two di switches that you have to set "off" for the cascaded device. Good luck! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>> If disable/enable sequence, which is lot simpler and takes considrably >> less time, can correct the sync problem, I think it will be better. > >It looks to me as if the mouse is automatically enabled by >default after a reset? No, the mouse is disabled after reset. We need to explicitly enable it. This will be done during our re-initialization sequence. >If this is true, then doing a disable >then a reset will result in the next mouse packet coming in >on a correct boundary. It makes the reset a tiny bit more >complicated, but makes the results more deterministic. Yes. We can expect we get the packet boundary right after the reset command followed by the enable command. And that's why we shall reset the "error counter" to zero after reset/reinitialize. >I don't know what to tell you, if the keyboard goes away during >the reset process: it seems counter-intuitive, and it means you >can't use keyboard shortcuts to get to a mouse "control panel" >to fix the problem manually... 8-(. The keyboard won't be inaccessible during the mouse reset sequence. Its data won't be lost (in theory). But, you just feel the keyboard is not responding quickly... Anyway, I shall make a patch and we test it to see how it behaves... >I think if that's unavoidable, a simple comment to that effect >in the code would save you loads of grief later. > >-- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>o If you are going to reset, disable and drain the input > queue before you do it; this will make the mouse lose > buffered data, making a partial send with a disable > in the middle not resume (e.g. it is no longer an > issue for you). Don't worry. I was going to do this :-) >o Because reinitialize can take a relatively _long_ > time, split the "reset" and "reset" complete operations > across a tsleep() (or msleep) so that the rest of the > system doesn't stall (I think the number I saw was 2 > seconds?!?). If you get an interrupt on the reset > complete because it always sends data, then that's not > a real issue: the tsleep becomes a guarantee, rather > than a requirement. Yes, we need to be careful about this. As the AT keyboard data and the PS/2 mouse data must read from the same keyboard controller port on the motherboard, we want to remove the mouse data from the keyboard controller port as soon as it arrives, otherwise the keyboard data will be blocked. >o You may want to implement a rate throttling mechanism; > init will stop respawning a getty on a port, if it is > exiting too rapidly, while inetd will rate limit the > number of connection attempts a second, as well. I > guess you probably don't want to disable it, ala init, > but limiting the number of reinitialize/resets per > interval would address the "too expensive" and "reset > causes additional resync errors" cases. We are not running getty on the mouse port. So, we don't need to worry about this. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote: > 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. I have a VAIO PCG-XG29; basically, I've just been shrugging my shoulders, alt-consoling the thing, and then restarting moused to make things happy, with a little hack to the sysmouse driver so X doesn't freak out. I didn't really complain, since there are several things on my VAIO which don't work (though I recently go my jog-dial working as a one dimensional, one button mouse; I use it for a third button, when I don't want to chord by forcing an Xevent 8-)). > 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).) I have to admit, I'm not running -current; I'm actually running a fairly down-rev system, as these things go, at least on the VAIO. > >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. It's required (or rather, a hack like it is) for my PCGA-PSX1 "Mini docking station" for the external mouse plugged into the mouse port on the thing. My hack doesn't fix the VersaPad. > 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. There doesn't seem to be a problem using either on the VAIO, FWIW: I can use them interchangeably. > >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. I think I just have one of the problem systems, so I'm seeing a lot of these issues. The KVM issues are seperate on my work boxes, not the laptop (no reason to be so perverse as to run a laptop docking port connectors through a KVM!!!). As usual, your post was informative, thanks! Personally, I'm one of those people who looks at the list archives, so I really don't have a problem with the driver documentation... but if you want, the code I've been working on lately just passed off its acceptance testing today, so I could go through and put some comments in the code and send it off to you, and you can edit it and use it for a future commit. So... (1) Would this be useful, and (2) if so, do you prefer diffs against -current or -stable? (all of my work systems are -stable, but I could check out a -current work directory for this specifically). Thanks again, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Mike Smith wrote: ** Takes self too seriously > > [Terry blathers] Warning that uncivil posting will follow shortly > > > Surprisingly, setting "vidconsole" in the SRM didn't make > > > my TGA work in FreeBSD. 8-p. > > 'vidconsole' is the x86 loader console driver. Under SRM, there are no ** Repeated use of quoteing of term, despite pretense that post being replied to did not do the same. > console options (because the platform doesn't give you any). |John Baldwin writes: | > What dance? Works great for me. If SRM uses serial console, so | > does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, ** Terminology matching term in original post | > this is the _only_ way it can work on the Alpha since SRM just | > gives you one console device handle and one boot device handle. | > | > Have you actually used an Alpha before? :-P *** Humor indicator in original post | | Yes, I've used a Miata and a Multia with FreeBSD, and several | others with DEC UNIX, and had a PC164 at one time. | | Surprisingly, setting "vidconsole" in the SRM didn't make Obvious use of "finger quotes" | my TGA work in FreeBSD. 8-p. *** Large indicator for humor impaired people -- Terry * Person tired of people being mean to others on lists for no good reason, and with no attempt at humor to blunt criticism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote:
> While we are carrying out the reset/initialization sequence, the mouse
> pointer will be frozen on the screen. The keyboard input may not
> respond in a timely fasion because the PS/2 mouse and the AT keyboard
> share the same I/O port. Then, I suspect our user may feel uneasy and
> think the entire FreeBSD is frozen...
The keyboard freeze seems problematic; can you decouple the
reset vs. the reset complete notification, by keeping a flag
("currently resetting") that the interrupt handler can look
at? This kind of goes with your next observation:
> What do you think the average user will do in such situation? It is
> quite likely that s/he will wiggle the mouse (rather frantically?) to
> see if the mouse is dead, won't he? I am not sure our initialization
> sequence is robust enough to not be disturbed by this.
Yes, wiggling the mouse to make it work is the natural thing
for someone to do...
> If disable/enable sequence, which is lot simpler and takes considrably
> less time, can correct the sync problem, I think it will be better.
It looks to me as if the mouse is automatically enabled by
default after a reset? If this is true, then doing a disable
then a reset will result in the next mouse packet coming in
on a correct boundary. It makes the reset a tiny bit more
complicated, but makes the results more deterministic.
I don't know what to tell you, if the keyboard goes away during
the reset process: it seems counter-intuitive, and it means you
can't use keyboard shortcuts to get to a mouse "control panel"
to fix the problem manually... 8-(.
I think if that's unavoidable, a simple comment to that effect
in the code would save you loads of grief later.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote: > Anyway, I am now considering the following experiment. > > - We make the psm driver count the number of the "out-of-sync" errors. > - When the error is detected for the first time, the psm driver will > throw few data bytes (up to entire packet size) and see if it can > get back to sync. > - If the error still persists, the psm driver disable/enable the mouse > and see if it works. > - If the error still persists and the count goes up to N (10 or 20?), > the psm driver reset and reinitialize the mouse. The counter > is reset to zero. > > Too complicated? Nope; looks right, actually. You might want to go further, though, if you are concerned about relinitializtion time, and repeats (someone suggested that resetting the mouse might result in interrupts, which could result in an "out of sync", which could result in a reset, ...). o If you are going to reset, disable and drain the input queue before you do it; this will make the mouse lose buffered data, making a partial send with a disable in the middle not resume (e.g. it is no longer an issue for you). o Because reinitialize can take a relatively _long_ time, split the "reset" and "reset" complete operations across a tsleep() (or msleep) so that the rest of the system doesn't stall (I think the number I saw was 2 seconds?!?). If you get an interrupt on the reset complete because it always sends data, then that's not a real issue: the tsleep becomes a guarantee, rather than a requirement. o You may want to implement a rate throttling mechanism; init will stop respawning a getty on a port, if it is exiting too rapidly, while inetd will rate limit the number of connection attempts a second, as well. I guess you probably don't want to disable it, ala init, but limiting the number of reinitialize/resets per interval would address the "too expensive" and "reset causes additional resync errors" cases. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach)
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
> > Too complicated? > >It sounds fine to me. I was thinking that if you are truly concerned >about the amount of time that the disable/enable calls take, the way to >solve that is a combination of counter and timer. Increment a counter >when you take the disable/enable path to prevent recursive calls. Set a >timer the first time through the pair of functions to get the basic >timing down. Then, limit the calls to the pair of functions so that you >never call them closer than 10x the time to complete the pair. (maybe >100x the time is better? It depends on how long the function pair >actually takes to complete. Is it variable depending on MB or other >factors?) I think that timing the calls is important to limit the >possibility of calling the functions too often in case of pathological >circumstances. This seems to be the overriding concern anyway. I have >only seen the problem once since I enabled that flag. We don't need to worry about such situation. As soon as we send the disable command to the mouse, it will stop sending data packet. So, we are not going to send another disable command before it completes, because we won't get another data byte which looks "out-of-sync" before the enable command. If we get "out-of-sync" data bytes after we send the enable command, there are two possible reasons: a) Disable/enable didn't work. The data packet is in wrong format. We need reset/re-initialization. b) The disable command was sent while the mouse was sending a data packet, and the mouse tried to send the remaining part of the packet after the enable command. This shouldn't happen for the well-behaved mouse. Logitech's technical document states that if the mouse is disabled in the middle of a data packet, the unsent part of the packet will be discarded, and the mouse will start sending a new packet after the next enable command. But, I would be rather cautious about this; there are so many wacky mice out there; they may not be as good as Logitech's :-) So, I would rather wait few more times after disable/enable and before reset/re-initialization. >What happens if you set your KVM into cyclical mode? Does it force a >mouse interrupt when it switches from machine to machine? It depends on the KVM's firmware, doesn't it? Both the mouse and the host computer do not know they are connected to a KVM. If the mouse is somehow forced by the KVM to send a data packet whenever you switch between machines, we will see the mouse interrupt. Otherwise I cannot imagine the mouse voluntarily sending data packets when you switch machines. You see, the root of the problem is here. The KVM tries to be transparent to the host computers and the mouse (and the keyboard) and there is no way for the host computer and mouse to know that it is connected to a KVM and to know exactly when the user switch between the machines. Kazu > I can imagine >a KVM misbehaving during the automatic rotate mode to cause a real >cascade of problems. On the other hand, if you put it in the rotate >mode, you probably aren't touching the mouse, so it shouldn't cause >problems. > >How difficult is it to keep some sort of timer value in the code? If it >costs too much to get a timer, then a counter is probably sufficient. > >/Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>Does it make sense to have a timeout (or perhaps just timestamps) in the >driver, so that after some period of inactivity, you "know" that the >next byte from the moust is the first of a multi-byte message? > >louie I haven't thought about this. Yes, it may be possible. But, when the mouse is moving rather fast, we may get continues flow of packets and this technic may not work... I will invesitgate and experiment with your idea. Thanks. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
>: Too complicated? > >I like this idea. It will allow mechanical KVM switches to "work" >better than they do now (which is to say, not much at all). I also >have one KVM switch that hits the out-of-sync problem when its power >fails. Unfortunately, it has a horrible user interface: The power >button and the switch console buttons are next to each other. > >I assume that initializing the mouse is somewhat expensive and >something that you wish to avoid? Yes. Reset and re-initialization involves sending a series of commands to the mouse. It will take time. In addition, after we send the reset command to the mouse, we have to wait until it returns a status code. Loctech's technical document states that it will be between 300 and 500 msec. But, I know, from our users' reports in the past, that some mice take a lot longer time than this before sending the status. Moreover, if we have a KVM between the mouse and the FreeBSD box, there may be additional delay (I also had a report on such KVM). So, the current psm code will wait up to 2 seconds in the worst case. There have been some cases where I had to advise users to set longer wait time via the kernel compile option PSM_RESETDELAY and PSM_MAXWAIT (see the man page for psm(4)) for some mice and KVM. While we are carrying out the reset/initialization sequence, the mouse pointer will be frozen on the screen. The keyboard input may not respond in a timely fasion because the PS/2 mouse and the AT keyboard share the same I/O port. Then, I suspect our user may feel uneasy and think the entire FreeBSD is frozen... What do you think the average user will do in such situation? It is quite likely that s/he will wiggle the mouse (rather frantically?) to see if the mouse is dead, won't he? I am not sure our initialization sequence is robust enough to not be disturbed by this. If disable/enable sequence, which is lot simpler and takes considrably less time, can correct the sync problem, I think it will be better. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA writes: > Anyway, I am now considering the following experiment. > > - We make the psm driver count the number of the "out-of-sync" errors. > - When the error is detected for the first time, the psm driver will > throw few data bytes (up to entire packet size) and see if it can > get back to sync. > - If the error still persists, the psm driver disable/enable the mouse > and see if it works. > - If the error still persists and the count goes up to N (10 or 20?), > the psm driver reset and reinitialize the mouse. The counter > is reset to zero. > > Too complicated? It sounds fine to me. I was thinking that if you are truly concerned about the amount of time that the disable/enable calls take, the way to solve that is a combination of counter and timer. Increment a counter when you take the disable/enable path to prevent recursive calls. Set a timer the first time through the pair of functions to get the basic timing down. Then, limit the calls to the pair of functions so that you never call them closer than 10x the time to complete the pair. (maybe 100x the time is better? It depends on how long the function pair actually takes to complete. Is it variable depending on MB or other factors?) I think that timing the calls is important to limit the possibility of calling the functions too often in case of pathological circumstances. This seems to be the overriding concern anyway. I have only seen the problem once since I enabled that flag. What happens if you set your KVM into cyclical mode? Does it force a mouse interrupt when it switches from machine to machine? I can imagine a KVM misbehaving during the automatic rotate mode to cause a real cascade of problems. On the other hand, if you put it in the rotate mode, you probably aren't touching the mouse, so it shouldn't cause problems. How difficult is it to keep some sort of timer value in the code? If it costs too much to get a timer, then a counter is probably sufficient. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 15-Aug-01 Mike Smith wrote: >> >> On 15-Aug-01 Mike Smith wrote: >> > >> > [Terry blathers] >> >> > Surprisingly, setting "vidconsole" in the SRM didn't make >> >> > my TGA work in FreeBSD. 8-p. >> > >> > 'vidconsole' is the x86 loader console driver. Under SRM, there are no >> > console options (because the platform doesn't give you any). >> >> Errr, there is a CONSOLE SRM variable that can be set to either "serial" or >> "graphics" that determines which SRM console (and thus boot and kernel >> consol >> e) >> you end up with. "serial" : "graphics" :: "comconsole" : "vidconsole" > > Bah. I know that. I misinterpreted "in the SRM" to mean "in the loader > under SRM". Brain fart, sorry. Apple overworking you a bit much recently? :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
> > On 15-Aug-01 Mike Smith wrote: > > > > [Terry blathers] > >> > Surprisingly, setting "vidconsole" in the SRM didn't make > >> > my TGA work in FreeBSD. 8-p. > > > > 'vidconsole' is the x86 loader console driver. Under SRM, there are no > > console options (because the platform doesn't give you any). > > Errr, there is a CONSOLE SRM variable that can be set to either "serial" or > "graphics" that determines which SRM console (and thus boot and kernel consol > e) > you end up with. "serial" : "graphics" :: "comconsole" : "vidconsole" Bah. I know that. I misinterpreted "in the SRM" to mean "in the loader under SRM". Brain fart, sorry. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 15-Aug-01 Mike Smith wrote: > > [Terry blathers] >> > Surprisingly, setting "vidconsole" in the SRM didn't make >> > my TGA work in FreeBSD. 8-p. > > 'vidconsole' is the x86 loader console driver. Under SRM, there are no > console options (because the platform doesn't give you any). Errr, there is a CONSOLE SRM variable that can be set to either "serial" or "graphics" that determines which SRM console (and thus boot and kernel console) you end up with. "serial" : "graphics" :: "comconsole" : "vidconsole" -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Does it make sense to have a timeout (or perhaps just timestamps) in the driver, so that after some period of inactivity, you "know" that the next byte from the moust is the first of a multi-byte message? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
In message <[EMAIL PROTECTED]> Kazutaka YOKOTA writes: : Anyway, I am now considering the following experiment. : : - We make the psm driver count the number of the "out-of-sync" errors. : - When the error is detected for the first time, the psm driver will : throw few data bytes (up to entire packet size) and see if it can : get back to sync. : - If the error still persists, the psm driver disable/enable the mouse : and see if it works. : - If the error still persists and the count goes up to N (10 or 20?), : the psm driver reset and reinitialize the mouse. The counter : is reset to zero. : : Too complicated? I like this idea. It will allow mechanical KVM switches to "work" better than they do now (which is to say, not much at all). I also have one KVM switch that hits the out-of-sync problem when its power fails. Unfortunately, it has a horrible user interface: The power button and the switch console buttons are next to each other. I assume that initializing the mouse is somewhat expensive and something that you wish to avoid? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
[Terry blathers] > > Surprisingly, setting "vidconsole" in the SRM didn't make > > my TGA work in FreeBSD. 8-p. 'vidconsole' is the x86 loader console driver. Under SRM, there are no console options (because the platform doesn't give you any). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Ok, I am back. There are so many issues to be explained and discussed. I will tackle them one by one - Flags 0x8000 for psm and "out-of-sync" error As many people want to make it default, and my initial intent to make it an option didn't work out well as a hindsight, we had better make it the standard, default feature. However, I would point out that THERE ARE CASES WHERE IT DOESN'T CORRECT "out-of-sync". The "out-of-sync" problem occurs in three situations. Case 1: there was communication error between the keyboard and the motherboard and data bytes from the mouse were somehow dropped. (I expect this is to be very rare these days.) Case 2: when you switch between more than two host computers connected to a KVM, there may be a loss of data bytes from the mouse to the FreeBSD box, if you try to switch computers during a packet is being sent from the mouse. This can be avoided if the KVM is intelligent enough to know the boundary of mouse data packets, but I suspect many KVMs on the market are not that smart; there are so many different mouse data format and packet length that I seriously doubt that KVMs know all of them and are able to ensure all data packets are sent to the host computers without splitting a data packet. Case 3: when you use a KVM, the mouse is initialized to one operating mode by a host computer, and then another computer tries to set up another operating mode of the mouse. Modern PS/2 mice have more than one operating mode to support wheels, additional buttons, and other extra features. These advanced modes most certainly use different packet data format and packet length than the original IBM PS/2 mouse (2 buttons, three-byte packet). If two computers try to put the mouse in different modes, they may be expecting different packet length, and will be confused when you switch between them. Even if the two computers are expecting the same packet length, you may witness wiered mouse pointer movement (instead of the "out of sync" message) because of the data format difference. If the KVM understands all the mouse operating modes from all venders and is able to set up the correct operaring mode for each computer when switching between them, we will have no problem. But, the KVMs we have today are not that capable for the same reason as I stated in the case 2 above. The flags 0x8000 can correct the first two situations and should get the mouse and the FreeBSD box back in sync. In case 3 above, this flag won't help; you will get a series of "out of sync" and "re-enable the mouse" messages. (I initially didn't like the idea that there would be a lot of traffic from the host computer to the mouse to disable/enable the mouse and we would still never get out of the error if we fell into this trap. That was another reason why I made the flag optional.) To get out of this error, we need to reset the mouse and reinitialize it the way we want. The trouble is that it is impossible for the psm driver to distinguish the above three situations. Reset and re-initialization is also effective for the case 1 and 2, but considered overkill and it will take a long time to do it. Another note on the "out-of-sync" error: we cannot guarantee that we can always detect it. Because there is no reliable way to find the start of the mouse data packet, the psm driver may operate without noticing the error and the mouse pointer goes berserk on your screen... Anyway, I am now considering the following experiment. - We make the psm driver count the number of the "out-of-sync" errors. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to N (10 or 20?), the psm driver reset and reinitialize the mouse. The counter is reset to zero. Too complicated? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Mon, 13 Aug 2001, Terry Lambert wrote: > Chris Dillon wrote: > > Occasionally I'll have mouse sync problems when I switch between > > FreeBSD and NT when the NT box has had difference mice (wheel vs. > > non-wheel MS mice, apparently) used on it via the dual-user KVM > > switch. NT seems to handle that case fairly well by resetting the > > PS/2 port and/or the mouse (not sure which) and redetecting the mouse > > type. > > There is actually a Cybex-specific "Microsoft Knowledge Base" > article which discusses the registry setting you need to pound > on to make NT not attempt to detect the mouse wheel (FWIW). I've found it. This will apply to any case where you would want to disable the wheel mouse detection in NT. For archive purposes, here it is: http://support.microsoft.com/support/kb/articles/Q165/3/25.ASP > > FreeBSD doesn't like when NT has done that to the mouse, > > though, and spews sync errors when I switch back. Usually I can kill > > moused and restart it to fix the problem. > > The 0x8000 flag fixes exactly this problem! I see that this flag exists in -STABLE but is undocumented as of yet. I'll give it a try. Luckily this problem is not too common since I rarely use the second user on the other KVM switch. [...snip...] > > Hmm... I'll have to check, maybe thats why mine works. :-) > > Little square sticker with rounded corners on the bottom, about > 1/2" by 1/4", with just the version, e.g. "1.9"... The 4-port OmniCube on my desk only has version 1.5, but that probably doesn't matter (how would I upgrade it? I have a ROM burner). I can't find the firmware version on my OmniView Matrix. The only caveat with these two KVM switches hooked together is that it is a real PITA when I hit Scroll Lock twice to change consoles on the remote KVM that sometimes the local KVM will see the same sequence and think I want to change consoles on it instead. I wish there were a way to disable the keyboard shortcuts on the OmniCube and just use the front-panel button. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 13-Aug-01 Terry Lambert wrote: > John Baldwin wrote: >> > More ideally, the FreeBSD box would detect whether or not >> > the video card had been disabled, and use _that_ to decide >> > whether or not to use a keyboard. It would become the job >> > of the video driver -- be it a regular driver, or be it an >> > LCD driver -- to make the distinction. >> >> This might be practical except that lots of motherboards ship with >> built-in video these days. > > I think that disabling this in AMI BIOS, at least, will result > in the carry flag being set to indicate INT 10 call failures. Unfortunately there are other BIOS vendors, and we need a solution that works across the board and doesn't trigger false positives. (Most BIOS's don't set the enhanced keyboard bit for USB keyboards, and some don't set it for PS/2 keyboards either, hence turning off -P.) >> What dance? Works great for me. If SRM uses serial console, so >> does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, >> this is the _only_ way it can work on the Alpha since SRM just >> gives you one console device handle and one boot device handle. >> >> Have you actually used an Alpha before? :-P > > Yes, I've used a Miata and a Multia with FreeBSD, and several > others with DEC UNIX, and had a PC164 at one time. > > Surprisingly, setting "vidconsole" in the SRM didn't make > my TGA work in FreeBSD. 8-p. Not all of those machines have TGA's, and you could be testing out the TGA driver. However, there is no song and dance, you set the console to serial for a TGA machine and it all works and fine. Not exactly a song and dance. :) > -- Terry -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Chris Dillon wrote: > Occasionally I'll have mouse sync problems when I switch between > FreeBSD and NT when the NT box has had difference mice (wheel vs. > non-wheel MS mice, apparently) used on it via the dual-user KVM > switch. NT seems to handle that case fairly well by resetting the > PS/2 port and/or the mouse (not sure which) and redetecting the mouse > type. There is actually a Cybex-specific "Microsoft Knowledge Base" article which discusses the registry setting you need to pound on to make NT not attempt to detect the mouse wheel (FWIW). > FreeBSD doesn't like when NT has done that to the mouse, > though, and spews sync errors when I switch back. Usually I can kill > moused and restart it to fix the problem. The 0x8000 flag fixes exactly this problem! > > and the local wiring (non-ethernet version) of the Belkin OmniView > > switches work if the FreeBSD mouse/keyboard is selected at boot > > time, so that the aggressive probe/attach can satisfy itself. > > That is the KVM switch's fault, not FreeBSD's. On all but the most > expensive KVM switches which offer true "keyboard and mouse emulation" > on all ports, even NT (or actually the BIOS, I assume) can fail to > enable keyboard and mouse support in that case. The dual-user Belkin > OmniView seems to handle this correctly. I can't recall any problem > booting FreeBSD on it even when its console isn't active. Yes, it has to to support the dual use case; we have one of those in the lab, as well... > > Belkin went out of its way to support FreeBSD specifically, > > actually: their firmware version 1.9 fixes the local wiring > > switches, so that they can pass FreeBSD's aggressive probe, even > > if the FreeBSD mouse/keyboard is _not_ selected. > > Hmm... I'll have to check, maybe thats why mine works. :-) Little square sticker with rounded corners on the bottom, about 1/2" by 1/4", with just the version, e.g. "1.9"... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)
Gordon Tetlow wrote: > This is such a great example of how tone can come across poorly in a text > medium. I doubt (hope) that Joe didn't mean to come across as that. But > tone in email is so often inferred based on the readers own moods, that > phrasing email becomes much more important so as to not give the reader > the wrong impression. > > This should be required reading for anyone considering posting to a > FreeBSD mailing list. My personal suggestion: it's nice to "be nice", but it's better to be as nice as you can, and grow a thick skin. This isn't me being facetious: many of the people involved in FreeBSD are not coming to it as native speakers of English, and most of the discussions on these lists are in English. If you insist on taking offense at every opportunity, or even at half of them, then you will find yourself not getting along very well. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Joe Kelsey wrote: [ ... 0x8000 ... ] > Again, all I am asking is for someone to explain why they make a design > decision. The comment in the psm.c file about a "hack" is extremely > unhelpful. Why did the coder think it was a "hack" solution? What were > the pros and cons that went into that decision. Was there a discussion > on -current about it that I missed? If there was a discussion and a > conclusion was reached, the proper thing to do is to insert > documentation into the code to explain the design decisions that were > made. If you don't document the design in the code, it will be > forgotton, as there is no other place to document it in FreeBSD. Kazu stated that the reason he didn't enable this by default is that he wanted it tested before he committed to making it the default. It's a bit over the top conservative (since it can't make a broken mouse any more broken), but I understand his intent, if not his reasoning. It's a hack solution, since it should "just work", but this makes an intrinsic assumption that you won't put something between you and the hardware to cause problems. It could be that he just hadn't thought of that -- but I doubt it, since the code came from him in the first place. All in all, I agree with the sentiment on design documentation: I'd like to see a lot more of it before code is thrown at a problem, and I'd like to see more literate programming, and most of all I'd like to see benchmarks froving that changes are not gratuitous, or if they are, they at don't injure performance (people have actually been much better about this lately, for the most part, though I still fear for the tcptmpl elimination, rather than merely a reduction in the allocation size). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Joe Kelsey writes: > : I also second Terry's comment about 0x800. There is no reason to add > : yet more driver flags in order to "do the right thing". The "do the > : right thing" case should always be default and a flag (sysctl variable, > : etc) should be used for those who want "the wrong thing". > > The main reason that it wasn't added at the time was that it was > expensive in terms of CPU utilization, so it shouldn't be on by > default. There may be other reasons as well... ??? It was just recently added; I'd like to see it MFC'ed for 4.4, but certainly, Kazu hasn't been slacking on 0x8000. I personally don't see how it could be more costly in terms of CPU, since it only invokes in the case of a desynchronized mouse event coming in to the mouse driver: e.g. a failure case that only triggers when there's bot a failure, and a monkey on the other end of the mouse cable. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
John Baldwin wrote: > > My suggestion for a probe in this case would be to set up > > a different handler for the reset signal, and then ask the > > keyboard to send the reset signal. If it does, then there > > is a keyboard present. > > Yeah, and resetting the controller works fine on machines that don't > have keyboards, so it returns false positives. I don't *want* the controller reset: that's what makes the LEDs flash and screw up the KVM's. > > More ideally, the FreeBSD box would detect whether or not > > the video card had been disabled, and use _that_ to decide > > whether or not to use a keyboard. It would become the job > > of the video driver -- be it a regular driver, or be it an > > LCD driver -- to make the distinction. > > This might be practical except that lots of motherboards ship with > built-in video these days. I think that disabling this in AMI BIOS, at least, will result in the carry flag being set to indicate INT 10 call failures. > What dance? Works great for me. If SRM uses serial console, so > does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, > this is the _only_ way it can work on the Alpha since SRM just > gives you one console device handle and one boot device handle. > > Have you actually used an Alpha before? :-P Yes, I've used a Miata and a Multia with FreeBSD, and several others with DEC UNIX, and had a PC164 at one time. Surprisingly, setting "vidconsole" in the SRM didn't make my TGA work in FreeBSD. 8-p. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
John Baldwin wrote: > 1) Implement probing/detection for PS/2 keyboards post-boot. You can hack > this by having the atkbd0 driver always attach to IRQ 1, but not create and > export a kbd0 syscons keyboard driver until it gets an interrupt event from > the keyboard. This would be pretty easy. > 2) Rewrite the syscons keyboard layer so that we don't have a primary > keyboard that is always the current keyboard, but instead make it accept > input from all keyboards currently plugged into the system. With this you > could go back to assuming a PS/2 keyboard is always around as a hack. This would be rather cool, since it would let me dock and undock my laptop or use an external USB keyboard at the same time... I'll have to find some time to go to Fry's some time in the next couple of weeks or so... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Mike Smith wrote: > > Here is the _precise_ problem with older firmware: > > > > The Belkin KVM switch uses the "on->off->on" or "off->on->off" > > of this LED to signal a port change character is coming next, > > and times out the port change request only after a little > > while. > > Ah, so the problem is actually a design defect in the Belkin switch. > Nice to have that part confirmed. Toe-may-toe, Toe-mah-toe. Other vender's hacks are no better; if there's a design defect in the switch, it's that it doesn't take the double scroll-lock, instead of using the LED from the host, such that if it's wedged, you have to manually hit the "next console" button. On the other hand, I can force a console switch from software on a machine by toggling the scroll lock LED, and then forcing the keyboard to send me a key-down for a digit by priming its buffer, which is really handy if you want to do an automated rolling demo for a trade show, etc.. > > The fundamental problem here is that FreeBSD _resets_ a > > keyboard which has already been correctly reset by the BIOS, > > if it is present. > > You can't be sure of this. Just as we reset everything else we > talk to, we reset the keyboard. Specific examples where *not* > resetting things gets us into trouble can typically be found by > looking for "when I reboot from Windows XYZ doesn't work". I think that depowering the thing and repowering it at POST is enough to know its state... The only historical fly in this ointment is that some old systems didn't put a real flip-flop on the CPU reset line, and latch it as a result of getting the keyboard reset command from the keyboard controller. Most of these are using XT keyboards, though, which won't work with any KVM switches out there today, since the controller chip is on the wrong side of the keyboard connector cable. 8-). > > The FreeBSD keyboard detection is another matter; FreeBSD > > will assume that there is no keyboard, and try to "helpfully" > > drop you into serial console mode. > > No it won't, unless you explicitly configure it. This is the "-P default" case; most people are not running that recent a -current. > > Some of this _used_ to > > be mitigated by checking for the "extended keyboard bit" in > > the "keyboard identify" BIOS call, but this was a problem > > for people with antique keyboards. > > This is not the problem, as I have already mentioned in another message. > BIOS vendors have *stopped* setting this bit. I've checked 5 machines, including the Tyan and SuperMicro (the latter is AMI BIOS), as well as my Sony VAIO... all set the bit. That said, I agree that it's not a very good way of detecting a keyboard being out there... 8-(. > > My suggestion for a probe in this case would be to set up > > a different handler for the reset signal, and then ask the > > keyboard to send the reset signal. If it does, then there > > is a keyboard present. > > Keyboard probing is a dead loss, which is why we don't do it > by default. I wish we could avoid resetting, as well. I think that the BIOS you are seeing not setting the bit has decided to not do the probe, too. That's understandable, given that KVM switches are becoming more and more common: they probably saw the same thing FreeBSD is seeing with these boxes. > > More ideally, the FreeBSD box would detect whether or not > > the video card had been disabled, and use _that_ to decide > > whether or not to use a keyboard. It would become the job > > of the video driver -- be it a regular driver, or be it an > > LCD driver -- to make the distinction. > > There is no standardised way of detecting whether a display > has been "disabled". One gross way that I have never seen fail is to make an INT 10 call to set a standard (the default) video mode, and note that the registers indicate a failure. > > Absolutely ideally, FreeBSD would come up with the boot code > > on _both_ (this is an option), and then be told by the user > > to not use one of them -- or boot using _both_, until told > > to do otherwise. > > We've tried this already; people didn't like it. Well, I think the only option left here is explicit configuration. The boot loader doesn't reset the keyboard, does it? I've never seen the LEDs "flash dance", between the PST and the FreeBSD keyboard probe, anyway. Perhaps we could elect to reset the keyboard from the boot loader, as an option, and not do it by default... > > This would _also_ solve the Alpha serial console dance. > > Actually, it wouldn't, since we use the SRM console for quite a ways, and > SRM doesn't do multi-source console I/O. (And when you have a version of > SRM that allows you to 'pull' the console by sending a few keystrokes, > you can't work out where it's actually directed anyway.) Ugh. I was thinking more in terms of activating both drivers, and sinking both inputs to the same /dev/console... not pretty, either. Cheers, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "u
Re: FreeBSD's aggressive keyboard probe/attach
Jason Evans wrote: > I had the same problems, and took my KVM switch apart, expecting to find > the chips reversed. They were in fact installed correctly, so at least in > my case, the problem exists regardless. If I'm careful to have the KVM > switch on the same channel as a booting machine, and leave it on that > channel until the probing is done, everything seems to work fine. > Otherwise, the keyboard is not detected. See my other post; an upgrade to firmware version 1.9 will fix the problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sat, 11 Aug 2001, Terry Lambert wrote: > Finally, most keyboard/mouse/monitor switches don't work with > FreeBSD; for example, the Belkin console extender that uses the > ethernet cable doesn't work at all (it's the best one out there), I'm using a Cybex KVM-over-CAT5 extender with a cheap 4-port Belkin OmniCube KVM switch on one end (my desk) and a much more expensive 8-port dual-user Belkin (OmniView?) KVM switch on the other end (the server closet) attached to three FreeBSD servers and one NT box. I only use keyboard and video for the FreeBSD boxes, but that much has always worked perfectly. Occasionally I'll have mouse sync problems when I switch between FreeBSD and NT when the NT box has had difference mice (wheel vs. non-wheel MS mice, apparently) used on it via the dual-user KVM switch. NT seems to handle that case fairly well by resetting the PS/2 port and/or the mouse (not sure which) and redetecting the mouse type. FreeBSD doesn't like when NT has done that to the mouse, though, and spews sync errors when I switch back. Usually I can kill moused and restart it to fix the problem. > and the local wiring (non-ethernet version) of the Belkin OmniView > switches work if the FreeBSD mouse/keyboard is selected at boot > time, so that the aggressive probe/attach can satisfy itself. That is the KVM switch's fault, not FreeBSD's. On all but the most expensive KVM switches which offer true "keyboard and mouse emulation" on all ports, even NT (or actually the BIOS, I assume) can fail to enable keyboard and mouse support in that case. The dual-user Belkin OmniView seems to handle this correctly. I can't recall any problem booting FreeBSD on it even when its console isn't active. > Belkin went out of its way to support FreeBSD specifically, > actually: their firmware version 1.9 fixes the local wiring > switches, so that they can pass FreeBSD's aggressive probe, even > if the FreeBSD mouse/keyboard is _not_ selected. Hmm... I'll have to check, maybe thats why mine works. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)
On Sun, 12 Aug 2001, Warner Losh wrote: > A word about tone. If you were to get as in my face about, say, > pccard, as you about the psm driver, I'd certainly be ill inclined to > provide you with what you want. > > Good Tone: > Say Warner, why do you bother turning off the power after > you suspend a socket. Shouldn't the power routines take care > of that? Is there something subtle that's going on? Maybe a > comment is in order? > > Bad Tone: > Please explain the pros and cons for turning the power off > after suspending a socket. I really want to know. Why did > they do this? Didn't the coder trust the power routines? The > least he could have done was include a comment. Was there > some long discussion that I missed? > > See the difference? The first tone is friendly, suggesting that > something in the code might be unclear. The second seems to imply > that I'm a moron for not documenting every trivial solution with a 20 > page thesis on why it is good or bad to do. This is such a great example of how tone can come across poorly in a text medium. I doubt (hope) that Joe didn't mean to come across as that. But tone in email is so often inferred based on the readers own moods, that phrasing email becomes much more important so as to not give the reader the wrong impression. This should be required reading for anyone considering posting to a FreeBSD mailing list. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
In message <[EMAIL PROTECTED]> Joe Kelsey writes: : Warner Losh writes: : > In message <[EMAIL PROTECTED]> Joe Kelsey :writes: : > : I also second Terry's comment about 0x800. There is no reason to add : > : yet more driver flags in order to "do the right thing". The "do the : > : right thing" case should always be default and a flag (sysctl variable, : > : etc) should be used for those who want "the wrong thing". : > : > The main reason that it wasn't added at the time was that it was : > expensive in terms of CPU utilization, so it shouldn't be on by : > default. There may be other reasons as well... : : Please explain the reference to "expensive in terms of CPU : utilization". I have currently turned this code on by default (simply : removed the if blocking and the hack comment) so that it always does the : log message followed by the disable/enable calls. So far, where I used : to see thousands of "out of sync" messages, I now have seen exactly one : "out of sync" message followed by the "re-enable" message. I cannot see : how a single disable/enable call at the first mouse motion can cause : massive CPU utilization problems. But then again, maybe I am thinking : wrong? That's what I was told when I asked to make it default. The enable/disable routines were, at least at the time, somewhat expensive because they did things to the mouse port at 1uS per transaction and there were lots of transactions. : Please explain this. Do you expect to be resetting the mouse thousands : of times per second? It is an error condition. The default must be to : fix the errors. As soon as someone reports that the fix is being : executed thousands of times per second on their broken hardware, then we : can implement the opposite flag to disable the fix in those pathological : cases where it causes a problem. It is possible, i believe, to have patholigical cases where resetting the mouse would cause another out of sync, which would cause another reset, which would cause another out of sync, etc. This would result in a hung system, for all intents and purposes. That's why it isn't enabled by default. At least that's my dim recollection of the mail I had with yokota-san, that may have been private. : Again, all I am asking is for someone to explain why they make a design : decision. The comment in the psm.c file about a "hack" is extremely : unhelpful. Why did the coder think it was a "hack" solution? What were : the pros and cons that went into that decision. Was there a discussion : on -current about it that I missed? If there was a discussion and a : conclusion was reached, the proper thing to do is to insert : documentation into the code to explain the design decisions that were : made. If you don't document the design in the code, it will be : forgotton, as there is no other place to document it in FreeBSD. Sometimes things don't get documented. That's the nature of the beast. A word about tone. If you were to get as in my face about, say, pccard, as you about the psm driver, I'd certainly be ill inclined to provide you with what you want. Good Tone: Say Warner, why do you bother turning off the power after you suspend a socket. Shouldn't the power routines take care of that? Is there something subtle that's going on? Maybe a comment is in order? Bad Tone: Please explain the pros and cons for turning the power off after suspending a socket. I really want to know. Why did they do this? Didn't the coder trust the power routines? The least he could have done was include a comment. Was there some long discussion that I missed? See the difference? The first tone is friendly, suggesting that something in the code might be unclear. The second seems to imply that I'm a moron for not documenting every trivial solution with a 20 page thesis on why it is good or bad to do. Also, sometimes you have to know when to give a point a rest. Hammering this again so soon after yakota-san sent out his long, very well written message that said he was going on a business trip and would be out of touch isn't going to have the results you expected. He'll get back from his trip and will likely be swamped. That's the worst time to hit someone with a "hey, can you document this more" message. Warner P.S. The answer is that we don't power off before that point and if we fail to power it off, the card will continue to draw power while suspended and can cause machine hangs when the machine is resumed. A careful tracing of the code shows that no power down commands are issued in the disable path. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Warner Losh writes: > In message <[EMAIL PROTECTED]> Joe Kelsey writes: > : I also second Terry's comment about 0x800. There is no reason to add > : yet more driver flags in order to "do the right thing". The "do the > : right thing" case should always be default and a flag (sysctl variable, > : etc) should be used for those who want "the wrong thing". > > The main reason that it wasn't added at the time was that it was > expensive in terms of CPU utilization, so it shouldn't be on by > default. There may be other reasons as well... Please explain the reference to "expensive in terms of CPU utilization". I have currently turned this code on by default (simply removed the if blocking and the hack comment) so that it always does the log message followed by the disable/enable calls. So far, where I used to see thousands of "out of sync" messages, I now have seen exactly one "out of sync" message followed by the "re-enable" message. I cannot see how a single disable/enable call at the first mouse motion can cause massive CPU utilization problems. But then again, maybe I am thinking wrong? Please explain this. Do you expect to be resetting the mouse thousands of times per second? It is an error condition. The default must be to fix the errors. As soon as someone reports that the fix is being executed thousands of times per second on their broken hardware, then we can implement the opposite flag to disable the fix in those pathological cases where it causes a problem. Again, all I am asking is for someone to explain why they make a design decision. The comment in the psm.c file about a "hack" is extremely unhelpful. Why did the coder think it was a "hack" solution? What were the pros and cons that went into that decision. Was there a discussion on -current about it that I missed? If there was a discussion and a conclusion was reached, the proper thing to do is to insert documentation into the code to explain the design decisions that were made. If you don't document the design in the code, it will be forgotton, as there is no other place to document it in FreeBSD. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
In message <[EMAIL PROTECTED]> Joe Kelsey writes: : I also second Terry's comment about 0x800. There is no reason to add : yet more driver flags in order to "do the right thing". The "do the : right thing" case should always be default and a flag (sysctl variable, : etc) should be used for those who want "the wrong thing". The main reason that it wasn't added at the time was that it was expensive in terms of CPU utilization, so it shouldn't be on by default. There may be other reasons as well... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 13-Aug-01 John Baldwin wrote: > runtime interface (IMO). I realize the user side of the attributes is up for > debate, but working on solving this problem is much more problem than > complaining that people aren't giving you the free gift you want. s/problem/productive/2 -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Terry Lambert wrote: > The FreeBSD keyboard detection is another matter; FreeBSD > will assume that there is no keyboard, and try to "helpfully" > drop you into serial console mode. Some of this _used_ to > be mitigated by checking for the "extended keyboard bit" in > the "keyboard identify" BIOS call, but this was a problem > for people with antique keyboards. Umm, this is the -P flag to boot2 which is no longer on by default. Not a kernel issue. > My suggestion for a probe in this case would be to set up > a different handler for the reset signal, and then ask the > keyboard to send the reset signal. If it does, then there > is a keyboard present. Yeah, and resetting the controller works fine on machines that don't have keyboards, so it returns false positives. > More ideally, the FreeBSD box would detect whether or not > the video card had been disabled, and use _that_ to decide > whether or not to use a keyboard. It would become the job > of the video driver -- be it a regular driver, or be it an > LCD driver -- to make the distinction. This might be practical except that lots of motherboards ship with built-in video these days. > Absolutely ideally, FreeBSD would come up with the boot code > on _both_ (this is an option), and then be told by the user > to not use one of them -- or boot using _both_, until told > to do otherwise. > > This would _also_ solve the Alpha serial console dance. What dance? Works great for me. If SRM uses serial console, so does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, this is the _only_ way it can work on the Alpha since SRM just gives you one console device handle and one boot device handle. Have you actually used an Alpha before? :-P -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Terry Lambert wrote: > Mike Smith wrote: >> >> > :Finally, most keyboard/mouse/monitor switches don't work with >> > :FreeBSD; >> >> This is actually not true. I'd doubt that you've even tried many of them. *sigh* It seems no one has investigated why we probe keyboards at all. Maybe if people would do a little research, they would _learn_ something. Assuming that we always have PS/2 keyboards present breaks the case of people who use *shock* non-PS/2 keyboards like USB keyboards. Now, I'm sure that you think that everyone should use PS/2 keyboards and that anyone who doesn't is just absolute pure scum of the earth, but I don't share that same view. :-P Seriously, if you go up to a FreeBSD box and hotplug a USB keyboard (which was _designed_ for hotplug) it will work just fine. Now, there are a couple of different ways to fix the problem: 1) Implement probing/detection for PS/2 keyboards post-boot. You can hack this by having the atkbd0 driver always attach to IRQ 1, but not create and export a kbd0 syscons keyboard driver until it gets an interrupt event from the keyboard. 2) Rewrite the syscons keyboard layer so that we don't have a primary keyboard that is always the current keyboard, but instead make it accept input from all keyboards currently plugged into the system. With this you could go back to assuming a PS/2 keyboard is always around as a hack. Obviously Windows can handle USB keyboards, so why don't you put your money where your mouth is and make FreeBSD work fine on hardware that Windows works on. Patches accepted. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 12-Aug-01 Joe Kelsey wrote: > Thank you very much for the clear and cogent explanation of your > philosophy of the psm code. Could I suggest that you copy the > aforementioned e-mail directly into the psm.c file for everyone to see > in posterity? > > Also, I have a fundamental problem with device flags. I believe that > every situation which uses device flags should instead use sysctl > variables, allowing easy manipulation at run-time. Of course, there are > no doubt situations not addressable at run-time, but these should be the > rare special cases where a driver flag is used. Patches accepted. This is a volunteer project. If you want to be productive, work up a device attribute interface that allows devices to query attributes and allows devices to be notified when outside events change their attributes. You should probably use kernel environment variables (like the hints we have now) for setting attributes from the loader, and then use sysctl's to back the runtime interface (IMO). I realize the user side of the attributes is up for debate, but working on solving this problem is much more problem than complaining that people aren't giving you the free gift you want. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
> Here is the _precise_ problem with older firmware: > > The Belkin KVM switch uses the "on->off->on" or "off->on->off" > of this LED to signal a port change character is coming next, > and times out the port change request only after a little > while. Ah, so the problem is actually a design defect in the Belkin switch. Nice to have that part confirmed. > The fundamental problem here is that FreeBSD _resets_ a > keyboard which has already been correctly reset by the BIOS, > if it is present. You can't be sure of this. Just as we reset everything else we talk to, we reset the keyboard. Specific examples where *not* resetting things gets us into trouble can typically be found by looking for "when I reboot from Windows XYZ doesn't work". > The FreeBSD keyboard detection is another matter; FreeBSD > will assume that there is no keyboard, and try to "helpfully" > drop you into serial console mode. No it won't, unless you explicitly configure it. > Some of this _used_ to > be mitigated by checking for the "extended keyboard bit" in > the "keyboard identify" BIOS call, but this was a problem > for people with antique keyboards. This is not the problem, as I have already mentioned in another message. BIOS vendors have *stopped* setting this bit. > My suggestion for a probe in this case would be to set up > a different handler for the reset signal, and then ask the > keyboard to send the reset signal. If it does, then there > is a keyboard present. Keyboard probing is a dead loss, which is why we don't do it by default. > More ideally, the FreeBSD box would detect whether or not > the video card had been disabled, and use _that_ to decide > whether or not to use a keyboard. It would become the job > of the video driver -- be it a regular driver, or be it an > LCD driver -- to make the distinction. There is no standardised way of detecting whether a display has been "disabled". > Absolutely ideally, FreeBSD would come up with the boot code > on _both_ (this is an option), and then be told by the user > to not use one of them -- or boot using _both_, until told > to do otherwise. We've tried this already; people didn't like it. > This would _also_ solve the Alpha serial console dance. Actually, it wouldn't, since we use the SRM console for quite a ways, and SRM doesn't do multi-source console I/O. (And when you have a version of SRM that allows you to 'pull' the console by sending a few keystrokes, you can't work out where it's actually directed anyway.) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
2nd data point for keyboard probes (was Re: FreeBSD's aggressive keyboard probe/attach)
> I've seen the 'have to be on the machine while booting' behavior > using a Belkin Omniview Pro switch, which oddly, wasn't a problem > with their OmniCube switch, at least not with my machines. Windows > had as much, or more problems with not having the console on the > booting machine as fbsd though. Again, this is only my (one) data > point. Make that two data points, I don't think you're alone in this observation. > I finally got fed up with the Belkin, because *windows* keep losing > it's mouse (or instead of just losing it, it would start sending > what appeared to be random button-press events for tracking events...) > and broke down and bought a Raritan KVM. You mean you got tired of the "Ctl+esc, Up arrow, Enter, Enter" key sequence to get the mouse back? I wonder why ;~) None the less, having to have the console active for the system while the BIOS && OS probe the keyboard is a pain when managing a large number of systems. We eventually made a policy that required the use of a laptop + serial cable anyone when you went to one of the data centers to do some administration of the systems (downtime for a keyboard wasn't an option). -sc -- Sean Chittenden PGP signature
Re: FreeBSD's aggressive keyboard probe/attach
On Sun, 12 Aug 2001 10:16:47 -0600, Nate Williams wrote:
>> > > :Finally, most keyboard/mouse/monitor switches don't work with
>> > > :FreeBSD;
>> >
>> > This is actually not true. I'd doubt that you've even tried many of them.
>>
>> Boy, you are on one about me...
>>
>> I have tried 5 switches. At ClickArray, we have a large number
>> of Belkin Omniview switches. I have one with firmware version
>> 1.9 at my desk, and freqiently use one with firmware version 1.6
>> in our lab, with the results I have described.
>
>Strange, as the group at Nokia is running quite a lot of them (Belkin
>OmniView and OmniCube) without any problems.
>
>I'm guessing it's operator error. :)
>
>
>
>
>Nate
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
I've seen the 'have to be on the machine while booting' behavior
using a Belkin Omniview Pro switch, which oddly, wasn't a problem
with their OmniCube switch, at least not with my machines. Windows
had as much, or more problems with not having the console on the
booting machine as fbsd though. Again, this is only my (one) data
point.
I finally got fed up with the Belkin, because *windows* keep losing
it's mouse (or instead of just losing it, it would start sending
what appeared to be random button-press events for tracking events...)
and broke down and bought a Raritan KVM. Yep it is/was pricey, but it's
probably one of the purchases I've been happiest with, over the long
run. Video quality ('doze and X displays) is much, *much* better than
the Belkin, and no machine has a problem booting without the console
pointing to it.
Just my $.02.
Thanks,
Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sun, Aug 12, 2001 at 02:35:22PM -0700, John Polstra wrote: > > Maybe they swapped the labels on the chips too. :-) Well, it apparently doesn't fry anything to have the chips reversed, so maybe I should try swapping them just to make sure. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
In article <[EMAIL PROTECTED]>, Jason Evans <[EMAIL PROTECTED]> wrote: > On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote: > > > > I just want to add that in the case of the Belkin OmniView, it > > should be noted that Belkin shipped a bunch of them with a couple > > of EPROM chips swapped accidentally. > > I had the same problems, and took my KVM switch apart, expecting to find > the chips reversed. They were in fact installed correctly, so at least in > my case, the problem exists regardless. If I'm careful to have the KVM > switch on the same channel as a booting machine, and leave it on that > channel until the probing is done, everything seems to work fine. > Otherwise, the keyboard is not detected. Maybe they swapped the labels on the chips too. :-) Seriously, that's really strange. I have all variety of machines hooked up to my Belkin OmniView, including FreeBSD (-current and -stable, i386 and Alpha), Linux, OpenBSD, NetBSD, Tru64, NT, and Win2k, and I don't see any major problems, even using the mouse (no-name 2-button). There is only one thing that drives my the KVM out of its mind: powering down the Alpha. As soon as I do that, the KVM is totally hosed. Even invoking its so-called "reset" function (pressing both selector buttons simultaneously) doesn't help. As soon as I reboot any machine (even the Alpha) that's connected to the KVM, it's OK again. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote: > > I have no argument about the keyboard probes. I just want to add > that in the case of the Belkin OmniView, it should be noted that > Belkin shipped a bunch of them with a couple of EPROM chips swapped > accidentally. There's a page on the Belkin web site that tells how to > check for it and how to fix it. Once I put the chips into the right > sockets, my OmniView started working a _whole_ lot better. :-) The > weird thing is, it appeared to kind of sort of work most of the time > even before. So all along I assumed it was just a poorly designed > device, when actually it was just assembled wrong. (I still think > it's a poorly designed device, but it's a lot better than it was > before I swapped the chips.) I had the same problems, and took my KVM switch apart, expecting to find the chips reversed. They were in fact installed correctly, so at least in my case, the problem exists regardless. If I'm careful to have the KVM switch on the same channel as a booting machine, and leave it on that channel until the probing is done, everything seems to work fine. Otherwise, the keyboard is not detected. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
