[Bug 955] wrote:
https://qa.mandrakesoft.com/show_bug.cgi?id=955It is NOT only a logitech thing-- Microsoft Wheel Mouse Optical (Glidepoint chip), USB and PS\2 multimodal with a PS\2 physical connect does this also. This mouse behaves as a:
------- Additional Comments From [EMAIL PROTECTED] 2003-01-24 15:32 -------
No, it's a very common PS/2 mouse :
Logitech cordless wheel mouse
M/N : M-RG45
P/N : 850612-1000
But I don't think it depends on the mouse type.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Reminder: -------
assigned_to: [EMAIL PROTECTED]
description: - Start install with a wheel mouse
- choose "standard wheel mouse" at mouse choice, click next
- test your buttons and click "next"
--> even at the next step, the mouse cannot be driven outside the dark blue area.
expected behaviour : the mouse boundaries should be limited only for the wheel
test, but should be released for the next dialog.
[root@ root]# cat /etc/sysconfig/mouse
MOUSETYPE=imps2
XMOUSETYPE=IMPS/2
FULLNAME="PS/2|Generic PS2 Wheel Mouse"
XEMU3=no
WHEEL=yes
device=psaux
[root@ root]#
and thusly works, but as a glidepoint it races when hooked to PS\2 port (psaux) but works as a USB-- in 9.0, and in 91. beta2 post-install ( but has bounding box probs IN install after mouse test, and since the summary box is in that bounding area, is this a high priority thing??? simply map within test box bounds after mouse test for dialogs???). Basicly, looks like mouse settings are not being taken\accepted\then USED by installer, or this is a bounding box persistence problem per se and not relevant to the mouse driver-- way back when, some folks forced a full screen bounding box reset after small dialogs locked mice cursors to small areas in a couple other operating systems-- I think this might be a lack of remapping the mousable area frame size as part of a successful test exit, and it persists until a larger screen area is refreshed\repainted than the old area (it was called bounding box focus retention in one operating system, and persisted when folks either forgot to force a new box the size of the window or full screen as appropriate in a submodule exit, or forgot to define a default large enough and return to that default after a module exit, or changed the default and forgot to revert it by multiusing one variable). I am getting similar things with MCC in beta2, not mouse boundaries, but refresh\repaint area resets not happening until the full right pane is forced to repaint with a menu event like a choice to see logs or not. I have had to in some cases unembed MCC submodules to get them to run (KDE desktop). This latter thing might be programmatically related, so I include here. Some modules in MCC stick with the wait logo and label displayed and no GUI action I can derive will open them-- boot floppy is one such in MCC in KDE.
John.
