Issues with xset

[fault-tolerant]

Did anyone experience strange behavior of xset? I had it working fine in Ubuntu x86 embedded device once, now trying to get same operation in piCore 7.0 on Raspberry Pi 2 B.

When I place xset commands like "xset -dpms s off" or "xset +fp ..." in my .xsession or other starting script files ran from it, I can see the screen flickering, the background disappears for some reason, and there's no actual effect (checking by running "xset q" later). Same if I run it with a "sleep" of several seconds. But if I run it manually in the terminal after the Xorg loads, it works fine...

Didn't find anything problematic in the X log, tried setting the xset stderror output to a file and nothing's there. Can't figure out what's wrong with it.

[fault-tolerant]

It would be helpful if anyone could just confirm that the problem exists by simply running, say, xset -dpms s off in xsession after the background is loaded (and/or manually) to check if it kicks the background off, and whether it has any effect afterwards on DPMS and screensaver settings (check with xset q).
For me it happens whether the window manager is running or not.
Thanks.

[Misalf]

I don't have a RPi but I have seen inconsistencies regarding xset on x86.
In my case, xset wasn't always able to set the keyboard auto-repeat delay/interval, regardless of how long I let it sleep.
The only solution I found to always work, is to alter Xorg's command options directly in .xsession:

Code: [Select]

/usr/local/bin/Xorg -ardelay 250 -arinterval 40 -nolisten tcp &
Which, in your case, might result in something like this:

Code: [Select]

/usr/local/bin/Xorg -dpms -s off -nolisten tcp &
[untested]

[fault-tolerant]

Thanks for sharing your experience.
Actually, I've put the commands in a .conf file, to at least disable the default screensaver, and the server gets them on startup. Still, in my case the main java GUI application (in a kiosk-type project) should be able to set these values on the fly per user settings made through the app.
If we can define the problem, we may be able to fix it as well.

Sent from my SM-G920F using Tapatalk

[Misalf]

Maybe you can get different results by using either
/usr/bin/xset  from  Xlibs.tcz
or
/usr/local/bin/xset  from  Xorg-7.7-bin.tcz
?

[fault-tolerant]

Nice idea, @Misalf, didn't think of that. Nevertheless, the result is still the same.
I actually blame the Xorg server and not the xset tool, since the same tool works fine when started manually later on. Any sense in that?

Sent from my SM-G920F using Tapatalk

[Rich]

Hi fault-tolerant
Have you tried placing you  xset  command in a file. Then save that file to the  ~/.X.d  directory?

[fault-tolerant]

Tried that now, Rich, same result - background is gone, the settings were not actually set. This is practically the same thing, although "the right way" to do that, while I was just putting the command in to the .xsession file directly, since the files in .X.d directory are executed by the same .xsession file.
Did I mention I also notice screen blanking when the command executes? Like the x server is restarted or something...


Sent from my SM-G920F using Tapatalk

[xpector]

Nice idea, @Misalf, didn't think of that. Nevertheless, the result is still the same.
I actually blame the Xorg server and not the xset tool, since the same tool works fine when started manually later on. Any sense in that?

Sent from my SM-G920F using Tapatalk

I got the same problem. Here, too, xset -dpms works if I run it manually later on. I wonder if and how you solve it. I'm going to try background script called from /opt/bootlocal.sh with a big delay and than xset commands.

[fault-tolerant]

@xpector, I should have updated this post, you're right. My solution was not the most elegant, but it got things running. In this project I've had a Java app starting at the last stage, and I made it run xset, like xset -dpms s off and/or xset dpms force off or something like that, maybe with a delay, I don't remember.
If you solve it in other way, please post your solution here for others. Thanks.

[xpector]

In my case, it helped to place a script in ~/.X.d which repeats xset -dpms every minute
http://forum.tinycorelinux.net/index.php/topic,21794.msg136406.html#msg136406

Interestingly, I only had this trouble on older boards that, by coincidence, have faster SD cards. Maybe I just had some luck with timing on newer boards with slower cards. Got no time for cross-checks, unfortunately.