Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Zaujimalo ma ako to s VGA bude u Intelackych ATOM dosiek. Ked uviedol prve tak sa kdesi nechal pocut ze do lacnych dosiek s atomom bude montovat vyhradne a len VGA D-SUBTo je jednoduché, nebude to nikdo kupovat.
Takova vymozenost je az u vetsich ARMu (AT91sam7S ma taky pouze device), pripadne asi u AVR32, ale to je jiz taky jina liga.Nebo u tohodle
zlepšují jednočipy, takže to USB se už dá pořešit celkem lehceNo, pane kolego není USB jako USB. MCU dnes poměrně běžně mají USB OTG (On The Go), což znamená, že takovýto MCU může být snadno periférií třeba PC s USB HOST HUB, ale nelze k němu připojit třeba USB flash disk. Například konkrétně u Cortex M3 jader, řada STM32F (od ST Microelectronics) "umí" USB HOST funkci pouze nejvyšší typové řady STM32F105 a STM32F107! Takže bych s tvrzením, že "USB se dá pořešit lehce" bych byl velice opatrný. Skutečně připojit ISA kartu k mcu je jednoduché - je to dostatečně pomalé, komunikace je jednoduchá. Ale už připojit PCI kartu k mcu znamená použití výkonného FPGA čipu. Stejným případem je ATA komunikace (a SATA na druhé straně). Pokud chci připojit přes ATA třeba hard disk k mcu, tak to jde - komunikace je totiž řízena masterem, kterým je ten mcu. Ale SATA vyžaduje jakousi minimální rychlost a ta je tak vysoká, že běžný mcu (nemám na mysli nadupané Cortex A9 s příslušným řadičem) to nedokáže zvládnout. A když už jsme u toho VGA - rovněž generování VGA signálů není tak obtížné. Ale zvládnout generaci HDMI znamená koupit (draze
Neřekl bych, že HDMI je nějaká výhra. Když jsem si pořídil kartu s HDMI výstupem, celý natěšený jsem ji hned zkusil připojit k televizi … a zjistil, že prostě neexistuje způsob, jak přes HDMI používat nativní rozlišení televize (1366x768). Lze jen 1280x720 (což je zkreslené přeškálováním) nebo 1920x1080 (což televize nezvládne). Takže jsem se zase pokorně vrátil ke starému dobrému VGA…
Jen doufám, že v tomhle bude DisplayPort lepší.
Nepomohlo zaškrtnout ve widlích "zobrazit i režimy, které monitor nepodporuje"?
Nevím, to bych tam nejdřív nějaké "widle" musel nainstalovat, abych to mohl vyzkoušet.
Jo vy mluvíte o Linuxu? "Mode lines" už v Xech nefungujou?
U analogového výstupu nějak fungují, ale monitor si s tím stejně většinou dělá, co chce. U digitálního z nich má smysl v podstatě jen rozlišení a vzorkovací frekvence. V daném případě prostě 1280x720 byla jediná varianta, při které bylo na televizi vůbec něco vidět. A co jsem zkoušel googlit, nebyl problém ani ve mně ani ve zvolené kombinaci videokarty a LCD, protože je to víceméně obecná vlastnost připojení přes HDMI. Teoreticky možná HDMI podporuje i něco jiného, ale praxe je bohužel trochu jiná.
A *zkoušel* jste si s těmi modelajnami hrát?
Pokud ano, mělo to nějaký efekt, jako třeba aspoň že to přestalo úplně fungovat?
Příště si nejdřív přečtěte příspěvek, na který odpovídáte. Tam jasně píšu, že jsem zkoušel ledacos a že 1280x720 bylo jediné rozlišení, při kterém bylo na obrazovce něco vidět. Na konkrétní modelíně pak zase až tak nezáleželo - což je ostatně u digitálního výstupu standardní chování (pokud není úplně nesmyslná). Ten problém jsem navíc neměl jen já, naopak, nepodařilo se mi najít jedinou pozitivní zmínku někoho, kdo by uspěl.
Ale pokud trváte na tom, že to dokážete, tak něco navrhněte. Jakmile budu mít čas (což bude asi tak v pondělí), rád to vyzkouším.
Poslední příspěvek v této diskusi taky vypadá moc povzbudivě… Za blbost se holt platí - kdybych rok počkal, mohl jsem mít za stejnou cenu 40" FullHD a jako bonus by mi (možná) fungovalo nativních 1920x1080 přes HDMI.
Mimochodem, DVI vstup by na té telce nebyl?
Bohužel. Jen HDMI, VGA, Scart a komponentní. Možná i nějaké to S-Video by se našlo. Holt nezbyde než zůstat u VGA.
Nojo... to mě mrzí. Vám to už asi nepomůže, ale třeba někdo jiný bude mít větší štěstí, proto tady jsou nějaké návrhy, co třeba zkusit:
Podle návodu zvaného "Generalized Timing Formula" (dle původního Xfree86 video timings howto) by mohla být sjízdná třeba tahle modelína:
Modeline "1366x768" 85.12 1366 1398 1726 1758 768 768 775 807 +hsync -vsync
No a IEGD CED nabídl nějaký režim, o kterém sice tvrdí, že toto rozlišení není CVT-compliant (což možná kecá), ale časování bude zřejmě zhruba odpovídat:
Modeline "1366x768" 85.20 1366 1438 1574 1782 768 771 781 798 +hsync -vsync
Tady je k tomu taková tabulka (XLS, sorry).
No a dá se cvičit s různými věcmi: se šířkou a pozicí synchronizačních pulzů, už mi taky jednou pomohlo otočit polaritu HSYNC... Nebo jsem u DVI snížil pixel clock (kvůli EMC filtrům, které při rychlých hodinách mrvily přenos) a pak jsem ubíral pixely v "temném prostoru", abych udržel aspoň trochu slušný frame rate
...ale tohle všecko bylo na relativně košer VGA a DVI vstupech u počítačových monitorů. Hrůza jménem "HDMI vstup na televizi" mě fakt ještě nepotkala Díky za bezvadnou debatu, jsem zase o něco chytřejší.
vzdyt IMHO je levnejsi vyvest ven rovnou digital, nez tam cpat jeste D/A prevodnikPro analogovy vystup potrebujes D/A prevodnik, pro digitalni (v podobe DVI-D) zas potrebujes TMDS encoder. Tipuju, ze to druhe je drazsi/slozitejsi.
Ovšem dneska se to asi dělá u VGA výstupu tak, že nejdřív je DAC, pak ADC a pak ještě DAC na budiče LCD.Však právě z toho důvodu mám připojený monitor pomocí digitálního výstupu i když mi nefunguje dobře. Prostě je mi to blbé (i když ta vizuální ztráta dat převodem je nepozorovatelná). A lidi co kolem mně chodí a nevědí co je to framebuffer si jen klepou na čelo. No uznejte: Jsem snad magor já?
Prostě je mi to blbé (i když ta vizuální ztráta dat převodem je nepozorovatelná).Ovšem stačí trochu rušení a hnedka je jasný, že VGA je slabý
+1
Analogove VGAcko uz melo davno zkoncit na propadlisti dejin. Nejhorsi to je u notebooku, Tam se analog drzi porad, pritom je to uplna debilita, vzdyt IMHO je levnejsi vyvest ven rovnou digital, nez tam cpat jeste D/A prevodnik . Pripada mi to jako spiknuti.NTB se hodně používají v kombinaci s projektory na VGA.
stale pomale , DP i HDMI jsou staveny na daleko vetsi datove toky , zvlaste diky sve specializaci a k tomu pres HDMI de tahnout Ethernet .....
NA druhou stranu je omezena delka kabelaze ...
Imho totiž současný způsob připojení grafika-monitor je velmi neefektivní (ztrácí se informace).Naprosto minimálně. klasické RGB analogové signály jsou z pohledu zpracování lidským visuálním systémem natolik redundantní, že už jsem na vlastní oči viděl ale 10m rušený VGA kabel a přesto plně transparentní (teda aspoň když si člověk zajede do pohovky) obraz. Akorát ten převod DA->AD->DA je tam naprd no.
Grafika přímo v monitoru by mohla zobrazovat data mnohem efektivněji (například celý řádek najednou, bez toho, aby se musel někde buferovat sériová DVI data.Mně osobně se nejvíc líbilo kdyby LCD měly YCbCr matici a žralo to přímo Fourierovi/DCT či jiné frekvenční koeficienty. To je asi zatím (opakuju:zatím – i tak je hodně aproximovaná) z ztrátovosti nejmíň redundantní varianta. Teda krom toho samozřejmě ještě kompatibilní linku s VT100, protože samotný TELETYPE pomocí (VIDEO)BIOSu mě fakt štve.
Jinak já bych to vedl nejradši optickým kabelem (dokonce to snad už to nějaký modely grafik maj)To se zas blbě implementuje. TTL logika je TTL logika.
S omezenou informací jsem myslel například to, že grafika často ví jakej pixel bude příště, kdežto monitor dostává jen aktuální data a pokud chce znát příští pixel, tak musí frame nabufferovat.Ňák nechápu k čemu by to bylo dobré.
Stejně tak, musí mít buffer na jeden řádek, a čekat na naplnění.Znova nechápu v čem je problém.
Jako, že bys měl nějakou optickou matici YCrCb přímo realizovanou tekutejma krystalama?No, tak něco. Korelovat jasovou složku by asi nebyl problém (akorát by pro ni bylo potřeba 2× krystalů než pro zbytek), sytost asi také ne ale z odstínem už to bude horší – to mě nenapadá jak by krystaly zvládly. To by tam muselo být implementované nějaké absolutně černé těleso jehož spektrální tvar by něco emitovalo.
BTW DVI nemá TTL logikuTo je šumák.
Cokoliv se bufferuje znamená automaticky zpoždění.Jo, ale řádky jsou periodické a determinovatelné zpoždění v řádech ms. A když je to víc než jednotky ms, tak má většina lidí kecy (především pak něco co vyžaduje co nejmenší odezvu – typicky hraní her a ovládání desktopu). Jak veliká by musela být GOP aby si něčeho takového dosáhl (zvláště pro ty hráče) nehledě na fakt, že výpočetní komplexnost pro snímek neudržíš (to je závislé na datech) ani když nastavíš CBR. Prostě o takových kravinách se nebavme ani hypoteticky. Uráží mě to.
Znalost dvou pixelů můžeš použít pro rychlejší natočení krystalů v pixelu.V prostoru nebo v čase? Má totiž takový pocit, že mluvíš o Delta modulaci (DPCM,…). V tom případě by to ovšem nebylo nic moc, protože chyba (ať už digitální nebo analogová) by se v čase hromadila až by mohla přerůst práh viditelnosti, takže pro tyto důvod je lepší používat okamžitou hodnotu (a nebo aspoň periodicky na způsob I-Framu).
Znalost dvou pixelů můžeš použít pro rychlejší natočení krystalů v pixelu.Musel jsem si vygooglit název. Jedná se o overshoot a undershoot pro urychlení přechodového děje. S jedním vzorkem moc dobrý regulátor neuděláš, se dvěma to je lepší (imho diference 1. řádu).
Snad jedině, že bys to posílal nekomprimovaný, což by ale bylo možná náročnejší než RGB.Reprezentace dat ve frekvenční doméně je naprosto ekvivalentní reprezentaci dat v doméně časové, jen jsou naprosto stejná data reprezentována jinak (pomineme-li lineární kvantovací hodnoty, ale i s těmi se to dá váhováním vyřešit). Je to prostě jen jiný pohled na ta stejná data. A obrázek o rozlišení X×Y bude zabírat furt stejné množství pásma ať bude v reprezentaci jaké chce. Obě reprezentace jsou prostě naprosto ekvivalentní. Ovšem v případě doménové reprezentace si můžeme dovolit více redundance (a to i klidně v podobě CRCC a ECC) u nižších frekvencí a naopak méně u vyšších a budeme mít jistotu že jakkoliv chyba bude mnohem méně viditelná (a z toho vyplývají třeba delší přenosové délky, rychlosti atd.). Druhou věcí je, že k zpětnému převodu by se dala využít nějaký fyzikální vlastnost (např. v případě optiky a analogové domény je frekvenční reprezentaci dat technice mnohem bližší než číslicová) a tak by jsme si jednak ušetřili jeden inverzní (iDCT z.B.) prvek v cestě a druhak by jsme adaptováním byly schopni dosáhnout vyšších rozlišení. Lidské oko je totiž citlivé na vysoké frekvence v určitých místech a s určitou přesností (tradičně především hrany) a v případě doručení tak obrovského rozlišení čistě v časové reprezentaci by jsme dosáhli obří redundance, která by byla kvůli psychovisuálnímu maskovacímu efektu na nic (nehledě na to, že v současném technickém stavu je max. dosažitelné rozlišení, jež je oko schopné zpracovat buď téměř nemožné a nebo aspoň velmi neekonomické). Naopak v případě rekonstrukce dat ve frekvenční doméně už by to tak nemožné být nemuselo, nehledě na detail že by to mělo mnohem větší smysl než nějaké komerční kraviny typu RGBY.
Ovšem u časové organizace dat je jedno, který vzorek následuje.U frekvenční je třeba u sériového přenosu u každé sadu koeficientů označit první hodnotu.Eh? Co, proč, jak a kde?
V případě rozdělení na YUV bys musel ještě ukládat nějaké informace o uložených datech.Naprosto to samé jak v předchozím případě: Eh?
Taky by mě zajímalo jak by se vyřezávaly data z framebufferu grafiky (okno může být překryto).Jasně. Převod z interní reprezentace počítačové grafiky (RGB) by byl asi to nejsložitější. Přímý průchod by to mohl být tak leda pro Xv (teda pokud by se ze dne na den nepřešlo z RGB na YCbCr). Proto spíš jen takový námět k diskusi.
V příspěvku, na který jsem původně reagoval, byla řeč o Fourierových nebo DCT koeficientech.Jak říkám. Špatně jsme se pochopili. Protože pak GOTO 121.
A to je v podstatě princip ztrátové komprese JPEGu, takže očekávám velmi podobné vlastnosti - nerozeznatelnou degradaci u fotografií nebo videa, ale značné problémy s čárovou grafikou, textem a ostrými přechody obecně.Jasně. Jak jsem řekl, tak pro text bych nejradši zavedl nějaký VT100. Ono je to obecně s těmi druhy obrazových dat a přecházení mezi nimi velmi složité. Jinak v JPEGu se to ořezává z 64 koeficientů per blok na pár, které se dají napočítat na prstech jedné ruky. Když se ovšem nebude nic zahazovat, tak šířka pásma bude naprosto stejná jen s tou výhodou, že šum bude prostě míň vidět (a to se týká obecně jakýchkoliv dat).
Tedy datový tok do grafiky je variabilní, ale datový tok přes DVI/RGB/atd. musí být pořád maximálníJenze ten datovy tok pres DVI je radove mensi nez toky, na ktere je dimenzovane 16x PCIe, kterym je pripojena grafika.
Nejhorší varianta přenosu je tak videoSpousta obrazovek/TV už obsahuje DPS procesory a nějaký ARMový řadič. Zas na druhou stranu, když by se to nacpalo všechno do jedné krabice, dost těžko by se to obměňovalo a obecně je to dost nemodulární varianta.
Jinak samozřejmě jde mechanicky udělat i výměnné GPU v monitoru.Tož to určitě je, ale dovedu si představit jak by to vypadalo kdyby něco takového dostaly do ruk komerční výrobci i kdyby se napsal kopec nějakých standardů. Jinak teď co je obrazový výstup digitální mě vlastně napadlo, že grafická karta je stejně přebytečná. By se mělo pomalu pouvažovat kam s ní.
Tož to určitě je, ale dovedu si představit jak by to vypadalo kdyby něco takového dostaly do ruk komerční výrobci i kdyby se napsal kopec nějakých standardů.Jo to by se muselo sjednotit. To by byl docela problém
Jinak teď co je obrazový výstup digitální mě vlastně napadlo, že grafická karta je stejně přebytečná. By se mělo pomalu pouvažovat kam s ní.No, jako výkonný procesor, který umí lehko věci jako FFT se hodí vždycky
Z trhu ale bude mizet plynule, přeci jen VGA výstup je stále v mnoha a mnoha strojích, zejména v podnikové sféře, takže žádné skokové utnutí se konat nebude. Intel a AMD jakožto významní výrobci grafických karet/čipů plánují jeho vyřazení do roku 2015, zajímavé je, že podobný osud má stihnout v průběhu nejbližších let i digitální DVI (stejně jako kombinovaný výstup DVI-I).Teda to jsou věci. DVI se nestihlo ještě pořádně rozkoukat a už končí. Holt vývoj jde dopředu.
aby to nedopadlo jako usb micro ktere je uplne napytel.Co je na něm špatného?
snad ještě RJ-45, za ty ale stačí víc zatáhnout a vznikne z toho RJ-45 bez packy, což je u mě rozšířenější kontektor než typ s packou.Já tu mám kromě modelů bez zobáčku ještě modely, kde se zobáček ulomil tak napůl, zůstává na konektoru, ale už nepruží. Lze to vyřešit vložením víckrát přeloženého papírku pod páčku a zaizolepováním
s nějakým extrémním rozlišením - nevidím písmenka, nevidím lištu, nevidím hlodavce?Nastav si správně své grafické prostředí.
>>> Nastav si správně své grafické prostředí.
Jenze on si nastavil to spravne co monitor ma nativne.
Jenze on si nastavil to spravne co monitor ma nativne.Nejspíš zapomněl na DPI.
Pro běžného uživatele je kino s úhlopříčkou 60 cm a víc nevyužitelné.To je možné, ale já jsem reagoval na nevidím písmenka, nevidím lištu, nevidím hlodavce, nikoli na využitelnost tak velké plochy.
Nakonec, kdo z vás, vy kritici, někdy nastavoval více jak jeden monitor na počítač? Já mohu napsat, že jo.Monitor k notebooku připojuji běžně.
k čemu na pracovním PC "kino" nad 30x40cm s nějakým extrémním rozlišením - nevidím písmenka, nevidím lištu, nevidím hlodavce?
Já mám zhruba těch 40x30 (20" LCD s 1600x1200) a kdybych si za rozumnou cenu mohl pořídit něco většího (ne, 1920x1200 není rozdíl, který by stál za řeč), jdu do toho.
Na tema mizeni VGA z maticnich desek, GPU adapteru a notebooku cekam podobny zapisek.
Nechcete tu nekdo plakat nad zmizenim 8" floppin...... aneb kazdy si najde duvod o opevovani zastaralych periferii a zarizeni.
Tiskni
Sdílej: