Beiträge von kls

    Da fällt mir ein, der "Transfer-Mode" (cTransfer) benutzt ja auch ein cControl. Somit scheidet mein Vorschlag von oben auch schon gleich wieder aus, denn sonst würde der VDR im Live-TV-Modus auch nie runterfahren.


    Also bleibt wohl nur, den Patch zurückzuziehen und das Radio-Plugin muss sich etwas anderes überlegen. Was muss es auch ständig das OSD offen halten?


    Klaus

    Das ursprüngliche Problem wurde von Ulrich Eckhardt berichtet und bestand darin, dass das Radio-Plugin dauerhaft ein OSD offen hält, um die RDS-Daten anzuzeigen. Der Patch sollte dafür sorgen, dass der VDR trotzdem automatisch heruntergefahren wir. Nun weiß ich nicht, ob das Radio-Plugin ein cControl anlegt für seine Wiedergabe (ich fürchte ja). Wenn nicht, dann könnte es helfen, in vdr.c die Zeile


    if (!cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {


    in


    if (!cControl::Control() && !cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {


    zu ändern. Sollte aber das Radio-Plugin tatsächlich ein cControl anlegen, dann würde ich eher dazu tendieren, den ganzen Patch zurückzuziehen und zu sagen, dass, wenn ein cControl aktiv ist, der automatische Shutdown halt eben ausgehebelt ist.

    Kann bitte mal jemand klären, ob das Radio-Plugin ein cControl benutzt?


    Klaus

    Zu den Warnungen in recording.c:


    Zeile 2901 sieht bei mir in VDR 2.4.0 so aus:

    FileName::~cFileName()

    also handelt es sich wohl um eine gepatchte Version.


    Die memcpy()-Stelle hat nur mit dem Index zu tun, kann also an der falschen Sortierreihenfolge nicht schuld sein.


    Ich glaube zwar nicht, dass die strncpy()-Stelle etwas damit zu tun hat, aber um das auszuschließen wäre es zunächst interessant zu wissen, ob beim Start von VDR die Option --dirnames oder --vfat angegeben wurde.


    Am besten baut ihr mal in der Funktion cRecording::SortName() (in recording.c) ein paar Debug-Ausgaben ein um zu sehen, welche Namen da für die Sortierung erzeugt werden.


    Klaus

    Danke für den Test. Vielleicht sollte ich erstmal klären warum "setxkbmap -query" bei mir etwas anderes liefert.

    Ich habe die Spur jetzt nach /etc/X11/xdm/keytable und weiter nach /etc/X11/xorg.conf.d verfolgt. Dort steht bei mir in /etc/X11/xorg.conf.d/00-keyboard.conf:

    Code
    1. # Written by systemd-localed(8), read by systemd-localed and Xorg. It's
    2. # probably wise not to edit this file manually. Use localectl(1) to
    3. # instruct systemd-localed to update it.
    4. Section "InputClass"
    5. Identifier "system-keyboard"
    6. MatchIsKeyboard "on"
    7. Option "XkbLayout" "us"
    8. EndSection

    Irgendwie soll diese Datei wohl via /etc/X11/xdm/keytable erzeugt werden, aber ich schaffe es nicht, da was anderes als "us" reinzubringen.

    Kannst du bitte mal den Inhalt deiner /etc/X11/xorg.conf.d/00-keyboard.conf posten?


    Klaus

    openSUSE speichert diese Dateien anscheinend in /usr/share/X11/xkb/symbols.

    Ein "setxkbmap -query" liefert bei mir


    rules: evdev

    model: pc105

    layout: us


    was etwas verwunderlich ist, denn ich habe als Tastaturbelegung bei der Installation "German, nodeadkeys" angegeben.

    In der Hoffnung, meine via Xmodmap eingestellte Tastaturbelegung auf einfache Weise dort hinterlegen zu können, habe ich mit "xkbcomp $DISPLAY" eine Datei server-0.xkb erzeugt, die vom Aufbau her den Dateien in /usr/share/X11/xkb/symbols recht ähnlich sieht. Diese habe ich dann unter /usr/share/X11/xkb/symbols/us gespeichert und den X-Server neu gestartet - mit dem Ergebnis, dass überhaupt keine Tastatureingaben mehr möglich waren :-(. Nachdem ich die ursprüngliche "us"-Datei wieder eingespielt hatte, funktionierte es zumindest wieder so wie vorher.


    Ich hänge meine server-0.xkb mal hier dran, vielleicht kannst du ja erkennen, warum diese nicht apzeptiert wird.


    Klaus


    Dateien

    • server-0.xkb.gz

      (8,05 kB, 9 Mal heruntergeladen, zuletzt: )

    Einen Aufruf von xmodmap (direkt oder über udev) wollte ich eigentlich vermeiden, denn das dauert einige Zeit, während der der Desktop teilweise recht träge ist und die Tasten eben noch nicht richtig belegt sind.


    Was ich erreichen möchte ist, dass das System meine Tastenbelegung als "nativen Default" benutzt. Irgendwo muss es ja wohl eine Datei geben, die hierfür zuständig ist


    xkbcomp hab ich gerade nochmal probiert, es bringt aber auch auf dem neuen System die o.g. Meldungen.

    Müsste ich das als root laufen lassen? Oder müsste ich das server-0.xkm File irgendwo hinkopieren, wo es beim Start greift?


    Klaus

    Nachdem ich dieser Tage meinen Arbeitsrechner neu installieren musste (openSUSE Leap 15.0), greife ich diesen etwas älteren Thread nochmal auf, in der Hoffnung, dass vielleicht noch jemand eine Idee hat, die zur Lösung des Problems führt.


    Ich benutze eine Apple Aluminium Tastatur, auf deren Tasten ich die zum Programmieren nötigen Sonderzeichen wie z.B. '[]{}\@' an meine gewohnten Stellen gelegt habe. Dazu benutze ich eine Datei die Keycodes wie z.B.

    Code
    1. keycode 39 = odiaeresis Odiaeresis braceleft
    2. keycode 40 = adiaeresis Adiaeresis braceright
    3. keycode 41 = less greater bar

    enthält. Diese gzippe ich und kopiere sie nach /usr/share/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz, ersetze also damit die vom System installierte Version dieser Datei.

    In /etc/vconsole.conf steht bereits von der Installation her "KEYMAP=mac-de-latin1-nodeadkeys", so dass ein "mkinitrd" die von mir veränderte Datei für künftige Sysetmstarts einbaut. Nach einem Reboot habe ich dann an den virtuellen Konsolen (tty1 etc.) die gewünschte Tastaturbelegung.


    Für den Desktop unter X11 habe ich die Tastaturbelegung bisher über ~/.Xmodmap gemacht, aber leider geht diese Belegung verloren, sobald die Tastatur vom USB-Port abgetrennt wird (ich schalte wie oben erwähnt über einen KVM-Switch zwischen verschiedenen Rechnern um). Nach dem Zurückschalten auf den Desktop-Rechner muss ich jedesmal erst wieder "xmodmap ~/.Xmodmap" machen.

    Nun habe ich versucht herauszufinden, wo die Default-Tastenbelegung liegt, die X11 verwendet (wenn der Benutzer keine ~/.Xmodmap hat). Wenn ich diese (so wie oben für die virtuellen Konsolen) austauschen könnte, dann wäre der Default gleich für mich passend. Nur leider finde ich nicht heraus, was das Äquivalent zu /usr/share/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz für X11 ist.


    Kann da jemand weiterhelfen?


    Klaus

    Nachdem ich auf meinem Arbeitsrechner openSUSE Leap 15.0 installiert habe ist die Belegung der F-Tasten plötzlich invertiert. Wenn ich z.B. 'F3' drücke, werden alle offenen Fenster verkleinert angezeigt, anstatt die Funktion 'F3' an die laufende Applikation weiterzugeben. Ich muss jetzt jedesmal 'fn+F3' drücken (gilt für alle F-Tasten).


    Im Web fand ich viele Hinweise, dass man das im BIOS einstellen können soll. Aber mein BIOS hat keine solche Einstellung. Und ausserdem hat es vorher (mit openSUSE 42.3) auch einwandfrei funktioniert.


    Weiß jemand Rat?


    Klaus

    "pactl list sinks" liefert

    Eine "/etc/asound.conf" gibt es nicht (auch nicht auf dem alten System).

    Was es gibt (identisch auf beiden Systemen) ist eine "/etc/asound-pulse.conf":

    Eine "~/.asoundrc" gibt es nicht (meine Home-Directory ist in beiden Fällen das Gleiche).

    Ich war heute leider gezwungen, meinen Arbeitsrechner neu zu installieren (Leap 15.0, war vorher 42.3).

    Leider funktioniert die Tonausgabe über HDMI jetzt nicht mehr.

    Mit 'aplay -l' erhalte ich zwar

    Aber wenn ich mit YaST versuche, den Sound zu konfigurieren, sehe ich nur "Sunrise Point-H HD Audio" und nichts mit "Intel" oder "HDMI".

    Mit Leap 42.3 hat das prima funktioniert (bis auf das Problem von hier, das sich aber durch Abwarten und Updates irgendwann von selber erledigt hat. Zumindest ging damals der Ton, aber jetzt geht momentan gar nichts :-(.

    Kann mir hier jemand weiterhelfen?


    Klaus

    Die ~/.inputrc war auch schon vorher da, enthielt aber immer nur Kommentare.

    INPUTRC wurde und wird in /etc/profile gesetzt:

    Code
    1. if test -z "$INPUTRC" ; then
    2. INPUTRC=/etc/inputrc
    3. test -s $HOME/.inputrc && INPUTRC=$HOME/.inputrc
    4. export INPUTRC

    was sich durch den Update auch nicht geändert hat.

    Wenn ich ~/.inputrc lösche, dann funktioniert es wieder wie vorher.

    Merkwürdig, aber zumindest kann ich jetzt wieder arbeiten.

    Danke für die Hilfe.


    Klaus