Ho avuto successo con i seguenti pochi esperimenti.
Innanzitutto, scopri se X sta usando TrueColor RGB imbottito a 32 bit (o supponi solo che sia così). Quindi scopri se hai il permesso di scrittura su fb0 (e che esiste). Se questi sono veri (e mi aspetto che molti toolkit/desktop/PC moderni possano usarli come predefiniti), allora dovresti essere in grado di fare quanto segue (e se questi valori predefiniti non reggono, allora probabilmente puoi ancora avere successo con i seguenti test anche se i dettagli possono variare):
Test 1:apri un terminale virtuale (in X) e digita:$ echo "ddd ... ddd">/dev/fb0dove ... è in realtà un paio di schermate piene di d. Il risultato sarà una o più linee (parziali) di grigio nella parte superiore dello schermo, a seconda di quanto è lunga la tua stringa di eco e quale risoluzione in pixel hai abilitato. Puoi anche scegliere qualsiasi lettera (i valori ascii sono tutti inferiori a 0x80, quindi il colore prodotto sarà un grigio scuro .. e variare le lettere se vuoi qualcosa oltre al grigio). Ovviamente, questo può essere generalizzato a un ciclo di shell o puoi cat un file di grandi dimensioni per vedere l'effetto più chiaramente:ad esempio:$ cat /lib/libc.so.6>/dev/fb0per vedere i veri colori di alcuni fsf sostenitori;-P
Non preoccuparti se una grossa parte dello schermo viene sovrascritta. X ha ancora il controllo del puntatore del mouse e ha ancora la sua idea di dove sono mappate le finestre. Tutto quello che devi fare è afferrare qualsiasi finestra e trascinarla un po' per cancellare il rumore.
Test 2:cat /dev/fb0> xxxpoi cambia l'aspetto del tuo desktop (ad esempio, apri nuove finestre e chiudine altre). Infine, fai il contrario:cat xxx> /dev/fb0 per riavere il tuo vecchio desktop!
Ah, beh, non proprio. L'immagine del tuo vecchio desktop è un'illusione e te ne libererai rapidamente quando apri una finestra qualsiasi a schermo intero.
Test 3:Scrivi una piccola app che catturi un dump precedente di /dev/fb0 e modifichi i colori dei pixel, ad esempio, per rimuovere la componente rossa o aumentare il blu, o capovolgere il rosso e il verde, ecc. Quindi riscrivi questi pixel in un nuovo file che puoi guardare in seguito tramite il semplice approccio shell del test 2. Inoltre, tieni presente che probabilmente avrai a che fare con quantità B-G-R-A di 4 byte per pixel. Ciò significa che vuoi ignorare ogni 4 byte e trattare anche il primo di ogni set come componente blu. "ARGB" è big-endian, quindi se visiti questi byte aumentando l'indice di un array C, il blu verrebbe prima, poi il verde, quindi il rosso.. cioè, B-G-R-A (non A-R-G-B).
Test 4:scrivi un'app in qualsiasi lingua che vada in loop alla velocità del video inviando un'immagine non quadrata (pensa xeyes) a una parte dello schermo in modo da creare un'animazione senza bordi di finestre. Per ottenere punti extra, fai muovere l'animazione su tutto lo schermo. Dovrai assicurarti di saltare un ampio spazio dopo aver disegnato una piccola riga di pixel (per compensare la larghezza dello schermo che è probabilmente molto più ampia dell'immagine animata).
Test 5:fai uno scherzo a un amico, ad esempio, estendi il test 4 in modo che l'immagine di una persona animata appaia sul suo desktop (magari filmati per ottenere i dati dei pixel), quindi vai su uno dei loro desktop importanti cartelle, prende la cartella e la fa a pezzi, poi inizia a ridere istericamente, e poi fa uscire una palla di fuoco e inghiotte l'intero desktop. Anche se questa sarà tutta un'illusione, potrebbero impazzire un po'... ma usatelo come esperienza di apprendimento per mostrare Linux e l'open source e mostrare quanto sia molto più spaventoso per un principiante di quanto non sia in realtà. [i "virus" sono generalmente illusioni innocue su Linux]
Sto pensando di scrivere un programma basato su framebuffer, solo perché devo essere in grado di scorrere (cascata SDR). Vedi https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=232493&p=1425567#p1425567 Il test di scorrimento che considero riuscito. In quelle 2 strutture che recuperiamo da ioctl per informazioni ci sono anche cose sulla profondità del colore. Sembra che tu abbia basato il tuo programma sullo stesso esempio che ho fatto io. Come ottenere il colore dei pixel dal framebuffer su Linux (Raspberry Pi)
Il mio funziona bene sul mio Raspberry Pi, con X o meno. Non ha alcun effetto sullo schermo del mio laptop. Ha un /dev/fb0, il programma viene eseguito e i numeri sembrano corretti, ma visivamente non fa nulla. Forse è un doppio buffer o qualcosa del genere.
Sotto X in realtà non fa alcun danno. Se trascini alcune finestre in giro in modo che le cose vengano ridisegnate, tutto torna indietro. Quindi ho deciso di eseguire il backup di ciò che è sullo schermo e rimetterlo quando ho finito, anche questo funziona. Una finestra che ho spostato e rimesso a posto funziona come se non l'avessi mai toccata. X non si rende conto che ho incasinato il buffer dello schermo, sa cosa ha messo lì e registra i clic del mouse di conseguenza. Se spostassi una finestra e non la riposizionassi, i clic continuerebbero a funzionare dov'era.
Direi di fare attenzione prima di provare a scrivere su /dev/fb0, come suggerito sopra. L'ho provato con Xin Ubuntu 10.04 e a) visivamente non è successo nulla, b) ha danneggiato tutte le finestre della shell, anche altre tty, causando errori del kernel e mancanza di funzionalità.
Se stai utilizzando X11, DEVI passare attraverso le API X11 per disegnare sullo schermo. Andare in giro per il server X è molto rotto (e, spesso come hai visto, non funziona). Potrebbe anche causare arresti anomali o solo un danneggiamento generale del display.
Se vuoi essere in grado di funzionare ovunque (sia console che sotto X), guarda SDL o GGI. Se ti interessa solo X11, puoi usare GTK, QT o persino Xlib. Ci sono molte, molte opzioni...