Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
Nicht zu vergessen das Ubuntu / Canonical einfach funktionierende Pakete aus den Repositories entfernt und durch Snap ersetzt hat.
Ist ja so schön praktisch...

Das die a) keiner wollte und die b) wie nen Sack Schrauben laufen ist dann das I-Tüpfelchen.
Dazu werden die nicht mehr über bisherige Wege aktualisiert, sondern irgendwie macht das das Programm dann von alleine, oder auch nicht.

Dann immer mehr Werbung im apt-get einbinden, die 20.04 User vom Mainline repository aussperren ohne sich zu äußern (https://askubuntu.com/questions/133...epends-on-libc6-2-33-non-installable-in-focal).

Ich teste jetzt Arch auf einem Notebook.
Sieht gut aus, habe zwar kein Netzwerk... sieht aber gut aus :heul:

Ehrlicherweise hoffe ich darauf das dank Steamdeck das SteamOS endlich mal von Debian 8 auf 11 gehoben wird, das würde mich reizen.
Ansonsten stecke ich grade fest.
Linux Mint -zumindest das auf meinen Odroids- hat mich zur Weißglut getrieben.
Arch stehe ich ganz am Anfang und würde ehrlicherweise irgendwas auf dpkg/apt Basis stark bevorzugen, schon alleine weil ich andauernd die falsche Syntax in Pacman haue -.- .
(Oder ich zwar gerne mal die ein oder andere Stunde in was reinstecke, aber in Arch vieles nur funktioniert wenn man vorher die Wiki gelesen und ausführliche Webrecherche betrieben hat und dann mit 4 Anleitungen da steht die alle etwas leicht anders machen).

Ich hänge also auf Kubuntu 22.04 fest, habe nen paar dutzend externe Repositories eingebunden, da es die bei Ubuntu nicht mehr gibt, ärger mich über Werbung in apt und warte auf den Stein der Weisen.

Und auf SteamOS auf Debian 11 kannst du wohl lange warten, denn das Steamdeck läuft mit Arch. Wenn überhaupt wird SteamOS darauf umgestellt. Und ehrlich gesagt: Wenn man was zum (auch) zocken haben will ist alles Debian-basierte (das nicht Ubuntu heißt) einfach ungeeignet aufgrund der konservativen (und das ist die höfliche Betrachtungsweise - aus der Perspektive des zockens betrachtet) Packetveröffentlichung. Ubuntu geht allerdings garnicht, aus den von dir beschriebenen (und vielerlei ähnlichen) Gründen.

Was deine Arch-Probleme angeht: Intel WiFi? Da gibts für den AX200 ne Kernel-Regression die echt HART nervt. Wenns daran liegt kann ich vielleicht helfen.
Ansonsten: Gib Manjaro nen Versuch. Mit pamac brauchst du da pacman garnicht. Alternativ Garuda, das ist fürs zocken zur Zeit wohl die Speerspitze.

Was Snaps, Flatpacks und ähnliche Electron verseuchte Geschichten angeht: Don't. Just don't. Nativ oder direkt zum kompilieren ist das einzige das dauerhaft funktioniert und das System nicht total zumüllt und unsicher macht.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hm also mit Mint komme ich gut zurecht, aber er kapiert nicht dass ich eine dedizierte GPU habe mit der ich gerne auch was spielen würde.

Er spielt dann automatisch mit dem IntelHD3000 Ding, welcher natürlich nicht wirklich ausreichend potent ist...

Unter Ubuntu konnte ich direkt mit Rechtsklick auswählen "mit dedizierter Grafikkarte starten"...

Wie bekomme ich Mint dazu?
 
@Shihatsu ich habe mit meiner Dorfleitung hier bis morgens um drei fürs Setup auf dem Notebook gebraucht.
Ich ging allerdings nicht davon aus das ich irgendwas fürs LAN / WLAN installieren müsse, da ich es ja bereits für das Setup mit dem Scannen nach SSID und Eingabe des Passworts erfolgreich verbunden hatte.
Also habe ich das Ding dann mehrere Stunden runterladen und installieren lassen, freute mich als es morgens nach dem Aufstehen fertig wurde.
Startete neu und tadaaaa, fertig die 100% offline Kiste.

Ich werde das bei Gelegenheit nochmal wiederholen :)
Auch Danke für das Hilfsangebot, evtl. komme ich darauf zurück. Aktuell bin ich aber noch am abwägen was ich jetzt da drauf installiere.

