Beiträge von mitscherdinger

    Hi!

    Unter "Einstellungen -> System -> Eingabegeräte" kann man eine "Unterstützung für Joystick und Gamepad aktivieren".
    Ich stelle mir das so vor, dass ich mein Gamepad damit als Fernbedienung für XBMC missbrauchen und in den Menüs herumswitchen kann. Warum tut sich dann nichts, wenn ich's aktiviere? Oder funktioniert das jetzt ganz anders?

    Ich nutze einen Snakebyte idroid:con Bluetooth-Controller, der nach dem Verbinden als /dev/input/js0 ansprechbar ist (getestet mit jstest).

    Grüße!
    Mitsch

    Hi!

    Seit meinem letzten Update von XBMC 12 aus dem deb-multimedia-Repositorium habe ich das Problem, dass sich der "Advanced Launcher" weigert, Programme auszuführen. Wenn ich das tun will erscheint nahezu verzögerungslos die Nachricht: "Fehler Script-Fehler!: addon.py" Alles andere (Videos und Musik abspielen, Wetter, andere Video- und Musik-PlugIns) funktionieren ohne Tadel.
    Das Problem besteht schon seit ein paar Tagen. Ich wollte warten, ob eine neuere Version das Problem behebt. Leider war das nicht der Fall. Gerade eben habe ich eine Aktualisierung von XBMC vorgenommen, leider besteht das Problem weiterhin. Die gerade installierte Version lautet "3:12.0~git201210-dmo2".

    Bevor ich einen Bugreport an deb-multimedia oder xbmc verfasse, wollte ich mal nachfragen, ob dieses Problem auch anderen hier in der Community bekannt ist und ob es evtl. eine Möglichkeit gibt, es zu beseitigen...

    Grüße!
    Mitsch

    Ach so!

    So Sachen wie: Bildschirmschoner oder Ausschaltknopf sperren, wird bei komplexeren Desktop-Environments normalerweise per dbus erledigt.Dbus ist allerdings seinerseits recht komplex, da blicke ich nicht durch. Wie das bei XBMC gelöst ist, vermag ich allerdings auch nicht zu sagen…

    Grüße!
    Mitsch

    Die Technologie die dahinter steckt bei ATI ist nicht VDPAU sondern VAAPI und daran wird momentan auch gearbeitet...ich meine ´, das ist sogar schon in den Nightlies drinne...


    Ich habe nochmal nachgeguckt: ATIs Beschleuniger heißt XvBA. VA-API ist von Intel. Aber wenn 'ne Software VA-API unterstützt, kann VA-API den Stream mittels irgendwelcher Bibliotheken an XvBA weiterreichen.
    Ich dachte, es wird an VDPAU für ATI gearbeitet, aber da hab ich mich wohl getäuscht…

    Aber egal: Hauptsache Hardwarebeschleunigung kommt! :)

    Grüße!

    Dringendsdes Feature wäre für mich die Unterstützung einer hardwarebasierten Video-Beschleunigung für Ati-Karten auf Linux, also entweder, dass XBMC seine Möglichkeiten um xv, xvmc oder xvba erweitert oder, dass X.org VDPAU für Ati möglich macht…

    Dann fände ich eine automatische Einrichtung von Icons für frisch installierte Software dufte - entweder in irgendeinen Launcher oder sonstwie in eine Menüstruktur. Bei sämtlichen grafisches Oberflächen funktioniert das ja auch ganz einfach.

    Und volle geil fände ich, wenn XBMC nicht seine eigene Python-Libs nutzt, sondern die vom System. Dann könnte ich ohne Frickelei nämlich Firefox und andere Python-basierten Sachen vom Launcher aus starten.

    Alle Wünsche waren für XBMC/Linux gemeint… :)

    Grüße!
    Mitsch

    Hi!

    Um das Ganze mal aufzuwärmen: Also, ich bin auf den "Advanced Launcher" umgestiegen, aber das Python-Problem ist dasselbe.

    Wie meintest Du das mit dem Script? Ich kann mir halt nicht gerade vorstellen, für jedes Spiel ein eigenes Script zu kreieren. Ich wüsste jetzt z.B. nicht einmal, welches Verzeichnis ich als PYTHONHOME oder PYTHONPATH angeben sollte.

    Das eigentlich ärgerliche ist doch, dass XBMC sein eigenes Python-Paket (2.4) mitliefert, anstatt das distributionseigene Python 2.7 (von Ubuntu) zu verwenden. Sollte doch abwärtskompatibel sein, oder? Ich würde es ja gerne ausprobieren, aber ich weiß absolut nicht, wo die Datei ist, die die Umgebungsvariablen für Python setzt. Das zu wissen, wäre schon mal ein Schritt nach vorne…

    Grüße!

    Hallöchen!

    Habe meine XBMC um Executor erweitert, um meinen HTPC um Browser- und Spielefunktionalität zu erweitern. Bin dabei auf ein überaschendes Problem gestoßen: Wenn ich Python-Programme vom Executor starten lasse oder wenn ich Python-Programme aus einem Terminal starte, das wiederum zuvor von Executor gestartet wurde, machen sie Probleme - bzw. starten sie erst gar nicht. Ich vermute, ich habe auch das Problem gefunden. In einem Terminal, das von Executor gestartet wurde:

    Code
    $ env|grep PYTHON
    PYTHONCASEOK=1
    PYTHONOPTIMIZE=1
    PYTHONHOME=/usr/share/xbmc/system/python
    PYTHONPATH=/usr/lib/xbmc/share/python/python24.zip


    Das könnte heißen, dass alle Python-Programme, die unter XBMC gestartet werden, nicht das vom Paketmanager installierte Python 2.7, sondern die von XBMC mitgelieferte 2.4 genutzt wird, was zwangsläufig Probleme mit sich bringt - auch, weil Python-Erweiterungen, die ich mit Aptitude installiert habe, ignoriert werden würden.

    Komisch ist allerdings, dass ich dieses Problem nicht schon immer hatte: Anfangs konnte ich beispielsweise "Frets On Fire" ohne Probleme starten. Das ist vielleicht zwei, drei Monate her.

    Frage an Euch:
    * Habt Ihr auch Probleme mit Python-Programmen, die mit Executor gestartet werden?
    * Wo werden eigentlich die Umgebungsvariablen(, die für Python relevant sind,) gesetzt? (Problem ist nämlich zum Beispiel auch, dass ich nicht in meinem /home/xbmc-Verzeichnis bin, wenn ich ein Terminal starte - da fehlt wohl eine Angabe für $HOME…)

    Grüße!
    Und danke für jede Hilfe

    Moinsen! Ich mal wieder!

    Habe es endlich geschafft, meine Bluetooth-Tastatur zum Laufen zu bekommen. Einziger Fehler: Das Tastaturlayout ist (vermutlich) us - jedenfalls sicherlich nicht de. Zunächst! Denn: Wenn ich ein Terminal öffne und "setxkbmap" eingebe, ist mein Tastaturlayout wieder deutsch.

    Frage: Jemand einen Vorschlag, wie man das mit 'ner BT-Tastatur hinbekommt, dass sie gleich das richtige Keyboardlayout verpasst bekommt? Wenn ich mit 'ner verkabelten Tastatur rummache, habe ich das Problem nicht! (Eintragungen in die xorg.conf werden also vermutlich nichts an der Situation ändern… Ich tippe eher auf irgendwelche udev-rules oder dbus-Geschichten.)

    Zu Erinnerung: Ubuntu Natty Minimal, Xorg, XBMC-Live - kein Desktop Environment. (Also auch kein GUI zum Einstellen von Hardware: Alle Einstellungen über Konsole. Das freut den Puristen… :) )

    Grüße!
    Mitsch

    Naja, wenn man ein gewöhnliches Desktop-Environment am Start hat, juckt die Einstellung ja eh nicht. Deswegen fällt's normalerweise auch niemandem auf…

    Die Einstellung funktioniert in einer kleinen Abwandlung jetzt übrigens, aber nur, wenn man "xset s blankoff" in die /etc/X11/xinit/xinitrc über die Zeile ". /etc/X11/Xsession" schreibt. Nach 10 Minuten wird der Bildschirm nur den Bruchteil einer Sekunde schwarz. Nicht so schlimm beim Spielen. Mit einer zweiten Zeile "xset s off" sollte es dann erledigt sein.

    Das Thema ist durch! Endlich!
    Auf zum nächsten! :)

    Man kann nicht sagen, die neue Einstellung hätte nichts geändert, aber…
    Nun ja, der Bildschirm wird trotzdem dunkel, weil: Linux is ja nich blöd. Kann ja auch ohne DPMS den Bildschirm schwarz machen. :)
    Kurz: Das ist leider immer noch nicht des Rätsels Lösung.

    Ein Hinweis käme von http://www.shallowsky.com/linux/x-screen-blanking.html
    Dort heißt es:

    Zitat

    In my case, it turned out that Ubuntu Breezy sets the dpms timeouts in /etc/acpi/power.sh, which gets called at boot time. So anything you set in xorg.conf may well get overridden.

    Falls es trotzdem interessieren sollte: die passenden Optionen für die xorg.conf lauten…

    Zitat

    Then, in the "ServerLayout" section (for Xorg 7.2 and later, make a separate ServerFlags section instead), include lines like this:

    Option "BlankTime" "4"
    Option "StandbyTime" "0"
    Option "SuspendTime" "0"
    Option "OffTime" "5"

    Mal ganz nebenbei bemerk, gibt es das Verzeichnis /etc/acpi auf meinem Rechner nicht…

    Noch ein anderer Fund aus den unendlichen Weiten des Internet-Universums: http://www.shellperson.net/prevent-screen-blanking/

    Zitat

    You can turn off X's screensaver by adding the following code to your .xinitrc:

    xset s off

    And you can verify that it worked by noting that the timeout is zero with "xset q":

    james@tv:~$ xset q
    ...
    Screen Saver:
    prefer blanking: yes allow exposures: yes
    timeout: 0 cycle: 600
    ...


    Ich bin so frei und schreibe den Befehl "xset s off" in die /etc/X11/xinit/xinitrc - finde ich besser als in die xorg.conf, weil es ja sein könnte, dass ich irgendwann den fglrx nicht mehr brauche oder gar nicht mehr verwenden kann und dann ist es gut, wenn ich auch keine xorg.conf mehr benötige. :)

    Test dann wieder morgen!
    Grüße!
    Mitsch

    Zerstört das nicht die Autokonfiguration? Sprich: Heißt das nicht, dass ich da eine komplette xorg.conf abliefern muss? Im Augenblick habe ich nämlich keine und mit der xorg.conf habe ich mich seit Jahren nicht mehr befasst. Sprich: Da lebe ich lieber mit dem Manko, alle 5 Minuten mit dem Mauszeiger zu wackeln oder ich frickel mir das lieber in irgendeinem Startscript mit diesem xset zurecht (falls das gehen sollte), als mich noch mal in die xorg.conf einzuarbeiten… :)

    Sorry, ich bin ein fauler Arsch. Danke trotzdem! :)
    (Mal sehen, vielleicht nervt's mich doch irgendwann genug…)
    Ich bin echt platt, wie schnell das immer mit den Antworten geht bei Euch!

    Grüße!
    Mitsch

    Au, Mann!

    Also, der Kernel-Parameter war richtig, um eine 0 in die Datei /sys/module/kernel/parameters/consoleblank zu schreiben. Ich dachte, das war's - weil die 600 Sekunden, die in dieser Datei per default stehen, nämlich genau den 10 Minuten entsprechen, die das System zum Bildschirm-Abschalten benötigt. Anscheinend aber hat das nichts mit X zu tun: Der Bildschirm wird weiterhin abgeschalten.

    In /etc/kbd/config gab es eine weitere Zeile, die aber, falls sie etwas mit meinem Problem zu tun haben sollte, ebenfalls - zumindest in dieser Datei - außer Funktion ist: POWERDOWN_TIME=30

    Ein weiterer Hinweis in dieser Datei gilt X. Es soll das Programm "xset" zum Einstellen von Energiespafunktionen genutzt werden. Käme auf einen Versuch an - aber ich fürchte, dass man das nach jedem Reboot ausführen müsste, was ja nicht Sinn der Sache sein kann. Man wird wohl irgendeine Datei in /etc/X11/ bearbeiten müssen. Falls jemand die Suche hier abkürzen kann, wäre ich natürlich dankbar. Ansonsten mach ich mich mal dran…

    Grüße!

    Ich glaube, ich hab's: Der Kernel-Parameter zum Abschalten der Bildschirmschoner-Funktion heißt "consoleblank=0" und wird in /etc/default/grub in die Zeile GRUB_CMDLINE_LINUX_DEFAULT= eingetragen.
    Also rebooten und checken. Wenn Ihr nichts mehr von mir hört, war's das!
    (Ich gehe davon aus, dass es funktioniert… :) )

    Grüße!
    Und Danke für's auf die richtige Spur führen!

    Mitsch

    Bei mir gibt's nur die Verzeichnisse /etc/console und /etc/console-setup. Aber ich kann die console-tools ja mal spaßeshalber installieren…
    UPS - nö, kann ich nicht: "conflicts with kbd"
    Hey, da gibt es aber eine /etc/kbd/config und darin folgende Zeilen:

    # screen blanking timeout. monitor remains on, but the screen is cleared to
    # range: 0-60 min (0==never) kernels I've looked at default to 10 minutes.
    # (see linux/drivers/char/console.c)
    BLANK_TIME=30

    Der Kernel selbst also ist der Übeltäter! Ich probiere mal, 'ne 0 einzutragen. Wenn's dann immer noch abschaltet, muss man wahrscheinlich mit sysconfig oder Kernel-Optionen oder so hantieren…