Category Archives: Fedora

es geht um scrcpy

Posted on by

Heute solls um ein kleines Projekt namens „scrcpy“ gehen. Das ist jetzt kein L33t-Speak ;), sondern stand wohl mal für „screen copy“, denn genau darum geht es: Eine Bildübertragung vom Handy zum PC – Live.

„scrcpy“

Das Projekt gibt es bei GitHUB im Genymobile Repo und man muß es selbst zusammen häkeln. Das stellt natürlich eine gewisse Hürde dar, daher hier eine kleine Hilfe, was man machen muß :

Schritt 1: Buildtools installieren

Dazu bitte als Root ausführen:

Wer noch kein RPMFusion für Fedora aktiviert hat, könnte es machen:

# enable RPM fusion free
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

Ansonsten braucht Ihr nur das hier:

dnf install SDL2-devel ffms2-devel meson gcc make java

Schritt 2 – Sourcen laden

Zunächst machen wir uns mal ein neues Arbeitsverzeichnis:

[marius@eve Programme]$ mkdir scrcpy
[marius@eve Programme]$ cd scrcpy/

Dann laden wir die Sourcen von dem Programm via git herunter:

[marius@eve scrcpy]$ git clone https://github.com/Genymobile/scrcpy
Klone nach ’scrcpy‘ …
remote: Counting objects: 2441, done.
remote: Total 2441 (delta 0), reused 0 (delta 0), pack-reused 2441
Empfange Objekte: 100% (2441/2441), 539.98 KiB | 1.27 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1417/1417), Fertig.

Nun brauchen wir noch den Server ( den kaputten Buildprozess für den Server überspringen wir hier, da es einen PreBuild-Server gibt, aber wir brauchen trotzdem einige Files aus dem Buildprozess):

[marius@eve scrcpy]$ wget https://github.com/Genymobile/scrcpy/releases/download/v1.3/scrcpy-server-v1.3.jar

Schritt 3 – Umgebung bauen:

[marius@eve scrcpy]$ cd scrcpy
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Program ./scripts/build-wrapper.sh found: YES (/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh)
DEPRECATION: build_always is deprecated. Combine build_by_default and build_always_stale instead.
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[30/31] Linking target app/scrcpy.

Wenn Ihr das hier lest:

[31/31] Generating scrcpy-server with a custom command.
FAILED: server/scrcpy-server.jar
/home/marius/Programme/scrcpy/scrcpy/server/./scripts/build-wrapper.sh ../server/. server/scrcpy-server.jar release
Downloading https://services.gradle.org/distributions/gradle-4.4-all.zip

und dann jede Menge Gradle-Schrottdownload-Meldungen erscheinen, hats mit dem eigenen Server nicht geklappt und es kommt der nächste Schritt:

Den Scheiss wieder löschen 😉

Das Ihr hier andere Pfade habt, muß ich glaube ich, nicht extra erwähnen, oder ? 😉

[marius@eve x]$ cd ..;rm -rf x
[marius@eve scrcpy]$ meson x –buildtype release –strip -Db_lto=true -Dprebuilt_server=/home/marius/Programme/scrcpy/scrcpy-server-v1.3.jar
The Meson build system
Version: 0.47.1
Source dir: /home/marius/Programme/scrcpy/scrcpy
Build dir: /home/marius/Programme/scrcpy/scrcpy/x
Build type: native build
Project name: scrcpy
Project version: undefined
Native C compiler: cc (gcc 7.3.1 „cc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)“)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency libavformat found: YES 57.71.100
Native dependency libavcodec found: YES 57.89.100
Native dependency libavutil found: YES 55.58.100
Native dependency sdl2 found: YES 2.0.7
Configuring config.h using configuration
Build targets in project: 6
Found ninja-1.8.2 at /usr/bin/ninja
[marius@eve scrcpy]$ cd x
[marius@eve x]$ ninja
[31/31] Linking target app/scrcpy.

Schritt 5 – Installieren

[marius@eve x]$ sudo ninja install
[sudo] Passwort für marius:
[0/1] Installing files.
Installing app/scrcpy to /usr/local/bin
Stripping target ‚app/scrcpy‘
Installing server/scrcpy-server.jar to /usr/local/share/scrcpy

