Here's a workaround ...

[dave@hodgins ~]$ cat .kde4/Autostart/noblank 
#!/bin/bash
/home/dave/bin/noblank &

[dave@hodgins ~]$ cat /home/dave/bin/noblank 
#!/bin/bash
sleep 60
xset s 0 0
xset s noblank
xset s off
xset dpms 0 0 0

Make sure both scripts are marked executable.  The sleep 60 is to allow kde
to do whatever it's going to do, and then override the settings.

CC: (none) => davidwhodgins

Option "DPMS" "false" 
in xorg.conf works here.

It may be better if Mageia has an option to set it up without any DE/WM options.

Too much advanced options would make XFdrake GUI harder to read/use.
And this is not a xserver bug, such options are usually handled by the desktop (KDE, GNOME, ...).
What desktop do you use?

CC: (none) => thierry.vignaud
Source RPM: x11-server-1.10.1-1.mga1.src.rpm => (none)

I'm using LXDE and WindowMaker. I don't remember any options referring to DPMS in GNOME. 

DPMS is built in X window, There are several option to change behavior (for example - http://www.mythtv.org/wiki/DPMS ), 

Custom script was mentioned incomment 1.

I was trying 

Section Monitor
       ...
       Option "DPMS"
       ...
EndSection
[...]
Section "ServerFlags"
       ...
      Option  "StandbyTime"   "1"
      Option  "SuspendTime"   "2"
      Option  "OffTime"       "3"
       ...
EndSection

and simple 'Option "DPMS" "false"'. It didn't work.

Finally
$ xset -dpms
and it works.

The question: is Mageia going to do something to help users to watch movie on Mageia boxes? BTW, Mageia bugzilla doesn't have an option to enhance a package or add an option. 

I'm looking xorg.conf 

[...]
# File generated by XFdrake (rev 262502)
[...]
Section "Device"
    Identifier "device1"
    VendorName "ATI Technologies Inc"
    BoardName "ATI Radeon HD 2000 and later (radeon/fglrx)"
    Driver "ati"
    BusID "PCI:2:0:0"
    Option "DPMS"
EndSection
[...]

I don't remember about being asked about 'Option "DPMS"' included there. There could be another option included as well.

Set version to cauldron:
https://wiki.mageia.org/en/Triage_guide#Enhancement_requests

Version: 1 => Cauldron

(In reply to comment #3)
> Too much advanced options would make XFdrake GUI harder to read/use.
> And this is not a xserver bug, such options are usually handled by the desktop
> (KDE, GNOME, ...).
> What desktop do you use?

(In reply to comment #4)
> I'm using LXDE and WindowMaker. I don't remember any options referring to DPMS
> in GNOME. 
> 


Assigning to LXDE maintainer

@ Oliver

Please assign back and explain if you think I'm wrong to assign to you.

Assignee: bugsquad => oliver.bgr
CC: (none) => marja11

As I remember there is no option to change X setting in GNOME. It doesn't sound like a good idea to force LXDE do it.

The original purpose of the bug was to create something that doesn't shut down X windows in 15 min. 

Shut it down in two hours instead.

Well, there could be more people against it if Mageia does it.

I'm not sure lxde offers something in this respect as KDE/GNOME do.

And most simple window managers won't.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Anyone who can confirm this bug is still valid ?

Roelof

CC: (none) => r.wobben

Of course this bug is still valid.
Probably in all Mageias, so far!

Here...
 http://www.mageia-gr.org/forum/viewtopic.php?f=7&t=318
in the greek forum we had a conversation about it.

Can we say that most users find this "smart" function annoying?
And that it, most likely, is an old feature that has very little use, nowadays?

A quick workaround is this...

Check...
   xset q
   
It will tell you your X settings.
It will probably look like this...
...
  Screen Saver:
    prefer blanking:  yes    allow exposures:  yes
    timeout:  600    cycle:  600
...

Change that, with this...
   xset s SECONDS_FOR_TIMEOUT SECONDS_FOR_CYCLE
   
I've set mine to 1hour...
   xset s 3600 3600
   
and made it execute everytime I log into IceWM
~/.icewm/startup


----

You could easily fix this bug by increasing the default time 
it takes X to go to screensaver... as others already mentioned.
From 10 minutes (600 sec) to NO LESS than half an hour (1800 sec)
(for me, 1 hour is even better).

Is this something Mageia can do or is it up to the developers of X?

CC: (none) => 231036448

(In reply to nikos papadopoulos from comment #11)

Thanks for the instructions on how to change the settings with xset, Nikos :)

If the default time until the screen turns off is increased, others will complain:
* Some want to keep their power bills as low as possible
* Others are all for the environment and being good stewards for the earth's ressources
* and, of course, for laptops many will prefer the screen to dim and then be turned off, when there is no activity for a while..... batteries always get empty too fast.

I propose to change this bug into a request to package (or create) a frontend for xset.

Is there an existing and still maintained tool? All I found is gxset, but that is dead.

Source RPM: drakx-kbd-mouse-x11 => (none)
Keywords: NEEDINFO => (none)

(In reply to Marja van Waes from comment #12)
> If the default time until the screen turns off is increased, others will
> complain:
I don't think so.
Because they can, easily, adjust any power manager to blank the screen,
or use a program like xscreensaver
(If they have in mind what you describe, then they MUST, already, use a power manager).

What you can NOT do, is use a program to prevent the screen from going black every ten minutes.
Of course, you propose to create such a program.
But that solution doesn't take in consideration the fact that Mageia's resources are limited.
Someone has to wonder... How much time will it take, for a developer, to create such an application...
In other words... this proposal will never materialize.

This is the reason I proposed an easy fix (although not perfect)
that would only take a few minutes to implement.

----
And why from 10 minutes to 30 minutes, and not 1 or 2 hours?

As I have already said, I can only understand this "smart", forced, blanking of the screen 
as a forgotten feature from the past.

It must have to do with how people used their computers,
and what hardware they had.
(Screen savers where invented to protect the early monitors.
And those days, noone would watch a 2 hour long video online, in something like Youtube).

But, still, this "feature" might have some unknown use for someone.
So I proposed a compromising solution of just 30 minutes.

And then see how it goes.
If people complain, and for what reason, then adjust (most likely, increase the time) 
or come up with a different solution.

----
By the way...
in the time it took us to write these comments,
a developer would have already made the "quick fix", ten times. ;)

And I am saying "fix", because this "smart feature" is a "malfunction".
Having to click on your keyboard every ten minutes is nothing but an annoyance.

Recent example: while I was writing bug report, X was off on installation I was writing about. Not a big deal on the same computer. More inconvinient to watch a long movie on big screen TV constantly pressing keyboard bottons.

(In reply to nikos papadopoulos from comment #11)
> 
> A quick workaround is this...
>    
> I've set mine to 1hour...
>    xset s 3600 3600

It turns out that the above "solution" only works for my Mageia 3 computer.

In my Mageia 4 computer I have to disable DPMS, altogether.
So, the "solution" would be...
   xset -dpms

As Marja suggested, the real solution is a gui application to change the screen blanking timeout for the lighter desktops that don't offer this feature.
Better, a similar application that takes into account the type of function running.
The current default timeout is entirely appropriate, for the vast majority of functions on a computer.  (Most will probably never watch a long movie on their computer.)

The easiest workaround is to simply move the mouse every few minutes if watching a long movie.  As you said, "Having to click on your keyboard every ten minutes is nothing but an annoyance."  Certainly not onerous.

CC: (none) => andre999mga

(In reply to andré blais from comment #16)
> (Most will probably never watch a long movie on
> their computer.)
Hmmm, I wonder... all those MILLIONS of views on documentaries, on youtube.
Are they fake, or something?  ;)
(http://www.youtube.com/results?search_sort=video_view_count&search_query=documentary)


> The easiest workaround is to simply move the mouse every few minutes if
> watching a long movie.  As you said, "Having to click on your keyboard every
> ten minutes is nothing but an annoyance."  Certainly not onerous.
Do you clap your hands every 15 minutes, so that the lights, in your home, don't go out?
Do you turn the nob of your radio, every 15 minutes, so that it can go on playing?

(In reply to nikos papadopoulos from comment #17)
I do agree that it is an annoyance, just differ on the appropriate solution.

> (In reply to andré blais from comment #16)
> > (Most will probably never watch a long movie on
> > their computer.)
> Hmmm, I wonder... all those MILLIONS of views on documentaries, on youtube.
> Are they fake, or something?  ;)
> (http://www.youtube.com/
> results?search_sort=video_view_count&search_query=documentary)

Considering that there are 100's of millions on the internet, and I suspect that many documentary viewers tend to watch many, that indicates a not very large portion.
My timeout is set to 5 minutes, and I do sometimes (rarely) have to move the mouse on the videos I view.  I must admit I'm always fiddling with something, so it might as well be my mouse.

> > The easiest workaround is to simply move the mouse every few minutes if
> > watching a long movie.  As you said, "Having to click on your keyboard every
> > ten minutes is nothing but an annoyance."  Certainly not onerous.
> Do you clap your hands every 15 minutes, so that the lights, in your home,
> don't go out?
> Do you turn the nob of your radio, every 15 minutes, so that it can go on
> playing?

Actually, I'm usually too busy tapping on my keyboard ;)

Seriously, I think a gui application to allow setting the timeout is the solution.  Note that the vast majority of Linux users already have that through their desktop.  (Gnome, KDE, Mate, probably XFCE, among others.)
It is the lighter desktops that lack this function.
Since most users will never change the default unless they need to, the current default is best kept.

(In reply to andré blais from comment #18)
> Considering ...
>
> My timeout ....
> 
> Since most users...
Sorry, but I can't follow your "logic" in any of the above.
Are you trolling, or something?
You "got me" there for a moment...


> Seriously, I think a gui application to allow setting the timeout is the
> solution.  
Yeap... if we repeat the same argument 50 times... that will prove it "right".
Now... let us start a "flame war"...
(not really) 

> Note that the vast majority of Linux users already have that
> through their desktop.  (Gnome, KDE, Mate, probably XFCE, among others.)
Have you actually test that, or are you just guessing?

By the way... quoting from xset manual
(http://www.xfree86.org/4.0/xset.1.html)

> Note that NOT all X implementations are guaranteed to honor all of these options. 

As I have already said, the " xset s " option is being ignored in my Mageia 4 system.

(In reply to nikos papadopoulos from comment #19)
> (In reply to andré blais from comment #18)
> > Note that the vast majority of Linux users already have that
> > through their desktop.  (Gnome, KDE, Mate, probably XFCE, among others.)
> Have you actually test that, or are you just guessing?

I've tested the gui for Gnome + Mate + XFCE (an older version), and I've seen numerous reports for KDE.
I am assuming that those desktops represent the vast majority of desktop linux users.

I haven't looked at xset before.  But it is installed on my system, and required (and successfully used) by the Mate and Gnome desktops.  But not by my currently partially installed XFCE.
Also there is an additional executable to enable using it for KDE, so KDE might use something else by default.

What desktop are you using ?
Also, did you try
 xset s 3600
without the second value ? (which is the period to change screensaver images)
If that works (you can use a much shorter period to test), then setting
 xset s blank
will give you a blank screen instead of whatever screensaver image.
Or you can continue disabling screensaver functions with
 xset -DPMS
if you prefer.

You could also re-enable the screensaver functions when not watching movies by
 xset +DPMS
With that approach, maybe you have no need to change the default timeout.

I am using IceWM, and I used to have XFCE's power manager running with that.
Either way, with, or without the power manager, the problem is there.
And I have already found a "solution" that works for me.

But, here, we are not in a forum, trying to help someone find a solution to his problem.
And certainly, this bug is not about me (or you).
It's about the user of Mageia that shouldn't have to have his screen go blank by force.
And shouldn't waist his time, trying all sorts of different "solution" to a problem that shouldn't have been there, in the first place!!!

-------------
More on xset...
In my Mageia 4, setting...
   xset +dpms
   xset 10
will make the screen go blank in 10 seconds,
right as it ought to.
But, setting...
   xset 3600
will be ignored,
and the screen will go blank in something between 7 and 15 minutes.
Didn't count exactly. 
I think it's 10 minutes (600 seconds).
Which is the same, as the following (default) setting
(this is probably not a coincidence)...
   [bash 4.2]$ xset q
   ...
   blah blah
   ...
   DPMS (Energy Star):
   Standby: 600    Suspend: 600    Off: 600
   DPMS is Enabled
   Monitor is On

Of course the system doesn't standby (suspend or shut off) in 600 seconds.
Only the screen turns blank.

Today, 6 years later, some videos players like VLC rely to dbus connections to prevent screen blanking while playing videos, even in full screen mode.

Such requested tool, must be distribution agnostic.

DPMS should be carefully managed to prevent ill-functioning on notebook.



Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Status: NEW => RESOLVED
Resolution: (none) => OLD