Steam Controller není jen obyčejný ovladač, dá se velmi detailně nastavovat, jak se chová (umí emulovat myš a klávesnici, a to na úrovni USB HID), takže není problém jej používat ve hrách, které ovladače vůbec nepodporují.
Ty dotykové plochy na Steam Controlleru jsou dvě, ten velký kříž vlevo je taky touchpad (i když většinou se používá nastavený jako směrový či tlačítkový kříž).
Se Steam Controllerem jde ovládat jakékoliv jiné aplikace i mimo Steam a Steam Link přenáší cokoliv, co je zrovna na obrazovce. Jde je tak používat i pro přehrávání filmů či promítání fotek.
Steam Controller už ke mě pádí poštou a Steam Link si pořídím, jen co zahojím tu finanční ránu z vánoc.
No a co se týká Steam Machine - dřív jsem si říkal, že je to k ničemu, ale časem, s tím jak mě přestalo bavit řešit jaký mám počítač a řeším jen to jestli stačí na moje běžné činnosti, to beru jako skvělou věc - prostě můj laptop bude stačit na všechno kromě her klidně i ještě 10 let (pokud to přežije) a na hry si pořídím Steam Machine. Jen počkám až na druhou generaci s podstatně silnějším HW, protože teď by to pro mě nebyl moc upgrade, spíš naopak.
To je sice hezké, ale přeci nebudu kupovat méně výkonný HW, než už mám. Moje potřeby teď pokryje můj ThinkPad W520 s i7 2960-XM, 32GB RAM a nVidia QUADRO 2000 2GB RAM, připojený k televizi přes Steam Link.
Až budou do Steam Machine dávat nějakou grafiku s plnou podporou Vulcanu a 4GB nebo raději 8GB RAM, tak to by byla jiná káva a takovou mašinu si hned koupím.
Tak od včera mám steam gamepad doma a říkám tohle nemá šanci. Možná je to o cviku ,ale opravdu špatně se mi s ním hraje. Nejlepší je x360 gamepad a jeho design. Ten kdo navrhl tlačítka ABXY na spodek vůbec netuší co tím způsobil. Do ruky nepadne LB a RB daleko vysoko. Ty placky v střílečkách bez šance něco trefit. Ne ne Valve to podělal a Steam mašinky bych bohužel nikomu nedoporučil.
Vulcan vypadá hodně zajímavě. Aby ho však herní vývojáři začali používat, tak je potřeba začít ho podporovat v herních SDK. Takový Unreal Engine 4 už má podporu linuxu, ale stále používá pro překlad linuxové verze OpenGL místo Vulcanu. Pokud by byl Vulcan podporován největšími herními engine, tak by to pro hrani na Linuxu mohla být zajímavá budoucnost. Zatím, pokud vím, má podporu pro linux jen výše zmíněný Unreal Engine 4 a pak ještě Unity 5 a Source Engine 2, ale u něj si nejsem jistý, zda už je SDK dostupné. A žádný z těchto enginů nepoužívá dosud Vulcan, podle posledních informací, které jsem četl. Nejsem si ani jistý, zda je už Vulcan v takovém stavu, aby se dal běžně nasadit.
To, ze Steam machines vopred pochovava zvysok sveta este dokazem pochopit - ten clanok na arstechnice prisiel pred Vianocami vhod a bezmyslienkovite ho skopiroval snad uplne kazdy portal. Ale na roote by som to necakal.
Podla mna je trocha priskoro pochovavat nieco, co este nezacali predavat. Predpredaje su navyse celkom dobre, jednu radu modelov uz stihli vypredat.
Také mě překvapilo, že si toho nikdo nevšiml a testy nezopakoval.
Mně je to celkem volné, protože hry hraju výjímečně a nedovedu si představit, že bych k tomu ještě potřeboval online službu, ale připadá mně to tak, že se ten lajdácký test v pro trh zajímavé době, někomu náramně hodí.
Někdy před rokem jsem, pro zajímavost, zkoušel testovací aplikace od Unigine na PC s Nvidia grafikou a měl možnost to porovnat s prakticky totožným PC, kdy byly Windows 7. Rozdíly byly cca v řádu jednotek procent, pokud nějaké...
Pěkný článek. Dodal bych následující:
- Steam Controller podle všeho hráče moc nezaujal.
- Steam Link má dost negativní recenze, i když má podle všeho z recentních produktů Valve největší potenciál: http://www.pcgamer.com/steam-link-review/
- Vulkan API ještě nemá hotovou ani specifikaci, kdežto DirectX 12 má plnou dokumentaci, je součástí Windows 10, pár vydaných her už ho podporuje a další jsou ohlášené. Nechci být pesimistický, ale než se Vulkan rozhýbá, trh bude nejspíš patřit DirectX 12.
Tak poslední bod je trochu zavádějící. Podle mého odhadu trh v té době nebude patřit DirectX 12, ale možná tak DirectX 14. To ale nebude asi žádný velký problém, ne? Podívejte se jak skvělé bylo DirectX 9 a kde je teď. Vulkan zkrátka nesoutěží s nějakou konkrétní verzí DirectX.
Este pre pobavenie, citat o hlavnom probleme Steam Link podla odkazovanej recenzie :)
Most frustrating, those crashes and streaming issues often require problem-solving on the host PC. An afternoon of testing games on the Steam Link usually means trudging upstairs to my PC half a dozen times to close a pop-up that pulled me out of the game I was trying to stream, restarting Steam after it mysteriously crashed, or closing a game that suddenly refuses to take controller inputs.
V preklade, pan ma problemy s Windows :)
Přesně tak, žádný z těch problémů jsem v Linuxu neměl, jediné problémy bylo občasné sekání se přenosu, když jsem to zkoušel přes Wi-Fi (vyřešil Ethernet), hry, které tvrdí, že podporují ovladač, ale přitom jej nepodporují (stačí přemapovat, co ovladač dělá), a to, že vše jde přes HDMI a mám projektor, tak jsem musel pořídit audio splitter.
Btw. vypnutí hry, která přestane reagovat na ovladač, je velmi snadné bez vstávání z gauče: Steam tlačítkem se přepnout do overlaye a tam zvolit Ukončit hru.
To první je problém aplikací běžících na Windows. To že spadne Steam nebo hra přestane reagovat nevypadá na problémy s Windows. A jistě jste si v té recenzi všiml i dalších věcí: nedostatečný bitrate (lze řešit nastavením které může zvýšit latency), hry nereagují ovladač, nelze je ukončit (using the Steam overlay to exit the game left it running in the background with menu music at full blast), nefunguje streamování (multiple crashes and situations where a game didn’t seem to properly launch for streaming, either giving me a black screen or returning to Big Picture Mode), nefungující overlay (trying to pull up the Big Picture mode overlay to quit would be sluggish or unresponsive).
A jak se tam také píše, SteamOS je pod kontrolou Valve, takže by situace teoreticky mohla být lepší. Jenže k čemu to je, když na něm chybí atraktivní hry, zaostává ve výkonu atd.?
> hry nereagují ovladač, nelze je ukončit (using the Steam overlay to exit the game left it running in the background with menu music at full blast), nefunguje streamování (multiple crashes and situations where a game didn’t seem to properly launch for streaming, either giving me a black screen or returning to Big Picture Mode), nefungující overlay (trying to pull up the Big Picture mode overlay to quit would be sluggish or unresponsive).
Lenze prave toto su vsetko problemy Windows.
hry nereagují ovladač - windowsia dinput / xinput schyzofrenia, alebo teda hry, ktore sa tvaria, ze gamepad podporuju, reaguju pri tom ale iba na ten xbox paskvil. Linuxu sa to netyka, /dev/input/js je univerzalne a rovnako tak i sdlinput. Este som nestretol hru, ktora by sdlinput nepouzivala.
can't exit the game using the Steam overlay - v linuxe sa posle sigterm, potom sigkill. Sigkill windows nema, takze hra _moze_ ukoncenie odmietnut. V *nixoch nema sancu
nefungující overlay - opat problem windows schyzofrenie. Overlay funguje len s DX hrami, hry vyuzivajuce OpenGL, html (ano, aj take su) alebo gdi (ano....) overlay nezobrazia. V Linuxe sa overlay zobrazi cez OpenGL, v SteamOS pomocou window managera.
Ona sice vacsina PC hier existuje iba pre Windows, Windows sa ale napriek tomu za hernu platformu maximalne nehodi :(
Ad prave toto su vsetko problemy Windows - nejsou.
Ad windowsia dinput / xinput schyzofrenia... - Steam Controller má podporovat i hry, které počítají jen s klávesnicí a myší. Pokud to nefunguje, je to špatně. Chyba může být na velké spoustě míst, včetně špatného profilu hry ve Steamu, ale nemyslím že je to věc Windows.
Ad v linuxe sa posle sigterm, potom sigkill. Sigkill windows nema, takze hra _moze_ ukoncenie odmietnut - aha. A k čemu je podle vás funkce TerminateProcess()? Otázka je, jestli ji Steam zavolá. A i kdyby ji zavolal, tak musí vědět, jaký proces má odstřelit. V některých případech totiž hru spustíte jako proces A, ten spustí proces B, a pak se terminuje. Steam by pak musel vědět, že má sestřelit proces B. Každopádně to nevypadá na problém Windows.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686714(v=vs.85).aspx
Ad Overlay funguje len s DX hrami... - to je věc Steamu. Zobrazit okno nad aplikací používající OpenGL nebo GDI není žádná magie, a minimálně OpenGL hry Steam Overlay umí. Pokud jsem si všiml, tak to otravné overlay na Shift+Tab zajišťuje nějaká knihovna ze Steam SDK. Buď tu knihovnu ve Valve dokopali, nebo třeba hra hookuje klávesy které se používají pro vyvolání overlay, nebo je problém úplně jinde. Každopádně to nevypadá na problém Windows.
Obecněji jsou hry pro PC psané pro klávesnici a myš, případně pro gamepad, a jsou na to testované. Když začnete dělat něco na co testované nejsou, tak možná prvních pár her bude fungovat jak předpokládáte. Ale v té velké spoustě her se s vysokou pravděpodobností najdou takové, které nebudou fungovat podle představ autorů Steamu.
> Steam Controller má podporovat i hry, které počítají jen s klávesnicí a myší. Pokud to nefunguje, je to špatně.
Nechcite po mne, aby som zacinal o tom, kolkymi sposobmi moze vo Windowse hra poolovat klavesnicu. Taku schyzu nema ani Blek :)
> V některých případech totiž hru spustíte jako proces A, ten spustí proces B, a pak se terminuje. Steam by pak musel vědět, že má sestřelit proces B. Každopádně to nevypadá na problém Windows.
Rozhodne to nieje problem mimo Windows. Unix pri sigkille zabije i dcerske procesy, takze je to opat nieco, co na SteamOS netreba riesit. Naviac sa TerminateProcess dokaze zablokovat na i/o waite, co je pri "zamrznutej" hre docela pravdepodobne.
k tomu zvysku:
Ja sice chapem a suhlasim, ze toto vsetko je hlavne problem Valve, problem, ktoreho riesenie ma zakaznik ocakavat. Som ale presvedceny, ze riesit ich na Windowse je vdaka jeho zufalej roztriestenosti ovela komplikovanejsie, nez riesit rovnaky problem na Linuxe.
Na Linuxe overlay a emulacia klavesnice znamena napichnut sa medzi hru a SDL, pripadne o vrstvu hore, medzi hru a Xlib. Neexistuje tretia moznost. A kedze si Valve dava do podmienok publikovania na SteamOS podporu presne tych konkretnych verzii SDL a Xlib, ktore su dodavane vramci SteamRuntime, myslim, ze 100% kompatibilny prototyp steamlinku dokazali uplacat za jednu noc a nespotrebovali pri tom ani dve konvice kavy.
Sam som nedavno riesil nieco podobne a 90% z tych 5 hodin, co som na to potreboval som stravil lustenim dokumentacie k iXkam.
Ad kolkymi sposobmi moze vo Windowse hra poolovat klavesnicu - na Linuxu minimálně /dev/input, Xlib a Qt events, plus je řada dalších možností. Co z toho plyne? Nejspíš vůbec nic. Nebo možná to že je Linux zoufale roztříštěný? :)
Ad nieje problem mimo Windows. Unix pri sigkille zabije i dcerske procesy, takze je to opat nieco, co na SteamOS netreba riesit. Naviac sa TerminateProcess dokaze zablokovat na i/o waite, co je pri "zamrznutej" hre docela pravdepodobne - pokud se na Unixu parent process ukončí, child process je orphan adoptovaný initem, takže to musíte řešit úplně stejně. Samozřejmě pokud je proces zablokovaný uvnitř jádra, tak na SIGKILL nereaguje. Triviálním příkladem je NFS mount s option hard a bez intr, odpojený NFS server a proces který se k němu snaží přistoupit. Hlavně se ale obávám, že ukončení hry je implementované nějak přes Steam Runtime, a žádné procesy se neodstřelují.
Ad Valve dava do podmienok publikovania na SteamOS podporu presne tych konkretnych verzii SDL a Xlib - to je jejich problém, jaké požadavky dávají pro publikaci na té které platformě.
Ad emulacia klavesnice znamena napichnut sa medzi hru a SDL, pripadne o vrstvu hore, medzi hru a Xlib - dokud nenarazíte na hru, které používá třeba přímo /dev/input. Pokud bych pro Windows implementoval gamepad typu Steam Controlleru, nejspíš bych napsal Common Controller driver a exportoval i HID class (klávesnici, myš a "tradiční" controller). Konkrétní hra pak může dostávat buď události přes XInput, nebo klidně třeba keystrokes. V profilu hry (ty profily Steam Controller stejně vyžaduje) pak popíšete mapování, a nakrmíte tou informací driver. Řešit to někde na úrovni SDL nebo Xlib, namísto implementace v driveru, je naprostý nesmysl.
Pokud jde o zachycení Shift+Tab na zobrazení toho otravného Steam Overlay, tak s tím kupodivu Steam nemá žádný problém. Ale podle autora recenze je občas problém, když se používá Steam Controller. Tipnu si že jde o dojebaný driver, dojebanou konfiguraci controlleru pro konkrétní hru, nebo problém Steam Runtime. Každopádně je to problém Valve, ne Windows.
> na Linuxu minimálně /dev/input, Xlib a Qt events, plus je řada dalších možností. Co z toho plyne? Nejspíš vůbec nic. Nebo možná to že je Linux zoufale roztříštěný?
Nie. Citat z /dev/input by znamenalo programovat si 3/4 vstupnej hal nanovo, bez moznosti sledovat, ci ma hra prave focus. Xlib je najspodnejsia vrstva, vsetko ostatne ide cez nu. Preto staci spravit emulaciu na tejto urovni a vsetko ostatne bude fungovat. Taka moznost na Windowse nieje. Nepomoze dokonca ani len napisat si vlastny driver - nebol by to "xbox controler" a vacsina hier by s nim odmietla spolupracovat.
> pokud se na Unixu parent process ukončí, child process je orphan adoptovaný initem
Na to by sa musel launcher hry demonizovat, co by naviac Steam vyhodnotil ako ukoncenie hry a vratil sa do big screen modu.
Rovnako tak by nemal byt problem so zombie process (tj vysledok sigkillu poslany pocas IO). Mozno ostane vysiet nejaku dobu v tabulke procesov, uzivatela to ale vrati do big screen modu a nic o nom netusi. Prave som to vyskusal :)
> Hlavně se ale obávám, že ukončení hry je implementované nějak přes Steam Runtime, a žádné procesy se neodstřelují.
Obavate sa zbytocne. Posiela sa sigterm, potom sigkill. Taktiez prave vyskusane.
> dokud nenarazíte na hru, které používá třeba přímo /dev/input. Pokud bych pro Windows implementoval gamepad typu Steam Controlleru, nejspíš bych napsal Common Controller driver a exportoval i HID class (klávesnici, myš a "tradiční" controller)
Viz odpoved hore. /dev/input nemoze fungovat ani na Linuxe, driver zase bude fungovat "len obcas" na Windows. Na Linuxe by bolo mozne napisat si vlastny driver, tj ale podla mna overkill a pokial viem, Valve to nerobi.
> Každopádně je to problém Valve, ne Windows.
Je to problem Valve, sposobeny Windows :)
Ad Citat z /dev/input by znamenalo programovat si 3/4 vstupnej hal nanovo, bez moznosti sledovat, ci ma hra prave focus - informaci o focusu dostanete od X11, vlastní vstup můžete klidně realizovat čtením /dev/input. A mimochodem implementace joysticků a gamepadů stojí na /dev/input. "Samozřejmě" /dev/input/jsX a /dev/input/event* má odlišný interface, joystick API vs evdev API.
Ad Na to by sa musel launcher hry demonizovat - pokud jsem si všiml, tak stačí když proces A vytvoří proces B, a pak se proces A ukončí.
Ad Nepomoze dokonca ani len napisat si vlastny driver - nebol by to "xbox controler" a vacsina hier by s nim odmietla spolupracovat - s klidem můžete napsat driver typu Common Controller, a exportovat i HID class (klávesnici, myš a "tradiční" controller). Nakonec i Xbox Controller ve Windows poskytuje HID class, takže s ním fungují i hry které nejedou přes XInput. Tady se můžete podívat, jak se mapuje Xbox Controller na HID.
https://msdn.microsoft.com/en-us/library/windows/desktop/hh405052(v=vs.85).aspx
Ad Na Linuxe by bolo mozne napisat si vlastny driver, tj ale podla mna overkill a pokial viem, Valve to nerobi - co na to koukám, tak Valve na Linuxu používá uinput, což je kernelový modul který umí injektovat input events. Aby controller fungoval ve hře, musí být zapnutý a funkční Steam overlay (nejspíš aby emulace ty události "hjkl space enter" neposílala když nejste ve hře). Alternativně existuje emulátor dalších controllerů, který přes uinput injektuje příslušné input events.
https://wiki.archlinux.org/index.php/Gamepad#Steam_Controller
Ve Windows se dá podobně použít Virtual HID Framework, případně starší ne-MS implementace. Nezkoumal jsem ale co Valve skutečně používá.
https://msdn.microsoft.com/en-us/library/windows/hardware/dn925048(v=vs.85).aspx
https://github.com/djpnewton/vmulti
Další možností je naučit přímo gamepad po stisku tlačítka A vrátit řekněme stisk mezerníku. Výhodou by bylo to že nemusíte řešit jestli jste na Windows, MacOS nebo Linuxu. Kódem specifickým pro danou platformu jen nacpete do controlleru seznam toho co má posílat na stisk tlačítek, a je hotovo.
Upřímně je to hezký tech talk, ale jako zákazníka by mě to moc nezajímalo. Existuje spousta cest jak implementovat emulaci klávesnice pomocí gamepadu, a je čistě na Valve, jak si to zařídí. Pokud to Valve nefunguje, není to problém Windows.
> informaci o focusu dostanete od X11, vlastní vstup můžete klidně realizovat čtením /dev/input.
Pozor, ja netvrdim, ze sa to neda. Len si neviem predstavit, preco by niekto taku hlupost robil. Bol by to skvely sposob, ako reimplementovat koleso, velmi nekompatibilnym sposobom. Plust by to nesmelo byt vydane ako "hra podporujuca SteamOS"
> pokud jsem si všiml, tak stačí když proces A vytvoří proces B, a pak se proces A ukončí.
Tj, myslim, obecna definicia demonizacie :) V kazdom pripade, toto by mozno nechalo hru bezat na pozadi, urcite by ale uzivatela vratilo do big screen modu. Hned po spusteni, nie pri pokuse o ukoncenie.
> Nakonec i Xbox Controller ve Windows poskytuje HID class, takže s ním fungují i hry které nejedou přes XInput
Lenze hry pod Windows podporujuce XInput - a, zial, tych je v poslednej dobe vacsina - jednoducho na nic ine, ako xbox controller nereaguju. Vo Windowse sa to riesi ohackovanou verziou xinput.dll. Ostatne, pripomenul ste mi, ze jedna hra robi rovnaky o*eb aj na Linuxe - nereaguje na gamepad, kym (asi) v lsusb nedetekuje ID xbox controlleru. Zacitujem Vam k tomu autora hry:
Hiya Kozec,
Alas yes, the Mark of the Ninja gamepad controls are hard-coded to
Xbox 360 controls.
We were required to do it this way by Microsoft, who originally
published Mark of the Ninja.
Zial, i linuxovy port hry ma za publishera Microsoft :(
> Upřímně je to hezký tech talk, ale jako zákazníka by mě to moc nezajímalo
Ved ja ani pohlad zakaznika neriesim. Napokon, uzivatela SteamOS sa ziaden z popisanych problemov netyka.
Prislo mi len vesele, ze najvacsim problemom SteamLinku nakoniec bude nutnost mat na jednej strane prave Windows.
Ad si neviem predstavit, preco by niekto taku hlupost robil - pravda, u klávesnice to asi nemá moc smysl, protože můžete použít X11 events. Gamepady se ale používají přesně tímhle způsobem.
Ad toto by mozno nechalo hru bezat na pozadi, urcite by ale uzivatela vratilo do big screen modu - to je možné.
Ad hry pod Windows podporujuce XInput - a, zial, tych je v poslednej dobe vacsina - jednoducho na nic ine, ako xbox controller nereaguju - XInput je tu tuším 10 let, a koupit herní ovladač (gamepad, volant, joystick, knipl, dance pad, kytaru, bicí, arcade pad) bez jeho podpory asi bude dost obtížné. Staré hry s herními ovladači používajícími XInput fungují. Nové hry s 10+ let starými herními ovladači by default nefungují, i když se k tomu samozřejmě dají několika technikami přinutit (psal jste o patchování xinput.dll, vyjma toho se dá třeba injectnout library). Osobně nevidím problém.
Ad jedna hra... nereaguje na gamepad, kym (asi) v lsusb nedetekuje ID xbox controlleru - co tu vidím, tak tu hru lze hrát i s jiným XInput kompatibilním ovladačem, ale má jiné problémy, včetně ukončování.
https://github.com/ValveSoftware/steam-for-linux/issues/2961
Ad Prislo mi len vesele, ze najvacsim problemom SteamLinku nakoniec bude nutnost mat na jednej strane prave Windows - samozřejmě na jedné straně potřebujete Windows, pokud chcete mít co hrát :). Ale nepřijde mi, že by problémy byly způsobené Windows. Vidím jich dost i na Linuxu/SteamOS. Problém je zjevně v tom, že ve Valve nemají odladěno. Co jsem četl, tak Steam i firmware Steam Controlleru updatují jako zběsilí.
https://github.com/ValveSoftware/steam-for-linux/issues/4155
https://github.com/ValveSoftware/steam-for-linux/issues/4130
https://github.com/ValveSoftware/steam-for-linux/issues/4129
https://github.com/ValveSoftware/steam-for-linux/issues/4126
https://github.com/ValveSoftware/steam-for-linux/issues/4111
https://github.com/ValveSoftware/steam-for-linux/issues/4098
https://github.com/ValveSoftware/steam-for-linux/issues/4066
https://github.com/ValveSoftware/steam-for-linux/issues/4004
https://github.com/ValveSoftware/steam-for-linux/issues/4130
https://github.com/ValveSoftware/SteamOS/issues/393
https://github.com/ValveSoftware/SteamOS/issues/340
https://github.com/ValveSoftware/SteamOS/issues/246
https://github.com/ValveSoftware/SteamOS/issues/273
Mimochodem ty výše linkované problémy mi nepřipadají v principu nijak odlišné od těch, které popisoval autor recenze na pcgamer.com.
> Gamepady se ale používají přesně tímhle způsobem
Gamepady pouzivaju sdlinput. Cokolvek ine ma 90% sancu *ne*fungovat mimo autorov pocitac.
> XInput je tu tuším 10 let, a koupit herní ovladač (gamepad, volant, joystick, knipl, dance pad, kytaru, bicí, arcade pad) bez jeho podpory asi bude dost obtížné.
Teraz neviem, ci je to daky pokus o humor, alebo kompletne odtrhnutie od reality, ale xinput ovladace existuju dva. x360 pad a xbone pad. Este par kusov od logitechu ho vie emulovat, ale to nefunguje zakazdym.
Cokolvek ine kupite ma HID.
> Osobně nevidím problém.
To ste mimo MS asi jediny :)
> co tu vidím, tak tu hru lze hrát i s jiným XInput kompatibilním ovladačem, ale má jiné problémy, včetně ukončování.
Ako vravim, ta hra sa odmietne spustit s cimkolvek, co sa ako x360 pad nehlasi. Take spravanie na Linux nepatri.
> Co jsem četl, tak Steam i firmware Steam Controlleru updatují jako zběsilí.
Za par dni sa maju steam machines zacat predavat, co moze sposobit neprijemne stretnutie ValveTime s realitou :D Viac by ma znervoznovalo, ak by nepatchovali.
Ad gamepady pouzivaju sdlinput - který používá /dev/input. SDL v1.x používá /dev/input/jsX i /dev/input/event*, SDL 2.x jen /dev/input/event*.
Ad xinput ovladace existuju dva. x360 pad a xbone pad - po chvíli hledání jsem našel vyjma pár modelů od Logitechu i další kusy od výrobců SpeedLink, Buddies, Deepon, Defender, Edge, GameSir, Genius, Joytron, Thrustmaster, vidím tu volant od Logitech, Megadream atd. Netvrdím že XInput podporuje každý PC gamepad, protože to nemůžu podpořit daty. Ale zcela jistě to nejsou jen dva kusy od MS plus Logitech.
Ad ta hra sa odmietne spustit s cimkolvek, co sa ako x360 pad nehlasi. Take spravanie na Linux nepatri - já hrál na Linuxu naposledy Tux Racer (BTW na SW rendering, 3D akcelerace přes mou urputnou snahu nefungovala), takže se neodvážím posuzovat, co na Linux patří nebo nepatří :)
Ad Za par dni sa maju steam machines zacat predavat, co moze sposobit neprijemne stretnutie ValveTime s realitou - střet s realitou přinesly už recenze, a prodeje to nejspíš jenom dorazí.
> Ad gamepady pouzivaju sdlinput - který používá /dev/input
Rovnako ako prislusne node v /dev/input pouziva Xorg. Napriek tomu nieje dobry napad citat /dev/input pre ziskanie vstupu z klavesnice :)
> Netvrdím že XInput podporuje každý PC gamepad, protože to nemůžu podpořit daty. Ale zcela jistě to nejsou jen dva kusy od MS plus Logitech.
V tom pripade viete googlit lepsie nez ja, namatkovo som skusil Deepon a Megadream, najviac co som nasiel su staznisti zakaznikov na neexistujucu podporu dinput :)
> střet s realitou přinesly už recenze, a prodeje to nejspíš jenom dorazí
Recenzie su zatial pozitivne az nadsene a predpredaje viac vypredane ako k dispozicii. Chcel by som mat taky neuspech.
Ad viete googlit lepsie nez ja, namatkovo som skusil Deepon a Megadream, najviac co som nasiel su staznisti zakaznikov na neexistujucu podporu dinput - jak jsem už psal, podpora DirectInput je u zařízení podporujících XInput automatická. Linkoval jsem vám i mapování buttonů z XInput pro hry podporující DirectInput. A ohledně googlení jedna poznámka: někteří výrobci (zcela nesprávně) píšou o "X-Input" nebo "X Input", nikoliv XInput.
http://www.amazon.co.uk/Steering-Megadream-Antiskid-Vibration-Rotation-Black/dp/B016VSNCE0
http://www.lowpriced-electronics.com/ProductLookup.aspx?id=B00RVI58JC
Ad Recenzie su zatial pozitivne az nadsene a predpredaje viac vypredane ako k dispozicii - mluvíte o Steam Machines, Steam Linku nebo Controlleru? A můžu se zeptat na zdroj? Žádná relevantní čísla jsem nenašel.
> najviac co som nasiel su staznisti zakaznikov na neexistujucu podporu dinput - jak jsem už psal, podpora DirectInput je u zařízení podporujících XInput automatická.
Pardon, to bol preklep. Staznosti boli na nepodporu xinput.
> mluvíte o Steam Machines, Steam Linku nebo Controlleru? A můžu se zeptat na zdroj
Machines a Controlleru, Steam Link nijak zvlast nesledujem.
Recenziu som vcera jednu linkoval, asi v inom vlakne:
http://www.overclock3d.net/reviews/systems/zotac_steam_machine_zbox_nen_sn970_review/1
Tak to asi ti výrobci měli nebo mají i modely bez podpory XInput. Moc nechápu důvod, protože "tradiční" gamepady byly každý pes jiná ves, a bylo je potřeba konfigurovat v podstatě pro každou hru.
Ad recenze - tu jsem četl, a je to zřejmě nejlichotivější recenze Steam Machines, kterou jsem četl. Autorovi se po čase začal líbit Steam Controller, což je názor který jsme četl i jinde. O vlastním SteamOS tvrdí že má spoustu problémů a málo her, ale čas to prý může vylepšit. A spoléhá na to že se ujme Vulkan API, které usnadní portování her. Bohužel to že je portování technicky snadné toho moc neznamená, protože podporu Linuxu už má spousta enginů, a hry na nich postavené často Linux nepodporují. Například nový CryEngine podporuje Linux, ale z 18 her jsou/budou jen 4 pro Linux. Navíc Vulkan ještě nemá ani hotovou specifikaci, zatím co DirectX 12 má SDK, běží u 27% zákazníků Steamu, má první vydané hry, a další jsou na cestě.
Nikde jsem v recenzi také nenašel žádná čísla týkající se prodejů, předobjednávek apod. Buď špatně čtu (přiznám že jsem text nečetl celý), nebo to tam prostě není.
> Moc nechápu důvod, protože "tradiční" gamepady byly každý pes jiná ves, a bylo je potřeba konfigurovat v podstatě pro každou hru.
Pretoze XInput gamepady funguju len s par hrami na Windows a obecne na Linuxe. Naviac su hru s podporou xinput u hracov neoblubene, nakolko casto neumoznuju konfigurovat ovladanie.
> Navíc Vulkan ještě nemá ani hotovou specifikaci, zatím co DirectX 12 má SDK, běží u 27% zákazníků Steamu, má první vydané hry, a další jsou na cestě.
Napriek tomu existuju 2 hry s realnou podporou DX12 a ohlasenych je ich asi 7, ak zaratate Armu 2x. Okrem toho ma podpora novych DX zo strany vyvojarov dost zufalu historiu - nakolko ju MS vzdy zviaze s aktualnou verziou Windows, este dnes vychadazaju hry s podporou DX9 - naposledy Heroes, minuly tyzden.
Mimochodom, NVidia vydala driver s podporou Vulkanu tusim v oktobri, to by malo byt tak 55% zakaznikov.
Ad XInput gamepady funguju len s par hrami - jak jsem linkoval, XInput gamepady poskytují interface i pro DirectInput HID. Driver poskytuje interface pro XInput, a zároveň HID interface. Například tlačítko A na Xbox 360 Common Controller gamepadu se mapuje na DirectInput HID Button 1. Naopak pokud gamepad nemá podporu XInput, tak si s ním neporadí hry, které podporují výhradně XInput.
https://msdn.microsoft.com/en-us/library/windows/desktop/hh405052(v=vs.85).aspx
Ad casto neumoznuju konfigurovat ovladanie - myslím že hráči ocení spíš to že hra jde bez konfigurace gamepadu, než to že si mohou ovládání konfigurovat. Nakonec to tak funguje i na konzolích.
Ad existuju 2 hry s realnou podporou DX12 a ohlasenych je ich asi 7 - Wiki zmiňuje 9 ohlášených áčkových titulů. Osobně se těším na Far Cry Primal.
Ad podpora novych DX zo strany vyvojarov dost zufalu historiu nakolko ju MS vzdy zviaze s aktualnou verziou Windows, este dnes vychadazaju hry s podporou DX9 - hry se vyvíjejí pár let, takže se to dá pochopit. Zvlášť u graficky nenáročných titulů není moc důvod přepisovat engine pro poslední verzi DirectX. Ohledně aktuální verze Windows souhlas. Ale pro Windows XP a Vista nemá smysl uvolňovat hry, protože jsou už velmi vzácné. Win7-8.1 rychle odcházejí ve prospěch Win10. Čekal bych že rozdělané áčkové tituly vyjdou s podporou DX12 i starších DX, a nově psané už jen na DX12. U indie scény bude samozřejmě přechod na DX12 výrazně pomalejší, protože jde většinou o graficky nenáročné tituly, takže chybí výhoda změny technologie. Ono se také pro DX12 a Mantle (a zřejmě tedy i Vulkan) píše o dost hůř, protože se programátor musí starat o spoustu věcí, které starší verze DX udělaly za autora kódu.
Ad NVidia vydala driver s podporou Vulkanu tusim v oktobri - četl jsem v listopadu, že se podpora chystá v další verzi driveru. Jenže driver bez SDK není dvakrát užitečný. A protože pořád není k dispozici dokumentace, tak bych čekal, že se ještě bude specifikace měnit. Nejspíš spolu s driverem.
Mimochodem Xbox One má nově DirectX 12. Vývojáři stejně musí Xbox One podporovat, takže to spláchnou spolu s Windows jedním API.
> myslím že hráči ocení spíš to že hra jde bez konfigurace gamepadu, než to že si mohou ovládání konfigurovat.
Ale hraci si to nemyslia. Otvorte si steam forum lubovolnej hry...
> XInput gamepady poskytují interface i pro DirectInput HID. Driver poskytuje interface pro XInput, a zároveň HID interface.
To sa ale tyka len Windows. Nepripojite ho k Androidu, iPhonu, na OSX potrebujete 3rd party driver, televizor ho vobec nevidi...
> Wiki zmiňuje 9 ohlášených áčkových titulů.
DayZ a Star Citizen su uz vydane, samozrejme bez DX12 podpory.
> Vývojáři stejně musí Xbox One podporovat
Musia? To uz MS oficialne presiel na mafiansky styl? XBone len nedavno dokazal prekonat predaje Wii U, takze by ma vobec neprekvapilo, keby buduce generacie "multiplatformovych" hier zahrnali PS3 a PS4. Do rakvy chyba uz len PS4 s podporou Vulkanu, ale tolky humor ani ja necakam.
> Čekal bych že rozdělané áčkové tituly vyjdou s podporou DX12 i starších DX, a nově psané už jen na DX12.
To by bola, vzhladom k uzasnej podpore W10 zo strany hracov, docela samovrazda :) Jedinym "modernym" API pouzitelnym napriec verziami Windows bude prave Vulkan.
Ad hraci si to nemyslia. Otvorte si steam forum lubovolnej hry - otázka je kolik procent uživatelů ty příspěvky na fóru reprezentují. Předpokládám že ti co ocení, že gamepad prostě funguje bez konfigurace, o tom na fóra nepíšou.
Ad To sa ale tyka len Windows. Nepripojite ho k Androidu, iPhonu, na OSX potrebujete 3rd party driver, televizor ho vobec nevidi - moc nechápu technický důvod. Měla by to být jen věc driveru. Ale také nevidím důvod připojovat gamepad kompatibiliní s Windows a Xboxem k iPhonu nebo MacOS X.
Ad DayZ a Star Citizen su uz vydane, samozrejme bez DX12 podpory - DayZ jsou v alpha verzi, k dispozici jako Early Access. Star Citizen je v "alpha 2.0".
Ad Vývojáři stejně musí Xbox One podporovat - příjmy z konzolí jsou pro vývojáře áčkových her zcela zásadní, takže pro ně má podpora Xboxu One vysokou prioritu.
Ad keby buduce generacie "multiplatformovych" hier zahrnali PS3 a PS4. Do rakvy chyba uz len PS4 s podporou Vulkanu, ale tolky humor ani ja necakam - pro PS3 a PS4 se píšou alternativní render paths (v řadě případů to za vás udělá autor enginu). Vulkan na PS4 možná jednou bude, nebo také ne. Zatím nikdo neví.
Ad To by bola, vzhladom k uzasnej podpore W10 zo strany hracov, docela samovrazda - jak jsem psal, Win10 už mají na Steamu přes 27%. Srovnejte s Linuxem (včetně SteamOS), který má pod 1%.
Ad Jedinym "modernym" API pouzitelnym napriec verziami Windows bude prave Vulkan - otázka je koho bude za rok dva trápit podpora Win7. Osobně si tipnu, že výrobci áčkových her vsadí spíš na DirectX 12, kterými pokryjou Windows a Xbox One, a zpočátku přidají render path pro starší verze DX.
To je samozřejmě jen můj názor, budoucnost se špatně předvídá. Jenže i kdyby Vulkan uspěl, pořád to neznamená, že hry budou vycházet i pro Linux. Jak jsem psal, už dnes podporuje Linux řada enginů, ale hry na nich postavené tu platformu většinou ignorují. SteamOS má šanci pokud Vulkan bude fakt dobrý na Windows, Linuxu i PS (na MacOS asi nebude, Apple má Metal API) && výrobci her budou psát pro Vulkan && rozhodnou se podporovat i Linux && platforma SteamOS nabere kritickou masu uživatelů. Na mě je tam moc těch "&&", a k tomu velmi vysoká pravděpodobnost, že jedna nebo více podmínek nevyjde.
Mimochodem to že je DX12 k dispozici daleko dříve než Vulkan, přestože jde podle všeho jen o přeleštěný Mantle od AMD, má jistou vypovídací hodnotu. Pokud je totiž Vulkan zpožděný už na startu, je otázka, jak bude stačit držet krok s dalším vývojem. MS má spoustu vývojářů i peněz, takže tenhle závod může snadno vyhrát.
> Win10 už mají na Steamu přes 27%. Srovnejte s Linuxem (včetně SteamOS), který má pod 1%
Nemyslim, ze by pocet hracov na Linuxe akokolvek suvisel s poctom hracov na SteamOS. Maximalne sa moze Valve chvalit, ze malo 12M betatesterov.
Ale hlavne, pocet ludi s Win10 zahrna "hracov" s laptopom a laptopovou grafikou. Vsimnite si hned vo vedlajsom grafe, 40% hracov ma kartu schopnu DX12 *bez* W10.
> otázka je koho bude za rok dva trápit podpora Win7
Najviac asi Microsoft :D A nepreskakujte tu medzikatastrofu, W8.
Ad Nemyslim, ze by pocet hracov na Linuxe akokolvek suvisel s poctom hracov na SteamOS - předpokládám že Steam stats vedou SteamOS jako Linux.
Ad pocet ludi s Win10 zahrna "hracov" s laptopom a laptopovou grafikou - Win10 má 27.42% instalací, DX12GPU & Win10 25.8%. Navíc DX12 se dá používat i na DX11 GPU.
Ad vsimnite si hned vo vedlajsom grafe, 40% hracov ma kartu schopnu DX12 *bez* W10 - ještě před cca čtvrt rokem to bylo 65%, což mi připadá jako celkem jasný trend. Win7 mají ukončený mainsteam support, a kdo si bude chtít zahrát novou hru pod DX12 (asi se shodneme že budou existovat DX12 hry bez podpory Vulkanu), ten prostě zdarma upgraduje. No a až jednou vyjde Vulkan, doufejme že před ukončením extended supportu Win7 :), tak pro něj budou první áčkové hry kdo ví kdy.
A ještě jeden argument: OpenGL je k dispozici na Windows řady NT odjakživa, a přesto se hry pro Windows až na pár výjimek píšou už léta pro DirectX. Proč by to s Vulkanem mělo být jiné?
Ad nepreskakujte tu medzikatastrofu, W8 - jestli někdo vidí "katastrofu" v tom že má ikonky aplikací na Start Screen místo ve Start Menu, když lze navíc alternativní Start Menu během půl minuty doinstalovat, tak já to nejsem :)
Ze se vubec tema jeho blabolama zabejvas ... a mimochodem, ve firemnim sektoru, coz je ten, kterej M$ zivi, je podil w10 presne 0 a jeste minimalne 5 let bude. A co bude pak? No to se uvidi, ale cim dal vic firem resi likvidaci M$ prostredi globalne.
On totiz M$ neustale zdrazuje. A pro pobaveni ... M$ exchange a potrebna bizuterie kolem (opice kvuli utloukovi ...) na 5 let ... pro 100 lidi ... +- 2MKc. Totez u konkurence (bezici na linuxu) +- 250kKc. Vcetne implementace a hotline (to M$ v cene samo nema).
A co se tyce games, takovych, ktery nejednou na dx9 je naprosty minimum. A vyvojari moc dobre vedi proc.
Ad Ze se vubec tema jeho blabolama zabejvas - a že se jimi vůbec zabýváte vy :)
Ad ve firemnim sektoru, coz je ten, kterej M$ zivi, je podil w10 presne 0 a jeste minimalne 5 let bude - firmy jsou tradičně konzervativnější, a přechod velkého množství klientů na novou verzi OS je přece jen větší projekt než upgradovat jeden domácí počítač. Podle SpiceWorks měly Win10 ve firmách už krátce po uvedení penetraci 11%, a do dvou let chce upgradovat 73% firem.
http://community.spiceworks.com/topic/1232403-windows-10-who-s-using-it-10-weeks-after-launch
Mimochodem za důležitý aspekt Windows 10 považují IT profesionálové bezpečnost. Win10 mají nový aplikační model, kde jsou aplikace sandboxované podobně jako na mobilech. Instalovaná aplikace pak nemůže poškodit systém a ostatní aplikace, ani kdyby chtěla. Možná budete mít jednou na Linuxu také něco takového :)
http://community.spiceworks.com/windows/windows-10/will-it-soar-report
Ad M$ exchange a potrebna bizuterie kolem (opice kvuli utloukovi ...) na 5 let ... pro 100 lidi ... +- 2MKc - na prvním místě byste se měl lépe zorientovat v multilicenčních programech. Na druhém místě vás nikdo nenutí kupovat celý MS Office, můžete si klidně pořídit jen Outlook. Jenže MS Office je stejně potřeba, protože konkurence prostě nemá srovnatelnou kvalitu, nemluvě o kompatibilitě. No a na třetím místě pokud byste opravdu dal za 5 let na licencích MS Office a Exchange 20000 Kč na uživatele, tak uvažte, že za tu dobu má každý zaměstnanec náklady na mzdy a odvody v průměru kolem 3M Kč. Těch 20K na uživatele je tedy 0.66% z těchto nákladů :). A to do nákladů na zaměstnance nepočítám zástup o dovolené a nemoci, HW, nábytek, rozpočítané náklady na nájem a energie atd. Když to shrnu, tak náklady na MS SW, který uživateli umožňuje pracovat, jsou proti nákladům na zaměstnance zanedbatelné.
Hele blabole, mam tu 50 PC s win 10 ... licencne. Realne na nich sou w7. Nehodlam se totiz v pondeli rano probudit s tim, ze widle pri updatu smazli erpcko ...
A ze ty nemas paru o licencich absolutne zadnou to uz davno vime, tohle je totiz nabidka primo od M$. A ja narozdil od tvych blabolu nepotrebuju nic zvazovat, protoze rozdil je v tom, jestli budu mit 2M nebo nebudu mit 2M, coz pochopitelne trotl jako ty nemuze chapat.
A pro pobaveni publika, na tema jak strasne vsichni chteji ty M$ kravince ...
..........................
Speciální firemní nabídky a akce ...
Finanční podpora na implementaci Office 365
Při objednávce Office 365 získává zákazník* implementační služby kvalifikovaného partnera Microsoft
v hodnotě 5 000 Kč + 10% z celkové ceny objednaných služeb Office 365.
Při objednávce Office nebo Office 365 získává zákazník slevu v hodnotě 5-25 % z celkové ceny objednaných licencí Office nebo Office 365 (až na tři roky). Velikost slevy je závislá na počtu objednaných licenci.
Nabídka platí do odvolání, nejdéle však do 31. 12. 2015
...................................
Zjevne jim vsichni doslova rvou ty licence z ruk ...
Jop, tohle neni zadna custom vec, tenhle spam rozesilaji vsem. A je toho tam samo vic.
Ad Hele blabole - aha, změna přezdívky z "j" na "fd". To už jste dostal ban za porušování podmínek diskuse? :)
Ad mam tu 50 PC s win 10 ... licencne. Realne na nich sou w7 - a?
Ad ja narozdil od tvych blabolu nepotrebuju nic zvazovat, protoze rozdil je v tom, jestli budu mit 2M nebo nebudu mit 2M, coz pochopitelne trotl jako ty nemuze chapat - to je pohled admina. Pohled managera je takový, že pokud ušetřením ekvivalentu 0.66% mzdových nákladů dojde k propadu produktivity práce byť jen o procento, tak firma prodělala. Plus manager ví, že kombinace MS Office a Outlook tvoří velmi produktivní nástroj, za který těžko najít odpovídající náhradu.
Ad Zjevne jim vsichni doslova rvou ty licence z ruk - Office commercial products and cloud services revenue grew 5% in constant currency... Server products and cloud services revenue grew 13% in constant currency...
https://news.microsoft.com/2015/10/22/strong-execution-drives-microsoft-first-quarter-results/
Hmm... Není moc diskutérů, kteří by uměli napsat regex a zároveň věděli co je constant currency :)
Microsoft presents constant currency information to provide a framework for assessing how our underlying businesses performed excluding the effect of foreign currency rate fluctuations. Silný dolar se samozřejmě na výsledcích podepsal, ale to pro srovnání nehraje moc roli. Nakonec i akcie zareagovaly slušným růstem.
Když už jsme u toho inputu, trochu nesouvisle, ale… Zjevně jste odborník, vysvětlete mi prosím jak v té opičárně změnit naprosto dementní chování kdy se pravý alt v systému chová jako ctrl+alt a možná u toho OS v práci zůstanu trochu déle, jinak okna letí oknem a nahrazuje je Arch. Ta zhovadilost mi způsobuje kolize rozložení klávesnice se zkratkami textového editoru a klikat místo nich po menu je opravdu blbá náhražka.
To není bug, ale feature :). Americká klávesnice má pravý a levý Alt, které se chovají stejně. Česká klávesnice (plus řada dalších rozložení včetně nepoužitelného US International) má levý Alt a pravý AltGr. AltGr se používá pro zadávání znaků, které daná národní klávesnice "normálně" neobsahuje: Euro, zpětné lomítko, zavináč atd. Linky níže ukazují českou QWERTZ a QWERTY klávesnici. Když najedete na AltGr (alespoň v MSIE a Edge), tak uvidíte mapování.
http://www.microsoft.com/resources/msdn/goglobal/keyboards/kbdcz.html
http://www.microsoft.com/resources/msdn/goglobal/keyboards/kbdcz1.html
https://msdn.microsoft.com/en-us/goglobal/bb964651
AltGr je z hlediska aplikace shodný s Ctrl+Alt.
Pokud chcete aby se AltGr choval vždy stejně jako levý Alt, pro všechny uživatele, můžete ho na klávesnici přemapovat. Koukněte na sekci Scan code mapper for keyboards v prvním linku a scan codes v druhém linku.
https://msdn.microsoft.com/en-us/library/windows/hardware/jj128267%28v=vs.85%29.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=22339
Konkrétně do "HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout" vložíte hodnotu "Scancode Map" typu REG_BINARY (little Endian format), a vložíte tam následující hodnoty:
0x00000000 (Header: Version)
0x00000000 (Header: Flags)
0x00000002 (Number of entries in the map, including the trailing null entry).
0xE0380038 (Right ALT key --> Left ALT key (0xE038 --> 0x0038))
0x00000000
Takže teď už to jen převrátit na little endian a nacpat do Registry: regedit.exe, větev a hodnotu k založení vizte výše, data jsou tady. Nakonec rebootujte.
00 00 00 00
00 00 00 00
02 00 00 00
03 00 00 00
38 00 38 E0
00 00 00 00
Alternativně si můžete vytvořit vlastní layout klávesnice. Ten je na rozdíl od výše zmíněného postupu per-user. Jestli chcete postup, dejte vědět.
BTW kam mám poslat fakturu? :)
Některé klávesnice nemají AltGr.
http://ayati.cocolog-nifty.com/photos/uncategorized/2009/04/23/m106.jpg
Další klávesnice mají dvě klávesy Alt, ale obě generují ten samý scan code. Upřímně při tom guláši který v klávesnicích je... buďte rád, že to nějak funguje :)
https://en.wikipedia.org/wiki/Scancode
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/scancode.doc
Na klávesnici bez AltGr člověk v zemích kde se používá prakticky nenarazí. Zato na situaci kdy by se mu hodilo mapovat si ctrl+alt+klávesa ano. A navíc je opravdu těžké dát na to položku třeba do usnadnění, případně s tím jen počítat v keymapách (aby si to uživatel mohl změnit)
Ještě by mohli opravit virtuální plochy, fakt že při jejich přepnutí nedostane poslední používaná aplikace na dané ploše focus tu funkci dost sráží…
Use the following guidelines for designing shortcut keys:
...
- Avoid CTRL+ALT combinations because the system interprets this combination in some language versions as an ALTGR key, which generates alphanumeric characters.
https://msdn.microsoft.com/en-us/library/ms971323.aspx
Na americké klávesnici (ve které v IT businessu stejně nejspíš strávíte většinu času) vám Ctrl+Alt+klávesa fungovat bude, na české ne. Jak jsem psal, můžete si udělat alternativní keyboard layout, který nebude mít AltGr.
https://msdn.microsoft.com/en-us/goglobal/bb964665.aspx
Dlouhé roky používám alternativní layout který je v základu programátorský US, ale altgr používá pro české znaky, včetně některých na normální klávesnici neobsažených. (česky píšu dostatečně často na to aby mi přepínání vadilo)
V textovém editoru mám pak nabindovaných dost zkratek, absence ctrl+alt by dost zamrzela.
Navíc už se mi několikrát povedlo při psaní zprávy zavolat kolegovi ze Skypu, ctrl+alt+r je vytočení (ten software už pěkných pár verzí patří MS, takže se zjevně nedrží vlastních design guidelines. To je taky vlastnost? Navíc jsem v menu vypl klávesové zkratky, ale tahle je zjevně hardcoded)
A fakt nevím proč bych se měl limitovat kvůli naprosto uhozenému rozhodnutí tvůrce OS…
Já to celé roky dělám tak, že používám US klávesnici na kód a angličtinu (cca 90% času), a českou QWERTY na češtinu. Přepnutí je na Win+Space, jsem tak zvyklý. Výhodou je to že při přepnutí jazyka se přepne i speller.
Ad ten software už pěkných pár verzí patří MS, takže se zjevně nedrží vlastních design guidelines - tak už to bývá :). Skype napsala jiná firma, a UI je prý psané v Delphi. BTW dají se udělat i klávesové zkratky na AltGr, ale ne přes standardní Win32 registraci hotkey. Například v message WM_CHAR lParam bit 24 Indicates whether the key is an extended key, such as the right-hand ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if it is an extended key; otherwise, it is 0. A hotkey na Ctrl+Alt+klávesa se podle všeho nemusí sepnout na AltGr+klávesa, pokud hotkey registrujete přes RegisterHotKey(); Skype asi hotkey identifikuje v message loopu nějak jinak. Ovšem registrací hotkey na Ctrl+Alt+klávesa zabijete možnost vkládat znaky používající AltGr na klávesnici, která AltGr nemá. Takže když to shrnu, držel bych se doporučení na MSDN nedělat hotkeys s Ctrl+Alt, a AltGr bych jako modifikátor nepoužíval.
Ad fakt nevím proč bych se měl limitovat kvůli naprosto uhozenému rozhodnutí tvůrce OS - mě zase přijde uhozené mít custom layout klávesnice, který najdete jen a pouze na svém stroji, když to navíc nefunguje na některých klávesnicích, nefunguje s tím speller a ještě to koliduje s klávesovými zkratkami v aplikacích. Jak vidíte, každý považujeme za uhozené něco jiného.
>mít custom layout
Pokud používám jiný PC, nemám problém použít i standardní US nebo CZ layout. Jen mi pro práci nevyhovuje.
>nefunguje na některých klávesnicích
Používám ho na svých strojích ke své práci, takže si klávesnici volím.
>nefunguje s tím speller
Funguje. Speller používám jen v pár aplikacích a jen občas, většinou jen v jednom jazyku.
>koliduje s klávesovými zkratkami
Za to může zjevně OS, jinak by nic nekolidovalo.
Jinak přepínat layouty jsem zkoušel, ale po tom co se mi párkrát v textovém editoru přepl z EN na CZ, vykašlal jsem se na to. Myslím že se to stávalo nejčastěji při změně virtuální plochy.
Osobně se snažím používat to co funguje všude. Například pro mě nemá smysl používat Total Commander, protože se často dostanu na servery, kde není a nesmí být. Podobně třeba na Unixech s mc. To že bych měl při přechodu na jiný stroj používat jiný layout klávesnice je pro mě noční můra. Pokud jste někdy používal francouzskou klávesnici, tak máte představu proč :)
Ad přepínání layoutů - není to tím že Win7 a starší mají rozložení klávesnice per process, a Win8 a novější by default per session? Když na Win7 přepnete třeba z emailu na IDE, tak se z tohoto důvodu může změnit layout.
Proto (a také kvůli upravitelnosti pro jazyk ve kterém v práci programuju… Je to trochu exotičtější věc) používám multiplatformní editor Atom, který má právě zkratky nabindované často na ctrl+alt (a je jich tolik, že by to vážně chybělo). Tvůrci jsou bohužel zjevně z anglicky mluvících zemí a tahle úžasná vlastnost Windows je zjevně nenapadla.
S tím layoutem to není tak horké, člověk si dovede zvyknout používat víc rozložení (ostatně, znám pár lidí kteří používají DVORAK či COLEMAK a u cizího počítače jim nedělá problém vrátit se ke QWERTY/QWERTZ). VOK (resp. mnou upravená varianta) se navíc bez použití AltGr chová jako standardní US rozložení.
Přepínání per proces mi osobně dost vadí, ale zvyknout se na něj dá. Tady bohužel došlo k tomu že se po přepnutí z US na CZ při přepnutí aplikací po návratu do editoru nevrátil US layout, ale zůstal CZ. Několikrát. Možná za to můžou zjevně nedodělané virtuální plochy…
Atom je tuším psaný v (derivátu) JavaScriptu, a běží pod browserem Chromium. AltGr+klávesa v případě registrace hotkeys přes Win32 API neaktivuje hotkey registrovaný na Ctrl+Alt+klávesa. Jenže Atom hotkeys rozeznává po svém. Pokud byste chtěl zkusit problém vyřešit, můžete kouknout na atom/src/window-event-handler.coffee, definice funkce handleDocumentKeydown(event). Zkusil bych to debugnout a zjistit, jak ty eventy vlastně vypadají. Pokud tam na AltGr+klávesa přijde něco jiného než na Ctrl+Alt+klávesa, mělo by to jít opravit. Pokud tam leze totéž, tak nedostáváte správné eventy, protože je Chromium zřejmě nepustí. Z dokumentace Chromia moc moudrý nejsem, vypadá to že je tam bug na bugu. Sám se tomu věnovat nemůžu, mám na rozdělané jiné věci.
Ohledně přepínání layoutu: ve Win10 můžete mít layout per session (default) nebo per process, nastavuje se to v Control Panel\All Control Panel Items\Language\Advanced settings. Přepínání virtuálních ploch ve Win10 na layout klávesnice u mě nemá vliv, a nevidím důvod proč by ho mělo mít. Samozřejmě jiné implementace virtuálních ploch mohou dělat cokoliv.
$ evtest /dev/input/keyboard | grep ALT
Event code 56 (KEY_LEFTALT)
Event code 100 (KEY_RIGHTALT)
Event: time 1448987010.155109, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1
Event: time 1448987010.203112, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0
Event: time 1448987010.555108, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 1
Event: time 1448987010.587112, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 0
lael, lael :)
Jasně, problém se šipkami… Na klávesnici bez AltGr jsem nenarazil ani mezi opravdu osekanými mechanickými klávesnicemi. Určitě bych si takovou nepořídil, stejně jako notebook s ní. Pokud už bych měl tu potřebu pracovat na takové, nebyl by pod Linuxem problém použít libovolnou jinou klávesu jako modifikátor, včetně kombinace Ctrl+Alt (nebo Caps Lock, proč ne…). On totiž není problém přebindovat modifikátory, když to OS umožní. Což Microsoftu jaksi zjevně nedošlo.
Ad problém se šipkami - tu bažinu podpory terminálů na Unixech snad ani diskutovat nemusíme, abychom se neumazali :)
Ad na klávesnici bez AltGr jsem nenarazil ani mezi opravdu osekanými mechanickými klávesnicemi - například originální PC XT mělo jen jeden Alt, vizte obrázek. K tomu jsem vám už linkoval nějaký netbook co nemá AltGr, plus některé klávesnice (uznávám že nejspíš historické) posílají na levý a pravý Alt stejný scan code.
http://www.pcguide.com/ref/kb/layout/z_011261xt.jpg
Toho roky navátého bahna je plno v každým OS, ale „bažinu podpory terminálů na Unixech“ nechápu, nebo se s ní nesetkávám.
Na PC XT programovat v blízké době nehodlám, takový netbook si vážně nepořídím a pak tu máme historické klávesnice… Super, takže se shodneme že k tomu chování Windows není v momentální době žádný racionální důvod (navíc se to defaultně může překládat na ctrl+alt, proti tomu nemám žádné výhrady… Kdyby to šlo vypnout.)
Unixy mají terminály jako čistě znaková zařízení vycházející ideově z dálnopisu. Aplikace má stdout, a když chce řekněme změnit barvu písma, zapíše na něj escape sekvenci. Vstup textu probíhá přes stdin, a šipky a spol. jsou opět řešené escape sekvencemi. A "krása" celého světa Unixů je v nejednotnosti. Escape sekvence pro změnu barvy fontu nebo pro klávesu RightArrow se liší podle typu terminálu. Vysloveně tristní je to, že se liší implementaci od implementace i Backspace a Delete :/. Aplikace musí zjišťovat jakou escape sekvenci má na stdin poslat, případně jak interpretovat stdin. Za tím účelem existuje env variable s typem terminálu, a několik různých databází escape sekvencí, které popisují minimálně stovky typů terminálů, včetně položek typu "Jeffův terminál na pokoji 321". Některé aplikace mají vlastní DB escape sekvencí.
Celé to má zajímavé důsledky. Například příkaz cat file nad "nevhodným" souborem může vysypat na terminál sekvence, které ho rozhasí tak že je nepoužitelný. Navíc když se z připojíte jednoho Unixu na jiný, případně z Windows na Unix nebo z Unixu na Windows, tak s vysokou pravděpodobností nepůjdou šipkové klávesy (plus F-klávesy a další). Což je přesně ten důvod, proč každý unixový admin musí umět ovládat pohyb kurzoru pomocí kláves hjkl a esc (což pochází z dřevních let Unixů). To jediné totiž na Unixech funguje vždy a všude.
Ad k tomu chování Windows není v momentální době žádný racionální důvod - myslím že historie a nedostatek důvodů ke změně jsou dost racionální důvody. Alespoň ve srovnání s tím co jsem popisoval výše :)
Nezabudnite na ^K^H^P^M, terminalove sekvencie sipok v DOSe a Windows :D
> Alespoň ve srovnání s tím co jsem popisoval výše :)
Inak teda neviem, ale ospravedlnovat nemoznost woken niecim, co platilo v Unixoch tak 20 rokov pred tym, nez Windows vobec bol je nizke aj na Vas. HJKL pouzivalo vi a po nom niekolko hodne starych shellov, a to jednoducho preto, ze boli starsie nez vynalez klaves so sipkami.
Cca od 1989 vsetko bezi na vt100 a ako $TERM sa udava xterm. Problem mozu mat maximalne tak masiny starsie nez Linux a potom samozrejme Windows, respektive putty.
S tou historií mi to nepřipadá zrovna relevantní. Jestli poslední PC bez AltGr bylo XT, Windows se tam těžko vyskytl. Po celou historii Windows už ta klávesa, pokud vím, byla. Celkem by mě zajímalo jak se k tomu chovají některé prastaré komerční Unixy.
Ale je fakt že pokud jde o lokalizaci, mnohá rozhodnutí MS jsou padlá na hlavu (třeba funkce v Excelu, i když tu šílenost snad už opravili)
Klávesnice s jedním Altem měly i originální PC AT. Na těch mimochodem běžely i Windows 3.1.
https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:IBM_Model_F_AT.png
Ad pokud jde o lokalizaci, mnohá rozhodnutí MS jsou padlá na hlavu (třeba funkce v Excelu, i když tu šílenost snad už opravili) - pokud má SW používat člověk který neumí anglicky, asi by měly být lokalizované i názvy funkcí. Souhlasím že to pak vypadá šíleně :). Osobně jsem měl český MS Office naposledy před cca 17 lety, takže mě to netrápí.
Taky používám všechen SW v angličtině… On člověk na Windows i Linuxu občas narazí v překladu na takové ukrutnosti, že to nejde. Na stranu druhou, udělat lokalizaci tak že je výsledek uložení do dokumentu nekompatibilní s jinými jazykovými verzemi (v jednom případě i sám se sebou, stará dobrá chyba s uložením csv děleným čárkami který pak excel nedovedl importovat), to už je extrém blbého návrhu za který by se mělo vyhazovat :)
To vidíme oba dost podobně. Zlatá angličtina.
Excel ukládá názvy funkcí v angličtině, a zobrazuje je v jazyce uživatele. Takže když uživatel v německém Excelu vytvoří soubor, uvidí názvy funkcí v němčině, uloží je v angličtině, a uživatel českého Excelu je uvidí v češtině. Pokud se vám někdy stalo, že v souboru byly cizojazyčné funkce které nefungovaly, důvod byl jiný. Zřejmě šlo o funkce psané ve VBA, které se zobrazují vždy tak jak jsou ve VBA deklarované. Když vám pak někdo pošle ořezanou verzi souboru bez maker, tak vidíte nefungující funkci.
CSV je trochu problém, protože český formát čísel má jako oddělovač desetinných míst čárku. Pokud je nastavené české locale, používá se jako oddělovač polí v CSV by default středník. Podobný problém je s formátem data, který se liší jak ohledně pořadí, tak oddělovače dne/měsíce/roku. Řešením je používat funkci import text, která otevře wizard, ve kterém lze vybrat oddělovače i formát data.
Ecel 2003 ukládal pokud vím názvy také v angličtině, a nevím o verzi která by to nedělala. Možná nějaká velmi stará. V novějších verzích Excelu byly naopak přidané nějaké funkce pro manipulaci s lokalizovanými jmény funkcí, pomocí kterých v českém Excelu můžete pomocí makra získat vzorec typu "=SEČTI(A1:B5)", což dřív nešlo. Příkladem je vlastnost FormulaLocal.
Je to nejaka doba co jsem videl prvni test steam os, mozna to bylo prave na arstechnice, kde test probihal na podivne sestave se starym gpu a slabym cpu (gpu gtx660, cpu celeron nebo pentium) v podivnych rozlisenich.
Na uvedenem odkaze na arstechnicu jsem ale nenasel na jake sestave test probihal (mozna jenom spatne koukam), ale podivne rozliseni zustalo.
Jasne je, ze ty hry na steam os bezi hure, ale myslim ze by bylo objektivnejsi testovat v nejakem tv rozliseni (nejlepe fullhd 1920x1080), pak by ten rozdil ve vykonu nebyl nejspis tak markantni. Navic jednu hru testuji v jinem rozliseni nez ostatni.
Zkratka ten test na ars technice mi neprijde moc dobre provedeny. Nevite nekdo o nejakem jinem?