Powersave & Xhost Issues

Hello all,

I've got two issues I'd like to get help on, and although they are somewhat related to the KDE desktop, I figured they are more of a X server issue than actual Desktop.

First:
When I installed SuSE 9.2 on one of my machines, I selected to run with KDE and it's default options for the ease of the other people who will be interfacing with this particular machine.
It seems that SuSE installs and automatically configures the X server to boot into KDE with the following:

X -nolisten tcp...

I'm trying to figure out how to disable that -nolisten tcp option because I have a remote system that sends a graphical display to my system via xhost.
The only way I could get around it was to try and use different versions of xdm, gdm, etc. Basically, I just need the system to be able to allow remote listening on what I believe is port 6000 via the xhost function.

Second:
Powersaving mode. Really annoying. After rebooting, I'm having the screen blank out on me. To get around this, I use the following command:

xset -dpms

However, I'd like to just disable powersaving in general. There is no need for it on this system.
I've looked through YaST, and found some powersaving options, but they don't seem to solve the issue. When I run a ps aux, I see that it automatically loads the powersaving scripts when it boots up.
Where can I disable this or how do I find the options for which startup scripts to NOT execute?

Any help is greatly appreciated.
Thanks.

just out of curiosity, are you running such an old version for hardware reasons?(old system) support, repos, would be almost non-existent.
If not, I would suggest to download a newer version.

just out of curiosity, are you running such an old version for hardware reasons?(old system) support, repos, would be almost non-existent.
If not, I would suggest to download a newer version.
[/b]

Well, I'm using 9.2 for a couple of reasons. Main reason is I work offshore, and we are out here for 5 weeks at a time. I didn't bring my copy of OpenSuSE with me from home, but I had 9.2 with me.
9.2 works well enough, and I'm not able to download a newer distro because we are on a sat connection and it is just way too slow to do that. Plus being on a moving ship at sea doesn't usually give us the most stable connection for long downloads.

At any rate, I have 9.2 running on a few old systems at home as well, and it has been stable enough for what they are used for. The machine I installed it on out here is a few years old... an HP desktop. And it's only going to be used for this display that I mentioned.

First:
When I installed SuSE 9.2 on one of my machines, I selected to run with KDE and it's default options for the ease of the other people who will be interfacing with this particular machine.
It seems that SuSE installs and automatically configures the X server to boot into KDE with the following:

X -nolisten tcp...

I'm trying to figure out how to disable that -nolisten tcp option because I have a remote system that sends a graphical display to my system via xhost.
The only way I could get around it was to try and use different versions of xdm, gdm, etc. Basically, I just need the system to be able to allow remote listening on what I believe is port 6000 via the xhost function.

[/b]

I used that earlier, but I can not find the documentation about how I did it. Have to go from my aging memory. You could try /etc/X11/xdm/xdm-config, look at the end. And also read /etc/X11/xdm/README.security. There it says that port 177 is the default, so maybe you should change the 0 into 6000 in /etc/X11/xdm/xdm-config instead of commenting it out.

Also grep XDMCP /etc/X11/xdm* gives more clues inside that directory.

Happy testing.

As it is KDE I may be wrong but in /opt/kde3/share/config/kdm/kdmrc I presume changing this would also achieve it. Or may be the correct way unsure whether the kde environment would over ride the other way.

ServerArgsLocal=-nolisten tcp

xset -dpms[/b]

this is long standing bug that I submitted for suse 10.0 Seems that it is not important for maintainers.
I got this working, but don't remember the resolution. You may need to search Novell's bugzilla as I posted steps required to fix this.
As far as I know, this should provide you with the general idea how to proceed as some options (depending of suse setup) should be turned on or off.

this is long standing bug that I submitted for suse 10.0 Seems that it is not important for maintainers.
I got this working, but don't remember the resolution. You may need to search Novell's bugzilla as I posted steps required to fix this.
As far as I know, this should provide you with the general idea how to proceed as some options (depending of suse setup) should be turned on or off.
[/b]

Well, the xset -dpms command actually works fine. It's just that I have to manually type it in each time the machine reboots and restarts the desktop.
So basically, what I'm doing is leaving a terminal window open, but minimized, on the second desktop so that each time the desktop restarts, it will automatically execute the commands I've put into the .bashrc file.
This seems to work fine for now. It's not the desired 'fix' I'd like to have, but it is what it is I guess.
Especially since I went back to the kdm now that I've 'solved' the issue with the xhost stuff.

Which brings me to the second part.
I switched back to kdm because I need to have the system boot, then auto-login a specific user each time. This is all to limit the 'oops' factor from the people who will be interfacing with this machine... notice I said 'interfacing' and not 'using'. I cannot trust them as they are not very computer literate much less Linux friendly.

I found a few options in YaST which allowed me to open up the listening on tcp for the X server, which basically got rid of that whole nasty -nolisten tcp debacle.

This should all hold well enough until I can return with a newer version of SuSE. I usually use Gentoo for systems like this, especially since they are so bare in actual terms of usage. It's really just a dumb terminal with a ported graphics program from another node. But again, because of limited connectivity out here, installing portage over this satellite connection really isn't an option.

Thanks for the replies/help.