Edit sagt: Garuda sieht interessant aus. Wenn es das jetzt noch mitm normalen KDE gäbe... mal reinlesen, danke für den Tip.
 
Zuletzt bearbeitet:
Garuda hat doch auch ne KDE Lite Version (for advanced Users, ganz unten auf der Garuda Seite) ... kann dir darüber allerdings nix sagen - mag KDE einfach nicht.
 
Hm also mit Mint komme ich gut zurecht, aber er kapiert nicht dass ich eine dedizierte GPU habe mit der ich gerne auch was spielen würde.

Er spielt dann automatisch mit dem IntelHD3000 Ding, welcher natürlich nicht wirklich ausreichend potent ist...

Unter Ubuntu konnte ich direkt mit Rechtsklick auswählen "mit dedizierter Grafikkarte starten"...

Wie bekomme ich Mint dazu?
was hast du denn für eine dedizierte GPU?

Evtl fehlen ihm Treiber etc.

Bei Nvidia mal in der Treiberverwaltung schauen, bei AMD Mesa Treiber installieren.

Ich mache meine iGPU eigentlich immer tot im Bios, wenn ich ne dedizierte Verbaue.
 
was hast du denn für eine dedizierte GPU?

Evtl fehlen ihm Treiber etc.

Bei Nvidia mal in der Treiberverwaltung schauen, bei AMD Mesa Treiber installieren.

Ich mache meine iGPU eigentlich immer tot im Bios, wenn ich ne dedizierte Verbaue.
Ist ne AMD 6630, wird auch in der Systeminfo erkannt.

Im BIOS deaktivieren is nicht ;)
 
Zuletzt bearbeitet:
Garuda muss man sich echt nicht antun. Diese Distro ist sowas von aufgeblasen und keinen deut besser beim Zocken als ein Manjaro oder andere Arch basierte Distro.
Wenn man schon nichts machen will, dann würde ich mir eher Nobara nehmen. Da ist wenigstens nicht so viel Zeugs dabei und es ist schön übersichtlich.
 
keinen deut besser beim Zocken als ein Manjaro
Dann slotte mal mit Firefox (ESR) unter Manjaro Gnome ... Anfangs null Probleme, die letzten Monate(!) regelmaßig Abstürze auf einer bestimmten Seite.

Betrifft nur mein System mit Intel UHD750 Grafik ... i-wann haste die Schn**ze voll und schießt Manjaro in den Wind (obwohl es mir noch immer gut gefällt).
 
also ich hatte gerade in letzter Zeit keine Probleme mit Manjaro, aber verwende auch keine iGPU. Würde es wohl unter den Umständen auch in den Wind schießen :d
 
Hab manjaro mal 'ne Zeitlang auf dem Laptop probiert, bin aber auch nie richtig damit warm geworden. Obwohl's mir zu Beginn echt gut gefallen hat....it's complicated
 
Magst du deine Meinung dazu vielleicht etwas ausführlicher formulieren?
Sehr gerne. Ich frage mich gerade sehr stark was Electron mit Snap/Flatpak zu tun haben soll. Oder was an Flatpak das System zumüllen soll, besonders im Vergleich zu irgendwas Selbstkompiliertem. Oder was das System daran sehr unsicher macht.
 
Unter Ubuntu konnte ich direkt mit Rechtsklick auswählen "mit dedizierter Grafikkarte starten"...

Wie bekomme ich Mint dazu?
Ist ne AMD 6630, wird auch in der Systeminfo erkannt.

