bah déjà tu as un kernel panic ('fin bon un warning mais c'est à peine mieux pour prendre en compte ton matériel) :/ ce n'est jamais très bon : souci d'initialisation de données, non adaptation/reconnaissance du matériel connecté... ça peut venir de pleins de choses.
L'idée c'est d'être robuste et pouvoir réinitialiser au déchargement / rechargement du module...
=> on ne voit pas très bien quelle action génère quelle trace : c'est toujours bien d'avoir un terminal affichant le journalctl -f en parallèle d'un terminal où l'on effectue les actions pour déterminer la réponse effective à chaque action.
=> pareil, je ne vois pas pourquoi tu passes de
qcom-camss acb3000.camss: VFE HW Version = 1.2.0
à
qcom-camss acb3000.camss: VFE HW Version = 1.5.0
pourquoi 2 versions différentes ? ça correspond à quoi ?
J'ai du mal à interpreter les résultats de dmesg n'étant pas de l'info.
ah c'était du dmesg et pas du journalctl ? => indique ta méthodologie pour débugguer :-)
en gros, il faut commencer par les couches basses : chargement du module par modprobe -i nom_module
logs correspondants, outils de diagnostic pour s'assurer que le matériel est correctement détecté
si ok, continuer avec actions de plus haut niveau, avec logs afférents
pareil outil de diagnostic que tout s'est correctement déroulé est correctement pris en compte (en s'assurant que dbus ne vient pas mettre la grouille au passage...)
En gros, savoir effectuer les actions séquentiellement et manuellement plutôt que de s'appuyer sur trop d'automatisation qui complique l'analyse...
La caméra est géré par liaison I2C et c'est le controlleur du driver camss qui renvoie cette erreur.
déjà voir avec les utilisateurs/développeurs de ce pilote s'ils ont un forum/une mailing-list/un chan IRC ou autre...
Ils te demanderont sans doute des informations complémentaires :
uname -a # pour voir quel noyau tu utilises
lspci -knn # pour voir quel matériel tu as et les éventuels pilotes le gérant
lsusb ; lsusb --tree # si c'est connecté en USB (a priori non) et quoi est connecté où
bah, tu peux essayer de le contacter, il est sympa :-) (je l'ai rencontré au Fosdem et j'avais un peu bossé avec lui pour ueagle-atm), il t'orientera peut-être mieux vers des utilisateurs plus spécialistes que lui (évite la LKML, spa le meilleur endroit pour obtenir du support... outre le fait que tu risques de faire exploser ta boîte mail)
Sinon, je vois que tu as un fairphone : essaie d'abord de voir sur leurs forums s'il y a d'autres utilisateurs dans ton cas.
A priori, tu n'auras pas besoin de recompiler de noyau, les pilotes ça suffit généralement si les interfaces n'ont pas trop changé...
Bon courage, tu n'es pas à l'abri de trouver un autre utilisateur ayant réussi à le faire fonctionner :-) Notez bien ce qui fonctionne correctement pour pouvoir avancer (et y revenir ensuite pour avoir une méthodologie reproductible)
[^] # Re: modinfo
Posté par BAud (site web personnel) . En réponse au message [Fairphone/PostmarketOS] : Adaptation d'un driver imx412 pour imx576. Évalué à 2.
bah déjà tu as un kernel panic ('fin bon un warning mais c'est à peine mieux pour prendre en compte ton matériel) :/ ce n'est jamais très bon : souci d'initialisation de données, non adaptation/reconnaissance du matériel connecté... ça peut venir de pleins de choses.
L'idée c'est d'être robuste et pouvoir réinitialiser au déchargement / rechargement du module...
=> on ne voit pas très bien quelle action génère quelle trace : c'est toujours bien d'avoir un terminal affichant le
journalctl -fen parallèle d'un terminal où l'on effectue les actions pour déterminer la réponse effective à chaque action.=> pareil, je ne vois pas pourquoi tu passes de
à
pourquoi 2 versions différentes ? ça correspond à quoi ?
ah c'était du dmesg et pas du journalctl ? => indique ta méthodologie pour débugguer :-)
modprobe -i nom_moduledbusne vient pas mettre la grouille au passage...)En gros, savoir effectuer les actions séquentiellement et manuellement plutôt que de s'appuyer sur trop d'automatisation qui complique l'analyse...
déjà voir avec les utilisateurs/développeurs de ce pilote s'ils ont un forum/une mailing-list/un chan IRC ou autre...
Ils te demanderont sans doute des informations complémentaires :
uname -a# pour voir quel noyau tu utiliseslspci -knn# pour voir quel matériel tu as et les éventuels pilotes le gérantlsusb ; lsusb --tree# si c'est connecté en USB (a priori non) et quoi est connecté oùd'après https://www.kernel.org/doc/html/latest/admin-guide/media/qcom_camss.html tu dois pouvoir contacter les gens de Linaro qui semblent avoir repris le sujet (je doute que qualcomm soit très coopératif vu que leurs docs' ne sont plus en ligne et dataient de 2016/2018...)
ah... je vois que c'est GKH qui est intervenu sur
https://git.codelinaro.org/clo/la/kernel/msm-3.18/
bah, tu peux essayer de le contacter, il est sympa :-) (je l'ai rencontré au Fosdem et j'avais un peu bossé avec lui pour ueagle-atm), il t'orientera peut-être mieux vers des utilisateurs plus spécialistes que lui (évite la LKML, spa le meilleur endroit pour obtenir du support... outre le fait que tu risques de faire exploser ta boîte mail)
Sinon, je vois que tu as un fairphone : essaie d'abord de voir sur leurs forums s'il y a d'autres utilisateurs dans ton cas.
A priori, tu n'auras pas besoin de recompiler de noyau, les pilotes ça suffit généralement si les interfaces n'ont pas trop changé...
Bon courage, tu n'es pas à l'abri de trouver un autre utilisateur ayant réussi à le faire fonctionner :-) Notez bien ce qui fonctionne correctement pour pouvoir avancer (et y revenir ensuite pour avoir une méthodologie reproductible)