Schritt 6 – Starten

Trommelwirbel und …

und wie man an dem Bild schon sehen, daß Ganze funktioniert nur, wenn man in den Entwicklereinstellungen des Handies das USB-Debugging erlaubt.

man sieht die Android Oberfläche mit Icons

Nun kann man, wenn man kann, mit der Maus das Handy auf dem PC fernsteuern, Eingaben machen, Programme starten, Surfen, Spielen, Videos schauen und mit SimpleScreenRecorder auch Tutorials vom Handy aufnehmen.

Wenn das böse Wenn nicht wär.

Die Sache mit dem Wenn man kann ist fies. Die Verbindung zu meinem Handy lebt nur wenige Sekunden, aber andere Handies bekommen das auch dauerhaft hin, wie Malte aus unserer LUG neulich demonstriert hat.

Es kommt also auf das Android ROM an, das auf dem Handy läuft. Wer eine Alternative sucht, kann Teamviewer für Android nutzen, das bekommt das deutlich stabiler auch auf einem Stock-ROM hin. Aber wer weiß dann schon, wer da mitliest.

Am Ende dann nicht vergessen den Gradle Kram wieder zu entfernen: rm -rf ~/.gradle

Nemo und die QMMP-Playlistfunktion

Ihr wollt Euch möglicherweise diese Action unten zu Eurem Nemo-Dateibrowser hinzufügen:

Location: ~/.local/share/nemo/actions/addmp3toqueue.nemo_action

[Nemo Action]
Name=Add to QMMP-Playlist
Comment=QMMP Playlistadder

Exec=<addmp3toqueue.sh %F>

Icon-Name=soundconverter

Selection=Any
Separator=;

Extensions=oga;mp3;acc;m4a

Früher gabs die Funktion direkt, wenn man QMMP hatte, aber seit einigen Versionen ist die reine Hinzufügen von Files zur Playliste in das „mit einem anderen Programm öffnen“ Menü gewechselt, was bei mehr als einem File zum Problem werden dürfte. Mit der Action ist das jetzt allerdings wieder möglich.

Hier noch das Shellscript dazu :

Location: ~/.local/share/nemo/actions/addmp3toqueue.sh

#!/bin/bash

IN=$*

IFS=";" read -ra FILES <<< "$IN"
for i in "${FILES[@]}"; do
      qmmp --enqueue "$i" 
done

Falls WordPress da wieder so komische Striche daraus machen sollte, es ist 2x ein einfacher Bindestrich.

\o/ Liebe Grüße an unsere mexikanischen Linuxfreunde ! Ich weiß, daß Ihr mich als Quelle verlinked \o/
\o/ Saludos a nuestros amigos mexicanos de Linux! Sé que me vinculaste como una fuente. \o/

Lokale Shell-Befehle einbinden

Posted on by

„ls -la“ kennt Ihr vermutlich aus jedem Konsolen-Tutorial für Linux. Aber habt Ihr auch schon mal einen lokalen Befehl nur für Euch gebaut ?

Globale oder Lokale Befehle ?

Globale Befehle kennt vermutlich jeder Linuxuser, denn alles was in /bin/ als Programm abgelegt und für alle Benutzer ausführbar ist, kann aufgerufen werden. Meistens laufen diese Programme im Context des aufrufenden Benutzers. Ausnahmen gibt es nur, wenn das SETUID-Flag gesetzt ist, dann darf jemand einen Befehl als ein bestimmter User ausführen. Üblicherweise ist das Root, aber andere user sind auch denkbar. „ls“, „find“, „uname“ usw. sind solche Befehle. So weit, so normal.

Wer den Videobeitrag Wie starten sich eigentlich Programme? gesehen hat, der ist da jetzt schon weiter, denn dort wird das genau erklärt. Kann ich Euch nur empfehlen, weil damit ist das hier möglich :

