Corentin Chary a écrit 174 commentaires

Oui .. en effet, sauf que ... On se base sur le format on-flash de UBIFS (et pas forcément avec UBI en dessous, mais la conversion est triviale avec EBM).
Donc, il y'aura de quoi lire.

En fait, pour faire un peu plus technique, uffs c'est:
- Un port de UBIFS en userspace sous linux, avec fuse
- Un port de UBIFS en userspace sous windows avec dokan
- Un futur port sous WinCE (kernelspace)
- Un futur port sous Windows (kernelspace)

L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).

Du coups, on fait une couche plus générique qu'UBI, qui peut gérer aussi les périphériques (sans wear leveling, ou avec, au choix). Mais on conserve les bonnes pratiques imposées par UBIFS (pas d'écritures plus petites que la taille d'io minimale, on essait d'écrire erase block par erase block).

Voila, pour plus de détails, allez faire un tour sur le site web !

Le but de mon message n'était pas de dire qu'on meure de faim, mais que le pouvoir d'achat ne se calcule pas en nombre de CD qu'on peut acheter avec son salaire. Rien d'autre.

> Il est donc absurde de nier que le pouvoir d'achat ait explosé.

Si t'achète que des chansons, oui, en effet. Mais je sais pas si t'as déjà essayé de manger un CD, c'est pas bon. Tu peux aussi t'habiller avec, te faire une maison avec ...

C'est pas comme ça qu'on calcul le pouvoir des chats =)

Hum, j'avais pas vu comme ça.
Oui en effet, mais hum, ce genre de trucs, ça devrait être un cran plus haut que tout les fs puissent en bénéficier ... Jvais voir ce qui se fait en ce moment pour ce genre de problèmes.

C'est notre projet de fin d'étude, le but est de répondre (entre autre) à cette problématique.
La bête est censée être portable, facile à installer (que ce soit sous Linux, Windows ou MacOS) et optimisée pour tout type de média à base de mémoire flash (SSD y compris).

Bon, le truc, c'est que y'aura pas de code utilisable avant un certain temps, mais ça avance !

En attendant .. ext{2,3,4} sans journal fera l'affaire.

c'est pas bon la tarte au concombre ....

iksaif@xfpc:/tmp$ tar -xf snowballz-0.0.3.tar.gz

gzip: stdin: unexpected end of file
tar: Fin prématurée (EOF) rencontrée dans l'archive.
tar: Fin prématurée (EOF) rencontrée dans l'archive.
tar: Erreur non récupérable: fin de l'exécution immédiate


et j'ai réessayé de télécharger deux fois.

En effet, pas encore de support pour le W6A. Envoie le contenu de /proc/acpi/dsdt et il y sera dans la prochaine version ;)

Bon .. bah je sais d'ou ça viens, c'est déjà ça. Par contre j'ai pas le temps de régler ça ce soir .. Et je vais me coder un analyseur de dsdt, parce qu'avec emacs et C-S ça suffit pas :D.
Je te prévient dès que j'ai un support complet du A2D :D (dans la semaine).

dmesg | tail donne quoi quand tu joue avec /proc/acpi/asus/lcd ? (lecture et écriture)

Heu .. bah en fait, le A2D j'ai pas encore rajouté le support, vu que je me suis vachement concentré sur le A6x et A3x là. Mais bon, ça devrais par être trop dur a faire, tu peux toujours essayer de modifier le fichier asus_acpi.c (dans acpi4asus/driver/ )

tu cherche ça :
{
.name = "A2x",
.mled_set = "MLED",
.wled_set = "WLED",
.wled_status = "\\SG66",
.lcd_switch = "\\Q10",
.lcd_status = "\\BAOF",
.brightness_set = "SPLV",
.brightness_get = "GPLV",
.display_set = "SDSP",
.display_get = "\\INFB"},

et tu remplace en ça :
{
.name = "A2x",
.mled_set = "MLED",
.wled_set = "WLED",
.lcd_switch = xxN_PREFIX "_Q10",
.lcd_status = "\\GO18",
.brightness_set = "SPLV",
.brightness_get = "GPLV",
.display_set = "SDSP",
.display_get = "\\ACTD"},
et après, comme dit au dessus, make rmmod etc ...
Ca va pas régler la question du resume, mais ça permettra de jouer avec le lcd.
Pour le suspend qui marche ou pas, ça peut être n'importe quoi, en général un pilote non libre genre wifi ou carte graphique.

