Fedora Core 2 (Tettnang) - Page 3

/usr/sbin/fix-mouse-psaux

que ce soit sous root ou sous user, ça fait rien...
cela dit, j'ai une souris USB, et non ps... ça joue peut-être...

j'ai essayé /usr/sbin/mouseconfig
je met genereric wheel mouse, USB
mais ça change rien non plus
(sous root, je le fais ; sous user, ça veut pas s'exécuter comme il faut ; pb de permissions on dirait)


dans mon /etc/X11/XF86Config, j'ai ça :

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
EndSection



# Ajouté par Squale
        Section "InputDevice"
        Identifier "Mouse2"
        Driver "mouse"
        Option "Protocol" "PS/2"
        Option "Device" "/dev/psaux"
        Option "Emulate3Buttons"
        Option "Emulate3Timeout" "50"
EndSection



Section "InputDevice"
# If the normal CorePointer mouse is not a USB mouse then
# this input device can be used in AlwaysCore mode to let you
# also use USB mice at the same time.
        Identifier  "DevInputMice"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
EndSection

celui du milieu, je l'ai rajouté pour avoir accès au touchpad du portable... sans ça, le touchpad marchait pas ; avec, il marche => je pense pas que ça influe sur la souris USB...

si quelqu'un a une autre idée...
(j'ai une logitech MX-500, en fait, pour êtr eplus précis ; j'avais cherché il y a quelques temps des drivers linux sur le site logitech... mais y'a po )

en fait, pour être plus précis, je peux cliquer avec la molette... mais pas la faire rouler...

Avec ça, je fais rouler mon MX500 :

Section "InputDevice"
    Identifier  "SourisUSB"
    Driver      "mouse"
    Option      "Device"        "/dev/input/mice"
    Option      "Protocol"      "ExplorerPS/2"
    Option      "Buttons"       "7"
    Option      "ZAxisMapping"  "4 5"
    Option      "SendCoreEvents" "true"
    Option      "Resolution"    "100"
    Option      "SampleRate"    "800" 
EndSection

IMPS/2 ça ne peut pas marcher pour une souris USB a priori (enfin ça serait pas très logique disons)

Sisi, ça marche, par exemple avec mon ancienne Wheel Mouse logitech (USB, avec molette). La seule diff avec ExplorerPS/2, c'est que explorerPS/2 gere plus de boutons...

./63> merci
à priori, ça tourne pas sous le 2.6
(ou alors, j'ai encore foiré quelque chose )
mais, avec un peu de chance, ça me permettra d'utiliser plus de boutons sous le 2.4

ça tourne pas sous 2.6 ???????
Heu, si si, j'ai un 2.6.6-mm5 actuellement, alors....

Par contre, y a-t-il le support "<*> Event interface" (input_evdev) dans ton kernel ? Si il n'y est pas, il faut le rajouter

Par contre, y a-t-il le support "<*> Event interface" (input_evdev) dans ton kernel ?

heu... j'en sais rien
comment dire... je suis un peu (enfin, un peu beaucoup même ) neuneu, une fois qu'on me parle de linux

Si il n'y est pas, il faut le rajouter

argh, horreur

Ça ne va pas marcher dans le 2.4 non plus, parce que /dev/input/mice, c'est du 2.6.

cf beaucoup plus haut :

KK, tu me déçois ... freeciv avec le son ... mais noooooooon ça sert à rien le son sur freeciv, à part faire comprendre à son boss que l'on ne travaille pas (tant que ça)

./69> argh...
argh...

/dev/input/mice, me semble l'avoir déjà croisé sur 2.4 ...

gandalf@hulk2:~$ ls /dev/input/mice  -l
crw-rw----    1 root     root      13,  63 Mar 14  2002 /dev/input/mice
gandalf@hulk2:~$ uname -a
Linux hulk2 2.4.26 #1 Wed Apr 21 13:52:12 CEST 2004 i686 GNU/Linux

hm :]

C'est bien ce qu'il me semblait, mais j'avais pas de Linux sous la main. (même que je parierai que c'est plus vieux que la date de sortie de la 2.6.0)

Tiens, une bonne réponse aux "reviews" qui descendent FC2 sans bonnes raisons: http://www.fedoranews.org/dowen/FC2/.

c'est petit comme réaction, un peu comme les minables éditeurs qui disaient que leur soft n'étaient pas stables à cause de l'OS à la grande époque des Win9X alors qu'en fait il livraient des choses mal testées/qualifiées... et après ça va se permettre de critiquer debian (qui préfère TOUT tester avant de realeaser, c'est plus "pro" comme attitude) qui ne fait pas N versions par an comme tel ou tel autre de ses concurrents...

vince> J'ai oublié de préciser que l'auteur ne travaille pas pour Red Hat et n'est pas un développeur de Fedora, c'est juste un volontaire de fedoranews.org, site totalement indépendant de Red Hat.

Je ne vois pas ce que ça change...

Getting the binary NVIDIA drivers working Other complaints have been that there are no binary drivers for NVIDIA cards for FC2. NVIDIA's site claims 2.6 kernel support. The default stack size in the FC2 kernels is only 4K, while the NVIDIA drivers require at least 8K of stack to work properly. Linuxant has recompiled the fedora kernels with 8k stacks. You can download them here.

Bref fedora est buggé...

J'ai utilisé plusieurs distributions 2.6 avec les drivers nvidia, j'ai jamais du changer quoique se soit au niveau param pour la pile du kernel

non, fedora n'est pas buggé a ce niveau, le 4k stack sera d'ici a la prochaine release stable du kernel par défaut dans le noyau (c'est actuellement optionnel) (2.6.7 d'après la lkml), et nvidia traine la pate pour mettre a jour ses drivers... c'est UNIQUEMENT la faute d'nvidia qui flemardise...

Bah, Fedora c'est une distrib qui sert de plateforme de beta-testing grandeur réelle (version en développement du kernel, nouvelle option à la mode mais incompatible avec les drivers nvidia, instabilité des drivers audio, pas de firewire parce que ça marche pas, problème de dual boot, etc...), normal que les gens se plaignent.
C'est plutôt bien pensé de la part de Red Hat, avec ça ils peuvent sélectionner ce qui marche bien pour l'intégrer dans leur Red Hat Enterprise Linux, qui est stable, lui.

guilc
: non, fedora n'est pas buggé a ce niveau, le 4k stack sera d'ici a la prochaine release stable du kernel par défaut dans le noyau (c'est actuellement optionnel) (2.6.7 d'après la lkml), et nvidia traine la pate pour mettre a jour ses drivers... c'est UNIQUEMENT la faute d'nvidia qui flemardise...

et pourquoi pas le passer a 2ko ? et pourquoi pas changer aussi l'ABI/API des modules en passant de la 2.6.7 a 2.6.8 aussi ?
non mais n'importe quoi

4k = taille d'une page de swap, donc ça me paraît difficile/peu utile de passer en-dessous

Pollux: non mais je voulait dire qu'il etait abérant de changer des trucs aussi sensible dans une révision mineure..

Godzil
: et pourquoi pas changer aussi l'ABI/API des modules en passant de la 2.6.7 a 2.6.8 aussi ?

L'ABI des modules change entre chaque version du noyau. C'est pour ça que NVIDIA ne fournit pas un module compilé, il le compile lors de l'installation (et il y a des versions pré-compilées pour des distributions spécifiques). Fixer l'ABI des modules reviendrait à fixer une interface interne du noyau qui est en constant changement. Linus s'y refuse.

Godzil
: non mais je voulait dire qu'il etait abérant de changer des trucs aussi sensible dans une révision mineure..

Ce n'est pas si sensible que ça. La seule incompatibilité quasiment c'est pour les modules binaires (qui vont être mis à jour). Par contre au niveau amélioration des performances, c'est très intéressant (surtout pour les gros serveurs qui gèrent des tonnes de threads).

Godzil : le 4KB_STACK est en testing depuis le 2.6.4...
Le but n'est pas de faire des changements rendant incompatibles les drivers nvidia, mais d'améliorer la réactivité du kernel, et de faciliter les allocations.

Par ailleur, j'ai vu sur le forum de nvnews (forum qui sert de base communicante a nvidia...) que les modifications a apporter au driver nvidia sont mineures (a ce que j'ai vu, ça se joue a 4 instructiosn assembleur...). Si je retrouve le lien, je vous le file. Donc bon, nvidia aussi se fout un peu de la gueule du monde...

Pour le Firewire, ça sera corrigé dans la prochaine mise à jour du noyau, et si vous en avez besoin tout de suite, il y a les RPMs dans Rawhide et dans l'espace web du mainteneur (Arjan).

Pour le 4KSTACKS et NVidia, si ça se joue vraiment à 4 instructions ASM, personne pour hacker leur driver?


Sinon: Si vous avez comme moi une carte son sans support matériel du MIDI, vous pouvez dès maintenant utiliser le MIDI dans toutes les applications (merci ALSA). Malheureusement, la version de TiMidity++ livrée avec FC2 est trop vieille (l'interface alsaseq est désactivée par Red Hat parce qu'elle ne marche qu'avec les très vieux ALSA), mais vous pouvez récupérer la 2.13.0 sur http://timidity.sourceforge.net. Ensuite:
./configure --enable-interface=alsaseq --enable-audio=esd
make CFLAGS='-Os -s'
cp timidity/timidity /usr/local/bin/timidity-2.13.0
ln -s /usr/share/timidity /usr/local/share/timidity

Et puis mon script /usr/local/bin/timidity-alsaseq:

#!/bin/bash
timidity-2.13.0 -iADq -s 22050 -EFresamp=l --sequencer-ports=1 --realtime-priority=1

Attention, ces règlages sont optimisés pour mon processeur relativement lent (733 MHz). Si vous avez du 2 GHz, les options -s 22050 (divise la samplerate par 2) et/ou -EFresamp=l (interpolation linéaire plutôt que par courbes) ne seront pas nécessaires.

Débrouillez-vous pour lancer ce script une et une fois à chaque utilisation du PC. (Le me demande quel est la meilleure méthode? /etc/rc.d?)

Kevin Kofler :
Pour le Firewire, ça sera corrigé dans la prochaine mise à jour du noyau, et si vous en avez besoin tout de suite, il y a les RPMs dans Rawhide et dans l'espace web du mainteneur (Arjan).

Pour le 4KSTACKS et NVidia, si ça se joue vraiment à 4 instructions ASM, personne pour hacker leur driver?


Sinon: Si vous avez comme moi une carte son sans support matériel du MIDI, vous pouvez dès maintenant utiliser le MIDI dans toutes les applications (merci ALSA). Malheureusement, la version de TiMidity++ livrée avec FC2 est trop vieille (l'interface alsaseq est désactivée par Red Hat parce qu'elle ne marche qu'avec les très vieux ALSA), mais vous pouvez récupérer la 2.13.0 sur http://timidity.sourceforge.net. Ensuite:
./configure --enable-interface=alsaseq --enable-audio=esd
make CFLAGS='-Os -s'
cp timidity/timidity /usr/local/bin/timidity-2.13.0
ln -s /usr/share/timidity /usr/local/share/timidity

Et puis mon script /usr/local/bin/timidity-alsaseq:

#!/bin/bash
timidity-2.13.0 -iADq -s 22050 -EFresamp=l --sequencer-ports=1 --realtime-priority=1

Attention, ces règlages sont optimisés pour mon processeur relativement lent (733 MHz). Si vous avez du 2 GHz, les options -s 22050 (divise la samplerate par 2) et/ou -EFresamp=l (interpolation linéaire plutôt que par courbes) ne seront pas nécessaires.
Débrouillez-vous pour lancer ce script une et une fois à chaque utilisation du PC. (Le me demande quel est la meilleure méthode? /etc/rc.d?)

Bon alors sérieusement ? quand est-ce qu'elle sort cette fedora core 2 en version stable ? parcque bon les béta, ça va un moment mais bon... et après ils vont nous sortir qu'ils ont eu un leak de sources c'est ça...

La mienne est très stable. J'ai eu 2 plantages, tous les 2 n'étant pas du tout de la faute de Red Hat:
* le premier, un plantage complet du système, causé par une tentative râtée de faire marcher le ALSA sequencing (j'ai essayé de faire un mélange des sources de TiMidity++ 2.11.3 et 2.13.0 pour le chargement dynamique d'interface, avec des résultats catastrophiques)
* le deuxième, un plantage de knotify lors du démarrage de KDE dû à un problème d'initialisation de aRts corrigeable à chaud ([Ctrl]+[Alt]+[BkSp]), probablement causé par mon "montage" de son excessivement complexe (aRts->ESD), qui n'est pas la configuration par défaut de Fedora
Bref, les seuls problèmes de stabilité sont de ma faute, et le deuxième n'était pas bien méchant.