Fedora 16 è stata rilasciata solamente un mese fa, e già si torna a parlare del nuovo rilascio, Fedora 17 Beefy Miracle. Se fino ad ora di questa release si era parlato solamente il relazione al suo bizzarro nome, incominciano a trasparire i primi dettagli tecnici insieme alle future feature.
Secondo quanto possiamo apprendere da More Fedora, a partire da Fedora 17, troveremo il supporto nativo al multitouch. Grazie alla nuova versione di XOrg, che sarà inclusa in Fedora Beefy Miracle, avremo il supporto completo a tutte le gesture multitouch; spetterà poi ai vari sviluppatori dei relativi toolkit come GTK+ e QT, far sì che queste gestures possano essere utilizzate nelle varie applicazioni.
L’ottimo risultato ottenuto è il frutto di una collaborazione tra Peter Hutterer di Red Hat, Chaase Douglas di Canonical e Daniel Stone di Collabora. Ora resta da vedere se i vari sviluppatori delle varie applicazioni renderanno disponibile l’uso delle gestures; nonostante tutto questo è sicuramente un passo avanti per quel che riguarda l’esperienza utente su GNU/Linux.
Via | More Fedora
Wayland è presto diventato «l’oggetto del desiderio» degli utenti di Linux, a volte soltanto per l’insoddisfazione sviluppata nei confronti di X.Org. Nonostante non esistano dei desktop pronti a implementarlo, il lavoro sul display server continua alacremente: i programmatori si sono confrontati rispetto alla dichiarazione del DPI.
A livello predefinito, Wayland imposta il DPI a 96: è la stessa scelta effettuata da X.Org (e persino da Windows). Rispetto ad altri display server, però, Wayland non ammette la modifica manuale del valore preimpostato: non sembra un limite riconducibile all’avanzamento dei lavori. La variazione non è prevista, né lo sarà in futuro.
Questa scelta ha fatto discutere: Windows 8, ad esempio, ha rivalutato l’opzione della modifica manuale al DPI — rimuovendo il limite a quattro dimensioni preimpostate e permettendo qualunque valore. Perché, allora, Wayland dovrebbe fare un passo indietro? La risposta non è così semplice e gli sviluppatori hanno ragioni differenti.
Continua a leggere: Perché Wayland non permetterà la modifica manuale al DPI predefinito

