I'm running KDE under SuSE 10.0. Sometimes when I've left the computer running for a while by itself and the screen saver comes on, I come back and discover that there's no mouse cursor. I don't see any pattern to when it happens and when it doesn't. So-- 1. Is there anything I can do less drastic than Ctl-Alt-Bksp (which works) to get the cursor back? It clearly must be something that I can do from the keyboard alone. 2. What is likely to be causing the problem? Paul
On Saturday 26 August 2006 10:43, Paul Abrahams wrote:
I'm running KDE under SuSE 10.0. Sometimes when I've left the computer running for a while by itself and the screen saver comes on, I come back and discover that there's no mouse cursor. I don't see any pattern to when it happens and when it doesn't. So--
1. Is there anything I can do less drastic than Ctl-Alt-Bksp (which works) to get the cursor back? It clearly must be something that I can do from the keyboard alone.
2. What is likely to be causing the problem?
Hi Paul, First, I'd check for a conflict between two screensavers. I seem to recall once having two installed and activated by default at the same time. Disabling, then uninstalling the redundant package solved my problem. Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should get you to a console where you can login as root, then 'init 3' to drop to runlevel 3, 'Enter' to get your prompt back and 'init 5 && exit' to logout root and log back into your desktop. hth & regards, Carl
On Saturday 26 August 2006 10:59 am, Carl Hartung wrote:
On Saturday 26 August 2006 10:43, Paul Abrahams wrote:
I'm running KDE under SuSE 10.0. Sometimes when I've left the computer running for a while by itself and the screen saver comes on, I come back and discover that there's no mouse cursor. I don't see any pattern to when it happens and when it doesn't. So--
1. Is there anything I can do less drastic than Ctl-Alt-Bksp (which works) to get the cursor back? It clearly must be something that I can do from the keyboard alone.
2. What is likely to be causing the problem?
First, I'd check for a conflict between two screensavers. I seem to recall once having two installed and activated by default at the same time. Disabling, then uninstalling the redundant package solved my problem.
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should get you to a console where you can login as root, then 'init 3' to drop to runlevel 3, 'Enter' to get your prompt back and 'init 5 && exit' to logout root and log back into your desktop.
I don't think I have two screensavers going. I'll try the "init 3" trick next time I lose the cursor, since I expect no trouble in getting to another console. Paul
On Saturday 26 August 2006 11:16, Paul Abrahams wrote:
I don't think I have two screensavers going.
I think the conflict I had was between xscreensaver and gnome-screensaver... both had been installed and enabled by default at installation. It's easy enough to check, of course: carl@linux:~> ps ax | grep saver 5287 ? Ss 0:26 gnome-screensaver
I'll try the "init 3" trick next time I lose the cursor, since I expect no trouble in getting to another console.
Tip: If the only time you're having trouble with your mouse (pointer gone) is when the screensaver activates, you can always try switching from one screensaver program to another. In my case, I disabled and uninstalled xscreensaver and configured gnome-screensaver to my tastes. I could just as easily have done the reverse if gnome-screensaver wasn't working correctly with my hardware. Carl
On Saturday 26 August 2006 10:59, Carl Hartung wrote:
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should get you to a console where you can login as root, then 'init 3' to drop to runlevel 3, 'Enter' to get your prompt back and 'init 5 && exit' to logout root and log back into your desktop.
A much lengthier process than just ctl-alt-bksp since you're killing the X session anyway. I was going to suggest just doing ctl-alt-f(n) to get to a console and then immediately doing alt-F7 to get back into X. It *might* cure the problem.
On Saturday 26 August 2006 11:52, Bruce Marshall wrote:
On Saturday 26 August 2006 10:59, Carl Hartung wrote:
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should get you to a console where you can login as root, then 'init 3' to drop to runlevel 3, 'Enter' to get your prompt back and 'init 5 && exit' to logout root and log back into your desktop.
A much lengthier process than just ctl-alt-bksp since you're killing the X session anyway.
'Ctl-Alt-Bksp' kills X (crashes it) without closing it down in an orderly fashion. It's a useful 'escape hatch' (sometimes) when your desktop locks up, but I wouldn't recommend it's overuse on a regular basis. ;-)
I was going to suggest just doing ctl-alt-f(n) to get to a console and then immediately doing alt-F7 to get back into X. It *might* cure the problem.
Switching to a console and back again is a great suggestion... just to see if it 'nudges' the mouse loose... and is definitely worth a try. Carl
On Saturday 26 August 2006 11:10, Carl Hartung wrote:
On Saturday 26 August 2006 11:52, Bruce Marshall wrote: 'Ctl-Alt-Bksp' kills X (crashes it) without closing it down in an orderly fashion. It's a useful 'escape hatch' (sometimes) when your desktop locks up, but I wouldn't recommend it's overuse on a regular basis. ;-)
Very sage advice.
I was going to suggest just doing ctl-alt-f(n) to get to a console and then immediately doing alt-F7 to get back into X. It *might* cure the problem.
Switching to a console and back again is a great suggestion... just to see if it 'nudges' the mouse loose... and is definitely worth a try.
Carl
Also learn the keyboard shortcuts to activate the main menu, ALT+F1, and navigate to YaST, Hardware, Mouse, Test. See if that'll resurrect that recalcitrant rodent. Stan
On Saturday 26 August 2006 15:34, Stan Glasoe wrote:
On Saturday 26 August 2006 11:10, Carl Hartung wrote:
On Saturday 26 August 2006 11:52, Bruce Marshall wrote: 'Ctl-Alt-Bksp' kills X (crashes it) without closing it down in an orderly fashion. It's a useful 'escape hatch' (sometimes) when your desktop locks up, but I wouldn't recommend it's overuse on a regular basis. ;-)
Very sage advice.
I was going to suggest just doing ctl-alt-f(n) to get to a console and then immediately doing alt-F7 to get back into X. It *might* cure the problem.
Switching to a console and back again is a great suggestion... just to see if it 'nudges' the mouse loose... and is definitely worth a try.
Carl
Also learn the keyboard shortcuts to activate the main menu, ALT+F1, and navigate to YaST, Hardware, Mouse, Test. See if that'll resurrect that recalcitrant rodent.
Thank you, Stan! I regularly 'drive' by keyboard but could *not* for the life of me remember how to pull up the desktop main menu! I'd have mentioned it, otherwise, as it's very convenient. :-) regards, Carl
Le samedi 26 août 2006 16:06, Carl Hartung a écrit :
On Saturday 26 August 2006 15:34, Stan Glasoe wrote:
On Saturday 26 August 2006 11:10, Carl Hartung wrote:
On Saturday 26 August 2006 11:52, Bruce Marshall wrote: 'Ctl-Alt-Bksp' kills X (crashes it) without closing it down in an orderly fashion. It's a useful 'escape hatch' (sometimes) when your desktop locks up, but I wouldn't recommend it's overuse on a regular basis. ;-)
Very sage advice.
I was going to suggest just doing ctl-alt-f(n) to get to a console and then immediately doing alt-F7 to get back into X. It *might* cure the problem.
Switching to a console and back again is a great suggestion... just to see if it 'nudges' the mouse loose... and is definitely worth a try.
Carl
Also learn the keyboard shortcuts to activate the main menu, ALT+F1, and navigate to YaST, Hardware, Mouse, Test. See if that'll resurrect that recalcitrant rodent.
Thank you, Stan!
I regularly 'drive' by keyboard but could *not* for the life of me remember how to pull up the desktop main menu! I'd have mentioned it, otherwise, as it's very convenient. :-)
regards,
Carl
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of xorg.conf never get this problem since
On Saturday 26 August 2006 4:30 pm, Marc Collin wrote:
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of > xorg.conf
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line. Paul
On Saturday 26 August 2006 13:06, Paul Abrahams wrote:
On Saturday 26 August 2006 4:30 pm, Marc Collin wrote:
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of
xorg.conf
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line.
Paul
So edit it anyway. It was not that long ago this was all done by hand. I use sax to get the big stuff about monitor, etc, and then I tweak by hand to handle extra mouse buttons and such. -- _____________________________________ John Andersen
On Saturday 26 August 2006 13:10, John Andersen wrote:
On Saturday 26 August 2006 13:06, Paul Abrahams wrote:
On Saturday 26 August 2006 4:30 pm, Marc Collin wrote:
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of
xorg.conf
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line.
Paul
So edit it anyway.
Oh, I forgot the obligatory bit about making a backup, etc, etc.. -- _____________________________________ John Andersen
On Saturday 26 August 2006 5:10 pm, John Andersen wrote:
On Saturday 26 August 2006 13:06, Paul Abrahams wrote:
On Saturday 26 August 2006 4:30 pm, Marc Collin wrote:
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of
xorg.conf
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line.
Paul
So edit it anyway.
It was not that long ago this was all done by hand. I use sax to get the big stuff about monitor, etc, and then I tweak by hand to handle extra mouse buttons and such.
My concern is that the next time I call Sax the changes will get lost unless I remember to reinstall them. Paul
On Saturday 26 August 2006 16:15, Paul Abrahams wrote:
On Saturday 26 August 2006 5:10 pm, John Andersen wrote:
So edit it anyway.
It was not that long ago this was all done by hand. I use sax to get the big stuff about monitor, etc, and then I tweak by hand to handle extra mouse buttons and such.
My concern is that the next time I call Sax the changes will get lost unless I remember to reinstall them.
Paul
Usually SaX will keep your changes but, wait for it, make a backup of your changes anyway. Updating anything related to Xorg via YaST/Smart/Apt/etc may wipe out your changes at a later time. Then again, it might not. I've had all of the above happen to me since SUSE 7.3 with the same hardware setup. Preserve that xorg.conf especially when going from/to any version of SUSE such as from 10.1 to 10.2. Stan
On Saturday 26 August 2006 5:49 pm, Stan Glasoe wrote:
Usually SaX will keep your changes but, wait for it, make a backup of your changes anyway. Updating anything related to Xorg via YaST/Smart/Apt/etc may wipe out your changes at a later time. Then again, it might not. I've had all of the above happen to me since SUSE 7.3 with the same hardware setup.
Preserve that xorg.conf especially when going from/to any version of SUSE such as from 10.1 to 10.2.
Backup doesn't solve the problem I'm referring to. The problem is not losing the original xorg.conf; it's not having changes carried over. If SaX changes xorg.conf, I want the SaX changes -- but I also want my own changes to be integrated with them. If I can make the changes through SaX, then that's less of a concern since I know that SaX understands the file. The underlying question is whether SaX constructs a new xorg.conf by referring to the old one or by referring to some database of its own. If the former, I'm probably OK since I imagine that SaX simply retains any lines it's not fiddling with or doesn't understand. But if the latter, then my changes get lost. Paul
On Saturday 26 August 2006 17:58, Paul Abrahams wrote:
Backup doesn't solve the problem I'm referring to. The problem is not losing the original xorg.conf; it's not having changes carried over. If SaX changes xorg.conf, I want the SaX changes -- but I also want my own changes to be integrated with them. If I can make the changes through SaX, then that's less of a concern since I know that SaX understands the file.
<rant> Seems to me that if you can't make a note to yourself as to what you've done to the file, for future reference as well as problem solving, then you shouldn't make *any* change to any file. My gosh.... keeping notes about one's system is the first priority unless you are a totally hands off user. In which case, you wouldn't be diddling with Sax2. </rant>
On Saturday 26 August 2006 16:58, Paul Abrahams wrote:
The underlying question is whether SaX constructs a new xorg.conf by referring to the old one or by referring to some database of its own. If the former, I'm probably OK since I imagine that SaX simply retains any lines it's not fiddling with or doesn't understand.
Yes, from within YaST or from the init 3 command line without the -a or -r command line switches.
But if the latter, then my changes get lost.
Yes from init 3 and command line switches to reinitialize your setup. Or updates from one release to another; ie 10.1 to 10.2.
Paul
SaX can do both methods of changing xorg.conf that you describe. The drastic way has to be done via command line or during a fresh install/update. The traditional method of working with SaX has been to log out of your window manager. Switch to a console screen, Alt+Ctrl+F1-F6. Login as root and do an 'init 3' to stop X altogther. Run sax2 and use whatever command line switches you may need, if any. Make your changes if possible through SaX. If not, use everyone's favorite editor, vi, to make changes to xorg.conf. Then 'init 5' to restart X and see if all is well. Preserve your copies of xorg.conf to your home directory where SaX won't find them. Stan
On Saturday 26 August 2006 17:06, Paul Abrahams wrote:
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line.
Do you always do as your told?? :-)
On Aug 26, 06 17:06:45 -0400, Paul Abrahams wrote:
On Saturday 26 August 2006 4:30 pm, Marc Collin wrote:
there are a couple of month i had this problem somebody said me to add Option "HWCursor" "true" in the device section of > xorg.conf
You probably mean Option "HWCursor" "false" True is default. If this helps, please create a bug report.
A little problem there. The header of xorg.conf says that the file should not be edited because it's generated by Sax. But I can't find anyplace within Sax (called from Yast, anyway) to insert such an option line.
You can always edit it, it might just be that the option is removed
again if you happen to call sax2 once more.
In this particular case it shouldn't.
Matthias
--
Matthias Hopf
On Sunday 27 August 2006 15:48, Jan Engelhardt wrote:
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should
CAB does not "crash" X, it is a legitimate shortcut to kill it. Read xorg.conf manpage.
Jan, Yes it is a legitimate "shortcut to kill it" but that is *not* the same as undertaking a proper logout/restart, is it? Doesn't it just dump you at a command prompt at runlevel 5? Carl
Carl Hartung wrote:
On Sunday 27 August 2006 15:48, Jan Engelhardt wrote:
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should CAB does not "crash" X, it is a legitimate shortcut to kill it. Read xorg.conf manpage.
Jan,
Yes it is a legitimate "shortcut to kill it" but that is *not* the same as undertaking a proper logout/restart, is it? Doesn't it just dump you at a command prompt at runlevel 5?
It takes me to the login screen.
On Sunday 27 August 2006 17:34, James Knott wrote:
Carl Hartung wrote:
On Sunday 27 August 2006 15:48, Jan Engelhardt wrote:
Also, if 'Ctl-Alt-Bksp' successfully crashes X, 'Ctl-Atl-Fn(1 thru6)' should
CAB does not "crash" X, it is a legitimate shortcut to kill it. Read xorg.conf manpage.
Jan,
Yes it is a legitimate "shortcut to kill it" but that is *not* the same as undertaking a proper logout/restart, is it? Doesn't it just dump you at a command prompt at runlevel 5?
It takes me to the login screen.
I haven't had to use it in a long time so maybe my recollection is outdated (or fuzzy?.) I /do/ distinctly remember a time when it was considered, at a minimum, to be a fairly 'inelegant' way to exit (restart?) X. Did you try it with any programs or files open? Did it save your desktop on exit? Carl
CAB does not "crash" X, it is a legitimate shortcut to kill it. Read xorg.conf manpage.
Yes it is a legitimate "shortcut to kill it" but that is *not* the same as undertaking a proper logout/restart, is it? Doesn't it just dump you at a command prompt at runlevel 5?
It takes me to the login screen.
I haven't had to use it in a long time so maybe my recollection is outdated (or fuzzy?.) I /do/ distinctly remember a time when it was considered, at a minimum, to be a fairly 'inelegant' way to exit (restart?) X. Did you try it with any programs or files open? Did it save your desktop on exit?
It kills the X server (as in kill(2)), and ?dm then restarts it, effectively bringing you back to the login screen, if there was one. In case of startx, well, you don't run ?dm and therefore X will not restart. Jan Engelhardt --
participants (9)
-
Bruce Marshall -
Carl Hartung -
James Knott -
Jan Engelhardt -
John Andersen -
Marc Collin -
Matthias Hopf -
Paul Abrahams -
Stan Glasoe