Leider gar nicht, bzw. mit einem PR für Cinnamon…
Ubuntu / GNOME benutzt den switcheroo-control D-Bus Service, um herauszufinden, ob das System eine dGPU hat, und welche Umgebungsvariablen gesetzt werden müssen, um diese zu verwenden.
In Cinnamon sind sowohl die Erkennung in der Mint spezifischen libxapp, als auch die env vars in Cinnamon selbst hardcoded für den proprietären Nvidia Treiber. Mit dGPUs anderer Hersteller oder Nouveau als Nvidia Treiber wird das also nichts.

Als Workaround könntest du switcheroo-control selbst installieren und das mitgelieferte switcherooctl Tool in den entsprechenden Desktop Entries verwenden (oder einfach env verwenden um die passenden Variablen selbst zu setzen).

du kannst die Intel iGPU im bios nicht deaktivieren? Wie spartanisch ist das denn?
Das geht bei keinem Laptop mit muxless dGPU (quasi allen nach 2010, außer vielleicht ein paar mobilen Workstations und high-end Gaming Laptops), weil die dGPU nicht direkt mit dem integrierten Bildschirm (und anderen Ausgängen) verbunden ist. Stattdessen werden die Frames in einen mit der iGPU geteilten Buffer im RAM kopiert, die dann die Darstellung übernimmt.
 
Das geht bei keinem Laptop mit muxless dGPU (quasi allen nach 2010, außer vielleicht ein paar mobilen Workstations und high-end Gaming Laptops), weil die dGPU nicht direkt mit dem integrierten Bildschirm (und anderen Ausgängen) verbunden ist. Stattdessen werden die Frames in einen mit der iGPU geteilten Buffer im RAM kopiert, die dann die Darstellung übernimmt.
ok, sry, ich bin stur vom Desktop ausgegangen und nicht von einer Laptoplösung.
Im Bereich Desktop ist das ja alles nicht so hoch optimiert wie im Bereich mobile und auch die Lösungen aka Fusion Graphics wo APU und dedizierte GPU kombiniert wurden haben sich da ja nicht so durchgesetzt.
 
Leider gar nicht, bzw. mit einem PR für Cinnamon…
Ubuntu / GNOME benutzt den switcheroo-control D-Bus Service, um herauszufinden, ob das System eine dGPU hat, und welche Umgebungsvariablen gesetzt werden müssen, um diese zu verwenden.
In Cinnamon sind sowohl die Erkennung in der Mint spezifischen libxapp, als auch die env vars in Cinnamon selbst hardcoded für den proprietären Nvidia Treiber. Mit dGPUs anderer Hersteller oder Nouveau als Nvidia Treiber wird das also nichts.

Als Workaround könntest du switcheroo-control selbst installieren und das mitgelieferte switcherooctl Tool in den entsprechenden Desktop Entries verwenden (oder einfach env verwenden um die passenden Variablen selbst zu setzen).


Das geht bei keinem Laptop mit muxless dGPU (quasi allen nach 2010, außer vielleicht ein paar mobilen Workstations und high-end Gaming Laptops), weil die dGPU nicht direkt mit dem integrierten Bildschirm (und anderen Ausgängen) verbunden ist. Stattdessen werden die Frames in einen mit der iGPU geteilten Buffer im RAM kopiert, die dann die Darstellung übernimmt.
Okay vielen Dank

Jetzt würde ich gerne nur noch wissen wie ich das switcheroo-control unter mint installiere...
 
Jetzt würde ich gerne nur noch wissen wie ich das switcheroo-control unter mint installiere...
Entweder du klickst auf der oben verlinkten Seite
Als Workaround könntest du switcheroo-control selbst installieren
auf „Install“, oder führst in einem Terminal
sudo apt-get install switcheroo-control
aus.

Dannach musst du den Dienst noch aktivieren, z.B. mit
systemctl enable --now switcheroo-control.service

Aber wenn ich es recht bedenke macht es wohl in deiner Situation¹ mehr Sinn, einfach env DRI_PRIME=1 statt switcherooctl launch zu verwenden.

