Le blog de llaumgui - hardware

Fedora 9 + drivers radeon + gnome-display-properties = bluffant

llaumgui — Sun, 27 Apr 2008 14:08:00 +0200

Histoire de ne pas galérer avec le rétro-projecteur lors de ma présentation durant les 2ème Live eTIC Party de Montpellier, je me suis entrainé au dual-screen sur ma télé. J'avais en mémoire de mauvais souvenirs avec les drivers radeon et mon ATI Mobility X700 et je m'apprêtais à passer une bonne heure avec vim et mon xorg.conf.
Et bien non ! Fedora 9 intègre Xorg 7.3 et gnome-display-properties (accessible via Système / Préférences / Matériel / Résolution de l'écran) avec lesquels la configuration d'un dual-screen prend à présent 30 secondes montre en main ! Et ce, même avec les drivers libres radeon !

Bref, dans le cas d'une ATI Mobility X700, je le redis, fglrx ne se justifie pas !

HAL et mon Meizu M3

llaumgui — Sun, 03 Jun 2007 22:29:00 +0200

Comme ceux qui lisent régulièrement mon blog le savent, je me suis acheté un nouveau baladeur MP3. Ce dernier est parfaitement reconnu sous Linux, mais je regrettais juste qu'il apparaisse comme disque amovible sur mon bureau et qu'il soit monté dans /medi/disk/.

C'est après un passage sur les forums de fedora-fr ou j'ai trouvé la réponse à ma question, que je me suis fait ce petit fichier *.fdi qui permet de monter le Meizu dans /media/meizu_m3 et de l'afficher sur le bureau avec le nom "Meizu M3".

llaumgui@enterprise ~> cat /usr/share/hal/fdi/policy/95userpolicy/95-meizu-m3.fdi 

<?xml version="1.0" encoding="ISO-8859-1"?>

<deviceinfo version="0.2">

<!-- /usr/share/hal/fdi/policy/95userpolicy -->

  <device>

    <match key="volume.uuid" string="68DE-5DE7">

        <merge key="volume.label" type="string">Meizu M3</merge>

        <merge key="volume.policy.desired_mount_point" type="string">meizu_m3</merge> 

    </match>

  </device>

</deviceinfo>

Je recherchais une méthode sans passer par hal et plus orientée user (fichier dans /home/), mais, au final, cette méthode me convient parfaitement.

Xorg et Logitech Internet Keyboard

llaumgui — Sun, 03 Jun 2007 22:02:00 +0200

Avec l'arrivée de Moonshine, je suis passé de Xorg 7.1 à la version 7.3 avec mon éternel fichier xorg.conf que je récupère de version en version en corrigeant les problèmes dus à la (in)compatibilité descendante.

Ce coup-ci tout c'est bien passé, je me suis juste heurté à un petit problème du à mon clavier Logitech :

llaumgui@enterprise ~> cat /var/log/Xorg.0.log | grep BOGUS

BOGUS LENGTH in write keyboard desc, expected 5376, got 5380

Après une lecture de cette article du site de Gentoo (décidément, cette documentation est vraiment d'une très bonne qualité). Au final, voici donc ma section keybord (je rappel que je suis francophone de France, les autres devront adapter les ligne "XkbLayout" et "XkbVariant" :

Section "InputDevice"

    Identifier  "Keyboard0"

    Driver      "kbd"

    Option      "XkbModel" "logiik"

    Option      "XkbLayout" "fr"

    Option      "XkbVariant" "latin9"

EndSection

VirtualBox et l'USB

llaumgui — Sat, 17 Mar 2007 00:16:00 +0100

Maintenant que j'ai bien configuré mon Windows XP virtualisé, que j'ai installé les "Guest Additions" (le sujet de mon prochain billet sur VirtualBox), je me suis mis en tête d'utiliser mes ports USB dans ma machine virtuelle. La raison et que je veux pouvoir flasher mon Samsung E900 ou imprimer en haute qualité avec mon IP2000. Ce pose alors à moi un petit problème :

Après quelques recherches sur Google et sur le site de VirtualBox, je tombe sur cette solution qui bien que pas très propre a le mérite de fonctionner (à un chmod près).

Bon, je sais qu'une solution consistant à faire des chgrp à la volée est loin d'être le top, mais elle figure non seulement dans le wiki mais aussi dans l'aide officiel disponible à partir du logiciel grâce à la touche F1...

Créez un groupe usb. Pour cela 2 solutions system-config-users ou le traditionnel vim.
Ajoutez y les utilisateurs que vous voulez permettre de contrôler votre USB.
Ajoutez une règle dans udev : /etc/udev/rules.d/51-usb-group.rules (en annexe).
Ajoutez le script /etc/udev/scripts/set-usb-group (en annexe).
Ensuite appliquez les bons chmod :
root@enterprise ~> chmod 754 /etc/udev/scripts/set-usb-group root@enterprise ~> chmod 644 51-usb-group.rules
Et pour finir un petit reboot...

Voila, vous pouvez, comme moi, utiliser vos USB directement dans VirtualBox.

ATI Remote Wonder II, lirc 0.8.1 et lircd.conf : Enquête

llaumgui — Sun, 11 Mar 2007 17:52:00 +0100

Le drame à eu lieu ce matin vers 2 heure. Je me regardais pénard un double épisode d'X-Files (Zone 51) tout en dégustant un petit Pic St Loup. Entre les 2 épisodes, je lève mon bras pour passer au second via mon ATI Remote Wonder II quand tout à coup... Rien !
Désappointer devant cet échec technologique j'ai du prendre mon courage à 2 mains pour me lever de mon canapé et faire passer Totem à l'épisode suivant... 2 heure du mat', pas le temps de me lancer dans un investigation...

Le lendemain (en fait le jour même mais bon), tel Mulder et Scully (plutôt Mulder quand même ;-)) je me lance dans une enquête.
Avant toute chose, je vérifie le bon fonctionnement de mes piles. Cela ne viens pas de là...

Je lance le service à la main afin de vérifier que tout se passe bien :

root@enterprise ~> /usr/sbin/lircd --nodaemon

Puis un petit irw afin de voir si le signal arrive : rien !

Je tente de vérifier si ma télécommande marche avec le module ati_remote2 :

root@enterprise ~> rmmod lirc_atiusb 

root@enterprise ~> modprobe ati_remote2

La télécommande marche bien...

Il me viens alors une idée : refaire un fichier lircd.conf via irrecord... Et miracle, ça marche !!!

Conclusion : Une mise à jour de lirc a du faire planter mon fichier de configuration que j'utilise depuis la version 0.7.2 alors qu'aujourd'hui on est sous 0.8.1.

Remarque 1 : Je renomme mon ancien fichier en lircd_legacy.conf et je mets à jour mon lircd.conf que je vous mets à disposition en annexe.

Remarque 2 : Je n'en avais pas parlé, mais depuis quelques mois et une mise à jour du kernel, le module ati_remote2 pour l'ATI Remote Wonder II est directement pris en compte par Vanilla. Pour utiliser lirc_atiusb à la place de ati_remote2, il faudra passer par un blacklistage :

root@enterprise ~> cat /etc/modprobe.d/blacklist | grep ati

blacklist ati_remote2

Faut il légiférer sur une ouverture des spécificités hardware ?

llaumgui — Sun, 04 Mar 2007 14:06:00 +0100

En cette période électorale, c'est en effet la question que je me pose...
On pourrait faire le parallèle avec la loi Toubon qui oblige chaque produits ou logiciels vendus en France à ce qu'il soient livrés avec une notice en français; c'est aussi cette même loi qui transforme les airbag en coussin-gonflable, mais là je m'éloigne ;-).

Mon idée serait d'obliger chaque fabriquants vendant du matériel nu (ce qui n'est pas le cas de Apple qui vend le soft et le hard) a :

