Mouse hangs on launching X

[CentralWare]

I ran a search in the forums and couldn't find any hits on this topic, but since it's seemingly universal to all of the machines I've had TC on I figure it's hardly new news.

When launching X (vesa/org) under 4.x the mouse (ps2 and/or usb) just sits there for a few seconds while moving it around.  Eventually it "catches on" as though the mouse driver was asleep and when it catches, it tends to hit the bottom left of the screen with a right-click and thereafter acts as it should.  Whether attempting this right after booting or an hour later, it's that "first interaction" that has the issue - even after power savings shuts down the video everything is perfectly fine coming out of it.  (I haven't tried suspension.)

Has there been any work done in this area - it's much more of just an irritation as opposed to something dysfunctional so I'm not sure if it would have ever been a priority.

Thanks!

[curaga]

I've only seen it with tinyx, not Xorg, and as you say, hasn't been a big enough matter to go after.

[Lee]

I was concerned about that way back when but I haven't noticed it for a while (I'm still mostly on 4.x), but it might just be that I've stopped noticing it as it was never really a problem.  So it's not "just you".

Now that I think of it, I suppose that's why I always grab the mouse and swish it around whenever I sit down at any PC - even a Windows box.

[nitram]

I also experience a brief mouse freeze at boot on TC-6 using Xvesa but it works fine after a couple seconds. Never locks up or anything. Just assumed the system was still fininishing up the boot sequence.

Edit: Maybe TC boots too fast and gets ahead of itself, similar to the waitusb boot command?

[CentralWare]

boots too fast -- I've remotely woken a machine (WOL) and an hour later have gone to its terminal...  no difference, it still has that few seconds of lag even after 1+ hours of just sitting there.  I'd say "yes and no" but can't confirm it yet.

If we don't have a quick fix as to WHAT the problem is (I have a theory I'll be testing tonight) but anyone got a quick fix or willing to implement one for a one-shot app which merely API-moves the mouse a couple pixels in rotation for a few seconds to see if we can't try to band-aid the issue temporarily?  I'm thinking udevadm isn't finished when startx is being launched and Xvesa (tiny) is probably done loading HID devices before they're initialized.  Xorg happens less frequently (but still happens) but also takes a little bit longer to launch (thus the theory.)

fixit app: change the mouse pointer to "wait" and for the next 'x' seconds simply move x+1, y+1 then back a few and so on, then reset the cursor.  If getting elaborate, call for the cursor position and if/when it begins to show the changes, break the loop.  I'm not overly confident on my c++ skills in 'nix else I wouldn'tt even make such a request.

Cheers!

[coreplayer2]

Am sure there was a thread with this issue way back when..  Am trying to find it, but not having any luck with the search criteria

[Rich]

Hi centralware

fixit app: change the mouse pointer to "wait" and for the next 'x' seconds simply move x+1, y+1 then back a few and so on, then reset the cursor.  If getting elaborate, call for the cursor position and if/when it begins to show the changes, break the loop.  I'm not overly confident on my c++ skills in 'nix else I wouldn'tt even make such a request.

Maybe  xdotool.tcz  is what you are looking for. There's some information about it here:
http://tuxradar.com/content/xdotool-script-your-mouse

[CentralWare]

@coreplayer2: Same here -- I searched for something as simple as "X mouse" and could not find a hit which sounded related, but didn't go to the ends of the Earth digging

@Rich: Thank you for the link!!!  I'll dig into it as soon as time permits!  I may even have a cure for the issue, but I'm still knee-deep in HAL/uDevADM trying to determine when the hardware layer is finished processing devices (from trigger) without using verbose to where it spews a ton of otherwise useless information on-screen, not having the ability to piping it to a log or what-not makes this a little daunting.

From what it looks like, the call to udevadm in tc-config sends the trigger command, but (especially with Xvesa) when startx is launched, in many cases "settle" hasn't completed and I'm guessing (by what I've seen so far) HID, some networking, video devices and a few external items such as printers haven't been processed yet and are still in the queue.  I don't see a way to rearrange the order in which things are processed (not yet at least) so the only thing I can think of is to utilize some format of splash screen (CLI side) before startx is launched to give somewhat of a "Please Wait" look without the "Hurry up and wait" feeling that comes with it.  M$ finally figured this out with Win7 where the splash screen isn't so horrific (like the scrolling bar from Vista/XP days which is just a lot of repetition that aggravates the user into saying "I'm still waiting!" ) but since there aren't that many things we need to "wait" for in order to be "functional" landing on the desktop (mainly HID as it's the first thing they reach for) this should be a matter of simply showing a splash, monitoring for kb, mouse and other similar items and when at least one of each fit the bill, launch X and lest the rest settle on their own.)

"Sometimes...  being too fast just gets you nowhere, faster!"

[curaga]

There is no waiting like that, settle is synchronous, and this can be easily replicated by doing startx on a running, fully up system - it will still happen. The right place to look for is the mouse driver of X. As said I've never seen it on Xorg, so either it was fixed in a more recent driver, or it's the way I use Xorg (I always have a full xorg.conf, wasting time on autodetection doesn't suit me).

[nitram]

Just wanted to add my two bits with newbie eyes. Since it's so brief, not sure i would classify this as a mouse hang, but i guess that's accurate. I would just say a little sluggish out of the gate

Wouldn't vote for a splash screen option, just makes it look like the system is hiding something or exposes the user to various screen images and colours, which may clash with their preferred desktop appearance. A transparent central 'Loading ..." prompt over the mouse cursor would be okay. Or maybe a simple mouse cursor hourglass for 1-2 seconds.

Of course if you solve this relatively minor issue then none of what i said is useful anyway. Take care all.

[CentralWare]

@curaga: Thanks for the tid-bit...  gives me something to consider playing with (Xorg with full config) to see if I can get it to act up -- maybe deduce issues?

@nitram: If you've ever added debug as a boot code.. yeah, there's a lot to hide   Me, personally, I like a quiet boot (thus have stripped all of the echos out of start-up files (save for errors) where only the rotating dash (rotdash) is shown just so I know things are still going on, but a splash screen with a progress bar is what I had in mind (it's easy to count how many extensions you're going to load, for example, so updating the progress bar should be simple math.)  I played with Plymouth for a few last night and though it seems to depend on Xorg I might be looking into some method of an alternative if I don't have to re-invent the wheel for Xvesa and if I can't use Xvesa with Plymouth -- still a work in progress.

As for the mouse, I might have to do just that (the hourglass, so to speak) as it would be nice to have things "ready to go" once the desktop loads.  I'll be googling for tiny to see if this has been seen elsewhere just to see if anyone else has already come across a fix.  No..  it's not "hanging" as that tends to imply "stuck forever" - so we'll see!

Thanks for everyone's input!

[Rich]

Hi centralware
I don't recall if TC2 exhibited this mouse behavior but I know TC3 did.

[CentralWare]

@Rich: Thanks for the head's up...  though my mirror starts at 4.x; I never ventured any older than that, but I might look into that direction to see what has changed between the two.

[xyz-worx]

Hi centralware,

although I made my 'mouse-experiences' with TC3 maybe this thread
might be helpful:

http://forum.tinycorelinux.net/index.php/topic,10731.0.html

Regards

xyz-worx

[CentralWare]

@xyz: Thanks for the link; an interesting read if nothing more as to the trials and tribulations of hunting down oddities!   It has me thinking, though, since the word "old" isn't necessarily the issue here as I was also testing this little oddity out on a dual AMD and the exact same outcome.  I don't even know if I have stock boards and cards from the era (I think I unloaded most ISA to AGP cards quite some time ago along with the same vintage motherboards, but it's funny to read though as I came across an old IBM 486 (Cyrix) chip about a month ago and couldn't help but laugh thinking to myself "...ahh, back in the day where a failed heat-sink fan would cause a melt-down...  or a fire!"