Du könntest auch folgenden Patch auf das cinnamon Paket anwenden:
Code:
diff --git a/src/cinnamon-app.c b/src/cinnamon-app.c
index e3c2d704c..d7e392260 100644
--- a/src/cinnamon-app.c
+++ b/src/cinnamon-app.c
@@ -1163,8 +1163,7 @@ _gather_pid_callback (GDesktopAppInfo   *gapp,
 static void
 apply_discrete_gpu_env (GAppLaunchContext *context)
 {
-  g_app_launch_context_setenv (context, "__NV_PRIME_RENDER_OFFLOAD", "1");
-  g_app_launch_context_setenv (context, "__GLX_VENDOR_LIBRARY_NAME", "nvidia");
+  g_app_launch_context_setenv (context, "DRI_PRIME", "1");
 }
 
 static gboolean
diff --git a/src/cinnamon-util.c b/src/cinnamon-util.c
index cdd1da551..19640bac9 100644
--- a/src/cinnamon-util.c
+++ b/src/cinnamon-util.c
@@ -1055,15 +1055,5 @@ cinnamon_shader_effect_set_double_uniform (ClutterShaderEffect *effect,
 gboolean
 cinnamon_get_gpu_offload_supported (void)
 {
-    static gboolean offload_supported = FALSE;
-    static gsize once_init_value = 0;
-
-    if (g_once_init_enter (&once_init_value))
-    {
-        offload_supported = xapp_util_gpu_offload_supported ();
-
-        g_once_init_leave (&once_init_value, 1);
-    }
-
-    return offload_supported;
+    return TRUE;
 }

dann hättest du das Rechtsklick Menü (der Text wäre weiterhin „Run with NVIDIA GPU“) auf allen Anwendungen, ohne selbst eine Action hinzufügen zu müssen und Anwendungen mit PrefersNonDefaultGPU=true würden automatisch mit der dGPU ausgeführt.

Allerdings scheint mir das Patchen von Ubuntu Paketen recht kompliziert zu sein. Wobei man sich natürlich alle Schritte, die mit Signieren, Dokumentieren und Upstreamen zu tun haben für den Privatgebrauch sparen kann. Vielleicht kann dir einer von den Ubuntu / Mint Nutzern hier im Forum da weiter helfen.

[1] Das muss ja nur auf einem bestimmten Laptop funktionieren und an dessen Hardwarekonfiguration (zumindest den GPUs) wird sich wohl kaum was ändern. Von daher kann man immer von Mesa/R600g ausgehen und muss Vulkan nicht beachten.
 
Danke, habe jetzt via Terminal den switcheroocontrol installiert & aktiviert nach deiner Anleitung.


Leider starten die Spiele noch immer mit der iGPU.
Bei z.B. MaxPayne 2 sieht man es schön vorher da es ja einen Auswahlreiter gibt.
 
Danke, habe jetzt via Terminal den switcheroocontrol installiert & aktiviert nach deiner Anleitung.


Leider starten die Spiele noch immer mit der iGPU.
Bei z.B. MaxPayne 2 sieht man es schön vorher da es ja einen Auswahlreiter gibt.
Ich glaube, wir haben hier ein kleines Missverständnis:
Die Aufgabe von switcheroo-control ist es zu ermitteln, ob eine oder mehrere dGPUs vorhanden sind und welche Umgebungsvariablen angewendet werden müssen, um diese zu verwenden.
Herauszufinden, ob der User (oder die Anwendung selbst) eine dGPU verwenden will und die passenden Umgebungsvariablen zu setzen ist der Job des Anwendungsstarters (z.B. Cinnamon, GNOME Shell oder diverse Spiele-Launcher).

Das Problem hier ist, dass Cinnamon dafür feste Werte verwendet, wie nach einer dGPU gesucht werden soll und welche env vars gesetzt werden müssten, die nur mit dem proprietären Nvidia Treiber funktionieren. switcheroo-control nur installiert zu haben bringt dir also für von Cinnamon gestartete Anwendungen nichts, weil Cinnamon (im Gegensatz zu z.B. GNOME Shell) nicht mit switcheroo-control „redet“.
Das das switcheroo-control Paket kommt aber auch mit einem switcherooctl Tool. Das kann man verwenden , um Programme mit der dGPU zu starten: switcherooctl launch prog startet prog mit den vom switcheroo-control Dienst bezogenen env vars.

Wenn du also ein mit Cinnamon gestartetes Programm z.B. SuperTuxKart immer mir der dGPU ausgeführt haben willst, müsstest du den Desktop Entry entsprechend bearbeiten, indem du supertuxkart durch switcherooctl launch supertuxkart ersetzt:
Entweder mit dem Menü-Editor, der mit Mint kommt wie hier gezeigt (du würdest natürlich den bestehenden Eintrag bearbeiten, statt einen neuen zu erstellen).
Oder indem du manuell /usr/share/applications/supertuxkart.desktop nach ~/.local/share/applications/supertuxkart.desktop kopierst und dann die Exec=supertuxkart Zeile bearbeitest.
Man beachte auch die PrefersNonDefaultGPU=true Zeile, die normalerweise dafür sorgen sollte, dass das Programm automatisch von Cinnamon mit der dGPU gestartet wird.

Für ein Steam Spiel würdest du in der Bibliothek unter „Rechtsklick auf Spiel“ → „Properties“ → „GENERAL“ → „LAUNCH OPTIONS“ → „Advanced Users may choose to enter modifications to their launch options.“ switcherooctl launch %command% eintragen.

Wie bereits erwähnt sollte switcherooctl launch auf deinem spezifischen System immer nur DRI_PRIME=1 (technisch gesehen sowas wie DRI_PRIME=pci-0000_02_00_0, aber das ist in dem Fall äquivalent) setzten, daher hättest du dir wohl switcheroo-control komplett sparen und statt switcherooctl launch prog einfach env DRI_PRIME=1 prog verwenden können.

Cinnamon wie oben erwähnt zu patchen hätte eben den Vorteil, dass man nicht immer manuell an den Desktop Entries rummurksen muss.

KDE benutzt übrigens auch feste Werte, die aber nur mit Mesa funktionieren, quasi das gegenteilige Problem zu Cinnamon.
 
Ich teste jetzt Arch auf einem Notebook.
Sieht gut aus, habe zwar kein Netzwerk... sieht aber gut aus :heul:

ich zwar gerne mal die ein oder andere Stunde in was reinstecke, aber in Arch vieles nur funktioniert wenn man vorher die Wiki gelesen und ausführliche Webrecherche betrieben hat und dann mit 4 Anleitungen da steht die alle etwas leicht anders machen).

und warte auf den Stein der Weisen.
Allenfalls wäre EndeavourOS einen Blickwert: ist quasi Arch in pfannenfertig, soll heissen sehr nah an der Arch Basis aber mit vernünftigen Voreinstellungen und netter Community.
 
Danke für den Tip, werde ich mir mit als nächstes mal für Tests auf das Notebook hauen :)
 