Soit fournir des pilotes respectables,
Soit à ouvrir les spécificités afin que la communauté puissent faire ce que la firme refuse de faire.

Prenons le cas d'ALI qui est leader dans le domaine des webcams embarquées sur les PC portables, mais qui ne livre aucun pilote Linux et dont le projet de pilotes libres stagne pour cause de reverse engineering.

Autre exemple : ATI qui livre des pilotes de qualité douteuse (j'utilise les libres tellement les fglrx sont daubesques) développés par 3 pauvres développeurs dépassés.

Bref, on pourrait résumerer cette loi par : « Faites de bons drivers dignes de ce nom ou permetez nous de les faire. »

Carte ATI, drivers radeon vs fglrx

llaumgui — Tue, 21 Nov 2006 22:51:00 +0100

Alors que sur ma station de travail, la question ne se pose pas (grâce à la puissance des drivers NVIDIA); sur mon portable (ATI powered) le choix est Cornélien :

A ma droite, les drivers radeon, open-source, compatibles AIGLX/Composite, mais très gourmands en ressources et sans accélération 3D. Bref, un veau !
A ma gauche, les drivers closed-source de chez ATI : fglrx. Compatibles ni AIGLX, ni Composite, mais l'accélération 3D et les perfs sont là.

Mais pourquoi ai-je acheté une ATI ? Car malheureusement ATI domine le secteur du PC portable. Cependant ils se contrent-fou des utilisateurs de Linux, c'est pour cela que je vais m'orienter vers un boycotte pure et simple des produits ATI !

L'avenir d'ATI sous Linux ?

Changement de politique grâce au rachat par AMD ? Je demande à voir...
Une hypothétique version 9 des drivers embarquant un système compatible composite proche de la solution concurrente de NVIDIA ? Oui, mais quand ?
L'utilisation d'XGL ?

C'est en tout cas vers cette dernière solution que je vais me tourner dans un futur proche, surtout que FC5 + fglrx + XGL tournaient pas mal ensemble...

LLaumgui plus fort que cpuspeed ?

llaumgui — Sun, 19 Nov 2006 00:05:00 +0100

Pour ceux qui ont suivie ma précédente aventure sous Fedora Core 6 avec mon portable, vous avez pus remarquer que j'avais eu de gros problèmes. Et bien ils sont, depuis peu, tous résolus !

Je vais faire un rapide résumé des problèmes mineurs puis je m'attarderais sur le cas de cpuspeed qui part en vrille sur mon Centrino.

1er problème, un kernel i586 -> Bon, bien qu'il existe une solution, cette fois si je me suis retrouvé avec un vrai i686... Va comprendre !
2ème problème, Bios bug -> Le bug est toujours là (c'est un bug des BIOS Intel) mais avec le nouveau kernel (2.6.18-1.2849.fc6), je ne m'arrête pas 30 secondes dessus (ça c'était un bug du premier kernel 2.6.18) et je mets pas 2 minutes à lancer mon portable.
4ème problème, Plus de WiFi -> Suffisait de récupérer mes fichiers de conf de FC5 ;-).

Maintenant que les menus problèmes sont réparés, attardons nous sur cpuspeed... J'ai tout tenté, même d'installer la dernière version dans le dépôt testing, mais rien ! Pour ceux qui n'ont pas suivie mon aventure sur les forums de fedora-fr, en voici un petit résumé :

Le symptômes :

root@defiant /home/llaumgui> service cpuspeed start

root@defiant /home/llaumgui> service cpuspeed status

cpuspeed est arrêté...

root@defiant /home/llaumgui> /usr/sbin/cpuspeed

Pas de problème ni de message...
Je me tourne vers le fichier de lancement du service cpuspeed (/etc/init.d/cpuspeed) et compare les versions FC5 et FC6

Version FC5 :

#!/bin/sh

# Startup script for cpuspeed

#

# chkconfig: 12345 06 99

# description: Run dynamic CPU speed daemon



# Source function library.

. /etc/rc.d/init.d/functions



[ -f /usr/sbin/cpuspeed ] || exit 0



prog="cpuspeed"



# Get config.

if [ -f /etc/cpuspeed.conf ]; then

        . /etc/cpuspeed.conf

fi



start() {

    if [ ! -f /var/lock/subsys/cpuspeed ]; then

        # Attempt to load scaling_driver if not loaded but it is configured

        for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver; do

            # We want to run the code below only if the

            # wildcard above got no matches.

            [ ! -f "$file" ] || break



            if [ -n "$DRIVER" ]; then

                /sbin/modprobe "$DRIVER"

            else

                # use ACPI as a fallback if its available.

                if [ -f /proc/acpi/processor/CPU0/throttling ]; then

                    # Check we have throttling states available.

                    thr=`head -n1 -q /proc/acpi/processor/CPU*/throttling | uniq`

                    if [ "$thr" != "<not supported>" ]; then

                        /sbin/modprobe acpi-cpufreq

                    fi

                fi

            fi

        done



        # If we get this far with no driver, we must have no ACPI. We're doomed.

        [ ! -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver ] && return 0



        echo -n $"Starting $prog: "



        daemon cpuspeed -d $OPTS

        RETVAL=$?

        echo

        [ $RETVAL = 0 ] && touch /var/lock/subsys/cpuspeed

    else

        return 0

    fi

    return $RETVAL

}



stop() {

    if test "x`pidof cpuspeed`" != x; then

        echo -n $"Stopping $prog: "

        killproc cpuspeed -USR1

        killproc cpuspeed -INT

        echo

    fi

    if test "x`pidof cpuspeed`" != x; then

        killproc cpuspeed

    fi

    RETVAL=$?

    [ $RETVAL = 0 ] && rm -f /var/lock/subsys/cpuspeed

    return $RETVAL

}



case "$1" in

    start)

        start

        ;;

    

    stop)

        stop

        ;;

    

    status)

        status cpuspeed

        ;;

    restart)

        stop

        start

        ;;

    condrestart)

        if test "x`pidof cpuspeed`" != x; then

        stop

        start

        fi

        ;;

    

    *)

        echo $"Usage: $0 {start|stop|restart|condrestart|status}"

        exit 1



