Beiträge von jrie

Meine Frage bezog sich auf:
"if you need multiple Product IDs, please indicate + explain this at the first message, rather than applying for a second ID later".
Die Black Magic Probe z.B. hat eine PID für den normalen Anwendungsmodus, und eine für den DFU-Modus (= Device-Firmware-Upgrade Mode).
Wir könnten sowohl im Bootloader von 1eaf:0003 zu 1d50:x wechseln als auch mit dem "STM32 IRMP HID-Device" von 0483:5750 zu 1d50:x+1.
Der Produkt String des Bootloaders könnte dann auch gleich von "Maple 003" auf "STM32 IRMP Firmware Upgrade" oder "STM32 IRMP Bootloader" geändert werden.
Manche Projekte haben viele IDs. Ich denke, die zwei reichen für uns.

Seht ihr das auch so?
Ich will es gleich beim ersten Anlauf "richtig machen".

Danke, openmoko gefällt mir wesentlich besser, da sind wir in "guter Gesellschaft".
Reicht uns eine PID?

Habe den Pull Request übernommen.
Zum Testen komme ich frühestens nächste Woche.

Bin mir nicht sicher, ob das Ändern der VID und PID nützlich ist.
Ich bitte um Kommentare.

Meine Einwände:
pid.codes gibt es erst seit ein paar Tagen. Wer weiß, ob die nicht bald weg geklagt werden oder sonstigen Ärger bekommen.
Eine andere VID als von STM kommt mir komisch vor. Ist schließlich ein STM device. Wer kennt schon VID 1209?
Über die PID können wir eher reden, die hatte ich früher schon mal geändert, aber beim Aufräumen wieder zurück gesetzt. Hätte das einen Vorteil für uns, die zu ändern?

Die Änderungen am Makefile gefallen mir.
Falls Ole die noch bestätigt, übernehme ich die so.

Deine Namensnennung hätte ich lieber in der CONTRIBUTORS als im usb_hid.patch.
So wie beim letzten Mal.

Ich komme allerdings erst nach Ostern zum Testen.

Mein Konfigurationsprogramm läuft jetzt auch auf Windows (Kommandozeile).
Es basiert auf https://github.com/signal11/hidapi.

Zitat von M-Reimer

Ich könnte ein neues Target einbauen. Zum Beispiel "extclean". Wobei ich mir das "vorbereiten, dass nochmal gepatcht wird" durchaus auch direkt im "make clean" vorstellen könnte. Wie siehst du das?

Ja, letzteres ist vielleicht sogar noch besser. Dann muss man nicht mehr dran denken . Das wäre ein Vorteil für Jemanden, der nicht so in der Materie drin ist.
Andererseits ist es vielleicht aber auch unerwartet, wenn plötzlich die Verzeichnisse weg sind.
Am schönsten fände ich, auch ein "make prepare" einzuführen, aber damals in der Diskussion mit Ole ist daraus nichts geworden.

Hat sonst noch jemand eine Idee dazu?

Danke für deine Arbeit. Sobald ich Zeit habe, werde ich es mal ausprobieren.

ext_src zu löschen ist nicht nötig, dann wird nur alles noch mal runter geladen. Besser ist es nur ext_src/prepared zu löschen. cmsis cmsis_boot irmp stm_lib usb_hid müssen auch gelöscht werden. Dann wird beim nächsten make alles neu gepatcht.
Insofern ist der Patch ok, aber erst "make distclean" und dann "make" führt zu unnötig wiederholtem Download der externen Sourcen.

Statt einen neuen Patch einzuführen, werde ich lieber den usb_hid.patch ergänzen. Da stecken auch schon andere Bugfixe drin.

Muss man eigentlich nicht auch noch usb_regs.h anpassen?

snr 38% ist wirklich wenig. Ich habe 76%.

./femon -H -a 1
FE: STV090x Multistandard (DVBS)
status SCVYL | signal  65% | snr  76% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  65% | snr  76% | ber 0 | unc 0 | FE_HAS_LOCK

Du dürftest tatsächlich an der Empfangsgrenze sein.
Viel Reserve können die Anderen dann auch nicht haben.
Da hilft nur Schüssel ausrichten ...