Mint Spirit, è questo il nome del nuovissimo font creato dal team di Linux Mint che è stato recentemente annunciato da team di designer di Linux Mint. Ecco quindi che dopo Ubuntu, un’altra distribuzione GNU/Linux punta a creare una propria identità, facendo uso di un font proprio e non solo dei soliti colori.
Il font, a detto dello sviluppatore principale, è ispirato ai più famosi Futura, Gillius, NeoGothis e Ubuntu Fonts. Attualmente arrivato solamente alla versione alpha, il font punta ad essere un mix tra bello, fresco e moderno; elementi sicuramente di peso quando parliamo di un font.
Sul forum internazionale di Linux Mint è apparsa una versione da scaricare e da provare, che ha quindi consegnato a migliaia di blogger materiale di prova davvero interessante. Nonostante il progetto sia stato pubblicato già da poco si parla già di versione beta, che porterà con sé interessanti novità.
Via | Linux Mint Forum
David Airlie è intenzionato a dimostrare l’utilità di xf86-video-modesetting, il nuovo driver non accelerato per X.Org e il KMS, evidenziandone tutte le caratteristiche. L’ultima “trovata” convincerà anche i più scettici: il progetto è in grado d’avviare i monitor in stand-by, semplicemente collegando la presa a un sistema avviato.
A sostegno dei lavori, Airlie ha registrato un video che mostra come in pochi secondi l’output di X.Org compaia sullo schermo appena collegato. Il “trasporto” d’esempio riguarda xterm: non ancora soddisfatto dei risultati, Airlie vuole estendere le funzionalità ai driver specifici dei processori grafici per ottenere l’accelerazione.
Dal punto di vista tecnico l’esperimento equivale a Xinerama, spostando l’implementazione a un livello più basso dello stack grafico. Airlie ammette che la soluzione definitiva richiederà molto tempo, eppure le immagini parlano da sé. Un altro step prevede la possibilità d’effettuare lo switch su sistemi dotati di due schede video.
Via | David Airlie
Edward Cullen (no, non il Robert Pattinson di Twilight) ha cominciato a modificare la pagina su FreeDesktop riservata a X12, l’ipotetico successore del protocollo X11 utilizzato da X.Org. Sono stati aggiunti dei requisiti di massima per la realizzazione dell’aggiornamento: «X11 era stato concepito per un’altra era dell’informatica».
Evitando d’entrare nelle discussioni sull’opportunità di un abbandono definitivo di X11, Cullen recupera quanto dev’essere mantenuto. La chiave è nella Network Transparency, una funzionalità citata pure da Martin Gräßlin per Wayland che ha portato Miguel De Icaza a esaltare le novità di Windows 8 con Metro. Tutti d’accordo, quindi.
X12 dovrà incontrare le esigenze di un mercato più flessibile, nel quale il settore mobile ha un’importanza crescente: deve funzionare egregiamente su smartphone, tablet e netbook. Il framebuffer non dovrebbe essere accantonato, perché conserva tuttora un ruolo strategico in alcune situazioni. I lavori a X12 non inizieranno presto.
Via | Phoronix
X.Org offrirà presto la possibilità di “ripiegare” su un driver generico, non accelerato e alternativo a VESA, per le schede grafiche compatibili col KMS di Linux. David Airlie, infatti, ha ripreso i lavori a xf86-video-modesetting rimuovendo il codice riservato a DRI2 ed EXA e mantenendo il supporto a RandR 1.2, più i cursori ARGB.
Il nuovo driver si basa sui sorgenti di quello per le Radeon via Gallium 3D e fbdev, il framebuffer generico di X.Org. L’intenzione di Airlie è fornire una modalità fallback, qualora i driver specifici del produttore non funzionino: xf86-video-modesetting non è equiparabile al driver generico di Gallium 3D e non lo deve sostituire.
Il significato del «restart» di xf86-video-modesetting è proprio nel prendere le distanze dall’infrastruttura di Gallium 3D, accelerata e dotata dell’opzione swrast in caso di errori. Il branch precedente del driver ripreso da Airlie andava in quella stessa direzione: sarebbe stato soltanto clone a basse prestazioni per gli utenti.
Via | Phoronix
Martin Gräßlin, responsabile dello sviluppo di KWin per KDE, è intervenuto sulla questione della network transparency con Wayland. Attualmente questa funzione, ovvero la trasmissione in chiaro delle attività del server grafico sulla rete, non è possibile: Gräßlin è convinto che sia soltanto un aspetto positivo almeno per il momento.
Implementare la network transparency su Wayland, infatti, può avvenire con modalità diverse da quelle già previste con X11: ad esempio, utilizzando D-Bus (richiesto da tutte le applicazioni più recenti) si corrompe il forwarding di X.Org. Perciò la soluzione è quella di trovare nuove tecnologie. Qt 5 potrebbe risolvere il problema.
Ancora, nulla vieta per Gräßlin d’utilizzare il supporto legacy a X11 per la network transparency delle applicazioni via Wayland. Se ne parla da vent’anni, tuttavia ne serviranno altrettanti perché le distribuzioni rimuovano del tutto il protocollo di X11: pure OS X lo prevede ancora. Il problema, insomma, è facilmente risolvibile.
Via | Martin Gräßlin
Chromium arriverà su Wayland grazie all’impegno di Daniel Nicoara: non è ancora disponibile una versione funzionante del browser col nuovo server grafico tuttavia il progetto ha già qualche settimana e gli sviluppi sono di sicuro interesse. Specie se Google dovesse portare Wayland su Chromium OS per funzionare nei propri Chromebook.
Nicoara si è basato, per la prima patch, sul codice di EGL orientato a Wayland che è presente nel ramo di sviluppo per Mesa 3D. Il porting non ha nulla d’ufficiale, però i Chromebook “girano” coi driver grafici di Intel via Gallium 3D. Queste caratteristiche sono particolarmente favorevoli, per l’utilizzo di Wayland Display Server.
Più in generale, si potrebbe azzardare che il 2012 sarà l’anno di Wayland: KDE ha già annunciato i propri piani per l’adozione del server e le prime discussioni sul futuro di GNOME alludono ad altrettanto. Chromium su Wayland Display Server pareggerebbe i conti del backend per le Gtk+ con quello previsto da KDE per le Qt su WebKit.
Via | Phoronix
È stato rilasciato Openbox 3.5.0, il window manager derivato da Blackbox e utilizzato per la gestione delle finestre del desktop environment di LXDE. Openbox può essere implementato come alternativa a KWin per KDE e/o a Metacity (non ancora a Mutter, apparentemente) per GNOME. LXDE, in sé, sfrutta proprio questa seconda possibilità.
Openbox è apprezzato per la propria semplicità e “leggerezza”, caratteristiche alla base della scelta degli sviluppatori di LXDE. La versione 3.5.0 non aggiunge molte novità: quelle rilevanti sono essenzialmente due. La prima, più importante, riguarda la possibilità d’inserire le icone nei menù. La seconda è il supporto a Xinerama.
Una nuova modalità di visualizzazione delle finestre, in verticale, è stata introdotta con la scorciatoia [Alt]+[Tab]. Le altre modifiche riguardano l’aumento delle opzioni previste per la realizzazione dei temi, oltre alla consueta lista di bug fix e miglioramenti generali delle prestazioni. È un aggiornamento importante per LXDE.
Via | Phoronix
La Kernel Graphics Interface (KGI) è un progetto legato a FreeBSD per l’integrazione di un migliore supporto grafico al terminale dal kernel. Sì, è esattamente ciò che su Linux ha realizzato il Kernel Mode-Settings (KMS): la KGI era stata concepita già nel 2003, tuttavia non ha mai raggiunto gli obiettivi prefissati. Neppure su BSD.
Il passaggio su Linux, prima dell’avvento del KMS, era molto atteso. A breve potrebbe realizzarsi il contrario, cioè l’arrivo del KMS su BSD: la KGI non riceve aggiornamenti da un paio d’anni. Michael Larabel lo definisce come un progetto «effettivamente morto». La KGI costituirebbe una parte della General Graphics Interface (GGI).
Non tutto è perduto, perché a sostituire degnamente gli ambiziosi progetti di FreeBSD arriveranno (importati da Linux) DRI, GEM e KMS. Eppure il sostanziale abbandono di KGI/GGI è un peccato: quest’ultima aveva ottenuto dei discreti progressi anche su Linux e Windows. E l’aggiornamento dei driver grafici riguarda soprattutto Intel.
Via | Phoronix