esac



exit $RETVAL

Version FC6 :

#!/bin/sh

# Startup script for cpuspeed

#

# chkconfig: 12345 06 99

# description: Run dynamic CPU speed daemon



# Source function library.

. /etc/rc.d/init.d/functions



[ -f /usr/sbin/cpuspeed ] || exit 0



prog="cpuspeed"



# Get config.

if [ -f /etc/cpuspeed.conf ]; then

        . /etc/cpuspeed.conf

fi



start() {

    if [ ! -f /var/lock/subsys/cpuspeed ]; then

        # Attempt to load scaling_driver if not loaded but it is configured

        for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver; do

            # We want to run the code below only if the

            # wildcard above got no matches.

            [ ! -f "$file" ] || break



            if [ -n "$DRIVER" ]; then

                /sbin/modprobe "$DRIVER"

            else

                if [ -d /proc/acpi ]; then

                    EST=`grep flags /proc/cpuinfo | grep est`

                    if [ "$EST" ]; then

                        # use ACPI as a fallback

                        /sbin/modprobe acpi-cpufreq

                        # even ACPI didn't work, remove it, and bail out.

                        if [ -d /sys/devices/system/cpu/cpu0/cpufreq ]; then

                            /sbin/rmmod acpi-cpufreq

                        fi

                    fi

                else

                    # This is a no-ACPI machine. Just exit.

                    return 0

                fi

            fi

        done



        # If we get this far with no driver, we must have no ACPI. We're doomed.

        [ ! -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver ] && return 0



        drv=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)



        case "$drv" in

        centrino|powernow-k8)

            /sbin/modprobe cpufreq-ondemand

            for i in /sys/devices/system/cpu/cpu*

            do

                echo ondemand > $i/cpufreq/scaling_governor

            done

            RETVAL=0

            ;;

        *)

            echo -n $"Starting $prog: "

            daemon cpuspeed -d $OPTS

            RETVAL=$?

            echo

            [ $RETVAL = 0 ] && touch /var/lock/subsys/cpuspeed

        esac

    else

        return 0

    fi

    return $RETVAL

}



