Špatné rozlišení monitoru i přes použití XRANDR

[Ventero]

Nebo ten problém bude ve spolupráci i915 s tím xorg spíše, než s Mesa ...

[sicco]

Děkuji moc všem. Je to vyřešeno. Rozlišení změněno na 1440x900 a je to paráda. Vyšel postup, který uvedl Ramael a níže uvádím jeho citaci. Super. Ještě jednou díky moc všem.

JirkaZ to nakousl správným směrem. Tady xrandr nepomůže protože to letí na waylandu dle toho výpisu. Takže jedna z možností je se odhlásit, přepnout na xorg session a tam xrandr pomůže. Další možnost je přidat parametr k jádru. Nejdřív si to celé přečti! Edituj

Kód: [Vybrat]

/etc/default/grub
Přidej tam na konec řádku GRUB_CMDLINE_LINUX_DEFAULT před ukončovací uvozovku

Kód: [Vybrat]

video=1440x900@60
Za tím zavináčem je frekvence monitoru. Nevím jaká tam patří (Jsem na cestě ze školy do práce, tak nemám čas to dohledat). Mělo by ti to vyplivnout toto:

Kód: [Vybrat]

cvt 1440 900
Ulož to. A pak v terminálu

Kód: [Vybrat]

sudo update-grub
reboot
Dej vědět jak to dopadlo.

[JirkaZ]

No a já bych k tomu ještě docela rád věděl, zda ten systém po onom zásahu v grubu nadále běží na Waylandu...

Čili zopakuj

Kód: [Vybrat]

xrandr a dej sem zase výpis, dík. Jo a taky dopiš do názvu tématu, že je vyřešené...

[Ventero]

Pro mě je matoucí tahle část- zde jsem nepochopil, co se má vlastně udělat mimo přidání toho parametru spuštění:

Za tím zavináčem je frekvence monitoru. Nevím jaká tam patří (Jsem na cestě ze školy do práce, tak nemám čas to dohledat). Mělo by ti to vyplivnout toto:

Kód: [Vybrat]

cvt 1440 900

Podle všeho to dál jede na Wayland , protože se nikde displej server nepřepínal.

Ale nechápu, proč a jak, když to jede na wayland, že by vůbec příkaz xrandr reagoval a měl odpovídající výstup? Ten je přece svázaný s xorg - ne?

[JirkaZ]

Ventero: jsem na tom s nepochopením té části úplně stejně. Možná ramael myslel, že příkaz

Kód: [Vybrat]

cvt mu v reakci na něj jen potvrdí správnou volbu snímkové frekvence (kterou už výše napsal do modifikace grubu).

Jo a taky jsem přesvědčen, že to nadále jede na Waylandu (ale chci se ujistit).

Jak to, že xrandr přesto pořád funguje, to taky netuším (ale dle výpisu někde výše evidentně ano). Jestli ono to nebude tím, že to není čistý Wayland, ale Xwayland, jak je taky přesně uvedeno v onom výpisu po příkazu

Kód: [Vybrat]

xrandr
Souvislosti viz třeba jako obvykle tady (teda to je bordel...).

[ramael]

Po praci se to pokusim vice rozebrat. JirkaZ ma pravdu v tom potvrzeni frekvence. Sekl jsem to od oka. Ridil jsem a nebyl cas si to presne overit nebo dohledat. Jen jsem na chvilku zastavil. Uz jsem jednou touto cestou sel tak vim ze to jde.
Ano jede to dal na waylandu. Xrandr jede pres xwayland a je tam vlastne zbytecny. Tahle ficura je pridana nekdy v jadru 5. Jednoduse rika systemu, ze ma pracovat s timto rozlisenim.

[ramael]