Wenn du einen Treiber benutzen würdest, der UNC und BER unterstützt, wie z.B. der von UFO, könntest du diese Werte auch beobachten. Die sind im Grenzbereich interessant.

Um zu wissen wie gut oder schlecht dein Empfang tatsächlich ist, wäre eine Messung mit femon nützlich.
Mit neu3 von hier oder ev. neu4 von dort noch besser vergleichbar.

Du hast x@.service ersetzt durch x@vt7.service.
Ohne lange drüber nach zu denken, das kommt mir komisch vor.

Übrigens, hier und da hat der Autor vom xlogin was über xlogin geschrieben.
Leider nicht sehr erhellend für mich.

Edit: Das ist auch interessant.

Ok, danke, teste ich mal.

Danke für den --chartab=ISO-8859-9 Tip.

Die Sprache wird bei openSuse in /etc/sysconfig/language eingestellt, aber da mein VDR als root läuft und ich die Fehlermeldungen auf Englisch bekommen möchte, nützt das nichts.
So bleibe ich wohl bei Environment=LANG=de_DE.UTF-8 LC_ALL=de_DE.UTF-8 .

ExecStart=/usr/bin/X :0 vt7 funktioniert bei mir bestens, allerdings starte ich im Xserver nichts außer xine oder manchmal softhddevice.
Was soll denn daran nicht zuverlässig funktionieren?

Früher musste man bei openSuse auf vt7 starten, keine Ahnung, ob das immer noch so ist.
Jedenfalls starte ich mit

ExecStart=/usr/bin/X :0 vt7

Frage zum Environment, wenn das so "böse" ist, wie übergibt man dem VDR korrekterweise seine Sprache?

Ich habe die Bootloader Patche zu einem gemerget und einen Fork mit M-Reimer's gcc 4.9 Patch und meinem Bootloader Patch in meinem github.

Kompiliert wird dann mit
make PLATFORM=Dev (Developer Board) bzw.
make PLATFORM=Red (Roter) bzw.
make PLATFORM=Blue (Blauer).

Das Ergebnis der Diskussion zum automatisches Starten von irmplircd http://www.vdr-portal.de/board…rten-von-udev-zu-systemd/ ist jetzt in der Bauanleitung und im github.

Ok, habe fnu gebeten, Seite 6 auszulagern.
Für mich ist der Übergang von udev zu systemd in der Diskussion sehr fliessend und kaum genau auf einen Post festzulegen, deshalb gleich die komplette Seite 6.

http://www.heise.de/newsticker…-auf-Systemd-2569272.html
Systemd scheint sich überall durchzusetzen.

Laut http://www.freedesktop.org/software/systemd/man/daemon.html gilt das, was früher galt, nicht mehr für Systeme mit modernen Init Systemen. Das betrifft auch Daemone/Systemdienste/services. Insbesondere gilt das für's Forken, man soll das nicht mehr benutzen, und die Vorteile, die das früher brachte, werden auf modernen Systemen anders hergestellt. Es wird sogar empfohlen, in alte Daemone die Möglichkeit im Vordergrund zu laufen einzubauen, damit sie besser in moderne Systeme integriert werden können.

Mit

cat irmplircd.service
[Unit]
Description=Start irmplircd on irmp_stm32 device
BindsTo=dev-irmp_stm32.device
#Wants=dev-irmp_stm32.device
After=dev-irmp_stm32.device


[Service]
#Type=simple
#ExecStart=/z/irmplircd/irmplircd -t /z/irmplircd/irmp_stm32.map /dev/irmp_stm32 -f
Type=forked
ExecStart=/z/irmplircd/irmplircd -t /z/irmplircd/irmp_stm32.map /dev/irmp_stm32
#PIDFILE=/run/.../irmplircd.pid


[Install]
WantedBy=dev-irmp_stm32.device

startet irmplircd zwar, ist aber gleich wieder beendet.
Was ist überhaupt der Vorteil, wenn irmplircd als Daemon läuft?
Wie bringt man das zum Laufen?
Sonst lasse ich es erst mal so.

Das ist der Pfad, wo es bei mir liegt. Normalerweise eher /usr/bin/ oder /etc/.
Und *.map ist die Übersetzungstabelle für irmplircd.

Und warum ist Type=simple zu bevorzugen?