eventi acpi alla pressione di un tasto

[gigiobagiano]

Secondo me anche il fatto di aver la stessa cosa in due punti /sys e /proc non è proprio il massimo (però a differenza di spina sono decisamente una fonte poco attendibile ), poi è anche vero che entrambi si dovrebbero modificare nello stesso momento. Non avendo voglia di riscrivermi gli script che vanno a puntare su /proc ho compilato il kernel con il valore deprecato mentre il sys è deselezionato (almeno se non ricordo male).

[conraid]

Secondo me anche il fatto di aver la stessa cosa in due punti /sys e /proc non è proprio il massimo (però a differenza di spina sono decisamente una fonte poco attendibile ), poi è anche vero che entrambi si dovrebbero modificare nello stesso momento. Non avendo voglia di riscrivermi gli script che vanno a puntare su /proc ho compilato il kernel con il valore deprecato mentre il sys è deselezionato (almeno se non ricordo male).

Il fatto è che nel fisso uso solamente /sys e tengo le funzioni deprecate deselezionate, tranne "Deprecated /proc/acpi/event support" altrimenti ho una sfilza di errori ed ACPI non va (secondo la documentazione del kernel perché non aggiornato), e quindi volevo creare la stessa situazione nel notebook.
Ed in effetti sai che non ricordo se nelle tante prove ho provato a disabilitare /sys
Solo che non mi piace come idea, anche perché sarà eliminato /proc dal kernel prima o poi
Devo solamente capire adesso cosa modifica Xorg
Hal agisce su /proc e anche io come te per adesso lo lascio stare così

[absinthe]

adesso se trovo un secondo mi leggo un pò meglio hal... nel frattempo stavo pensando: non è che il tuo utente è nel gruppo powerdev? se sì prova a toglierlo!

M

[conraid]

adesso se trovo un secondo mi leggo un pò meglio hal... nel frattempo stavo pensando: non è che il tuo utente è nel gruppo powerdev? se sì prova a toglierlo!

Il gruppo powerdev non ce l'ho. Ho "power" ma non c'è nessun utente

[absinthe]

ok! non ho idea di come siano invocati però sulla stable hal gestisce l'acpi (usando vari backend). gli script incriminati sono in /usr/lib/hal/scripts e /usr/lib/hal/scripts/linux! e smanettano appunto sui file acpi! per quanto riguarda la policy che invoca tali script (per lcd) è situata in /usr/share/hal/fdi/policy/10osvendor.
la policy dice:

Codice: Seleziona tutto

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">

  <device>
    <match key="info.category" string="laptop_panel">
      <!-- only set if the laptop_panel.access_method is not custom -->
      <match key="laptop_panel.access_method" compare_ne="custom">
        <append key="info.interfaces" type="strlist">org.freedesktop.Hal.Device.LaptopPanel</append>

        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_names" type="strlist">SetBrightness</append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_signatures" type="strlist">i</append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_argnames" type="strlist">brightness_value</append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_execpaths" type="strlist">hal-system-lcd-set-brightness</append>

        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_names" type="strlist">GetBrightness</append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_signatures" type="strlist"></append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_argnames" type="strlist"></append>
        <append key="org.freedesktop.Hal.Device.LaptopPanel.method_execpaths" type="strlist">hal-system-lcd-get-brightness</append>

      </match>
    </match>
  </device>

</deviceinfo>

ho dato un occhio alle informazioni contenute in /usr/doc/hal-0.5.10/spec/hal-spec.html. interessante la sezione "method calls" che spiega il grosso del codice. di fatto pare che hal invochi lo script "hal-system-lcd-set-brightness" passando come argomento la variabile "brightness_value". questo script fa un paio di check e poi invoca due funzioni private di hal contenute in /usr/lib/hal/scripts/hal-functions. la prima ("hal_check_priv") controlla altri privilegi, la seconda ("hal_exec_backend") invoca il backend, ovvero il programma realmente responsabile degli aggironamenti di luminosità. il problema è che il codice è:

Codice: Seleziona tutto

hal_exec_backend() {
    local PROGRAM
    PROGRAM=$(basename $0)
    if [ -n "$HALD_UNAME_S" -a -x ./$HALD_UNAME_S/$PROGRAM-$HALD_UNAME_S ]; then
        exec ./$HALD_UNAME_S/$PROGRAM-$HALD_UNAME_S $@
    else
        echo "org.freedesktop.Hal.Device.UnknownError" >&2
        echo "No back-end for your operating system" >&2
        exit 1
    fi
}