No co si budem povídat. Je to celé na prd. Na stávajícím laptopu mám Arch(X) + Alpine(X) + Win + orígo Ubuntu 22.04 (Wayland). A to celé startuje z UEFI. A v tom je zakopaný pes. Tenkrát (vloni) jsem to použil na ženy PC kde je start přes MBR. Vypadá to jako blbost. Avšak z UEFI se jádro aktivuje s efifb (ten předává dál rozlišení) díky kterému se parametr video= ignoruje ač moudré rady píší opak. Musím si s tím ještě pohrát. Trvá to. efifb jsem samozřejmě schopen vypnout, avšak asi bude třeba ještě natáhnout jiné *fb protože ubu podle dmesgu modedb ani nezaregistruje. A co mě nejvíc sejří je ta vypatlaná politika snapu. Ubu nejen že startuje pomalu, ale opět ho kus nefunguje! A to hlavně "nastavení". V menu se nabídka ztratila a pravé kliknutí v ploše jen nabídku ukáže, ale dál nereaguje. Plus errory snapd. Fakt jsem rád, že jsem tu příšernou distribuci přestal aktivně používat.
xrandr nejspíš v Ubu zůstává kvůli lidem kteří si přepnou sezení na Xka. Tam samozřejmě funguje normálně.

[sicco]

Zde je výpis xrandr:
Screen 0: minimum 16 x 16, current 1440 x 900, maximum 32767 x 32767
XWAYLAND0 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1440x900      59.89*+
   1152x864      59.78 
   1024x768      59.92 
   800x600       59.86 
   640x480       59.38 
   320x240       59.52 
   1280x800      59.81 
   720x480       59.71 
   640x400       59.20 
   320x200       58.96 
   1368x768      59.88 
   1280x720      59.86 
   1024x576      59.90 
   864x486       59.92 
   720x400       59.55 
   640x350       59.77

Sice to v nastavení hlásí neznámý displej, ale to mi nevadí, protože rozlišení funguje. V příloze posílám screen obrazovky.
Jinak já ten pokyn s cvt pochopil tak, aby jsem si ověřil frekvenci monitoru mimo příkaz v grub.

[ramael]

Tos pochopil správně a jsem rád, že tě to funguje. Nicméně mě štve, když něco nefunguje (rozlišení mám v pořádku, ale nejde mne přenastavit cestou parametru jádra) a já nevím proč. Poprosím o výstup příkazu

Kód: [Vybrat]

ls /sys/firmware/efi
a

Kód: [Vybrat]

lspci -nnk | grep -i -A3 vga
a ještě

Kód: [Vybrat]

sudo dmesg | grep -i -e "fb0" -e "drm"
Moc dík předem

[sicco]

Klobouk dolů, že tak rychle reaguješ, i když jsi v práci. To smekám. Níže jsou výpisy příkazů. U toho prvního to nechce najít adresář. Vyndal jsem jen své uživatelské jméno ve výpisu.

~$ ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ sudo ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ lspci -nnk | grep -i -A3 vga
00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e32] (rev 03)
   Subsystem: ASUSTeK Computer Inc. 4 Series Chipset Integrated Graphics Controller [1043:836d]
   Kernel driver in use: i915
   Kernel modules: i915
~$ sudo dmesg | grep -i -e "fb0" -e "drm"
[    1.027809] fb0: VESA VGA frame buffer device
[    9.035250] systemd[1]: Starting Load Kernel Module drm...
[    9.802573] ACPI: bus type drm_connector registered
[    9.851546] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    9.859352] systemd[1]: Finished Load Kernel Module drm.
[   21.465961] fb0: switching to i915 from VESA VGA
[   21.479568] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[   21.606380] fbcon: i915drmfb (fb0) is primary device
[   21.665767] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

[Ventero]

Prosím dávej výpisy do "kódu" a případně citace nebo vhodné pasáže do "citace" - jsou to ty ikony v možnostech editace nahoře nad polem pro psaní v druhém řádku 4. blok zleva označené jedna jako # a druhá výmluvným symbolem.
Teď to ještě jde, ale jakmile jsou výpisy delší, tak je to opravdu praktická pomůcka.
Děkuji jménem komunity.

[ramael]

Klobouk dolů, že tak rychle reaguješ, i když jsi v práci. To smekám. Níže jsou výpisy příkazů. U toho prvního to nechce najít adresář. Vyndal jsem jen své uživatelské jméno ve výpisu.

