On Wed, 26 Feb 2003, Dr Andrew C Aitchison wrote: > On Wed, 26 Feb 2003, Peter Berg Larsen wrote:
>> This seems to happen because X is set to use a mouse repeater (that >> does not respond to commands), combined with that X resets the mouse >> when swithing to X from the console. >I have the same long freeze, but am not, as far as I am aware, using a >repeater. I do have two mice, which doubles the delay. My point was that because the repeater do not respond to commands I am waiting for a lot of timeouts, which is worsen because of retries. (Replaced with a real mouse lowers the freeze to about 2 seconds). Though, it seems that X is doing a lot other stuff when switching back to X, so some of these might also prolong the freeze in your case. (or slow mice, some need calibrationtime after a reset in the area of 7500000 msec) >> Why reset the mouse when switching to X in the first place ? How >> can it be turned off? (It can't if I have read the code correct, so the >> actual question is whether it is to late to do anything about it) >It isn't so much turning it off, but while the X server is switched >away, something else may have put the mouse into some other state; >eg most wheel mice can speak either PS/2 or IMPS/2. Okay, so how do I tell X that the mouse is not changing state, and even if it did, X could not do anything about it? It seems easy to just add an option for the mousedriver to skip initialisations, but there might be some obvious "fix" I a havent found, because I have only looked at mouse* code. So would it be to late to send a patch for that? Peter ps. Please cc me. _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