dove $@ al 4 rigo della funzione _dovrebbe_ rappresentare gli argomenti passati. se controlli la chiamata della funzione effettuata da "hal-system-lcd-set-brightness" ti accorgi che argomenti non ce ne sono:

Codice: Seleziona tutto

#<--------------- trascuro la parte iniziale!

# read value for set brightness
read value

# Check for values outside range
if [ ${value} -lt 0 ] || [ ${value} -ge $HAL_PROP_LAPTOP_PANEL_NUM_LEVELS ]; then
        echo "org.freedesktop.Hal.Device.LaptopPanel.Invalid" >&2
        echo "Brightness has to be between 0 and $((HAL_PROP_LAPTOP_PANEL_NUM_LEVELS - 1))" >&2
        exit 1
fi

export value

hal_check_priv org.freedesktop.hal.power-management.lcd-panel
hal_exec_backend

tutto sta ora nel capire quale cacchio di codice viene invocato. non so come trovare il valore della variabile $HALD_UNAME_S e $PROGRAM. _penso_ che $PROGRAM sia proprio "hal-system-lcd-set-brightness" ma l'altra... inoltre non capisco che sia ottenuta brightness_value! boh!

per quanto riguarda powerdev: errore mio mi sono incasinato con debian credo :-/

M

[conraid]

Grazie dell'interesse e degli spunti, domani lo guardo meglio. Ieri ho provato a disabilitare hal proprio in quella policy ma mi dava errore e non ho approfondito molto.
Però con le ultime modifiche al kernel, fuori X sembra che funzioni, quindi HAL il suo lavoro lo fa correttamente. Devo ora scoprire come dire ad X di non "intromettersi". Comunque ho capito un po' di più di quel che succede grazie ai vostri post.
Thanks

[conraid]

Ho visto che in /usr/lib/hal/scripts/linux/hal-system-lcd-set-brightness-linux c'è

Codice: Seleziona tutto

# we have /sys/class/backlight
if [ -w "$HAL_PROP_LINUX_SYSFS_PATH/brightness" ]; then
        echo "$value" > $HAL_PROP_LINUX_SYSFS_PATH/brightness
        exit 0
fi

il resto sembra che aggiorni dei file in /proc ma solo per acpi specifici, come toshiba, asus, ibm
Quindi "sembra" (dico sembra perché devo ancora studiarlo meglio) che modifichi proprio quel file che modificavo io
Però ho come l'impressione che usi il file sotto /scripts che segnalavi tu, che usa i sistemi di hald

Certo che HAL e UDEV sono potenti ma un po' "strani", io ho iniziato a studicchiarli quando avevo problemi con lo scanner, ma capirli ha fondo richiede tempo e studio. Come sempre nei problemi nasce l'interesse verso alcune cose.

[absinthe]

il problema è che invece di avere una struttura semplice con un cappero di file di testo, ti ritrovi con un groviglio poco documentato. prima era semplice:
pressione di un testo->identificazione del tasto come evento acpi grazie alla DSDT->processamento dell'acpi in kernel space->passaggio al demone acpi in user space.
per customizare il demone bastava agire su un banale bash script con uno switch-case al suo interno. e l'acpi faceva solo quello.

adesso non si capisce come cavolo vengano passate le variabili e tutto il resto. o per lo meno io non le capisco. e anche per monitorare gli scambi di informazioni con dbus-mponitor ti devi sbattere un pò. ieri poi ho abbandonato per motivi di tempo!
ora hal fa otto milioni di cose diverse e - essendo in continua evoluzione - non è stabilissimo come comportamento tra versioni diverse. io nelle policy non ho visto accenno hai file usati sotto .../scripts/linux! vorrei sapere a che servono

e poi sarà che io odio i tag... però quancuno mi spiega perchè da comprensibilissimi file di teso si è tornati in dietro con molto meno comprensibili file xml, che ascii sono ma non certo comprensibili al volo!

M

[targzeta]