~$ ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ sudo ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ ls /sys/firmware/efi
ls: nelze přistoupit k '/sys/firmware/efi': Adresář nebo soubor neexistuje
~$ lspci -nnk | grep -i -A3 vga
00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e32] (rev 03)
   Subsystem: ASUSTeK Computer Inc. 4 Series Chipset Integrated Graphics Controller [1043:836d]
   Kernel driver in use: i915
   Kernel modules: i915
~$ sudo dmesg | grep -i -e "fb0" -e "drm"
[    1.027809] fb0: VESA VGA frame buffer device
[    9.035250] systemd[1]: Starting Load Kernel Module drm...
[    9.802573] ACPI: bus type drm_connector registered
[    9.851546] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    9.859352] systemd[1]: Finished Load Kernel Module drm.
[   21.465961] fb0: switching to i915 from VESA VGA
[   21.479568] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[   21.606380] fbcon: i915drmfb (fb0) is primary device
[   21.665767] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

Kdepak v práci, dělám do 14h.
Ta chyba prvního příkazu je správně. Tím jsem si ověřil, že ti to nestartuje z EFI.
Ty další výpisy se plus mínus shodují s mojema při startu z EFI.
Zatím jsem přišel na toto:
Z MBR startu se dá to rozlišení jednoduše parametrem jádra upravit. Samozřejmě to musí podporovat monitor.
Dá se i snížit rozlišení (dnes s jádrem 4.15 odzkoušeno). Avšak to je ignorováno DE. To se snaží vždy nastavit na nejvyšší možné. Že se to podařilo se zjistí jednoduše přepnutím se do jiné konzole ctrl+alt+F3 třeba (za eFkem je číslo konzole). Vidí se větší písmo. Zpět do grafiky je to na konzoli 1 takže ctrl+alt+F1 (dřív to bylo standardem na sedmičce).
Z EFI už je to problematické. Je docela dost možné, že pokud bys systém spouštěl z EFI, nevzniklo by toto vlákno. Tam nastupuje efifb https://docs.kernel.org/fb/efifb.html. Snížení ignoruje po všech stránkách (minimálně u mne) . Po efifb nastupuje modul (driver) který je určen danému HW. U Tebe i u mne to je i915 a jeho framebuffer i915drmfb. No a to se chová stejně jako efifb. Hází bobek na jakékoliv options na snížení resolution a jede na vždy nejvyšší možnou hodnotu. Pak už záleží jestli se jede na X (úprava confu v xorg.d nebo xrandr) nebo Waylandu. U Waylandu se to dále dělí na compository. Weston má jednoduchý .ini soubor. DE postavená na wlrtool (třeba swaywm) má také jednoduchá nastavení v souboru. A pak tu máme hovadinu typu GNOME (Ubuntu) která si to ukládá ve vlastním "registru" buď nepřístupném přes nastavení (můj případ) nebo asi přes dconf. Vrtat se v tom nebudu protože to odporuje mému chápání linuxu.
Zkoušel jsem efifb vypnout, vnutit resolution dle výpisů daného framebuferu (i915drmfb u mne) atd. Maximálně zůstane v dmesg hláška o nepodporovaném rozlišení.
Aby toho nebylo málo, ještě mě do toho hodili vidle některé příspěvky. Zmiňující rozdíl v chování pokud je zavaděč v multibootu nebo ne. Pro doplnění na obou systémech kde se mi to podařilo přenastavit se nejenže startuje z MBR, ale ani tam není nainstalován žádný jiný systém. Kdežto kde mě to ignoruje, mám více systémů ale start z EFI...
Jak říká jedna klasická hláška: "Taková blbost a tolik času to stálo"
P.S. nejsem administrátor ani programátor. Je možné, že jsem něco špatně pochopil, nebo napsal.

[ramael]

Ok, příčina zřejmě nalezena. Mám tu ještě laptop se systémem postaveným na custom instalaci ubuntu 22.04 s Xkama a startem přes systemd-boot (EFI). Přidáním parametru jádra do boot confu se mění rozlišení bez problému. Systém je jediný na laptopu! To znamená, že ty parametry nefungují v multibootu.
EDIT: ještě je tu další možnost, že v tom multibootu to nezvládá grub. Bez výmluvy na Ubuntu, protože to nejde ani z grubu od Archu.
Takže problém buď kombinace grub - EFI nebo multiboot.

