# [RES]piccola disfunzione del 2.6 bis (spegnimento schermo)

## cloc3

Scusate se esagero, ma due problemi, due topic (mi sembra piu' ordinato).

Anche lo schermo del mio portatile (Compaq Presario 2800, Pentium 4, radeon 7500) si spegne male quando viene chiuso a panino.

Se sono in modalità carattere, sembra spegnersi correttamente, ma alla riapertura mostra un aspetto uniformemente grigio che mi costringe a digitare reboot a memoria.

Se ho lanciato X, non si spegne affatto. Non si spegne nemmeno dopo la chiusura di X e il ritorno alla modalità carattere.

Ho usato i moduli radeon per il framebuffer di console e per il DRI.

Alcune altre configurazioni del kernel che ho provato hanno dato risultati inaccettabili.Last edited by cloc3 on Sat Aug 07, 2004 7:10 pm; edited 1 time in total

----------

## Naspe

Direi che sarebbe piu opportuno mettere disfunzioni del kernel 2.6.3-[tipo di kernel] visto che io ho il 2.6.1-gentoo su un laptop ASUS M2E e nn ho alcun problema del genere...  :Smile: 

----------

## Peach

uso gentoo-dev-sources-2.6.3-r1 senza problema su un Presario 2710AE  :Smile: 

----------

## stuart

2.6.2 gentoo -r1 su sony vaio fr215e 

nessun problema

----------

## randomaze

 *cloc3 wrote:*   

> (Compaq Presario 2800, Pentium 4, radeon 7500) si spegne male quando viene chiuso a panino.
> 
> 

 

Forse dico una bischerata ma per spegnere le radeon non si dovrebbe usare il radeontool?

----------

## MyZelF

Stessi problemi sul mio portatile (Presario 2825EA), indipendentemente dal kernel utilizzato (provati dal 2.4.20 al 2.6.2).

Il DPMS va a farsi benedire una volta attivato il DRI. Per risolvere devi utilizzare radeontool in unione ad acpid.

```

# emerge radeontool

# emerge acpid

# rc-update add acpid default

# /etc/init.d/acpid start

```

Per gestire lo spegnimento dello schermo alla chiusura del lid serve una piccola modifica a /etc/acpi/default.sh

```

[...]

                        lid)

                                lidstate="`cat /proc/acpi/button/lid/C11E/state | awk '{print $2}'`"

                                case "$lidstate" in

                                        open)   /usr/bin/radeontool light on

                                                ;;

                                         closed) /usr/bin/radeontool light off

                                                 ;;

                                 esac

                                ;;

[...]

```

Per gestire lo spegnimento dopo x minuti attiva comunque il DPMS sotto X

```
Option "DPMS"
```

in XF86Config

e lancia questo script all'avvio di X:

```

#!/bin/bash

################################################################

 # dpmswatch.sh

 # Copyright 2003 Rob Mahurin <rob@utk.edu>

 # Available for use under the General Public License

 # No warranty etc.

 ##

 #  This is based on lightwatch.pl, but instead of using

 #  xscreensaver-command -watch, it uses xset to query the DPMS state

 #  of the LCD.  If the desired DPMS state is off, blank the LCD

 #  backlight using radeontool.

 ##

 #  If your system gives a different output to this command :

 #  $ for i in standby suspend off on ; do

 #      xset dpms force $i ;

 #      xset q ;

 #    done | grep Monitor | awk '{print $3 $4 }'

 #    inStandby

 #    inSuspend

 #    Off

 #    On

 #  then you may have to modify this script.

 ##

 #  It's written in shell instead of Perl because that's what I know.

################################################################

# commands to use.  Correct on Debian woody.

XSET=/usr/bin/X11/xset

RADEONTOOL=/usr/bin/radeontool

# The polling intervals, for feeding to sleep(1).  Is there way to

# make this event-driven, rather than poll all the time?  Does it

# matter?

#

# Notice that we don't want to watch the xscreensaver, since that

# would bring up the password box without turning on the LCD.  Very

# confusing.

inStandby_INTERVAL=5s

inSuspend_INTERVAL=5s

Off_INTERVAL=1s

On_INTERVAL=5s

INTERVAL=0s;

# check to make sure we have all the commands we need

for i in $XSET $RADEONTOOL

do    [ -x $i ] || { echo $i not found >&2 || exit 0 ; }

done

while : ; do

    # what is the state of the monitor?

    STATE=$($XSET q | grep Monitor | awk '{print $3 $4}')

    # if the monitor is in standby or suspend, change the polling

    # interval # but turn the light on or off.  If the monitor is Off,

    # turn off the # LCD backlight.  If the monitor is On, turn on the

    # backlight.  Then sleep until it's time to check again.

    case $STATE in

        inStandby)

                INTERVAL=$inStandby_INTERVAL

                ;;

        inSuspend)

                INTERVAL=$inSuspend_INTERVAL

                ;;

        Off)

                INTERVAL=$Off_INTERVAL

                $RADEONTOOL light off

                ;;

        On)

                INTERVAL=$On_INTERVAL

                $RADEONTOOL light on

                ;;

        # if something strange happens, turn the light on and fail.

        *)

                $RADEONTOOL light on

                exit 1

                ;;

    esac

    sleep $INTERVAL

done

```

Per ora non ho trovato soluzioni più pulite.

----------

## cloc3

 *MyZelF wrote:*   

> Stessi problemi sul mio portatile (Presario 2825EA), indipendentemente dal kernel utilizzato (provati dal 2.4.20 al 2.6.2).
> 
> 

 

Non so. Quando avvio il 2.4.24 non osservo problemi di sorta.

Comunque sono basito: per ogni problema banale che sollevo ricevo risposte competenti e precise.

Mi prendo qualche tempo per provare la soluzione e inserire il solito (ormai noiso) [Risolto]

----------

## MyZelF

 *cloc3 wrote:*   

> 
> 
> Non so. Quando avvio il 2.4.24 non osservo problemi di sorta.
> 
> 

 

Interessante, perchè in effetti credo di avere provato solo con 2.4.x patchati (gentoo-sources e ck-sources). Il problema potrebbe essere dovuto a qualche incompatibilità tra DRI e patch del 2.4.x entrate a far parte del kernel tree ufficiale 2.6.x. Indagherò.  :Wink: 

----------

## cloc3

Sono passato (quasi casualmente, da ottimo nubbio) dal kernel 2.6.3-rc2 al 2.6.3-r2 (tra l'altro, cosa è indicato da quella lettera c?) e ho avuto modo di verificare, come era d'altronde implicito dalle risposte precedenti, che quelli che registravo sono due problemi distinti.

a) il primo riguarda il comportamento dello schermo allo schiacciamento del lid prima dell'avvio di X. Funziona male per colpa del driver radeon. Infatti con l'uso del nuovo driver il problema non si presenta (questo kernel offre due driver radeon differenti).

```

CONFIG_DRM_RADEON=y

CONFIG_FB_RADEON_OLD=y

# CONFIG_FB_RADEON is not set

```

Con ciò il problema non è affatto chiuso, perché per il nuovo driver funziona malissimo, vibra e non azzecca le dimensioni corrette dello schermo, al punto che tra i due preferisco decisamente il primo.

Ora chiedo. Esiste un modo per sintonizzare correttamente il secondo driver in modalità carattere?

b) lo spegnimento dello schermo in modalità grafica dipende dalle radeontool, che funzionano benissimo se chiamate singolarmente, ma non allo schiacciamento del lid. Conseguenza: ho capito male le indicazioni di MyZelf, ma intendo occuparmene più avanti in un prossimo replay.

----------

## motaboy

 *Quote:*   

> 
> 
> (tra l'altro, cosa è indicato da quella lettera c?) 
> 
> 

 

_rcX = release candidate (un pre della versione del kernel in uscita)

-rX = la versione dell'ebuild relativo alla versione del kernel.

Bye!

----------

## cloc3

[RISOLTO]

Istruzioni: aspettate e dimenticatevi il lid.

Un giorno, fate una prova e scoprite che funziona.

No, non è merito del bootsplash. Per sfizio, ho provate a unmergerlo e funziona lo stesso.

Tra l'altro, adesso il nuovo modulo per il radeonfb gira correttamente come il vecchio.

----------

