eventi acpi alla pressione di un tasto

[targzeta]

Certo che è proprio strano . L'ultima cosa da provare è di mettere un exit esplicito nel tuo script 'brightness.sh '. In pratica alla fine del file, dopo il case mettici un 'exit'.

Sono sicuro che anche a me è capitata una cosa analoga ma non ricordo come la risolsi.

Spina

[conraid]

Certo che è proprio strano . L'ultima cosa da provare è di mettere un exit esplicito nel tuo script 'brightness.sh '. In pratica alla fine del file, dopo il case mettici un 'exit'.

Sono sicuro che anche a me è capitata una cosa analoga ma non ricordo come la risolsi.

Domani provo, adesso ho chiuso il portatile e sto chiudendo anche questo.
Grazie degli input

[conraid]

Certo che è proprio strano . L'ultima cosa da provare è di mettere un exit esplicito nel tuo script 'brightness.sh '. In pratica alla fine del file, dopo il case mettici un 'exit'.

Sono sicuro che anche a me è capitata una cosa analoga ma non ricordo come la risolsi.

Spina

Provato a mettere "exit" ma non cambia niente. Se ti viene in mente qualcosa mi farebbe piacere capire il tutto.
Grazie

[targzeta]

Mi spediresti i due file (l'handler e il brightness) all'indirizzo spina80ATfreemailDOTit ? Voglio vederli integralmente tutti e due e poi voglio provare a riprodurre l'errore sulla mia macchina, così da non sparare a caso .

Spina

[conraid]

Mi spediresti i due file (l'handler e il brightness) all'indirizzo spina80ATfreemailDOTit ? Voglio vederli integralmente tutti e due e poi voglio provare a riprodurre l'errore sulla mia macchina, così da non sparare a caso .

Te li mando come sono adesso, ultima versione di tante prove

[absinthe]

una cosa sola non capisco... se il file brightness ha il contenuto che indichi alcuni post più sù (con le due righe di dati) come cavolo fai, con un semplice cat, a rilevare il valore corretto indicato dalla seconda riga del file? quella con scritto "current: X".
forse mi sfugge qualcosa :-/

M

[conraid]

una cosa sola non capisco... se il file brightness ha il contenuto che indichi alcuni post più sù (con le due righe di dati) come cavolo fai, con un semplice cat, a rilevare il valore corretto indicato dalla seconda riga del file? quella con scritto "current: X".
forse mi sfugge qualcosa :-/

M

Come dico qualche messaggio più sutto, quel file è quello dentro /proc, era per rispondere al fatto se avevo o no un file simil IBM
Quello che uso è in /sys e contiene un unico valore
Mi sono scordato di specificare il percorso, pardon

Tanto per specificare meglio

Codice: Seleziona tutto

# cat /proc/acpi/video/C098/C1AA/brightness
levels:  100 43 27 30 37 43 48 51 52 62 71 82 100
current: 100

# cat /sys/devices/virtual/backlight/acpi_video0/brightness
100

Nel kernel ho compilato sia il supporto deprecato a /proc sia quello a /sys

[targzeta]

Questa cosa è impossibile, se tu leggi 82 con un cat, allora anche lo script deve leggere 82. Domande secche:
- Hai altri file nella directory /etc/acpi/events, oltre a quello di default che rimanda tutto a acpi_handler.sh?
- Potresti inserire un echo "$1" nel file handler.sh? Mettilo in cima a tutto, prima della definizione della variabile STATE_AC. Voglio vedere la stringa che gli passa acpid all'handler.

Sembra come se acpid invoca qualcosa altro prima, che gli scrive un 100 nel file del brightness.

spina

P.S. Io ho testato i due script e sembrano essere a posto, voglio solo vedere come viene davvero invocato l'acpi_handler.

Pippi.S. Nel log che mi hai mandato via email ci sono queste due righe:
[Sat Mar 15 10:03:37 2008] notifying client 2564[0:0]
[Sat Mar 15 10:03:37 2008] notifying client 2486[82:82]
chi sono questi due client? a che processo si riferiscono? non è che sono loro che fanno casino?

[targzeta]

Prova a fare così:
- disabilita il tuo script, in pratica non gestire l'evento.
- poi fai un echo '82' > file_brigthness
- ora premi il tasto
- fai un cat, il valore è 82 o qualche processo lo ha modificato?

fammi sapere,
spina

[conraid]

Allora:

in /etc/acpi/events ho solo questo file

Codice: Seleziona tutto

root@mobile:/etc/acpi/events# cat default
# This is the ACPID default configuration, it takes all
# events and passes them to /etc/acpi/default.sh for further
# processing.

# event keeps a regular expression matching the event. To get
# power events only, just use something like "event=button power.*"
# to catch it.
# action keeps the command to be executed after an event occurs
# In case of the power event above, your entry may look this way:
#event=button power.*
#action=/sbin/init 0

# Optionally you can specify the placeholder %e. It will pass
# through the whole kernel event message to the program you've
# specified.

event=.*
action=/etc/acpi/acpi_handler.sh %e

Che è quello di default, per il resto ci sono solamente i file che ti ho mandato


echo $1 messo in cima a tutto da come output

Codice: Seleziona tutto

video

echo $@ da invece

Codice: Seleziona tutto

video C1AA 00000087 00000000

Se disabilito l'evento mi rimette 100 ad ogni pressione del tasto
La cosa stronza è che un tasto con la "luna" (non so davvero cosa faccia normalmente, c'era Vista qui ma lo tolto subito) fa andare tutto a 100.
E' come se qualcosa gestisse l'evento "video"


Quei client come faccio a capire cosa sono?


UPDATE
mettendo un evento di default, che non fan niente, per "video" non mette più a 100 con quel tasto che non conosco, ma non mi fa scendere sotto 82
In pratica funziona solamente la prima volta

[targzeta]

ahhhh, allora ok. Tutto funziona bene. A mio avviso o è a livello hardware che viene gestita la faccenda, oppure solo i client che acpid avvisa prima di invocare il tuo handler. Io immagino che i numeri si riferiscano al pid dei client (e quindi con un 'ps'...).
comunque fai una prova, killa acpid e fallo ripartire con l'opzione -S per disabilitare il socket. Ora fai una prova con il cat manuale e pressione tasto, per vedere se il valore è modificato. Se viene modificato allora penso sia gestito a livello hardware (come il mio PC, ma a me funziona bene).

fammi sapere,
spina

[conraid]

PID

Codice: Seleziona tutto

root@mobile:/# ps -A | grep 2563
 2563 tty7     00:08:22 X
root@mobile:/# ps -A | grep 2485
 2485 ?        00:00:00 hald-addon-acpi

guardo in HAL se vedo qualcosa

con l'opzione -S funziona bene

[targzeta]

Allora il mistero è risolto , uno dei due client connessi a acpid gestisce l'evento prima del tuo script.
Ti posso confermare che nel log di acpid vengono stampati i pid dei client, ho provato a far ripartire X e il client si è riconnesso con pid diverso. Io non ho hal e quindi non posso dire se sia X o hal, ma nel tuo caso potresti killare X e vedere che succede, così se tutto funziona bene sei sicuro che è X il colpevole.

Spina

P.S. inutile dire che ci devi informare su quello che succede.

[conraid]

Ti posso confermare che nel log di acpid vengono stampati i pid dei client, ho provato a far ripartire X e il client si è riconnesso con pid diverso. Io non ho hal e quindi non posso dire se sia X o hal, ma nel tuo caso potresti killare X e vedere che succede, così se tutto funziona bene sei sicuro che è X il colpevole.

X non è, fa lo stesso anche in console se parto in init 3
Ci rimane HAL, a prima vista non trovo niente, ma me lo studio con calma.
Se trovo nuove info vi faccio sapere

Grazie

P.S.
ora si passa al microfono ed al suspend3ram

[conraid]

Nuove notizie dal mio portatile

Allora, se compilo tutto ACPI staticamente nel kernel e non come modulo, fuori X il tasto funziona correttamente, però modifica il file sotto /proc, mentre quello sotto /sys rimane uguale.
Da questo deduco alcune cose
1) ci vuole ancora la funziona deprecata di /proc/acpi
2) nel mio caso meglio ACPI statico che come modulo, anche se in molti casi su web viene descritto il contrario
3) Xorg ha qualche opzione che modifica il comportamento dell'evento. Pensando a KDE ho avviato fluxbox ma fa lo stesso.

Quindi mi viene una domanda:
Che opzione posso dare ad X per non modificare il comportamento dell'evento "pressione tasto"?