[sicco]

Kód: [Vybrat]

Prosím dávej výpisy do "kódu" a případně citace nebo vhodné pasáže do "citace" - jsou to ty ikony v možnostech editace nahoře nad polem pro psaní v druhém řádku 4. blok zleva označené jedna jako # a druhá výmluvným symbolem.
Teď to ještě jde, ale jakmile jsou výpisy delší, tak je to opravdu praktická pomůcka.
Děkuji jménem komunity.
Díky za upozornění. Příště se polepším.

[Ventero]

Ramael:
Takže i v případě EFI platí funguje ta samá úprava konfigurace zavádění, jakou jsi tady poskytl?

Je divné a nechápu jak, by fakt, že se jedná o multiboot, mohl mít vliv na zavádění jádra?

Napadlo mě, že by se to rozlišení dalo nejprve vynutit v grubu samotném. Buď v etc/deafult/grub nebo přímo přidáním parametru buď do jednoho s generačních skriptů nebo jako poslední operaci po update-grub rovnou do grub.cfg:

Kód: [Vybrat]

set gfxmode=nebo případně

Kód: [Vybrat]

set gfxpayload=a pak ještě doplnit tím parametrem pro jádro.

S něčím podobným býval problém i v MBR - na některých strojích s iGPU Intel dělal grub2 to, že Windows (v mulitboot) začal nabíhat s grafickými artefakty a až když naběhla akcelerace Win, tak se to opravilo. Jako kdyby grub2 tu akceleraci nebo rozlišení rozhodil. Myslím, že se to poprvé objevilo ve verzi 2.02. Toto jsem pozoroval na min. 3 podobných strojích a vím 100%, že to není HW závada a že to dělá grub2.

Mrkni kdyžtak na to, jako zkušenější mistr:
https://www.gnu.org/software/grub/manual/grub/html_node/gfxmode.html#gfxmode
https://www.gnu.org/software/grub/manual/grub/html_node/gfxpayload.html

[ramael]

Ramael:
Takže i v případě EFI platí funguje ta samá úprava konfigurace zavádění, jakou jsi tady poskytl?

Je divné a nechápu jak, by fakt, že se jedná o multiboot, mohl mít vliv na zavádění jádra?

Napadlo mě, že by se to rozlišení dalo nejprve vynutit v grubu samotném. Buď v etc/deafult/grub nebo přímo přidáním parametru buď do jednoho s generačních skriptů nebo jako poslední operaci po update-grub rovnou do grub.cfg:

Kód: [Vybrat]

set gfxmode=nebo případně

Kód: [Vybrat]

set gfxpayload=a pak ještě doplnit tím parametrem pro jádro.

S něčím podobným býval problém i v MBR - na některých strojích s iGPU Intel dělal grub2 to, že Windows (v mulitboot) začal nabíhat s grafickými artefakty a až když naběhla akcelerace Win, tak se to opravilo. Jako kdyby grub2 tu akceleraci nebo rozlišení rozhodil. Myslím, že se to poprvé objevilo ve verzi 2.02. Toto jsem pozoroval na min. 3 podobných strojích a vím 100%, že to není HW závada a že to dělá grub2.

Mrkni kdyžtak na to, jako zkušenější mistr:
https://www.gnu.org/software/grub/manual/grub/html_node/gfxmode.html#gfxmode
https://www.gnu.org/software/grub/manual/grub/html_node/gfxpayload.html

Tvl. "zkušenější mistr" 
Se mi v tom grubu nechce vrtat. Nicméně ta chyba je na 100% v grubu a multibootu. Už jsem to odzkoušel:
Na druhém laptopu jak už jsem zmínil dříve se systemd-bootem jsem si rozdělil disk a nainstaloval ještě jeden systém bez grubu dle mého návodu: https://forum.ubuntu.cz/index.php?topic=86181.0
Upravil jsem config bootu (velice jednoduché) a střídavě startoval systémy s různými parametry. A vše probíhalo bez problémů. V příloze je foto login promptu s normálním rozlišením. Dále foto doplnění rozlišení jako kernel parametru. A poslední je funkční výsledek. Malé shrnutí
-> EFI, multiboot - systemd-boot => no problem
-> EFI, multiboot - grub => problem
-> EFI, singleboot - systemd-boot => no problem
-> EFI, singleboot - grub => nevím
-> MBR singleboot|multiboot - systemd-boot => nejde páč je jen pro EFI
-> MBR singleboot - grub => no problem
-> MBR multiboot - grub => asi také problém viz níže
Aby se nemusel pořád updatovat zavaděč, dělám to při bootu klávesou "e". Vybere se systém ke spuštění, máčkne se "e" a upraví|vloží se kernel option. V grubu pak jen potvrdit pomocí ctrl+x v systemd-boot stačí odentrovat. Je to jen dočasné na jeden start.
Pokud máte někdo multiboot z MBR odzkoušejte to a dejte vědět jestli to funguje nebo také ignorace. Zde https://ubuntuhandbook.org/index.php/2021/05/custom-screen-resolution-ubuntu-wayland-xorg/ píše také o problému. Jen doplním, že na EFI nefunguje ani toto:

If you have dual-boot or multi-boot systems, below steps may not work for “other Linux” in Grub boot menu. For instance, I’ve Ubuntu 21.04 and Ubuntu 20.04 dual-boot in my laptop, the startup boot menu is handled by Grub for Ubuntu 21.04. It lists Ubuntu 21.04 as the first menu entry, custom Kernel parameter does not work for Ubuntu 20.04 in my case.

Je možné, že gfxpayload by pomohl. Ač si spíš myslím, že je to vhodné jen na ten základní terminál. A merit tohoto vlákna je o přidání (vnucení) jiného rozlišení systému (vlastně o jakémkoliv přidání option do jádra). Nezapomenout na mou poznámku, že grafická nástavba ať Xka nebo Wayland vyberou pak vždy nejvyšší rozlišení. Je třeba jim pak ještě sdělit co chceme mi. Vzhledem k časové náročnosti se mi v dalších zákoutích grubu moc vrtat nechce. Sami tvůrci jádra grub nedoporučují...
Pro jistotu jsem i zapínal a vypínal secureboot, nemá to žádný vliv. To jen kdyby náhodou, dnes už je možné vše.
To @sicco nezapoměň upravit Předmět: v Tvém prvním příspěvku tohoto vlákna přidáním [vyřešeno]

[Ventero]

Ono to totiž, podle té mé zkušenosti, vypadá, že grub2 má nějakou schopnost tu grafiku nějak ovlivnit/zablokovat na nějaké hlubší vrstvě a pak si s tím neporadí ani kernel Linuxu ani kernel Win. Akorát, že Win si to spraví, protože na rozdíl od Lin tam rozlišení a akcelerace nejsou tak úzce spjaté a přímo navázané na kernel - je to jiná koncepce.

Vyzkoušel bych to sám - ty parametry pro grub se dají taky přidat pomocí "e" na začátek - ale nemám teď kde a mám problém se dokopat k prioritnějším věcem 

[ramael]

Tak on zavaděč (grub) si má zpracovat co dostane od biosu, předat to dál jádru a to jádro spustit. Windowsu nerozumím, myslím si, že mu to grub předá raw a windows už si to sám přebere (má přece ovladače od výrobce HW). Kdežto linuxové jádro je hodně variabilní a potřebuje správné parametry. Což se většinou daří. To je pro start z MBR. Pak byl přepracován na grub2, ale stále ten základ je MBR.  A nyní nedokáže správně pracovat na EFI. Pozor, on funguje, ale ne na 100% jak má. Rozdíl mezi rychlostma startů grub vs systemd-boot je propastný. Na jednom starém laptopu mi to udělalo cca 3sec rozdíl! Jen změna zavaděče stačila. Na EFI má zavaděč dle mne jednodušší práci a to jen spustit jádro. No a protože grub nemá info z biosu, tak tam prdne nějaké základní nastavení a hotovo protože tak to z MBR fungovalo vždy.
Myslím, že systemd-boot není tolik preferovaný z několika hledisek
- systemd je první věc. Co si budem nalhávat systemd je jako EU. Na začátku se řeklo, že je tu jen pro paralelní zpracování init (rychlejší start) a všichni jsme jásali jak to bude super. A nakonec to fušuje do všeho a běda pokud se to někomu nelíbí.
- nedá se tak pěkně graficky upravit jako grub. Je spartánský.
- dá se nainstalovat jen ze systému běžícím na systemd (nejspíš). Ale když už je nainstalován, spouští systemdfree systémy bez problémů.
Je tu ještě pár dalších zavaděčů, ale s těma nemám žádnou zkušenost. Třeba refind vypadá zajímavě. Jedinou podstatnou nevýhodou těch zavaděčů je neuniverzálnost narozdíl od grubu.
Další věc k zamyšlení je jestli je UEFI ta správná cesta. Píše se o bezpečnosti atd. Ok, tomu nerozumím. Jenže co je bezpečného na tom, mít jádra uložená na souborovém systému FAT32?