y'a déjà un asus_acpi.c dans le kernel, c'est la version 0.30 de janvier avec quelques modifs, donc oui, y'a des chance que ça aille upstream.
Par contre si t'a un lien pour ton histoire de classe générique, je suis preneur ;)

Voila un aperçu :
http://xf.iksaif.net/linux/acpi4asus/acpi4asus-0.31b1.tar.bz(...)
Ca devrait gérer en plus :
A6J/A6R/A6B/A6K/A6V/M6-BV16R/F3J/A3N/A3L/A3E/A3F
Je suis en train de bosser a faire un tableau pour dire qu'est ce qui est supporté pour quel portable. J'essayerais aussi une fois la liste assez longue de modèles a supportée vide, d'améliorer asus_acpid, ou au moins les exemples de conf donnés avec.

Procédure de test :
tar -xjf acpi4asus-0.31b1.tar.bz2
cd acpi4asus/driver/
make
rmmod asus_acpi
insmod asus_acpi.ko (juste pour tester)

tester un par un les fichier de /proc/acpi/asus/ (après avoir lu le README)
Je suis assez intéressé par /proc/acpi/asus/disp (j'ai réussis a le faire marcher sur LCD + DVI, LCD + CRT, et je vais essayer sur LCD + DVI + CRT ...)

Voila .. je ferais un journal quand j'aurais un truc plus complet :)

J'ai donc sur papier a peu près de quoi gérer dix nouveaux modèles. J'ai repris le projet acpi4asus ( http://sourceforge.net/projects/acpi4asus/ ). Donc je vais intégrer tout ça, sortir une version de test, et je ferais un journal pour chercher des testeurs quand ça sera fait ^^. Enfin n'hésitez pas a envoyer des dsdt quand même !

vu que t'a un /proc/acpi/battery , si il fonctionne, t'a ptetre pas d'indicateur juste parce que klaptopdeamon est pas lancé :D

hum, pour clarifier la chose, la seule chose dont je compte *pour l'instant* m'occuper, c'est le support des nouveaux modèles dans le module "aus_acpi" qui gère les fonctions en plus ... Mais je peux toujours jeter un coups d'oeil aussi pour les autres trucs :p

Mais dans ton cas, ptetre que passer par l'utilitaire du bios pour recalibrer la batterie suffit ...

hum, et t'a quoi dans /proc/acpi ?

les trucs inutiles qui se trouvent dans /proc/acpi/asus/ .. c'est pas que ça serve franchement, c'est juste que j'ai trouver comment le faire marcher :D
par exemple, avec un echo 0 > /proc/acpi/asus/lcd je peux couper le rétroéclairage. /proc/acpi/asus/disp permet de gérer les sorties (CRT/LCD/DVI/TV-Out) quand on est en console (sous X, c'est le pilote qui à l'air de s'en occuper).
y'a aussi des trucs marrant, genre couper le bluetooth avec un echo 0 > /proc/acpi/asus/bluetooth ...
Pour plus d'infos, voir le readme d'asus_acpi =).

A chaque fois, j'aurais besoin de savoir ce que fait :
echo 0 > /proc/acpi/asus/lcd
echo 1 > /proc/acpi/asus/lcd

Si ça marche, ça devrait éteindre et allumer le rétroéclairage

ouep j'y ai pensé, et j'ai fait un tour là bas. Mais l'avantage de faire un journal c'est que je récupère des testeurs potentiels :p

oups, parlé trop vite, en fait y'a forcément un truc chiant qui change à chaque fois :D

bon, ça confirme mes doutes comme quoi le truc que j'ai fait marchera pour tout les A6xx ...
Par contre, le A6R n'a pas de prise DVI non ? (enfin, j'en vois pas de trace dans la dsdt).
J'attends d'avoir un peu plus de retour, et je file un patch correct ;)

Perso, j'ai un amd64 3200+ et 2Gb de ram
Le tout Gentoo (32bit) et j'obtient :

Firefox (2.0b2, avec des extensions) 1418ms
Konqueror (3.4.5) 2014 ms
Opera (9.02) 372 ms

Ce qui est quand même sacrément plus rapide que chez toi, avec un proc moins puissant.

j'aurais bien fait les tests avec wine pour rigoler, mais faut que je recompile mon kernel pour qu'il marche, donc la flemme :p.

Compiler a partir des sources ok, mais installer en utilisant portage uniquement, sinon autant pas avoir de distribution du tout si c'est pour encrader son système :)

Certains peuvent même pas y jouer parce que y'a pas clanlib 0.8 sous gentoo :'(