Bah au niveau des boîtiers, j'suis pas sûr que ça soit vraiment compatible entre le B et le B+, si ?

Il vaut mieux acheter un boitier B+, mais un "vieux" doit pouvoir fonctionner, au pire après quelques coups de cutter ou de dremel. Ouais, c'pas top, mais bon, ça doit plus ou moins marcher.

De toute façon, un "B" ne se vend plus.

un boitier oui, il aime pas les photos, sinon il reboot.
Hu! Hu! Hu!

le truc impossible à identifier avant la mise sur le marché, quand même

Une question: je viens de voir qu'on peut violer un raspeberry pi pour en faire un serveur d'impression sans fil.
Question donc:
- pour que ce soit allumé, il a besoin d'un chargeur ?
- et question technique : mon imprimante est une multi-fonction avec scanneur intégré, les logiciels, ils feraient aussi serveur de scan ? Ou ça va dépendre de mon imprimante ?

PetitCalgon- pour que ce soit allumé, il a besoin d'un chargeur ?

Non, le Raspberry est livré avec la puce QualcommGalaxyPower qui, à travers d'une fine membrane cosmique, puise son énergie d'univers parallèles. Bon, j'ai du mal comprendre la question, mais : oui, il faut un chargeur (un bête chargeur USB ou micro-USB (je ne sais plus) suffit).

PetitCalgon- et question technique : mon imprimante est une multi-fonction avec scanneur intégré, les logiciels, ils feraient aussi serveur de scan ? Ou ça va dépendre de mon imprimante ?

J'ai pas regardé le lien (enfin, si, mais en vitesse) et ça repose sur CUPS. Donc c'est juste de l'impression : tes impressions vont être envoyées au CUPS du Rasp (ou directement à l'imprimante et dans ce cas le Rasp sert de relais, mais c'est pas une bonne idée si tu veux organiser/prioritiser les impressions, voire les loguer) et CUPS se charge du reste. Si ton imprimante est supportée par CUPS, c'est gagné. Mais rien coté scanneur ne fonctionnera grâce à ça. Si tu cherches juste à "parfois scanner un truc, quitte à faire la retouche (cadrage, etc.) après", ça doit être faisable si on peut récupérer automatiquement l'output du scan et la partager via Samba (soit directement, soit via un port USB par ex, qui émule un disque externe pour l'imprimante, et qui en fait sert de buffer pour le rasp).

Même réponse, mis à part que :

* ça peut s'alimenter via une batterie. Mais dans le cas dont tu nous parle, un chargeur de smartphone c'est son alimentation (micro usb avec sortie 5V et minimum 700mA, de préférence 1A)
* CUPS est ze logiciel de serveur d'impression. Pas de scan. Il existe peut être, probablement, un logiciel le permettant dans la galaxie linux.

GuybrushNon, le Raspberry est livré avec la puce QualcommGalaxyPower qui, à travers d'une fine membrane cosmique, puise son énergie d'univers parallèles.

Et qui plante quand on la prend en photo ?

Merci

Dommage pour le scanner, mon imprimante est une bête HP qui a 10 ans et qui doit être supportée (j'ai déjà dû réussir à la faire marcher avec Linux il y a quelques années de ça) mais j'aurais voulu pouvoir scanner depuis n'importe quel PC de la maison aussi avec. Actuellement seul le PC relié en USB à l'imprimante peut scanner et aucun autre. Et avec le partage d'imprimante standard Windows, tous les PCs peuvent imprimer à partir du moment où celui connecté en USB à l'imprimante est allumé. L'idée était de me libérer de ça.

Le scan en réseau, c'est bien plus complexe que l'impression partagée. Note importante : j'ai jamais fait, je peux me planter. L'impression, tant que tu as le pilote de l'imprimante sur ta machine, ça marche, et le résultat est centralisé sous forme de papier dans un réceptacle, que tu peux aller chercher quelques heures après.

Le scan, faut avoir le pilote, faut se déplacer physiquement jusqu'au scan pour fournir le papier, retourner sur l'ordi, faire un préscan, redimentionner le scan, décider d'un format de fichier, scanner, et mettre le fichier quelque part où il soit accessible. Et si t'as deux feuilles à scanner, rebelote. C'est autre chose qu'un ctrl+p où il suffit d'un pilote basique pour que ça marche.

Y'a probablement des logiciels libres qui te permettent de faire ça. Mais ça demande probablement d'autres principes, ne serait-ce que l'espace de stockage du scan effectué.

Tu peux sans douter bricoler quelque chose pour le scanner, ça dépend un peu de ce que le driver supporte exactement.
Ca dépend aussi des utilisateurs de l'appareil

Par exemple, si tu as la possibilité de détecter l'appui sur le bouton "scan" de ton imprimante depuis le Rasp (dépend du driver) ou d'avoir une pool dans laquelle les fichiers scannés sont placés (dépend du driver) ou de commander le scan depuis le Rasp (dépend du driver), tu as gagné. Il te suffit alors de récupérer le fichier et de le placer dans un partage Samba. Bien sûr, tu n'auras pas de fonction de "cadrage" via une GUI, ou quoique ce soit pour tuner ton scan... mais là encore, y a moyen de s'en sortir : il existe de bons outils graphiques pour scanner (Skanlite n'est pas mal dans le genre) sous Linux, et tu peux sans doute t'en sortir avec un bureau distant, ou encore un mini-serveur web qui t'affiche du GTK dans le navigateur. Ca dépend un peu de tes utilisateurs : s'ils sont prêts à se connecter en SSH et faire de la ligne de commande, y a aucun souci. S'ils veulent juste un truc simple "je clique/j'appuie et j'ai toute la page, je ferai le traitement moi-même après si besoin", pareil. S'ils veulent quelque chose de complet, avec une GUI de prévisualisation, etc. il est clair qu'il faudrait un outil capable d'utiliser un scanner connecté par le réseau. Et là, malheureusement, je crains qu'il n'y ait pas grand chose (à part utiliser un outil graphique sur le Rasp et, dans ce cas, se connecter "graphiquement" au Rasp d'une façon ou d'une autre (webapp, bureau distant, ssh/cygwin avec support léger de X11, ...).

TchouL'impression, tant que tu as le pilote de l'imprimante sur ta machine, ça marche, et le résultat est centralisé sous forme de papier dans un réceptacle, que tu peux aller chercher quelques heures après.

Avec CUPS, tu n'as même pas forcément besoin du driver localement sur ta machine. Tu peux soit le récupérer directement (pas très secure en général), soit utiliser un driver générique et communiquer uniquement avec CUPS, qui lui se charge d'utiliser son driver local pour faire les choses comme un pro.