次のいくつかの実験で成功しました。
まず、X が 32 ビットにパディングされた TrueColor RGB を使用しているかどうかを調べます (または、これが事実であると仮定します)。次に、fb0 への書き込み権限があるかどうか (およびそれが存在するかどうか) を調べます。これらが当てはまる場合 (そして、多くの最新のツールキット/デスクトップ/PC がこれらをデフォルトとして使用する可能性があると思います)、次のことを実行できるはずです (これらのデフォルトが保持されない場合でも、おそらくいくつかの成功を収めることができます詳細は異なる場合がありますが、次のテスト):
テスト 1:仮想端末を (X で) 開き、次のように入力します。結果は、エコー文字列の長さと有効にしたピクセル解像度に応じて、画面の上部に 1 つまたは複数の (部分的な) 灰色の線が表示されます。任意の文字を選択することもできます (ASCII 値はすべて 0x80 未満なので、生成される色は濃い灰色になります。灰色以外の文字が必要な場合は、文字を変更します)。明らかに、これはシェル ループに一般化できます。また、効果をより明確に確認するために大きなファイルを cat することもできます。サポーター;-P
画面の大部分が上書きされても心配しないでください。 X は引き続きマウス ポインターを制御でき、ウィンドウがどこにマップされているかを把握できます。必要なのは、任意のウィンドウをつかみ、少しドラッグしてノイズを消去することだけです。
テスト 2:cat /dev/fb0> xxx 次に、デスクトップの外観を変更します (たとえば、新しいウィンドウを開き、他のウィンドウを閉じます)。 /P>
は、まあ、そうではありません。古いデスクトップのイメージは幻想であり、ウィンドウを開いて全画面表示にすると、すぐに忘れてしまいます。
テスト 3:/dev/fb0 の以前のダンプを取得し、ピクセルの色を変更する小さなアプリを作成します。たとえば、赤のコンポーネントを削除したり、青を増強したり、赤と緑を反転したりします。次に、これらを書き戻します。ピクセルを新しいファイルに変換し、後でテスト 2 の単純なシェル アプローチを使用して調べることができます。これは、4 番目のバイトごとに無視し、各セットの最初のバイトを青のコンポーネントとして扱うことを意味します。 「ARGB」はビッグエンディアンであるため、C 配列のインデックスを増やしてこれらのバイトにアクセスすると、青が最初に来て、次に緑、次に赤になります。つまり、B-G-R-A (A-R-G-B ではありません)。
テスト 4:ビデオ速度でループし、非正方形の画像 (xeyes を考える) を画面の一部に送信して、ウィンドウの境界線のないアニメーションを作成するアプリを任意の言語で作成します。余分なポイントについては、アニメーションを画面全体に移動させます。小さな行に相当するピクセルを描画した後は、必ず大きなスペースをスキップする必要があります (アニメーション化されている画像よりもはるかに広い画面幅を補うため)。
テスト 5:友達にいたずらをします。たとえば、テスト 4 を拡張して、アニメの人物の写真がデスクトップに表示されるようにします (ピクセル データを取得するために自分自身を撮影することもできます)。その後、重要なデスクトップの 1 つに移動しますフォルダーを拾い上げて細断し、ヒステリックに笑い始め、火の玉が出てデスクトップ全体を飲み込みます。これはすべて幻想ですが、彼らは少しびっくりするかもしれません..しかし、それを学習体験として使用して、Linuxとオープンソースを誇示し、初心者にとって実際よりもはるかに恐ろしいものであることを示します. [「ウイルス」は一般的に Linux では無害な幻想です]
スクロールできるようにする必要があるという理由だけで、フレームバッファーベースのプログラムを作成することを考えています (SDR ウォーターフォール)。 https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=232493&p=1425567#p1425567 を参照してください。成功したと思われるスクロール テスト。 ioctl で情報を取得する 2 つの構造体には、色深度に関する情報もあります。あなたのプログラムは、私が行ったのと同じ例に基づいているようです。 Linux (Raspberry Pi) でフレームバッファからピクセルの色を取得する方法
私のものは、X を使用するかどうかに関係なく、私の Raspberry Pi で正常に動作します。ラップトップの画面には影響しません。これには /dev/fb0 があり、プログラムが実行され、数値は正しく見えますが、視覚的には何もしません。多分それはダブルバッファか何かです.
X の下では、実際には何のダメージも与えません。いくつかのウィンドウをドラッグして再描画すると、すべてが元に戻ります。次に、画面に表示されているものをバックアップし、完了したら元に戻すことにしました。これも機能します。移動して元に戻したウィンドウは、まったく触れていない場合と同じように機能します。 X は、私がスクリーン バッファをいじったことを認識していません。X はそこに何を置いたかを認識し、それに応じてマウス クリックを登録します。ウィンドウを移動して元に戻さなかった場合、クリックは元の場所で機能します。
上記のように、/dev/fb0 への書き込みを試みる前に注意が必要です。 Xin ubuntu 10.04 で試してみたところ、a) 何も表示されず、b) すべてのシェル ウィンドウが破壊され、他の tty も破壊され、カーネル エラーと機能の欠如が発生しました。
X11 を実行している場合は、X11 API を使用して画面に描画する必要があります。 X サーバーの周りを移動するのは非常に困難です (そして、多くの場合、ご覧のとおり、機能しません)。また、クラッシュや一般的な表示の破損を引き起こす可能性もあります。
どこでも (コンソールと X の下の両方で) 実行できるようにしたい場合は、SDL または GGI を調べてください。 X11 だけに関心がある場合は、GTK、QT、または Xlib を使用できます。非常に多くのオプションがあります...