[marius@eve ~]$ firefox
Ich bin aber nicht der FireFox!
insgesamt 20
drwxrwxr-x. 2 marius marius 4096 14. Jul 09:45 .
drwxr-xr-x. 5 marius marius 4096 5. Jul 23:48 ..
-rwx——. 1 marius marius 100 14. Jul 09:45 firefox
-rwx——. 1 marius marius 112 5. Jul 23:48 fixrom
#!/bin/bash

echo „Ich bin aber nicht der FireFox!“

ls -la ~/.local/bin/
cat ~/.local/bin/firefox

[marius@eve ~]$

„Nicht die Mama“

Ok, Firefox ist jetzt nicht mehr Firefox .. super.. Browser kaputt gemacht 🙁 Was wäre, wenn im System ein Firefox Quantum installiert ist, der User aber Quantum ******** findet und lieber noch FF 52 ESR nutzen will? Egal welches Programm Firefox für seine Webseitendarstellung aufruft, es wird immer der systemweit installierte Firefox genommen. Der kleine Trick hier könnte das auf den Firefox ESR umleiten. Das wäre nur lokal für diesen Benutzer der Fall.

Wesentlich praktischer ist das andere kleine Programm in dem .local/bin Verzeichnis: fixrom . Wer den Beitrag über das fehlerhafte Fehlerfenster bei Runes of Magic gelesen hat, der weiß was es tut: Es verschiebt ein Fenster, daß nutzlos im Weg ist und dazu noch so defekt, daß man das nicht per Maus machen kann.

Da ich das kleine Script in das Lokale Bin-Verzeichnis verschoben habe, kann ich es von überall aus aufrufen und muß nicht mal den Pfad kennen, wo es wirklich liegt. ALT+F2 und die Eingabe von „fixrom“ startet es genauso, also wenn ich es in der Konsole eingebe. Ich kann es auch pauschal in die Desktopicons einbauen:

[marius@eve ~]$ cat Schreibtisch/Runes\ of\ Magic.desktop | grep Exec
Exec=env WINEPREFIX=“/home/marius/.wine“ wine C:\\\\windows\\\\command\\\\start.exe /Unix „/home/marius/Programme/GameforgeLive/Games/DEU_deu/Runes Of Magic/Runes of Magic.exe“

Dann würde es direkt nach dem Start von Runes of Magic gestartet werden und mir das Fenster sofort vom Hals halten. Aber, dann würde es auch bei jedem Start laufen und es muß nur eine Instanz davon aktiv sein, daher starte ich das von Hand. Gut, ich könnte das Script auch mit einem PID File versehen und prüfen ob es schon läuft und dann den Start umgehen, zeige ich vielleicht sogar mal 🙂

A Truth about Red Hat

Der vollständigkeithalber muß ich erwähnen, daß das mit dem Firefoxersatz unter Fedora nur klappt, wenn man seinen Pfad korrigiert. Wer nicht weiß was ein Pfad ist, schaut sich bitte das Video an. So sieht der Pfad unter Fedora aus:

$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/sbin:/usr/sbin:/home/marius/.local/bin:/home/marius/bin:/usr/sbin/:/usr/sbin

So müßte er aussehen:

[marius@eve ~]$ echo $PATH
/home/marius/.local/bin:/home/marius/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/sbin:/usr/sbin:/usr/sbin/:/usr/sbin

macht man übrigens so :

[marius@eve ~]$ export PATH=/home/marius/.local/bin:/home/marius/bin:$PATH

Natürlich müßt Ihr meinen Usernamen in Euren Änderungen durch Euren Namen ersetzen 😉

Wieso Fedora/Red Hat den Pfad so unbrauchbar gemacht haben, ist mir ein Rätsel, denn genau für solche Spielereien sind die lokalen Bin-Verzeichnisse da. Jetzt könnte man argumentieren, daß ein Angreifer damit den (im Beispiel) Firefox lokal ersetzen könnte und so ggf. noch mehr Schaden beim User durch Spionage anrichten kann. Das wäre zwar richtig, aber jeder, der von Remote da was hinlegen kann, kann noch ganz andere Dinge und hätte das Angriffsszenario nicht nötig 😉

Solange man aber nicht vor hat, ein Systemprogramm zu ersetzen, ist der Pfad eigentlich egal, nur .local/bin/ müßte halt drin vorkommen.