EDIT:
je tu ještě další možnost a to vrstva v grubu co spouští jádro. Spávně by mělo mělo být jádro na tom samém disku jako zavaděč. Tohle ale grub neomezuje. Takže musí mít nějakou utilitu která načte jiné drive s většinou jiným souborovým systémem a tam spustí (předá inicializaci) kernelu. Ale to už jsme nejspíš na hodně low úrovni (assembler).

EDIT II:
další možnosti - https://forums.fedoraforum.org/showthread.php?306271-uEFI-grub2-efi-nVidia-high-res-efifb-(non-nouveau)-virtual-consoles

[Ventero]

Koukám, že tam byla použita tatáž myšlenka, která napadla i mě a možná je to cesta i pro tento problém:

Kód: [Vybrat]

GRUB_GFXMODE=2560x1440x32,1920x1080x32,1280x800x32,1024x768x32,800x600x32
GRUB_GFXPAYLOAD_LINUX=keep


[ramael]

Hmm, jenze to take nefunguje (minimalne u mne).
Aktualizoval jsem kvuli tomu ubuntu a nic. Stale se neda dostat do nastaveni. Graficka nadstavba jede na druhem terminalu... S video vystupem se nehne. By me zajimalo na co tam ty ##pip## myslej kdyz to lepi dohromady.
Tenhle polowindows nema cenu instalovat.
Takze singleboot MBR v grubu. Jinak je lepsi se seznamit s jinym EFI zavadecem. A bud si neco na ubuntu postavit sam, nebo jit do jine distribuce.
Zase zabite dve hodiny. Jdu spat, rano musim makat.

[Roman Vacho]

Tato problematika je velmi obsáhlá a málokdo se v tom orientuje. Kdysi jsem čekal, že se věci zjednodušší, ale je to prozatím... něco horší něco lepší.

Na Intel se používaly nějaké háčky. Kapitola 3.2.
https://wiki.archlinux.org/title/GRUB/Tips_and_tricks

Četl jsem, že Grub2 půjde do důchodu. Třeba se to zlepší.

[Ventero]

Bohužel tam používají nějaký podpůrný balík, který je v odkazech jen v 32bit verzi a nejspíše se už nevyvíjí od roku 2007. Poslední .deb balík je o rok mladší, bez podpory Intel 65 . Ale 45 už měl.

[Roman Vacho]

OT: Netýká se tazatele. Jen MBR/EFI a Grubu a konzole.

Před časem jsem přešel z MBR na EFI (stejný HW).
Teď jsem třeba zjistil, že s EFI mám v Grubu max rozlišení  dle videoinfo pro EFIFB jen 1024x768.

Trošku jsem si s tím hrál, ale nevedlo to k ničemu. S grub konfigem, kernel parametrama, framebufferem, ....

Zkusil jsem snad všechno kromě kompilace vlastního jádra a požadovaného výsledku nedosáhl a nikdo na celém Internetu asi taky ne. Borec psal, že se ptal i AI.
Napříč distribucemi.

Některá řešení by teoreticky mohla chodit do kernelu 5.15. Vejš to prý už nefunguje. Nevím, jedu bohužel na novějším.