Zpravodaj o Víně – 2. 10. 2012: RandR 1.2 a NVIDIA

4. 10. 2012 | Luboš Doležel | Různé | 3294×

Nové verze Wine. Wine, fullscreen aplikace a RandR 1.2. Globálně instalované aplikace. Wine Mono 0.0.8. Změny v databázi aplikací.

Obsah

• Nové verze Wine
• Wine, fullscreen aplikace a RandR 1.2
• Globálně instalované aplikace
• Wine Mono 0.0.8
• Změny v databázi aplikací
  • Změny od správců programů
  • Změny od uživatelů

Nové verze Wine

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:

• Podpora multi-channel v ovladači ALSA
• Odstranění velkého zámku pro X11
• Podpora pro úpravy pozic párů (pair positioning adjustments) v Uniscribe.
• Více I/O stream implementací v runtimu C++.
• Různé opravy chyb.

Wine 1.5.12 vyšlo 31. srpna s těmito změnami:

• Možnost zakazovat jednotlivé joysticky.
• Lepší podpora konstatních tabulek D3DX9.
• Nějaká ta vylepšení v XRandR.
• Různé opravy chyb.

Wine 1.5.13 vyšlo 14. září s těmito změnami:

• Vykreslování oken na klientské straně pomocí DIB enginu.
• Podpora raw vstupu z klávesnice a myši.
• Podpora průhledných oblastí okna pomocí barvy jako klíče.
• Řádná podpora C++ RTTI na 64bit.
• Implementace informací o logických procesorech.
• Podpora pro fonty s lokalizovanými názvy.
• Různé opravy chyb.

Wine 1.5.14 vyšlo 28. září s těmito změnami:

• Mnohem lepší chování URL cache.
• Vylepšená podpora obrázků GIF.
• Více schopností parseru v v kompilátoru shaderů.
• Optimalizace v podpoře JavaScriptu.
• Různé opravy chyb.

Wine, fullscreen aplikace a RandR 1.2

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:

• „RasterSize“: rozlišení pixelů, které bude zasláno monitoru; to je to, co lidé obvykle považují za rozměry „režimu“.
• „ViewPortIn“: rozlišení pixelů, které zobrazovací engine získá z obrazovky (screen) X.
• „ViewPortOut“: toto je oblast _v rámci_ RasterSize, do které se pixely z ViewPortIn mají posílat. Všechny pixely z ViewPortIn mohou být škálovány nahoru nebo dolů v závislosti na velikosti určené pro ViewPortIn a ViewPortOut. Nastavením ViewPortOut na velikost menší než RasterSize lze také nastavovat letterboxing a overscan compensation.

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:

• Transformační matice RandR může být použita pro popsání škálování mezi ViewPortOut a ViewPortIn.
• Pokud je dostupná, tak výstupní atribut „Border“ může být použit k popsání toho, že je ViewPortOut menší než RasterSize. Pozor: většina X ovladačů RandR, včetně NVIDIA, tento atribut zatím nenabízí, ačkoliv na přidání do NVIDIA právě pracuji.

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:

• 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í?
• Přijali byste patch, aby dlls/winex11.drv/xrandr.c generovalo větší sadu takových prvků a následně by xrandr12_set_current_mode() použilo transformační matici a atribut Border pro jejich uspokojení? Představoval jsem si něco, kde bychom vzali „preferovaný“ režim pro daný výstup RandR a vytvořili následující rozlišení pomocí ViewPort{In,Out}:

          1920 x 1200
          1920 x 1080
          1600 x 1200
          1280 x 1024
          1280 x 720
          1024 x 768
          800 x 600
          640 x 480
  

• Kód v xrandr.c aktuálně vezme první CRTC/výstup, který ale nemusí být aktivní. Přinejmenším by měl hledat nějaký, který aktivní je. Řekl bych, že by bylo ještě lepší, kdyby si uživatel mohl nastavit, který výstup RandR chce. Bylo by to rozumné? Jaké mechanismy Wine nabízí uživatelům pro runtime konfiguraci?
• Podle současného kódu to nevypadá, že by se podpora RandR ve Wine snažila nějak řešit vícero současných výstupů RandR. Ironicky: toto funguje s RandR 1.1 + NVIDIA mnohem lépe: uživatelé si mohou nastavit své MetaModes pro popsání toho, jaký režim (plus nastavení viewportu) chtějí na každém z monitorů, a pak si RandR 1.1 vybere daný MetaMode.

  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ů?

Globálně instalované aplikace

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.

Scott Ritchie:

Ř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í:

1. Vytvoří dočasný adresář
2. Nastaví unionfs-fuse copy-on-write mount mezi ~/.aplikace a read-only prefixem v /opt namountovaným do dočasného adresáře
3. Spustí aplikaci s WINEPREFIX= v dočasném adresáři
4. Jakmile aplikace skončí, odpojí dočasný adresář

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í.

Wine Mono 0.0.8

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:

• Byly aktualizovány knihovny tříd Visual Basicu z upstreamu.
• Přechod z Mono 2.11.1 na 2.11.4.
• Počáteční podpora pro hostování prvků ActiveX ve winforms.
• Různé opravy v HttpClient.
• Vykreslování zaškrtávacích políček v neurčitém stavu ve winforms.
• Podpora ACL na Windows.
• Možnost trasovat všechny přechody mezi nativním a managed kódem pomocí WINE_MONO_TRACE=wrapper.
• K polím RVA lze nyní přímo přistupovat přes instrukci ldsfld[a], což by mělo pomoci v podpoře Managed C++.
• Přidáno chybějící MonoPosixHelper.dll
• Přidány hashe všech souborů v balíčku .msi, což je nutné při nahrazování souborů při upgradu.
• Přidány položky 64bitového registru do balíčku .msi

       

Komentáře

[Marián Kyral]

Díky za zajímavé počtení.

Ten nápad s unionfs vypadá zajímavě. Dalo by se to využít i u jednouživatelské instalace. Když se něco pokazí, tak stačí smazat konfiguraci v domovské složce a jede se od začátku.

[Luboš Doležel (Doli)]

Mně hlavně překvapuje, že tam je s unionfs nějaký problém, protože to takhle doma na jednom místě mám a funguje to bez problémů. Že by tam tu kontrolu práv přidali až nedávno?

[Marián Kyral]

Máš na to nějaký wrapper?

[Luboš Doležel (Doli)]

Dělám jen přesně to, co je popsané v článku. Akorát že ta uživatelská data jsou v tmpfs, protože to je systém bootovaný ze sítě:

Prefix s hrou je na NFS. Systém připojí NFS, udělá tmpfs, pak použije unionfs pro sloučení toho tmpfs s prefixem hry a Wine s tímhle funguje jak z praku.

[s]

Přesně co popisují mi s unionfs-fuse funguje stačilo jen přihodit UID a GID parametr, kdo má soubory vlastnit

[mankind_boost]

Nevim jak dnes, ale dřív byl UnionFS hlavně šílenej bastl. Mám radši AuFs.

[Luboš Doležel (Doli)]

Tohle je jinej unionfs, je přes FUSE.

[Honz]

Tak mě napadá - neznáte někdo nějaký repositář, kde by někdo dělal balíčky vývojových verzí pro Mageiu?

[chrono]

V Cauldron repozitári je vždy najnovšia verzia (takže práve teraz tam majú 1.5.14).

[chrono]

Každopádne netuším, či tam nie sú závislosti na nejakom príliš novom balíčku, ktorý nie je v bežnej verzii. Ja som to v Mandrive riešil tak, že som použil srpm balík a skompiloval som si ho sám.

[Grunt]

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 Mono

Windows Mono, Unix Mono, Wine Mono,… já už se v tom pomalu ztrácím.

[Hans1024]

Nojo, mam porad nvidia ovladace 295, protoze u vsech 30X.XX co jsem zatim zkousel byly 2 podstatne problemy:
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.
2. Xka se casto zasekavaji v 3D, horsi nez windows :D

[stativ]

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.

[Hans1024]

Kdyz jsem to naposledy zkousel, nektere aplikace (ve wine) to z nepochopitelneho duvodu ignorovaly a vsechna rozliseni se tam musi jednotlive vypsat - to je teda pokrok.

[stativ]

Možná to bude ten zmiňovaný problém, kdy s RandR 1.1 některá nastavení fungují, ale s Randr 1.2 už ne. Snad tedy přidají možnost vynutit 1.1 brzo.

[Rovano]

S 302.x se nezasekávali Xka, ale ovladač Nvidia. Zkus však této řady nejnovější verzi. Byly tam opravy.

[Yontalcar]

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'
nefunguje?