Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Od posledního dílu Zpravodaje o Víně vyšly čtyři nové (vývojové) verze Wine.
Wine 1.5.11 vyšlo 17. srpna s těmito změnami:
Wine 1.5.12 vyšlo 31. srpna s těmito změnami:
Wine 1.5.13 vyšlo 14. září s těmito změnami:
Wine 1.5.14 vyšlo 28. září s těmito změnami:
Právě takovýto titulek měl e-mail od Andyho Ritgera, vývojáře proprietárních grafických ovladačů NVIDIA. NVIDIA, kromě toho, že se konečně posunula k RandR 1.2, má zjevně zájem i o to, aby věci dobře fungovaly i v aplikacích pod Wine.
Proběhnuvší debata je současně zajímavým náhledem do toho, jak RandR 1.2 funguje a jaké překážky aplikace používající toto novější rozhraní musí řešit.
Ve verzi 302.xx jsme konečně přidali podporu RandR 1.2 do ovladače pro X od NVIDIA. Současně jsme přepracovali některé věci kolem validace časování režimů (modetiming) a jejich konfigurace ovladačem NVIDIA. Důležitou částí je to, že jsme odstranili implicitní škálování na plochých displejích a místo toho jsme umožnili explicitní konfiguraci skrze MetaModes a RandR 1.2. Pro uživatele se mění jen to, že v seznamu pro výstup RandR jsou pouze režimy získané z EDID displeje.
Trochu informací: modení GPU (alespoň NVIDIA, ale ostatní pravděpodobně také) mají flexibilní zpracování škálování, které se skládá z:
Pokud tedy například váš monitor zvládá režim 1920x1200 a vy chcete mít desktop o rozlišení 1280x720 se škálováním dle poměru stran, aby naplnil 1920x1200 (tedy 1280x720 škálované na 1920x1080 s 60 prázdnými řádkami nad a pod v režimu 1920x1200), tak byste v syntaxi MetaModes od NVIDIA mohli udělat:
„1920x1200 { ViewPortIn = 1280x720, ViewPortOut = 1920x1080+0+60 }“
Ačkoliv je syntaxe MetaModes specifická pro NVIDIA, toho samého lze dosáhnout přes RandR:
V praxi to znamená, že většiny rozlišení (tedy ne jen fixní seznam režimů) z pohledu velikosti desktopu je možné v RandR dosáhnout.
Mé otázky:
1920 x 1200 1920 x 1080 1600 x 1200 1280 x 1024 1280 x 720 1024 x 768 800 x 600 640 x 480
Dávalo by smysl, aby si uživatel mohl ve Wine určit konfiguraci RandR (aby měl obraz napříč výstupy RandR na obrazovce X)? To asi závisí na tom, jaké mechanismy pro konfiguraci runtime jsou možné.
Komunikace s Andym se ujal Henri Verbeet. Nejprve mu vysvětlil, že aplikace pro Windows si nevymýšlejí rozlišení samy, ale místo toho se zeptají na seznam dostupných a jedno si vyberou. Dále mu objasnil to, jak se mají věci řešit správně. Nejprve k vytváření seznamu standardních rozlišení:
[...] Řekl bych, že správným způsobem řešení by bylo generovat standardní režimy DMT apod. v jádře a použít vlastnost výstupu „scaling mode“ (režim škálování) pro ovládání škálování, tedy vlastně tak, jak to dělají ostatní ovladače.
A jak je to s určováním primárního výstupu?
Primární displej RandR by měl být CRTC 0, výstup 0. Uživatelé toto typicky mohou změnit přes xrandr nebo xorg.conf. Ale ne všechny ovladače se v tomto ve výchozím nastavení chovají rozumně, takže asi budeme muset přidat kód, kde vybereme první připojený displej pro primární displej Win32, pokud není v RandR žádný primární určen. Aktuálně ale používáme starší RandR, takže se to aspoň nechová hůř než dřív.
A co multihead?
Ano, náležitá podpora multihead je něco, co teprve musíme implementovat. Není ale mnoho aplikací, které by s vícero displeji dělaly něco užitečného, takže to teď nemá vysokou prioritu. Henri:
class="kt_citace" [...] S RandR 1.1 dostáváte jednu velikou obrazovku a můžete si vybrat mezi fullscreen aplikací roztaženou přes všechny displeje, nebo vypnout všechny displeje až na jeden. Ve skutečnosti jde o to, aby si aplikace mohla vybrat mezi fullscreen na konkrétním displeji nebo více displejích, pokud to aplikace podporuje, a všechno ostatní nechala být.
Mimochodem, smyšlené obnovovací frekvence generované z „DynamicTwinView“ také nejsou zrovna ku pomoci. Některé Win32 aplikace očekávají, že režimy 800x600 @60 Hz nebo 1024x768 @60 Hz vždy existují, a pokud ne, tak prostě umřou.
Dále se pokračovalo v diskuzi o tom, jak to podle standardu s primárním výstupem RandR vlastně je. Jak je to ale tedy bude s tím s multiheaded? Andy:
Souhlasím, že displeje, které Wine nepoužívá, by mělo Wine nechat být a ne je vypínat. Ale jak jsi řekl výše, tak většina Win32 aplikací nativně nevyužívá možností multihead systémů. Očekával bych, že by ale někteří uživatelé mohli chtít, aby jejich Wine aplikace běžela napříč vícero displeji. Nezní to snad rozumně?
Henri nevidí v multihead významný „use case“ pro uživatele Wine, zatímco Andy zase nechce, aby uživatelé najednou nemohli dělat něco, co s RandR a hackem v podobě MetaModes mohli. Na to Andy reaguje:
Protože máme odlišné pohledy na věc, což jen tak rychle nevyřešíme, co kdybychom jako kompromis přidali možnost, jak nechat uživatele vynutit RandR 1.1 místo RandR 1.2? Tak by uživatelé alespoň mohli dosáhnout určitých konfigurací, které jinak nepůjdou. Pokud to zní přijatelně, jaký je preferovaný mechanismus pro něco takového? Obyčejná proměnná v prostředí?
Na to Henri odpověděl, že by byla lepší hodnota „UseXRandR“ v registrech. U multihead je zásadním problémem absolutní svoboda, kterou s novým RandR aplikace mají – musí si totiž úplně všechno řešit samy, anebo se musí uživatel spokojit s tím, že nebude mít možnost nastavit to, co chce. Na Windows se tento problém v ovladačích NVIDIA řeší podobně jako na Linuxu s MetaModes. Andy pak odkázal na článek, který ve stejnou dobu náhodou vyšel na Phoronixu. Z něj vyplývá, že problém fullscreen aplikací na multihead je něco o čem se ví. A zde by mohla pomoci nějaká knihovna, do které by se soustředily snahy nadefinovat rozumné chování a usnadnit konfiguraci.
I když na druhou stranu – kolik z vás by rádo mělo hru přes několik displejů?
Současný princip fungování Wine je předurčen spíše k tomu, aby si sami uživatelé instalovali aplikace do svých prefixů v HOME. Objevuje se ale problém s „globální“ instalací aplikací pro Windows do umístění, kam mohou přistupovat všichni uživatelé – ale už tam nemohou zapisovat, a to je kámen úrazu.
Řekl bych, že mám platné využití pro ignorování [kontroly vlastnictví prefixu] a rád bych věděl, jaký patch by prošel.
Představte si distribuci obsahující hru pro Windows v podobě read-only kopie nainstalovaného prefixu (řekněme do /opt). Když uživatel spustí aplikaci (přes soubor .desktop), tak se spustí skript, který udělá následující:
To teď funguje docela dobře: nové (nebo upravené) soubory v prefixu jsou uloženy do ~/.aplikace, odkud se obnoví při příštím spuštění aplikace. Různí uživatelé mohou mít aplikaci spuštěnou souběžně, neboť mají každý svůj vlastní prefix. Vyhýbáme se zbytečnému kopírování souborů, protože se do domovského adresáře ukládají jen soubory změněné uživatelem.
Má to ale jeden velký háček: unionfs zobrazuje vlastníka jako root, dokud uživatel soubor neupraví/neokopíruje. To znamená, že Wine odmítne spuštění z prefixu pod obyčejným uživatelem. Zakomentování této části kódu Wine to krásně rozchodí, ale rád bych viděl řádné řešení.
Bylo by tu přijatelné něco jako přepínač pro Wine nebo proměnná v prostředí?
Francois Gouget měl nápad, že by stačilo udělat touch na soubor v prefixu a rázem by se změnila práva adresáře prefixu. Scott na to ale řekl:
unionfs bohužel vykazuje smíšenou strukturu práv: soubory jsou vlastněné uživatelem, jakmile byly upraveny, ale samotný název hostujícího adresář není možné takto upravit, což je právě to, co Wine kontroluje.
Jörg Höhle by na to šel úplně jinak. Jeho návrhem je zapsat si bokem všechny klíče v registrech, co instalátor aplikace vytvoří, dále pak všechny soubory, co vytvoří mimo instalační adresář. Samotný instalační aderesář pak pomocí symbolického odkazu dostat do profilu uživatele, kam se nakopírují i ostatní soubory a zapíší data do registru.
Řešení to také je, třebaže složité, jenže Scott na to napsal:
Vypnutí [této kontroly] řeší úplně všechny problémy, na které narážím, aniž bych musel dělat cokoliv složitého nebo něco řešil ručně.
Jak to tedy bude? Zatím se neví.
Krátce po sobě vyšlo Wine Mono 0.0.6 a 0.0.8, ta první jmenovaná verze byla pokažená. Toto je přehled změn od verze 0.0.4:
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Při pohledu na dlls/winex11.drv/xrandr.c zjišťuji, že seznam režimů prvního RandR CRTC/výstupu je používán pro vytvoření výčtu dostupných režimů ve Wine. Probíhá komunikace mezi Wine a aplikacemi pro Windows vždy tak, že musíte hlásit seznam tvořený prvky (šířka, výška, obnovovací frekvence)? Nebo někdy aplikace říkají Wine, jaké rozlišení samy chtějí?Aha, takže nVidia dělá své uzavřené ovladače na Linux pro platíc business zákazníky. Aha. A teď prosím tu o karkulce.
Wine MonoWindows Mono, Unix Mono, Wine Mono,… já už se v tom pomalu ztrácím.
1. zrusili GPU skalovani - misto toho aby se mi male rozliseni zobrazilo hezky s cernymi okraji, rozplzne se po celem velkem monitoru.Je v metamodes.
1. zrusili GPU skalovani - misto toho aby se mi male rozliseni zobrazilo hezky s cernymi okraji, rozplzne se po celem velkem monitoru. A pritom tohle byl krok vstric standartum. Nevim jestli ma na to ten skvely genialni RandR reseni.
xrandr --output LVDS --set 'scaling mode' 'Full Aspect'