Bhé, caro absinthe, posso capire il tuo sfogo, ma se hai seguito il susseguirsi di post con conraid avrai certamente notato che funziona ancora così la gestione degli eventi acpi. Nulla è cambiato. Come descritto dalla pagina del manuale di acpid lui accetta anche connessioni di client via socket. Hal e X si collegano al demone acpid tramite questo socket e vengono avvisati di un evento proprio come e "avvisato" un qualsiasi scriptino che vuoi che acpid processi (/etc/acpi/event/*), in particolare il passaggio di parametri dovrebbe essere esattamente lo stesso (prova a scrivere un client per verificare).
Se infatti si vuole escludere hal o X dalla gestione di questi eventi, basta disabilitare il socket di acpid (con l'opzione -S).

Se poi ti riferivi esclusivamente ad hal e alla sua gestione degli eventi segnalati dal demone acpid, allora è un altra storia, io non conosco hal.

spina

[absinthe]

[omissis]in particolare il passaggio di parametri dovrebbe essere esattamente lo stesso (prova a scrivere un client per verificare).[omissis]

scusa, imprecisione mia: è difficile capire il valore delle variabili passate, IMHO ovviamente.

[omissis]Se poi ti riferivi esclusivamente ad hal e alla sua gestione degli eventi segnalati dal demone acpid, allora è un altra storia, io non conosco hal.

spina

Offtopic: no non è un problema limitato all'acpi. è che proprio non riesco ad entrare nell'ottica di hal: mi pare un gran casino! come utente posso apprezzare le conseguenze del "casino" di cui sopra sull'automounting - ma è possibile farlo anche senza -, però è uno strato decisamente complesso. sotto certi aspetti è abbastanza frustrante vedere che una cosa relativamente semplice si trasforma in un groviglio! io sono della filosofia di non modificare una distro se questa funziona ed è testata (e pjv direi che non fa le cose a caso) quindi piuttosto che eliminare hal l'ho messo sperando un giorno di capirlo. quello che mi chiedo è se freedesktop.org aveva davvero bisogno di convogliarci tutti i sottosistemi (energia,stampa/scansione,storage etc...) su hal. non ho stampanti/scanner collegati direttamente al pc quindi su quello non posso valutare. per il resto ancora non capisco perchè aver fatto questa svolta... rimango nel dubbio ma sono anche OT quindi stop!
M

[conraid]

Se infatti si vuole escludere hal o X dalla gestione di questi eventi, basta disabilitare il socket di acpid (con l'opzione -S).

Io non avrei problemi ad usare l'opzione -S, solo che mi viene il dubbio se dopo devo specificare tutti gli eventi che adesso "funzionano", tipo accensione ventole, etc...
Alla fine la luminosità l'ho sistemata grazie al discorso della variabile temporanea, non sarà la soluzione ottimale, ma nell'attesa di trovare soluzioni migliori mi accontento.

@absinthe

Perché OT? Alla fine è pur sempre un discorso su come vengono gestiti gli eventi da HAL e/o Xorg, anche ACPI quindi.
Io come te non ho ancora capito bene HAL. Certo è che ha semplificato la vita ad alcuni utenti, ma forse l'ha complicata a chi amava i semplici file di testo "di una volta".
La cosa che ancora mi sfugge è cosa succede veramente a disabilitarlo, come te lo tengo perché cerco di tenermi il più possibile la slackware di default, e forse non averlo approfondito a suo tempo ora non mi fa apprezzare in pieno il suo ruolo. Da un altro lato forse ha semplificato molte cose, è inutile dire che prima le periferiche si montavano in modo semplice, ma oggi anche io uso l'automounting perché mi semplifica la vita con chiavette e dvd.

A proposito, come dico a KDE di non considerare una "sola" partizione di un HD USB esterno? Ce ne sono due nell'HD

[absinthe]

A proposito, come dico a KDE di non considerare una "sola" partizione di un HD USB esterno? Ce ne sono due nell'HD

a me le rileva automaticamente! io per i dispositivi esterni utilizzo l'applet "storage media" del pannello di kde: quando inserisco qualcosa mi compaiono le iconcine dei dispositivi e da lì decido se montarli,montarli e visualizzarli,smontarli etc... non ho mai avuto problemi di codesto tipo: ho un hd USB con 3 partizioni e mi vengono rilevate tutte e 3: una fat32 una ext3 e una ntfs!

M

[conraid]

non ho mai avuto problemi di codesto tipo: ho un hd USB con 3 partizioni e mi vengono rilevate tutte e 3: una fat32 una ext3 e una ntfs!

Mi sono espresso male, anche a me succede così, ma voglio che una delle due non venga considerata

[conraid]

Offtopic: è che proprio non riesco ad entrare nell'ottica di hal: mi pare un gran casino!

Da un post di Alien Bob su LQ

What happened was that KDE had to have them both.

Essentially, this is the only reason why HAL was included into Slackware and did not go into /testing.

Eric

[absinthe]

ah! mitico!

scusa ma non sono riuscito a rimettere le mani sui file di hal: hai risolto poi il problema delle partizioni?

M