Damit läufts wohl tatsächlich auf ACPI/DSDt Blödsinn raus.

So langsam gehen mir die Ideen aus. Ich hab mich an das Wiki gehalten: Aus der dsdt.dsl habe ich folgende Windows Versionen entnommen:

Code:
        Method (_INI, 0, Serialized)  // _INI: Initialize
        {
            OSYS = 0x03E8
            If (CondRefOf (\_OSI, Local0))
            {
                If (_OSI ("Windows 2001"))
                {
                    OSYS = 0x07D1
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    OSYS = 0x07D1
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    OSYS = 0x07D2
                }

                If (_OSI ("Windows 2001.1"))
                {
                    OSYS = 0x07D3
                }

                If (_OSI ("Windows 2006"))
                {
                    OSYS = 0x07D6
                }

                If (_OSI ("Windows 2009"))
                {
                    OSYS = 0x07D9
                }

                If (_OSI ("Windows 2012"))
                {
                    OSYS = 0x07DC
                }

                If (_OSI ("Windows 2013"))
                {
                    OSYS = 0x07DD
                }

                If (_OSI ("Windows 2015"))
                {
                    OSYS = 0x07DF
                }
            }

Also habe ich in der /etc/default/grub die Zeile
Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_os_name=Windows2015 udev.log_priority=3"
um den entsprechenden Parameter ergänzt und mit
Code:
grub-mkconfig -o /boot/grub/grub.cfg
aktualisiert. Ein Blick beim Booten mit "e" in die Optionen zeigt mir, dass es die Einstellungen übernommen hat. Aber leider bringt es es nix. Ich habe diverse verschiedene Alternativen von
Code:
acpi_os_name=
ausprobiert: Windows2015, Windows_2015, "Windows2015", "Windows_2015", "!Windows_2015". Selbiges habe ich mit dem Parameter
Code:
acpi_osi=
ausprobiert, auch ohne Erfolg. Mache ich was falsch? Hat noch jemand Ideen?

Wenn das System im Idle (mit ausgeschaltetem Bildschirm) bis S0ix kommt könntest du s2idle als Alternative versuchen.

Wie gehe ich das an?
 
Mache ich was falsch? Hat noch jemand Ideen?
Also erst mal (und bitte fass das nicht abwertend auf): Das sieht nicht wirklich aus, als ob du irgendeine Ahnung hättest, was du da tust…

Zum hinzufügen oder entfernen von OSI Strings müsstest du acpi_osi verwenden, nicht acpi_os_name; z.B. acpi_osi="Windows 2015" zum hinzufügen und acpi_osi="!Windows 2015" zum entfernen von Windows 2015. Das (mit einem Leerzeichen) ist übrigens die einzige korrekte Schreibweise, das Beispiel im Arch Wiki hat einen (Tipp-) Fehler. Die Anführungszeichen (ob/wie du' oder " verwendest) musst du ggf. noch an deine GRUB Config anpassen. Siehe _OSI strings for Windows operating systems für die volle Liste.

Alle in deinem DSDT-Ausschnitt verwendeten OSI Strings werden allerdings bereits von Haus aus vom Kernel verwendet. Durch hinzufügen von Windows 2015 würdest du also nichts erreichen. Mit acpi_osi="!Windows 2015" oder acpi_osi=! acpi_osi="Windows 2012" usw. könntest du dagagen erreichen, dass OSYS auf einen anderen Wert gesetzt wird.

Ob das deine S3 Standby Probleme löst sei mal dahingestellt. Vermutlich müsstest du dafür die DSDT selbst an irgendeiner Stelle patchen.
Beitrag automatisch zusammengeführt:

Wie gehe ich das an?
Um s2idle zu aktivieren s2idle nach /sys/power/mem_sleep schreiben.
Beim Auslesen sollten die Klammern dann um s2idle statt deep sein.
Permanent könnte man das dann mit einer udev rule machen? (Frag mich jetzt nicht wie die aussehen würde…)

Das sollte soweit auch ohne S0ix Support funktionieren, verbraucht aber dann ggf. relativ viel Strom im Vergleich zu S3. Die Leistungsaufnahme und States kannst du allgemein mit powertop prüfen und evtl. noch optimieren.

Bzgl. S0ix gibt es von Intel zwei recht gute Blog Posts: How to achieve S0ix states in Linux und Linux S0ix Troubleshooting.

Der „Unexpected S2idle wake up“ Abschnitt in letzterem kann dir vielleicht auch mit deinem S3 Problem helfen. Debugging hibernation and suspend ist hier evtl. auch nützlich, bin aber aber nicht sicher wie aktuell das noch ist.
 
Zuletzt bearbeitet:
Also erst mal (und bitte fass das nicht abwertend auf): Das sieht nicht wirklich aus, als ob du irgendeine Ahnung hättest, was du da tust…

Da hast du nicht ganz unrecht.

Zum hinzufügen oder entfernen von OSI Strings müsstest du acpi_osi verwenden, nicht acpi_os_name; z.B. acpi_osi="Windows 2015" zum hinzufügen und acpi_osi="!Windows 2015" zum entfernen von Windows 2015.

Ich habe beides benutzt,
Code:
acpi_osi
und danach
Code:
acpi_os_name
. Beides habe ich allerdings auch mit "Linux" als Wert versucht, Ergebnis war leider dasselbe.

Das (mit einem Leerzeichen) ist übrigens die einzige korrekte Schreibweise, das Beispiel im Arch Wiki hat einen (Tipp-) Fehler.

Das ist gut zu wissen. Ich habs eben mal mit
Code:
Windows\ 2015
probiert. Das geht durch. Verwendet man nur das Leerzeichen gibts eine Fehlermeldung.

Alle in deinem DSDT-Ausschnitt verwendeten OSI Strings werden allerdings bereits von Haus aus vom Kernel verwendet. Durch hinzufügen von Windows 2015 würdest du also nichts erreichen. Mit acpi_osi="!Windows 2015" oder acpi_osi=! acpi_osi="Windows 2012" usw. könntest du dagagen erreichen, dass OSYS auf einen anderen Wert gesetzt wird.

Ok, jetzt verstehe ich auch warum mein Vorgehen wie blanke Verzweifelung aussieht. Wenn ich aber nur einen einzelnen Windows-Eintrag entferne wird das Teil sich doch einfach den nächsten greifen nehme ich an.

Ob das deine S3 Standby Probleme löst sei mal dahingestellt. Vermutlich müsstest du dafür die DSDT selbst an irgendeiner Stelle patchen.

Das befürchte ich leider auch. Eine fertig gefixte DSDT habe ich leider nicht finden können.

Um s2idle zu aktivieren s2idle nach /sys/power/mem_sleep schreiben.

Den Ansatz werde ich mal weiter verfolgen, Danke!
 
Wenn ich aber nur einen einzelnen Windows-Eintrag entferne wird das Teil sich doch einfach den nächsten greifen nehme ich an.
Genau. Deshalb macht einfach nur entfernen eigentlich nur für den 2015er Sinn, dann würde der 2013er Wert gewählt. Für andere Werte müsstest du die Liste erst mit acpi_osi=! komplett leeren und dann den gewünschten Wert wieder hinzufügen.
Das geht durch. Verwendet man nur das Leerzeichen gibts eine Fehlermeldung.
Gut zu wissen. In der Kernel Command Line würden auch Anführungszeichen funktionieren, aber wie man die am besten durch GRUB / grub-mkconfig schleust wüsste ich auch nicht. GRUB ist eher nicht so mein Metier.
Eine fertig gefixte DSDT habe ich leider nicht finden können.
Ich hab auch mal kurz geschaut aber zum dem Thema allgemein nicht wirklich was finden können. Beim 2017er Swift 1 scheint das ja noch kein Problem gewesen zu sein.
 
Ich habe nochmal den Fokus erweitert und bin dabei auf eine recht simple Lösung, direkt aus dem Arch-Wiki gestoßen. Es war genau wie beschrieben, das device RP05 stand auf enable. Die "fix-suspension.service" erstellt, Gerät eingetragen und den Service gestartet. Danach gings. Dennoch ein großes Dankeschön für deine Mühe @YCbCr !
 
@YCbCr
Funktioniert das mit der dedizierten GPU Auswahl nicht auch unter dem Xfce / LXQt Desktop wie bei Lubuntu / Xubuntu?
Sorry, bin echt doof :d
 
@YCbCr
Funktioniert das mit der dedizierten GPU Auswahl nicht auch unter dem Xfce / LXQt Desktop wie bei Lubuntu / Xubuntu?
Sorry, bin echt doof :d
XFCE / Thunar unterstützt zwar PrefersNonDefaultGPU in Desktop Files, verwendet dafür aber auch hardcoded die NVIDIA env vars. (Auch gut: Der /* TODO: What is needed for AMD discrete GPUs ? */ Kommentar 🙃 )

LXQt hat soweit ich das sagen kann gar keine eingebaute Unterstützung für PRIME Render Offload.

Das zuvor gesagte bzgl. env und switcherooctl gilt natürlich auch für diese beiden.

Ob Lubuntu oder Xubuntu da noch irgendwas zusätzlich oben drauf haben weiß ich nicht.

Langsam würde sich hier ja fast ein Übersichts/Guide Thread zu dem Thema rentieren. :unsure:
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh