Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: CentralWare on January 31, 2015, 08:41:28 AM
-
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!
-
I've only seen it with tinyx, not Xorg, and as you say, hasn't been a big enough matter to go after.
-
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.
-
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?
-
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!
-
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
-
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
-
@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!" :)
-
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).
-
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.
-
@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!
-
Hi centralware
I don't recall if TC2 exhibited this mouse behavior but I know TC3 did.
-
@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.
-
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
-
@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!"
-
Not sure if centralware is still around :( ...just wanted to post an observation. Utilizing the same hardware on TC 6, mouse hung using Xvesa but no longer with Xorg.
-
This problem annoys me and I'm looking for a way to fix it. To get a better understanding I've got a question:
There is an old thread, that seems to refer to the same problem: http://forum.tinycorelinux.net/index.php/topic,11985.0.html.
"dfattcl" seems to have done some investigation, but as far as I understood the final post in his thread, he thinks that lxterminal should cause the mess... - but why? As far as I understand, lxterminal is an X application that emulates a terminal which can be used for console based applications. When xvesa starts, there is no lxterminal running, so how could lxterminal cause this problem?
Unfortunately dfattcl only wrote: "changing the terminal" could fix the problem. Anybody has an idea, what he could have done?
-
Do you have lxterminal installed onboot? The extension creates a symlink to xterm so it can be used by programs that are not aware of what terminal you use. Maybe it runs in the background?
-
No lxterminal installed. "aterm" is being used as X terminal emulator.
-
When my mouse hung, lxterminal was not installed. My impression is that this is an Xvesa issue.
Edit: Don't believe aterm is required to boot, so just for testing purposes you could try removing aterm from onboot to see if any difference.
-
Hi nitram
I see the same behavior under Xorg.
-
For me, under Xvesa I just need to move the mouse a tad, second attempt and things work.
Under Xorg I havn't seen it.
Would something like this be possible? Maybe via ~/.X.d/ .
sudo echo "something" > /dev/input/mice
-
Hi Misalf
I take back my previous statement. The machine I was referring to is running Xvesa, though I do recall someone else mentioning
they saw it under Xorg.
Would something like this be possible? Maybe via ~/.X.d/ .
sudo echo "something" > /dev/input/mice
Don't know if you could get that to work. Here's something which does seem to fix it though:
#include <stdio.h>
#include <unistd.h>
#include <linux/input.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <string.h>
// Compile using:
// gcc -march=i486 -mtune=i686 -Os -s -pipe -Wall mousemove.c -o mousemove
// Run using:
// sudo mousemove `cat /proc/bus/input/devices | grep mouse | grep event | awk '{ print $3 }'`
int main(int argc, char *argv[])
{
struct input_event event, event_end;
char mouse[256]="/dev/input/";
int i;
if(argc < 2)
{
printf("Mouse event required, i.e. event3\n");
return(-1);
}
strcat(mouse, argv[1]);
int fd=open(mouse, O_RDWR);
if (fd < 0)
{
printf("Error opening mouse:%s\nCould not open %s\n", strerror(errno), mouse);
return(-1);
}
memset(&event, 0, sizeof(event));
memset(&event, 0, sizeof(event_end));
gettimeofday(&event.time, NULL);
event.type=EV_REL;
event.code=REL_X;
event.value=50;
gettimeofday(&event_end.time, NULL);
event_end.type=EV_SYN;
event_end.code=SYN_REPORT;
event_end.value=0;
for (i=0; i < 10; i++)
{
write(fd, &event, sizeof(event));// Move the mouse
write(fd, &event_end, sizeof(event_end));// Show move
usleep(50000);// wait
}
close(fd);
return 0;
}
Compile the program and place the mousemove executable in ~/.local/bin
Create a file called mousemove in ~/.X.d with the following contents:
sudo mousemove `cat /proc/bus/input/devices | grep mouse | grep event | awk '{ print $3 }'`My scripting skills are lacking so there's probably a better way of implementing the above command.
-
Rich, you're awesome!
-
Hi Misalf
There was an error in the code I posted. It's been corrected.
-
I'm quite happy seeing Rich progressing with coding skills :)
That's a tad hacky though, given we do have the server source, and it's not half as bad to build compared to the old Xfree86 one.
Anyone having this issue, please test the new tinyX extensions posted at
http://tinycorelinux.net/~curaga
-
Hi curaga
That's a tad hacky though, ...
In what sense? The code itself, the cat/grep/awk command, that it's external to the server code ... ?
I can't learn anything without details. ;D
-
Confirming with tinyX there is no "mouse hanging".
-
Just did a remaster with the new Xvesa.tcz from curaga and no more mouse hanging after X starts.
Thanks a lot.
-
I'll wait a week for other confirmations before moving these to the main repo. Thanks for testing.
That's a tad hacky though, ...
In what sense? The code itself, the cat/grep/awk command, that it's external to the server code ... ?
I can't learn anything without details. ;D
In that it's a separate app to wiggle the mouse. The code is not bad (buffer overflow risk with the strcat), and you shouldn't use cat in pipes, as it's inefficient to launch a separate program when grep/awk can read files directly.
The pipe chain can also be done entirely in awk: awk '{ if (/mouse/ && /event/) print $3 }' < /proc/bus/input/devices
-
Hi curaga
True, I probably should have used strncat. I'm afraid my scripting skills will probably always be lacking as I don't often
use them. Usually the punctuation trips me up i.e. {}()"'`$ and so on. The awk syntax I actually lifted from something gerald_clark
post a while back.