stop() {

    drv=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)

    case "$drv" in

    centrino|powernow-k8)

        /sbin/rmmod cpufreq-ondemand

        RETVAL=0

        ;;

    *)

        if test "x`pidof cpuspeed`" != x; then

            echo -n $"Stopping $prog: "

            killproc cpuspeed -USR1

            killproc cpuspeed -INT

            echo

        fi

        if test "x`pidof cpuspeed`" != x; then

            killproc cpuspeed

        fi

        RETVAL=$?

        [ $RETVAL = 0 ] && rm -f /var/lock/subsys/cpuspeed

    esac



    return $RETVAL

}



case "$1" in

    start)

        start

        ;;



    stop)

        stop

        ;;



    status)

        status cpuspeed

        ;;

    restart)

        stop

        start

        ;;

    condrestart)

        if test "x`pidof cpuspeed`" != x; then

        stop

        start

        fi

        ;;



    *)

        echo $"Usage: $0 {start|stop|restart|condrestart|status}"

        exit 1



esac



exit $RETVAL

Je remarque de suite une nuance, les centrino sont passé en monde ondemand :

case "$drv" in

        centrino|powernow-k8)

            /sbin/modprobe cpufreq-ondemand

            for i in /sys/devices/system/cpu/cpu*

            do

                echo ondemand > $i/cpufreq/scaling_governor

            done

            RETVAL=0

            ;;

