Professional Web Applications Themes

Mouse issues on IBM server xSeries 335 using OSR5.0.6 - SCO

I have two of the above mentioned machines running OpenServer 5.0.6, sharing a keyboard, monitor and mouse using the special pass through feature on these servers. For those that don't know, the xSeries 335 has two non-standard connectors on the back for KVM (one input, the other output) so they can be stacked and use one set of IO devices. Sort of like an internal KVM switch. The problem I have is when I switch from one server to the other, the mouse no longer works properly. It has a y motion and does not read the button clicks correctly. ...

  1. #1

    Default Mouse issues on IBM server xSeries 335 using OSR5.0.6

    I have two of the above mentioned machines running OpenServer 5.0.6,
    sharing a keyboard, monitor and mouse using the special pass through
    feature on these servers. For those that don't know, the xSeries 335
    has two non-standard connectors on the back for KVM (one input, the
    other output) so they can be stacked and use one set of IO devices.
    Sort of like an internal KVM switch. The problem I have is when I
    switch from one server to the other, the mouse no longer works
    properly. It has a y motion and does not read the button clicks
    correctly. As an example, double left button click acts like a single
    right button click, but a single left button click will select the
    object under the cursor (sometimes).

    I had the mouse configured as a 'High Resolution Keyboard Mouse: PS/2
    (wheel)' and switched it to Low, but it didn't change a thing.

    I've tried looking for a BIOS setting to handle headless operations
    for the mouse, but can only find it for the keyboard, video, and
    floppy.

    TIA,

    Edward Hooper
    Princess Cruises
    Edward Hooper Guest

  2. #2

    Default Re: Mouse issues on IBM server xSeries 335 using OSR5.0.6

    Edward Hooper wrote:
    > I have two of the above mentioned machines running OpenServer 5.0.6,
    > sharing a keyboard, monitor and mouse using the special pass through
    > feature on these servers. For those that don't know, the xSeries 335
    > has two non-standard connectors on the back for KVM (one input, the
    > other output) so they can be stacked and use one set of IO devices.
    > Sort of like an internal KVM switch. The problem I have is when I
    > switch from one server to the other, the mouse no longer works
    > properly. It has a y motion and does not read the button clicks
    > correctly. As an example, double left button click acts like a single
    > right button click, but a single left button click will select the
    > object under the cursor (sometimes).
    >
    > I had the mouse configured as a 'High Resolution Keyboard Mouse: PS/2
    > (wheel)' and switched it to Low, but it didn't change a thing.
    >
    > I've tried looking for a BIOS setting to handle headless operations
    > for the mouse, but can only find it for the keyboard, video, and
    > floppy.
    Does this happen every time you switch the internal KVM, or only
    sometimes? What happens if the mouse is already in the bad state, and
    you switch the KVM away and back again -- does it get even worse, stay
    the same, or go back to normal?

    Try flipping away, flipping back, not touching the mouse, flipping away,
    flipping back, _then_ try the mouse. Try this with increasing numbers
    of back-and-forth flips before you touch the mouse; up to a total of 4.
    I am not suggesting these as workarounds, but probes to try to
    understand the problem.

    What I'm trying to probe is: the keyboard mouse driver expects to see
    data from the keyboard mouse in a certain sequence. It expects a packet
    of 3 or 4 bytes (depending on whether it's a non-wheel or wheel mouse).
    I'm imagining what would happen if, during the KVM flip, the driver saw
    a single byte of garbage. It might think it was the first byte of a
    packet, after which it would be off by one in interpreting packets. If
    each flip produces one garbage byte, flipping 3 or 4 times might get you
    back in sync.

    There's a problem with this theory: the driver attempts to detect this
    condition by rejecting additional bytes of a mouse packet if too much
    time has elapsed (defined as 1/4 second). This defensive check should
    prevent the above scenario. But maybe it doesn't quite work right.

    To enhance your testing, you can turn on a keyboard mouse driver debug
    flag. The flag is `kbm_noisy' and the easiest thing is to turn it on in
    your live kernel. Do this:

    # /etc/scodb -w
    scodb> kbm_noisy=1
    scodb> q

    The change will persist until you reboot (or change it back to 0 in the
    same manner). I would like to know whether you get any "kbmintr"
    warnings with it turned on, when the mouse is in the bad state.

    You can also set a second variable, `kbm_dbg', to values of 1 or 2.
    Setting it to 1 causes it to print information on what it's sending up
    to the mouse reader; 2 causes it to additionally print the actual mouse
    bytes as they are received. 0 turns it off. This output is extremely
    verbose for practical purposes, but might be helpful in understanding
    your problem.

    All of the output produced by these two debug variables appears on the
    console. Under X, it will appear in an "Error" window. You will
    probably find it easier to decipher behavior on a text multiscreen. In
    particular, set `kbm_dbg=2' and flip back and forth, see if the act of
    flipping is producing any mouse bytes.
    >Bela<
    Bela Lubkin Guest

  3. #3

    Default Re: Mouse issues on IBM server xSeries 335 using OSR5.0.6

    Bela Lubkin <belalsco.com> wrote in message news:<20030722001338.GD24551sco.com>...
    > Edward Hooper wrote:
    >
    > > I have two of the above mentioned machines running OpenServer 5.0.6,
    > > sharing a keyboard, monitor and mouse using the special pass through
    > > feature on these servers. For those that don't know, the xSeries 335
    > > has two non-standard connectors on the back for KVM (one input, the
    > > other output) so they can be stacked and use one set of IO devices.
    > > Sort of like an internal KVM switch. The problem I have is when I
    > > switch from one server to the other, the mouse no longer works
    > > properly. It has a y motion and does not read the button clicks
    > > correctly. As an example, double left button click acts like a single
    > > right button click, but a single left button click will select the
    > > object under the cursor (sometimes).
    > >
    > > I had the mouse configured as a 'High Resolution Keyboard Mouse: PS/2
    > > (wheel)' and switched it to Low, but it didn't change a thing.
    > >
    > > I've tried looking for a BIOS setting to handle headless operations
    > > for the mouse, but can only find it for the keyboard, video, and
    > > floppy.
    >
    > Does this happen every time you switch the internal KVM, or only
    > sometimes? What happens if the mouse is already in the bad state, and
    > you switch the KVM away and back again -- does it get even worse, stay
    > the same, or go back to normal?
    >
    > Try flipping away, flipping back, not touching the mouse, flipping away,
    > flipping back, _then_ try the mouse. Try this with increasing numbers
    > of back-and-forth flips before you touch the mouse; up to a total of 4.
    > I am not suggesting these as workarounds, but probes to try to
    > understand the problem.
    >
    > What I'm trying to probe is: the keyboard mouse driver expects to see
    > data from the keyboard mouse in a certain sequence. It expects a packet
    > of 3 or 4 bytes (depending on whether it's a non-wheel or wheel mouse).
    > I'm imagining what would happen if, during the KVM flip, the driver saw
    > a single byte of garbage. It might think it was the first byte of a
    > packet, after which it would be off by one in interpreting packets. If
    > each flip produces one garbage byte, flipping 3 or 4 times might get you
    > back in sync.
    >
    > There's a problem with this theory: the driver attempts to detect this
    > condition by rejecting additional bytes of a mouse packet if too much
    > time has elapsed (defined as 1/4 second). This defensive check should
    > prevent the above scenario. But maybe it doesn't quite work right.
    >
    > To enhance your testing, you can turn on a keyboard mouse driver debug
    > flag. The flag is `kbm_noisy' and the easiest thing is to turn it on in
    > your live kernel. Do this:
    >
    > # /etc/scodb -w
    > scodb> kbm_noisy=1
    > scodb> q
    >
    > The change will persist until you reboot (or change it back to 0 in the
    > same manner). I would like to know whether you get any "kbmintr"
    > warnings with it turned on, when the mouse is in the bad state.
    >
    > You can also set a second variable, `kbm_dbg', to values of 1 or 2.
    > Setting it to 1 causes it to print information on what it's sending up
    > to the mouse reader; 2 causes it to additionally print the actual mouse
    > bytes as they are received. 0 turns it off. This output is extremely
    > verbose for practical purposes, but might be helpful in understanding
    > your problem.
    >
    > All of the output produced by these two debug variables appears on the
    > console. Under X, it will appear in an "Error" window. You will
    > probably find it easier to decipher behavior on a text multiscreen. In
    > particular, set `kbm_dbg=2' and flip back and forth, see if the act of
    > flipping is producing any mouse bytes.
    >
    > >Bela<
    I set the debug flags as you mentioned (kbm_noisy=1 & kbm_dbg=2) with
    the following results:

    1) Switching between servers using the built in KVM switch does not
    generate a signal that the mouse driver is picking up.

    2) After a time, the debug messages stop displaying on the console,
    but the mouse continues to function (sort of: same problem as before).

    3) Switching rapidly between servers does not change behavior of the
    mouse. (I tried doing it one, two, three and four times...)

    4) Switch between virtual consoles on the same server unsticks the
    debug output (see #2). But not all of the time...

    And now I see that the graphical desktop (on tty02) has stopped
    functioning. I had to run 'scologin stop' and 'scologin start' to
    bring it back.

    Maybe I'm using the wrong driver here. Is there a special driver for
    the IBM series servers that is needed? When I looked up the server on
    the SCO website to see if it was certified, the page with all of the
    information showed which oss packages to load (already done) but
    didn't mention a special mouse driver that was required. Just as an
    experiment I will rebout the server that has the mouse plugged in
    directly and leave it there, to see if the mouse goes south all on
    it's own...

    Thanks for the help so far!

    Edward Hooper
    Princess Cruises
    Edward Hooper Guest

Similar Threads

  1. Testing Server Issues on Mac
    By Mark Westwood in forum Macromedia Dynamic HTML
    Replies: 0
    Last Post: June 5th, 11:41 AM
  2. web server connection issues
    By davidihill in forum Macromedia Contribute General Discussion
    Replies: 5
    Last Post: November 11th, 09:10 PM
  3. SQL Server Logins Issues
    By l_eric_l in forum Coldfusion Database Access
    Replies: 3
    Last Post: August 4th, 06:25 PM
  4. Building SOAP Clients on OSR5
    By J. L. Schilling in forum SCO
    Replies: 0
    Last Post: August 21st, 09:59 PM
  5. LDMs mouse over issues
    By Troy Hipolito in forum Macromedia Director Lingo
    Replies: 3
    Last Post: July 11th, 04:40 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139