[Maybe_Solved] Mouse erratic after awhile in browser

Oct 30 2011 ... cleaned the trackpad. No hal. Xorg is newer, Opera is newer,
intel rather than nvidia... (etc...)
uptime in X browsers upwards of twenty minutes.
nothing erratic.
Everything else older information below.




9/4 2010 update in the last post
...
9/2 working again a few minutes (touchpad...)
(the reason for this thread...touchpad)
(the good alternate... trackman wheel)
rebuilt imlib2 and cairo
altered the following in xorg.conf
Accel, DRI, AIGLX, RenderAccel, PixmapCache.
if only the xorg.conf was bios-type editing
(comments on the right, like generic kernel)
I would know which section and maybe which
option even to choose for each Option...
...



9/1 still working good.
9/2 still working good. (touchpad w/ undangled
adaptor approach)
9/2 broke again. (multiple qt-browser tabs open site)
rebuild libGL, nvidia, still broken. back to
Logitech... REMINDs oneself to test the keyboard in
another motherboard to confirm it is not the ps/2
port socket, rather than a hardware/Xorg/library
thing. OTOH the Logitech is probably the best
mouse out there AFAIK.


8/29
newest: working again
(thouchpad) (a few minutes at least).
Rebuilt hal, left it running.
Convoluted the serial-to-psu adaptor from
"hangs before the plug" to "approaches from above the
plug". (Logitech trackman wheel was working
flawlessly as a subsitute).



newest: on a Linux forum a similar problem was
described as "after the latest xorg update" ...
the person described "something will be highlighted.
If I click on something else to de-highlight the
first, the second item will be highlighted".
(xorg and/or mouse driver/option/setting?)



IGNORE THIS THREAD MAYBE:
...
keyboard with ps/2 touchpad: super
new (newer) (Same) keyboard: okay except serial > ps/2 (cord adapter
same keyboard): xorg very erratic (trackman mouse today on
that part of it). Serial xorg.conf tested a few hours, failed
so far. No solutions in sight.
...
Wanting the keyboard-touchpad rather than the mouse(trackman) because
stuff can be done 120 percent quicker... both suffice though.



Symptom: After a certain amount of time, a few tabs open,
traversing the mouse pointer to a new location:
anything it passed over was "auto clicked", in the
extreme, so by the time it passed over 5 links to get to the
new tab to open, each tab had been opened (as if clicked on)
and a link on the *new* page had been clicked (as if clicked on)
etc etc so what was ONE set of tabs became a whole NEW set of
opened tabs, with dialog boxes strobe-ing endlessly,
necessitating a cntl-alt-f1 (?) to exit X.
...
I've only had a minute or two to test, but libdrm was reinstalled
more recently than xorg-server; reinstalling the latter *may* have
fixed the issue. I'll know more in a few days... the problem had
been with any browser OR xterm OR keyboard OR window manager...
/edit (appears to work, an hour at least so far with
no problems...) /
Everything fixed it appears! I'd recc. this
rebuild for anyone even not having problems,
Code:
cd /usr/ports/x11-servers/xorg-server
make build-depends-list | grep gra

then

Code:
ls -lac /var/db/pkg/xorg-server-[number]
ls -lac /var/db/pkg/libdrm-[number]
also any other 2,3 that appear in the grep.
One might want the xorg-server more recent than
the graphic ports, for ALL files which appear
for each respective port in the var-db database
 
Reappeared. Had multiple tabs open.
Shut the computer off for over 10 min and
its back normal after I started Xorg without
the -retro and -ignoreABI switches. (Wondering
the cause...) at least it is again resolved.
......
Could even be caused by one of the xterm-clone's codes
or browser codes or mouse driver memory leaks or...
a certain html code style or css playing havoc with
an X11-something binary...
 
9 pm PST 8 23 2010:
temporarily fixed with
same keyboard, different (ordinary rather than on-keyboard) mouse.
ALL
*intermettent-then-persistent-then-intermittent* problems in this thread *maybe* originated with keyboards using
a serial-to-ps/2 converter. I tried and failed to setup the
serial (only) due to "legacy" settings not working usably... in
the short time I tested.



Broke again...
see OTOH below...


fixed again! (same day...)
Fixes more recent than below:
nvidia > nv

FIXED WITHOUT REBOOT.t
...
OTOH as I went to save this message, it appeared. All of a
sudden some of the lines above are being highlighted...
Tons of things to test.
....
Amazed if *that* fixes it for the entire week as the
below did not, the desktop appeared with the cursor in
the center, but something way to the left "selected" as if
I had a whole section highlighted and selected.
Also lots of
XIO: Fatal IO error 22 (35...) (18...) after NNNN requests...
upon X exiting...




