Ok guys...back onto this mouse lockup rubbish. Thanx to the poster about checkiing /var/lock & /dev and assc. linkings. They were all fine btw. Just as a sure measure though, I removed and redid them. Gpm was something else I hadn't actually considered, but doing the suggested gpm -K before sending startx off, perhaps only makes a difference 'a little', but this has been so spasmodic, as I'm sure others will testify, it's damn hard to say...still happening regardless anyhow :) There's one bit everyone should note here, it's not *just* netscape. Say I have a client running in shell..ftp transfer's go to stalled..and stay there until timeout on connection. What gives with the screen updates though? This is as similar with the xfer anim stopping on netscape. By what gawdawful way is a serial port trouble related to these screen issues? Just *why*, can *sometimes* the trouble be totally non evident, and such like screen updates (in netscape particularly) can actually stop, but the transfer keeps running happily in the background? This is rare, but it does happen still....reminds me of the '1200 when it does this :) It's just these interactions don't seem related, because it can happen just on raw cli just off logging in, and say starting ppp from there before startx....ie; I noticed I could get a ping to lock-up from there even BEFORE I startx...same chyt guys, move the mouse and this jerky blocklike cursor pops on the screen and it restarts???...what gives? As if a mouse is any use to you then ANYHOW :) I'm stumped. I'm thinking later of redoing my /devs by reinstalling them with a SRPM *just* incase the build matters. Is this safe to do once it's up and running off the very /dev you want to overhaul?? Sounds like it might have the potential to be nasty. I should mention one other thing, considering the video side of things. I have posted this to xfree86 themselves, and still await hopefully of a reply. Since I installed a gd-cl5464 graphicbraster 3d 4mb, it won't screenblank to black....oh, well, occasionally it'll choose black out of the available palette choices, but it likes the colours best, and displays them (when it should be black) with strange vertical banding? The only way to stop this behaviour, is to hit it with a xset s off. Something like xlock -mode whatever, works fine though. I haven't yet tried it, (because I can't remember if the mouse thing was then too), to put the old ark mt2000 back in and see how things happen then. Another thing that's gone since the cl5464 went in, is compatibility with KDE. It now smears, leaves artifacts, trashed pixels, colour table mixups, bizarre looking screen hacks like leaving 'zoom windows' type trails when you close a window, and dragging windows around leaves trails...quite funny actually. Anyone seen this behaviour before? I've tried all the relevant options for this chipset in XF86Config, but it seems to matter not. Anyone think this may be tied into the mouse trouble?? ..I'll change cards straight away and reconfig and see what happens.. cheers! Db -- PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES! http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject.