Il suffit donc de modifier les lignes en question en virant centrino pour que cpuspeed se lance sans problème comme sous Fedora Core 5...

La question est : pourquoi un ordinateur dont l'architecture est orientée mobilité est forcé en mode ondemand ? ? ? ! ! !
Je vais étudier la question et peut être rapporter un bug... Je reste cependant ouvert à vos remarques...
En attendant, la fréquence de mon ordinateur varie sans problème comme avant...

Ca y est ! Je l'ai fait !

llaumgui — Sun, 05 Nov 2006 20:57:00 +0100

Et oui, après l'échec de la migration de mon portable, je viens de basculer ma station de travail sans trop de problème sous Fedora Core 6. J'ai profité de cette bascule pour installer les drivers bêta de chez nvidia ainsi que AIGLX/Compiz et leur Desktop Effects.
J'en ai même profité pour tester Beryl, dont parle TitaX sur son blog, mais je trouve que trop d'effets tus l'effet et donne le mal de mer !

A switcher, autant switcher pour de bon, j'en ai aussi profité pour passer mon Firefox en version 2.0 et pour refaire toute ma configuration histoire de partir sur une base saine.

Pour installer les drivers bêta de chez nvidia/livna :

yum --enablerepo=livna-testing install kmod-nvidia

Pour installer beryl :

Je vous conseil de lire le blog de l'ami titax.

Quelques captures (AiglX, pas Beryl) :

Quelques captures d'écrans et vous trouverez mon fichier xorg.conf en document attaché à ce billet.

Les effets permettent de regarder un épisode de Prison Break à cheval sur 2 bureau ;-).

J'en ai aussi profité pour installer le nouveau thèmes d'icones en préparation pour FC7 : echo : yum --enablerepo=development install echo* Pour l'images de fond, c'est Fedora Cube de mola.

Fedora Core 6, bonjour et à bientôt

llaumgui — Sun, 22 Oct 2006 16:14:00 +0200

Alors que Zod n'a pas encore pointé officiellement le bout de son nez, en vu de l'install party de Samedi, j'ai tenté de faire un migration de mon portable de FC5 vers FC6. Puis devant les problèmes, une complète réinstallation. Puis devant les nouveaux problèmes une pose, une réflexion et un tour sur le Chan avec les copains.

1er problème, un kernel i586 :

Grâce aux indices du docteur, je me suis rendu compte que j'étais en i586 sur mon Intel Centrino... Anaconda dans son infinie délire m'avais affublé d'un kernel i585.

[root@defiant llaumgui]# file /lib/modules/2.6.18-1.2798.fc6/build

/lib/modules/2.6.18-1.2798.fc6/build: symbolic link to `../../../usr/src/kernels/2.6.18-1.2798.fc6-i586'

Bref la solution fut donc pour moi :

rpm -ivh --force '/root/Desktop/kernel-2.6.18-1.2798.fc6.i686.rpm'

2ème problème, Bios bug :

Dès le boot :

PCI: BIOS bug: MCFG area@e0000000 is not E820 reserved

PCI: not using MMCONFIG

Apparemment je suis en présence d'un bug du kernel Linux. La solution attendre un nouveau kernel...

3ème problème, acpi_cpufreq bug :

ksign: module signed with unknow public key

FATAL: Error inserting acpi_cpufreq

(/lib/modules/2.6.18.../kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):

No such device

Dans la ligné de mes problèmes de bios je présume...

4ème problème, Plus de WiFi :

J'avoue ne pas avoir trop cherché la solution, trop mare !

Solution générale

Une réinstallation de Fedora Core 5 qui elle marche nickel ! En attendant une mise à jour...

Je trouve quand même dommage que pas assez de personnes participent à la Rawhide et rapportent les bugs. Plus on sera nombreux à déboguer Fedora Core, plus Fedora Core avancera et sera stable à sa sortie. J'irais même jusqu'à dire qu'à cause de ça, les 2 premières semaines d'existences d'une version Fedora correspondent à une séance de débug massive.