Beiträge von Boreas

Du brauchst keine Programmierkenntnisse. Sauerland hat doch alles (die einzelnen Schritte, die Du durchführen musst) beschrieben.

also

git clone https://github.com/Myria-de/mt7610u_wifi_sta_v3002_dpo_20130916.git
cd mt7610u_wifi_sta_v3002_dpo_20130916
make
su
make install
mkdir /etc/RT2870STA
cp RT2870STA.dat  /etc/Wireless/RT2870STA/RT2870STA.dat

gut möglich, dass das Modem nicht richtig konfiguriert ist, denn

C: #Ifs=11 Cfg#= 1 Atr=e0 MxPwr=0mA

sollte so nicht aussehen. Leider kenne ich nicht die einzelnen Modi für Dein Modem, das offensichtlich mit einem Chip von Ericsson ausgestattet ist. Aber das Cfg#= 1 falsch ist, scheint für mich wahrscheinlich. Auch sollte der
max. Strom größer als mit 0mA angegeben sein. Was Dir wenig hilft - sorry. Es gibt ein perl-script, das erlaubt die Modi zu wechseln. Aber es setzt cdc_mbim als Treiber voraus - siehe hier und hier.

(Irgendwo habe ich noch ein HSPA+ Mobile Broadband mit Ericsson Chipset - ich schau mir das noch einmal an - kann jedoch ein paar Tage dauern.

@'Hedwig5
Poste bitte mal

usb-devices

(da bekommt man ein paar mehr Infos, die auch noch schön gelistet werden.)

Sollte jemand ein Notenbuch mit integriertem SD/MMC-Kartenleser nutzen und dieser vom
oben genannten Typ sein, so wird der Versuch SDXC-Karten zu lesen vermutlich fehlschlagen (gilt für openSUSE Leap 42.2).
SDHC-Karten bis Speed-Class 10 werden ohne Probleme vom genannten Reader gelesen und geschrieben.
Infos zu den Spezifikationen siehe hier
Wie oft bei GNU/Linux ist es dennoch mit wenig Aufwand möglich, diesem Problem beizukommen hier

Als Erstes solltet ihr prüfen, welcher Wert für die Option debug_quirks2 des Kerneltreibers sdhci_pci eingestellt ist (vermutlich 0x04). In einer root-konsole einfach

modprobe --show-depends sdhci sdhci_pci sdhci_acpi

eingeben und die gewünschte Auskunft wird erteilt .
Um diesen Wert zu ändern, müssen die folgende Kernelmodule entladen werden und anschließend die Option debug_quirks2
auf einen höheren Wert gesetzt werden. Jetzt das Kernelmodul erneut laden und prüfen, ob sich das gewünschte Ergebnis eingestellt hat.
Hier die Abfolge noch einmal zum besseren nachvollziehen:

modprobe -rf sdhci_acpi 
modprobe -rf sdhci_pci
modprobe -rf sdhci
modprobe sdhci debug_quirks2="0x1000"
modprobe sdhci_pci

Der Parameter f (force) ist bei mir notwendig gewesen - ist laut man-pages aber mit Vorsicht zu verwenden.
Sobald ihr eine funktionierende Einstellung gefunden habt, ist es sinnvoll, dass von Beginn, also bei Start des Rechners
dieser Wert für debug_quirks2 geladen wird.
Hierzu einfach eine Datei unter

/etc/modprobe.d/

erstellen, z.B. mit dem Namen "99-o2micro.conf".
Der Dateiinhalt muss mindestens folgende Zeile enthalten:

options sdhci debug_quirks2=0x1000

Falls jemand Probleme mit dem GPS-Empfang in Verbindung mit oben genannter WWAN-Karte von Broadcom, die in einem DELL-Notebook verbaut ist, haben sollte
- hier eine Beschreibung wie man die Karte zur Arbeit unter GNU/Linux motivieren kann.
Das Script

usb-devices

listet übersichtlich auf, welche USB-Geräte so im Rechner werkeln.
Hierbei wird auch die WWAN-Karte: Dell Wireless 5809e Gobi™ 4G LTE Mobile Broadband Card aufgeführt.
Entscheidend ist, welcher Treiber geladen wurde. Für den GPS-Empfang sollte dies "qcserial" sein und für die WWAN-Funktionalität "qmi_wwan".
Offensichtlich wird bei Leap 42.2 für die GPS-Funktionalität ein Treiber mit Namen "cdc_mbim" geladen. Damit ist jedoch kein
GPS-Signal abzurufen. Abhilfe schafft eine udev-Regel, die dafür sorgt, das "qcserial" als Treiber verwendet wird.
Die udev-Regel sieht wie folgt aus:

ACTION!="add|change", GOTO="mbim_to_qmi_rules_end"
SUBSYSTEM!="usb|drivers", GOTO="mbim_to_qcserial_rules_end"


# load qcserial module
SUBSYSTEM=="usb", \
        ATTR{idVendor}=="413c", ATTR{idProduct}=="81b1", \
        RUN+="/sbin/modprobe -b qcserial"


# force Dell WWAN 5809e to configuration #1
SUBSYSTEM=="usb", \
        ATTR{idVendor}=="413c", ATTR{idProduct}=="81b1", \
        ATTR{bConfigurationValue}="1"


# add the new id in the qcserial driver
SUBSYSTEM=="drivers", \
        ENV{DEVPATH}=="/bus/usb-serial/drivers/qcserial", \
        ATTR{new_id}="413c 81b1"


LABEL="mbim_to_qcserial_rules_end"

Diese Zeilen einfach in einer Datei speichern unter /etc/udev/rules.d/ z.B. mit dem Namen 99-gobi5809.rules.
Eigentümer: root, Gruppenzugehörigkeit: root, Dateirechte: -rw-r--r--
Testen könnt Ihr das ganze mit:

echo "\$GPS_START" >/dev/ttyUSB1
cat /dev/ttyUSB1


#beenden mit:
echo "\$GPS_STOP" >/dev/ttyUSB1

Hier noch die Links, die das viel besser beschreiben als ich das kann und die mir gezeigt haben, was zu tun ist.
1,2 und3.

Noch 2 Dinge: Damit der normale Nutzer, das auch machen darf muss er der Gruppe "dialout" angehören.
Wer navit nutzt kann ein kurzes Script schreiben, dass die Befehle hintereinander ausführt, also z.B.

#!/bin/bash
echo "\$GPS_START" > /dev/ttyUSB1
/usr/sbin/gpsd /dev/ttyUSB1
/usr/bin/navit
echo "\$GPS_STOP" > /dev/ttyUSB1

Viele Leute wollen alles immer schneller . Bringt der Geschwindigkeitszuwachs die erhoffte Befriedung und ein mehr an freier Zeit? Oder ist der Wunsch nach Geschwindigkeit nur eine andere
Form, um zu sagen, dass man mehr in die Tiefe des Systems eindringen will und seine (Un)kenntnis vergrößern will? Entschuldigung, das tut ja hier nichts zur Sache - scnr.
Wenn Du nach Dateinamen oder Dateinamenmustern suchst, ist i.d.R. locate die schnellere (bessere?) Wahl. Wichtig ist jedoch, dass die "Datei-Index-Datenbank", auf die locate zurückgreift "up to date" ist.
Auch sei erwähnt -> siehe man-file zu locate, das locate bestimmte Fallstricke aufweist - was jedoch generell für alle Programme gilt .
Im Übrigen kann die Ausführung auch von find bedeutend beschleunigt werden, sofern der Suchradius verringert wird. Das hängt direkt mit der Programmierung zusammen, denn typischerweise sind dieses Suchalgorithmen
(vgl. die Quellcodes) rekursiv programmiert.

Du bist hier im openSUSE-Forum - zum Installieren gibt das Konsolen-Installations-Schweizer-Messer

zypper

oder Du startest YAST (yast2 als Konsolenvariante). Die "Geschichten" mit android, die Du evtl. mit Deinem Post verfolgst sind besser hier oder bspw. hier zu finden.

Laut SUSE besteht ein Sicherheitsrisiko bei Freigabe der USB-Unterstützung für VirtualBox. Daher gibt es bei Installation von VirtualBox per default keine USB-Unterstützung, wenn VB aus den SUSE Repos installiert wird. Der Link von Sauerland auf die SUSE-Seite beschreibt, wie mittels UDEV-Regel diese Beschränkung aufgehoben werden kann. Die entsprechende UDEV-Regel wird bei der Installation von VB bereits mitgeliefert. Um jetzt die USB-Unterstützung für VB zu erhalten, musst Du lediglich die beiden Befehle wie angegeben ausführen. Nichts schlimmes also.

Imho sind die geposteten Listen im Hinblick auf Dein Problem nicht zu beanstanden - allerdings würde ich die Priorisierung der Repos überarbeiten.
Wie? Hier im Forum gibt es reichlich Hinweise dazu.
Wenn Dir der workaround über die pdf-Files nicht gefällt, musst Du Dich wohl oder übel mit den cups-Details beschäftigen.
Offensichtlich schlägt schon das saubere Erzeugen der postscript-Datei fehl. Evtl. könnte die ppd-Datei die Du unter
openSUSE 13.2 erfolgreich nutzt, das Problem lösen. Also würde ich diese einmal unter Leap 42.1 verwenden.

Bitte mal etwas klarer beschreiben.

Zitat von Wolle1956

Nachtrag:
Das betrifft nur mein o.g. Skylake-System.
Auf Haswell klappt alles.

D.h. mit einem Prozessor der Haswell-Generation klappt alles auch unter Leap 42.1?
Poste bitte mal was Sauerland hier beschreibt.