2022 februári hír, hogy:
"- Support for 30-bit color in the Plasma X11 session, starting with Plasma 5.24." [link]

Aztán idén elkezdték a HDR-t implementálni Linux szerte, volt áprilisban RedHat hackfeszt a témában, meg a Valve már játékok alatt is működő HDR-t produkált a Steam Deck-en, szóval biztosan nem ott tart a dolog, ahol 2 éve, de ki kellene próbálnod.

nVidiánál meg elkezdtek érdemben nyílt drivert fejleszteni (nvk), így idővel talán már náluk sem fog kelleni a gyári driver, de az még ki tudja mikor kerül be a mesa-ba.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

na és ezt ki állítja?

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

AMD fronton HDR-t illetően van vmi infótok ?

Debian Testing + Cinnamon, semmi különlegesség, de megvettem most a csilivili monitort és a redmondi szoftver jól hajtja, a Linuxban viszont nincs erre utalás, hogy HDR-t kezelne (se VLC se Settings se semmi).

A GPU a Ryzen prociba integrált (4650G).

POKE 16017,44 ..... SYS 2077

"Frissítés 2023 03 A Linuxon futó HDR-támogatással kapcsolatos munka folyamatban van , és úgy tűnik, még néhány évbe telhet, amíg élvezni fogjuk"
[link]

Tiszta sor, nagyon köszönöm.

POKE 16017,44 ..... SYS 2077

koszi.
.
raszantam magam ,, kiprobaltam , KDE + Nvidia RTX + x11 == a Transparency effect helyett fekete csikok !! ,, programok akadoznak , mintha le lennenek fagyva , a ' dekoraciok '' hianyosan jelennek meg !!
. . marad a 24-bit.

[ Szerkesztve ]

Main full time job : >>> The ultra fast money producer !!!

Végül is a 10 bit helyett a 24 olyan rossz...

https://www.coreinfinity.tech

Melyik disztrót nézted meg? A csomagverziók miatt kérdezem. Ha lenne ilyen 10 bites monitorom, akkor megnézném AMD kártyával mi a helyzet.

sh4d0w: jajj de az utóbbi 3 csatornára van.

[ Szerkesztve ]

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

AMD-vel (palcika wm) a masodlagos oled tv siman megy 10 biten.
[link]

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Szerintem az olvasó közönség 10%-a odáig sem jut el, hogy pálcika...... . A WM-et meg ne is firtassuk.

Akkor marad a szivas

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

a GARUDA ,, a Legfrissebb , dr460nized. + 535.54.03 Nvidia driver.

[ Szerkesztve ]

Main full time job : >>> The ultra fast money producer !!!

[link] zenbleed.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

napasztmek.
pont érint :/

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Ha Linuxot használsz, arra már jött frissítés.

https://www.coreinfinity.tech

Jelenleg egy a 6.5 rc3-ba került egy előzetes bejegyzés és ellenőrzésre az új mikrokódhoz(ez elég tiszta elolvasva a commitot), mivel AMD még nem készült egy a javítással, így nincs javítva. Pláne nem jött frissítés.

[ Szerkesztve ]

Hijnye...

Egyebkent meg javitva van a legutobbi AGESA-ban, de alkalmazas oldalon is lehet vedekezni ellene.

[ Szerkesztve ]

https://www.coreinfinity.tech

Tovabbi jo egest.

https://www.coreinfinity.tech

Microcode még csak is kizárólag Rome-hoz van, (az lenne ez), a többihez még nincs. A linkek nem tudom mit szeretnének mutatni(egyik egy példa egy 4éves mikrokód frissítésre, a másik leírja, hogy csak Rome-ához van), az AMD hivatalos target ideje október-december.
Tehát még egyszer Rome-ot kivéve semmire nincs ebben a pillanatban javítás mikrokód szinten, Linux 6.5 RC3-ba a bit állítás és a Roma mikrocode kivétel került bele, de ezen a verzión elég kevesen vannak...

Aki telepíteni akarja a workoround-ot akkor ennyit kell csinálni:
apt install msr-tools (ki milyen csomagkezelőt használ)
modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

A bit egy nem dokumentált kapcsoló, és AMD-n kívül senki se tudja, hogy mit csinál... Remélem hamarosan elárulják, mert így elég érdekes CPU beállítást módosítani...

Az SW oldali fix-ek nagy eséllyel (főleg böngésző) előbb lesznek mint mikrokód, AGESA, vagy bármi más.

Szerk:
Engem is ott cseszeget tegnap óta:
amd64-microcode/focal-updates,focal-security 3.20191218.1ubuntu1.1 amd64 [upgradable from: 3.20191218.1ubuntu1]
Ettől nem lesz a hiba kijavítva, nem lesz javított mikrokód, csak a fenti bit fix kerül bele, amit nem tudja senki, hogy mit csinál... Állítólag javítja, reméljük igen, és nem okoz más problémát.

[ Szerkesztve ]

Egy kis tisztázás, hülyeséget írtam "fenti bit fix kerül bele"-al, elég zavaros, hogy ez megy jelenleg. Nincs benne semmi ilyesmi.
Szóval ha jött bárkinek mikrokód frissítés, az egy általános bundle és csak a Roma-hoz van benne valós javítás. Tehát az egyetlen javított mikrokód a 0x0830107A, minden más ami, a "3.20191218"-ban van az nem a Zenbleed-re vonatkozik. pl. Family=0x17 Model=0x08 és Model=0x01 Zen és Zen+ modellek, amik nem érintettek a hibában.

Szóval amíg nincsenek kernel frissítések backportokkal (nem dev-en vagy RC3-mal), a korábban írt/linkelt workaround elvileg megoldja, amíg nem jön bármi más.

Tapasztalaton alapuló tanácsra lenne szükségem:
van egy gépem, asus prime z690m+ alaplappal, debian, és túl meleg a házban a vinyó. Nagyobb huzatot szeretnék csinálni benne, ha zajosabb, az nem annyira gond. A gépet kitermelni nem nagyon tudom, szóval első körben bios állítgatás nem játszik.

A kérdés: hogy tudom acpi-fan interfészen keresztül felgyorsítani a ventilátorokat?
tia

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Rolling disztrót használóktól kérdezem, hogy ti milyen gyakran szoktátok frissíteni a rendszeretek? És hogyan frissítetek, kézzel terminálból, valamilyen grafikus szoftverkezelővel, vagy automatikusra van állítva, és a háttérben frissül a rendszeretek?

Terminálból, rögtön a napi első boot után. EndeavorOS.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Szintén. de inkabb mar csak megszokasbol
Arch

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Teminálban, általában naponta (vagy amikor eszembe jut), ha biztos van rá időm, mert pl. egy config fájl frissül és össze kell fésülni a meglévővel (vimdiff).

kézzel, terminálból, átlagosan hetente.
egy rakás gépem van, amire a grafikus szemetet fel se raktam

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

és most mindenki gúvadja a saját disztrója frissítési híreit, mert komolyabb bug van a kernelben, és azt frissíteni kell.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Melyik pontosan? Nem látok újabbat az SMB hiba óta.

ma jött a levlistán az értesítés a zenbleed-ről.
kérdés, hogy a disztrókban benne van-e már vagy majd ezután.
nem linux disztró, kernel bug.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Most a betöméséről jött értesítés? Mert a zenbleed már egy 5-6 napos történet.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Terminalbol -> sudo pacman -Syu ... vagy yay.
Vagy grafikusan -> Pamac
Frissites: Manjaro stable branch - ritkabban (3-4 hetente) de akkor nagy
meretu (600-800MB- 1-1.2GB) meretu frissites.
Az inkabb Arch alapuak: naponta 8-10-15-20 csomag is frissulhet.
A frissitesek letolteset lehet automatikusra allitani, de a telepitest
manualisan kell kezdemenyezni.

Arch
1-2 naponta, terminálból

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Az ugye nem kernel hiba, hanem HW. A workaroundok jönnek majd a kernelekbe, ahogy írtam feljebb, de magát a workaroundot bárki implementálhatja a gépén nem kell új kernelre várni. A megoldás meg majd egyszer a mikrokódfrissítések lesznek.

Sziasztok, fdisk helpet szeretnék kérni.

Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 168466431 167933952 80,1G 83 Linux
/dev/sda3 168466432 976773167 808306736 385,4G 83 Linux

Az sda2-t szeretném a mostani 80GB-ról 150-re átméretezni úgy, hogy az sda3 megmaradjon, csak ugyanúgy a disk végén, és a hiányzó 70 GB abból leválasztva. Ja és egyik partíció adata se vesszen el. Mindössze 30% foglalt csak a shrinkelendő partíción, szóval lesz hely. Ja, és a partíciók között/után/előtt ne legyen egy unallocated byte se.

Előre kis köszi

Ez veszélyes művelet lesz, mert át kell helyezni az adataid egy részét. Előtt csinálj másolatot mindenképp!
Linuxos eszközt én nem tudok erre a célra, sőt ingyenest sem, fizetősből azt hiszem az AOMEI Partition Assistant vagy a EaseUS Partition Master biztos tud ilyet.

Az Easeust már nézem is, viszont előtte még egy gond.
Fent az fdisk 385 GB-nak látja az utolsó partíciót, a df viszont csak 150-nek (ennyi volt az eredeti mérete, mielőtt extendálva lett volna klónozás után)
A dolog előzménye, hogy a 250 GB ssd lett klónozva dd-vel az 500 GB-ra, majd az utolsó partíció (/home) lett 150-ről extendálva a disk végéig (385 GB).

Szóval most még fontosabb kérdés, hogy a df miért a korábbi méretet látja csak? Rebootolva már volt a gép.

Az Easeus is 385 GB-ot lát.

mert a fájlrendszert is át kell méretezni, ha a partíciót átméretezted.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Siker, ez volt a gond, köszönöm

ismét újabb proci sebezhetőségek, mindkét oldalon egy-egy.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Megint egy? Így is updatel vagy 2 naponta a fedora ...

"Ha egyedülállóval találkozunk, mindegy, mit mond, de biztos, hogy nem azért van egyedül, mert élvezi a magányt, hanem mert már megpróbált beilleszkedni a világba, de az emberek újra meg újra kiábrándítják."

A u-boot a jó rendszer architektúra szempontból. Az csak egy bootloader, beinicializál amit kell (pl. network, hogy TFTP legyen) utána berántja a kernelt és eltűnik a memóriából. A kernel a memória képet a device tree-ből kapja, ami eszköz specifikus és a kernel tree-ben van normál esetben. Ez az attack vectorokat is jelentősen csökkenti. Btw ARM esetén pl. microcode sincs, mert RISC.

A BIOS annyira konyhanyelv, hogy maga a vendor is BIOS-nak hívja a mai napig. De x86-on van ez az SMM dolog amikor végrehajtás közben visszaugrik a proci a BIOS-ra. Szóval ott a memóriában marad a BIOS, és kell is, mert az kezeli a hardver csatlakoztatást.

(#33448) Livius A mikrokód igazából tök mindegy, a kernel úgyis felupgradeli early boot-ban ha régi.