Working again. Not accustomed to bumping my own thread but...
fix1... tighten *very* tight the serial-to-ps/2 converter
...
fix2...
added the following to InputDevices per google:
(just the changes put here mostly, I don't have the file displayed.)
Protocol "auto" (was ps/2)
Option "Emulate3Buttons" "true" (True was missing)
Option "Emulate3Timeout" "70" (option was not present)
Option "SendCoreEvents" "true" (option was not present)
...
fix3 in the bios, ps/2 mouse from Auto to Enabled (or maybe
vice-versa).
...
It went haywire again on a page with many frames and/or tables,
with many tabs open.
Many errors after X exited:
DEBUG: "Unknown event type: 18"
(approximate error, some with different number.
...
Amazed if those xorg.conf additions fixes it for the
entire week.
 
Two commands I've learned in the last 48 hours or
so from searching that seem to be a workaround (apart
from all the stuff in the first and subsequent threads:
Code:
xset m 1 1
Typing that first thing upon starting X(org) seems to slow
down the mouse enough so that it doesn't go erratic
...
if it does (one forgets to type xset because it is working
too often or good)
Code:
killall -HUP Xorg
will probably enable a clean Xorg restart to type the
xset command intially.
...
Hopefully not bumping this thread anymore, if those two
commands work the only issue(s) of minor importance
might be the plethora of stuff that "might work" in
xorg conf, OR some suitable serial mouse xorg.conf (none
I've tried work for the touchpad, not having tried very
much so far.)
...
Might eventually put the xset in xinitrc...
...
NEVER MIND. Crashed again... using the logitech as of this editing of this post.
...
UPDATE
The mouse-touchpad seems to be working again. The following
were added/changed in xorg.conf
in "InputDevice" Section
Option "AutoRepeat" "500 20" # was 500 30, 200 30 was too slow
in "InputDevice" Section ("Mouse1" identifier one)
Option "ConstantDecelration" "2" # 3 seemed too slow?
Option "MinSpeed" "0.02"
Option "MaxSpeed" "0.04" # .18 and .28 were each too slow?
...
working SLOW again. WAITING for it to crash...
as of 09 (sept) 04 2010
...
CRASHED... reverted to logitech wheel mouse.
Might have worked if I kept it all "very slow"
"3" "0.02" "0.18" "200 30" IIRC from the edits immedately above.
....
Tried and failed to reconfigure the serial mouse (cursor flew
away upon movement, fsck...)
...
reinput the values
(mouse1 PS/2):
Option "MinSpeed" "0.02" # suspected not working without synaptics
Option "MaxSpeed" "0.18" # ditto
Option "ConstantDeceleration" "3" #
...these make too SLOW (possibly stable touchpad).
the following upon loading of the window manager:
Code:
xset m 3 2
make it NOT_too_Slow... and possibly stable.
Testing as of today... 9/5
9/6 had crashed
changed it to
Code:
xset m 2 1
working a few minutes so far...
(the touchpad that is)
Unsure of today's variables in xorg.conf enough
to post them here.
OOPS crashed again... using the Logitech trackman.
 
Just bumping because I learned something. Original problem persists (one keyboard brand with touchpad and ps/2 connector works fine with mouse driver, same brand with touchpad and
serial-to-ps/2 cable worked at first, now half of the touchpad/mouse-clickers do not work, and unknown if it is the cable extension, hardware, length of cable, driver, or a setting in xorg.conf; logitech trackman works fine. (Legacy serial trackball cursor crashes immediately.) Trivia: I have upwards of thirty or so xorg.confs accumulated (this one right now is from a few years ago maybe and thus the logitech is really speeded up)... Guessing that the touchpad is not detected as synaptics because dmesg detects it as mouse... WHY AM I i BUMPING THIS THREAD?

Because I found out this trivia:

at least on this mobo, one can unplug one ps/2, plug in another, unplug it and put in a third, ... I was hoping to test more that way, and did for a few minutes, but still have not the time to investigate (hardware, OR xorg OR driver OR cable OR ... ) since "plan B" (logitech) and "plan b" (one keyboard upon another, using keyboard from the top one and touchpad from the bottom one) each work...

The thread I found had only one of the twelve posts reporting it damaging a motherboard to hot-swap the ps/2 connectors.
 
Problem maybe solved per the first paragraph in the first post. No reason to bother reading anything else in the thread... it is old information (if the trackpad keeps working.) If so, I plan on switching trackpad > Kensington trackball > trackpad > etc. at the first sign of RSI per either.
 
When my box is upgraded to 9.0 RC1, I might have the similar problem as yours, which is fixed by disabling hald. Seems quite unbelievable. :)
 
Back
Top