戻る


2013/10/27 06:20

awesomeのluaスクリプトをいじくっていた。

今までもちょこちょこと、デフォルトのものに修正を加えていたが、マルチディスプレイ周りがびみょうだったこともあり、全体を見直して、大幅に書き換えることにした。

それで、大体満足な感じになったのだが、どうもawesome自体にバグっぽい仕様があるような雰囲気がする。

ディスプレイに1つもウィンドウが表示されていない場合に、別のディスプレイのフォーカスを移すことができないのだ。

ターミナルを1つでも起動するなりして、ウィンドウを作れば問題ないので、致命的とは言えないが。

しかし、ディスプレイに1つもウィンドウが存在しない状態というのは、つまり別のディスプレイに切り替えるということも十分考えられる操作なわけで。不便だ。

バージョンを上げれば改善されるかもしれないと思ったのだが、なんか知らんがビルドがこける。/dev/dri/card0に対して権限がないらしいのだが。chmodで無理矢理権限を付加してもだめだし、そういうことではないのかもしれない。

でもまぁ、タイル、フローティング、フルスクリーンの3つの状態を効果的に使えるようにできたので、大体満足。

生成されるウィンドウがデフォルトでフローティングとかいう、タイル型ウィンドウマネージャにあるまじき挙動になってるが。

でもまぁ、一発でディスプレイ内に表示中のウィンドウをタイルに変更したり、フローティングに変更したりできるようにしているので、問題はない。

正直、タイル状態をうまく活用できるプログラムは大して多くないのだ。ブラウザにしたって、音楽プレイヤーや動画プレイヤーにしたって、フローティングの方が扱いやすい。

ターミナルをタイル状態で並べるのはかなり便利なんだけど。開発が非常にやりやすい。


2013/10/26 15:50

ディスプレイ制御、インターフェースを変えた方がよさそう。

ディスプレイの解像度や回転方向を変更することはできるのだけど、どうもおかしいので調査していた。

おかしいのは、回転方向を変えた後、例えば1600x1200を90度回転させて1200x1600にした場合、向きは変わっているのだけど、表示自体は1600x1200のままになってしまっている、という点。

90度回転しているにも関わらず、表示内容は1600x1200のままなので、実質的には1200x1200のようになってしまっている、とでも言うべきか。

前から気になっていたので調査していたのだが、原因は大体分かったものの、きちんと解決するためにはインターフェースの変更も視野に入れた方がいいことが分かった。

原因としては、各ディスプレイの解像度とは別に、スクリーンサイズというものがあり、そのスクリーンサイズを変更していなかったのがいけなかったようだ。

複数のディスプレイを組み合わせて1つの大きな画面を構成する場合、最終的にできあがる画面のサイズを決める必要がある。例えば、1600x1200のディスプレイ2つを横に並べる場合には、3200x1200、というように。それがスクリーンサイズだ。

スクリーンサイズを決定してから、各ディスプレイに対し、その中のどの部分の表示を担当するか決定する、という流れになるわけだ。1600x1200のディスプレイ2つで考えると、一方を1600x1200+0+0、もう一方を1600x1200+1600+0、という感じ。

しかしながら、私が作った処理では、スクリーンサイズの変更をしていなかったため、うまくいっていなかった、ということらしい。

スクリーンサイズ3200x1200の中に1600x1200+0+0と1600x1200+1600+0の2つのディスプレイを設定していたものを、1600x1200+0+0と1200x1600+1600+0にしようとするならば、まずスクリーンサイズを2800x1600にしなければならない、ということだ。

スクリーンサイズを変更しなかった場合、ディスプレイの解像度を1200x1600にしたところで、スクリーンサイズの高さは1200までしかないわけで、下方1200x400は使うことができない、とかそういうことだ。

しかし、現状のインターフェースでは、1つのディスプレイの解像度を変更することしか考慮していないため、スクリーンサイズ、つまり表示全体のサイズを算出したりすることが困難だ。

そもそも、スクリーンサイズという概念が存在することを考えると、1つのディスプレイに対して処理を行うべきではなく、マシンで扱えるディスプレイ全てというか、表示に関わるディスプレイ全てに対し、同時に処理を行うべきなのだ。

ということになってくると、やはりインターフェースからして考え直さざるを得ない。正直、現状のインターフェースはしっくり来てなかったから、後で変更しようとは思っていたからいいけど。


2013/10/25 05:40

らでおんのオープンソースドライバを導入した。

前試した時はうまく動かなかったのだが、今回はきちんと動いてくれている。

サブディスプレイの90度回転しても問題ないし、windowsが必要ない場合はこれでいってみよう。

現時点ではOpenGLが2.1までしか使えないのは気になるところだが、きっと開発が進めば対応バージョンも上がるだろう、多分。ハードウェア的には、OpenGL4.3まで対応可能なはずなのだ。

なにより、他のオープンソースドライバと共存可能なのがいい。fglrxを使うと、drmからして有効にできないからなぁ。

他のオープンソースドライバと共存可能ということはつまり、windows上のvmwareで、ディスクを物理マウントして起動すれば、そのままvmwareのGPUアクセラレーションが有効になり、GUIも使えるということだ。これは強い。

TuxOnIceを使ってハイバネーションに対応しようとして諦めた。どうにもうまく動かない。

搭載メモリ=16GB分のスワップパーティションとか作るのめんどうなので、ファイルでやろうとしたがうまくいかなかった。

そもそも情報が少なすぎるのだ。検索して出てくる情報は、なんだか古いものばかりな気がする。設定ファイルのパスとかどれもまちまちだし。

スワップパーティションを作ることができれば、TuxOnIceなぞ使わずに、最初からカーネルに存在する機能でハイバネーションできるはずなのだが。

スタンバイは問題なく動くようなので、とりあえずはスタンバイでもいいかという気持ち。電力供給を止められないのは気になるけども。

とはいえ、普通に起動してもかなり速いんだけどね。どちらかというと、作業状態の保持をやりたいのだ。

あと、今までは離席する時にディスプレイの電源を切るだけで、電源を入れれば誰でも使える状態になっていたのだけど、そこも改善した。

gnome-screensaverを使い、画面のロックをできるようにした。

これで、離席する前にロックすれば、ロック解除しなければ使える状態にならないようになった。安心安心。

そんな感じで環境をいじくっていたので、全く進んでいない。

起きたら本気出す。


2013/10/24 06:05

truncate対応した。

これでファイル入出力もできるようになったし、次の段階に進むべきか。

足りない機能はまだまだあるが、それは必要になった段階で付け足していくことにする。


2013/10/23 17:00

読み書き追記、大体対応できた。

readにwrite、seek、tellに対応したので、読み書き、ファイルポインタの移動、現在位置取得ができるようになったわけだ。

しかし、あと1つだけ対応できてない機能がある。truncateだ。

truncateの機能は切り捨て、切り詰めだ。ファイルを指定した長さに切り詰め、以降のデータを存在しないものにする。

この機能を使えない場合に同じことをするなら、1度ファイルの内容を全て読み込み、fopenのモード指定でwやw+を指定することでファイル内容をクリアし、切り詰めない部分を書き込む、などという感じのことをしなければならない。なんともめんどくさい。

しかし、実際に用意されている機能は、切り詰めた後の長さを指定するだけのもので、微妙に信頼性に欠けている。

どういうことかと言えば、現在のファイルよりも長い長さを指定することも可能なのだ。その場合、増えた部分には\0の文字で埋められるか、エラーが発生するかする。

エラーが発生するかどうかは、ファイルシステムに依存するらしい。XSIとかいう仕様に従っているらしい、linuxのネイティブなファイルシステムでは確実に伸長されるようだが、例えばvfatのような、非ネイティブなファイルシステムではエラーになり、伸長されないらしい。

通常linuxでvfatを使うことなどあまりない、と言いたいところだが、例えばUSBメモリなどのリムーバブルメディアのファイルシステムは大体vfatのはずだ。なんにせよ、ファイルシステムによって失敗する可能性のある処理というのは面倒なものだ。

そもそも、truncateは切り詰めるための機能であり、伸長するための機能ではないのだ。失敗する可能性があるところからして、おまけと考えるべきだろう。伸長したいなら書き込めばいいのだ。

というわけで、伸長を許可しないインターフェースを用意したいところなのだが、どうしたものか。

例えば、削りたい長さを指定して、その長さ分末尾から切り詰める、というものを思い付いたが、正直使いやすそうとは思えない。

その長さを算出するためには、切り詰めた後の長さと切り詰める前の長さを把握してなければならないからだ。

win32APIにはSetEndOfFile()というものがあるが、これはファイルポインタの現在位置まで切り詰める、というものだ。

しかし説明を見れば分かる通り、ファイルポインタをファイルの終端より後の地点に移動させておけば伸長も可能な作りになっている。別にファイルポインタは、始端と終端の範囲内しか指せないという決まりはないため、そこでは縛りを作れない。

あるいは、truncateのインターフェースはそのままで、伸長は推奨しない、という形にするのもありか。とりあえずそれでいこう。


2013/10/21 04:50

おかしい。完成してない。おかしい。

18日の日記、直前の日記には、今日中にはlinux側の実装を片付けてしまいたいところなんて書いてあるのだが、未だ出来ていない。おかしい。

その理由の1つとして、若干やる気が削がれているというのがある。なんでだろう。

なんでだか分からないがやる気というのは出るものではなく出すものというのが私の意見であるので、今現在出ていない理由なんていうのは割とどうでもいいのだが。

2つ目の理由として、予想していたよりもややこしいことになっている、というのがある。

ファイル入出力は、前の日記に書いた通り、読み込み用に開いたなら書き込み関数の呼び出しがコンパイルエラーになる、書き込み用に開いたなら読み込み関数の呼び出しがコンパイルエラーになる、という仕様にしようと考えている。

しかしながら現実的には、用意されているAPIにそのような制約が存在しないパターンがほとんどだ。

開くとファイルポインタが得られ、それを使って読み込み関数を呼び出せば読み込み処理が行なわれ、書き込み関数を呼び出せば書き込み処理が行なわれる。オープン時の読み込み、書き込み指定と処理が合致していなかったりした場合、エラーとなり処理は失敗する。大体そんなもんだ。

そのようなAPIを使って今回の要件を満たすならば、内部的にはどのような開き方をしても読み込み、書き込みの両方を行なえるようにしておき、型によって可能な処理を縛る、というような感じになる。

今まで作ってきた機能よりも、環境が異なっても変える必要がない、処理を共通化できる箇所が増えたため、それを考慮した構成になるよう、コードを組むのに苦心している、といったところか。

あまりに考えすぎると、やる気がどんどん削がれていくのだ。考えすぎると手が出なくなってしまうわけだ。

まー、起きたらやっつけるとしよう。寝る前に、どこから攻めるかまとめておくとしよう。


2013/10/18 14:40

ファイル入出力機能を追加している。

大きなファイルの扱いについての対応がOSごとに違ったと思うので、その辺を共通のインターフェースで扱えないときつい。

linuxはfopen()と似たような感じでfopen64()とかの関数が用意されているが、windowsは全く別の名前の関数がwin32APIに用意されていた気がする。

fopen()などが、読み込み専用で開いたファイルに対して、失敗するとはいえfwrite()などの書き込み用関数を使える仕様なのが、私としては気に食わない。

なので、読み込み専用で開いたのなら書き込み用関数を呼び出せず、書き込み専用で開いたのなら読み込み用関数を呼び出せない、呼び出そうとしてもコンパイルエラーになるような構成にしようと思っている。

無論、読み書き可能で開いた場合には読み書きどちらの関数も呼び出せるようにする。

大体の構成はすでにイメージできているので、今日中にはlinux側の実装を片付けてしまいたいところ。

作業用の環境はlinuxなんだけど、今はvmware上で動いているため、まともにOpenGLとか使うならwindowsなんだよなぁ。

しかしwindows側は仮実装状態だらけで、すべて実装するのはなかなか手間だ。

私としては早いところ上位ライブラリの作成に移りたいのだけど、肝心のその構成はまだ定まっていない。

上位ライブラリは実際に動くプログラムが必要とする機能を追加していく形になるのだから、ライブラリより先にプログラムの方を進めるべきなんだろうか。

とりあえずファイル入出力をやっつけよう。話はそれからだ。


2013/10/17 05:40

グラボのlinux用プロプライエタリドライバは基本的にゴミクズ

作者に悪いだなんて思わないむしろ迷惑被った私に謝れ。

高速な3D描画が行えたとしても、まず安定しなきゃ意味がないのだ。

linux用のプロプライエタリドライバがまともなことなんてほとんどなかった。

初めて自作したマシンにインストールした時、64bitOSなのにnvidiaのドライバときたらメインメモリが4GBより多く積まれていると起動に失敗した。

startxする段階だったかOSの起動の段階だったかは忘れたが、確実にフリーズするのだ。64bit用のドライバなのに64bitに対応していないらしかった。

そのせいで、マシンをまともに使うというためだけにatiのグラボを購入したことがある。

またある時nvidiaのグラボを使っていたら、マルチディスプレイでの利用時に奇妙なことに気がついた。

OpenGLでの3D描画を行うプログラムを作った時、サブディスプレイでそのプログラムを表示すると、CPUの1コアの使用率が100%になってしまうのだ。

垂直同期を有効にしているにも関わらず、メインディスプレイでは垂直同期が効くのにサブディスプレイでは垂直同期が効いていなかったのだ。

atiのドライバもだめだめだ。

最近というか今さっきまで起こっていたことだが、安定板のドライバを使っていると、ウェブブラウザのGPUアクセラレーションが使われるタイミングで、非常に高い確率でフリーズする。

そうでなくとも、dmesgを見るとドライバモジュールが頻繁にBUGという文字列を出力している。

ベータ版のドライバを使ってみたところウェブブラウザ程度で高確率でフリーズすることはなくなったが、flashやjavascriptでの描画が真っ黒になったりちらついたりということが頻繁に発生する。

フリーズも高確率ではなくなっただけで発生する。

これは確証はないのだが、ターミナルソフトのサーバプログラムにも影響を及ぼし、サーバプログラムが勝手に死んでしまうということも起きた。どうもフォントの描画処理らへんのライブラリとの相性がよくないように思える。

ターミナルのサーバプログラムが死ぬと、開いているターミナルは全ておじゃんになる。非常に迷惑だ。

で、結局、私はnvidiaやatiのドライバを使うのをやめた。今は仮想マシンをwindows上のvmwareで動かしている。

OpenGLは2.1ぐらいまでしか使えないようだが、特に不便はない。ターミナルの透過処理も全く問題なくできているし、動画再生を行なっても全く支障がない。

マルチスクリーンを全て使って、vmware上でない、直接起動した時と全く同じ表示にできるし。安定した環境というのはいいものだ。

やる気がなくソースが公開されてないので誰も修正できないソースから作られたものなど、所詮どうしようもないものでしかないということらしい。

vmwareのオープンソースドライバも全部が全部公開されてるのかしらんけども。

atiのグラボ用のオープンソースドライバとかもあったが、びみょうに残念だったな。画面の回転ができなかったのだ。

将来的には可能になるようなのだが、私はサブディスプレイを縦向きにしているため、回転できないと困る。いずれじゃ困るんだ。いるのは今だ。


2013/10/15 15:10

gentooの32bit chroot環境の構築も完了した。

前の環境にはclangとか入れてたっけ。今は入れてないが、使う機会がまだないからいいだろう。

pulseaudioのpa_threaded_mainloopをpa_mainloopに置換できるかどうか試したが無理だった。

複数のpa_mainloopは生成できないらしい。しようとするとエラーが出て落ちる。

グローバル変数を使ったクソ実装の香りがする。

結局、動いているから今は触らない方がいい気がしてきた。

改良するなら、もはやpulseaudio以外を使うくらいしかない。

しかし、pulseaudioの作りが奇妙すぎていらいらする。

たかが音声を再生するために、

こんな感じ?pa_threaded_mainloopとかpa_mainloop_apiとかpa_contextとかってなんやねん。それって本当に必要か?

出力先デバイスの指定はpa_stream生成時に行なうのに、ロックの単位はpa_threaded_mainloopだし。まさかとは思うがデッドロックを回避するためとかほざくんだろうか。

まぁいいや。これ以上考えても頭が痛くなるだけだ。

音声出力オブジェクトをポーズ状態で生成する関数を追加したら、そろそろ次のステップに移ってもいい気がする。

しかし、イベントハンドラの差し替え機能とかいらないんじゃないかなぁなどと、今更になって考えている。

そんな機能が必要なら、ライブラリ利用側で勝手に用意すればいいのだ。

イベントハンドラの差し替えなんかしない場合、イベントハンドラ呼び出し時に毎回std::unique_lockかけるのなんて無駄だしなぁ。

差し替えないなら、イベントハンドラ取得関数なんてのも無駄になるし。省いてしまおう。


2013/10/10 22:00

gentooの起動が問題なくなった。

うまくいかなかったのは、GPTなハードディスクについてのマウントポイント指定をUUID=で/etc/fstabに記述していたのがいけなかったのかな、という気がする。

blkidで出力した結果にはPARTUUID=と書いてあったのに、見慣れないからというだけで、多分大丈夫だろうと思いUUID=にしてしまったのだ。PARTUUID=にしたら問題なくなった。

気がついたら問題なく起動できるようになっていたため、それを直したら直ったのか、直した後もだめだったのかなんなのかはわからない。

少なくともカーネルモジュールの組み込みについては、修正する必要がなかった。

あと、UEFIモードで起動した場合に何も表示されない問題も解決した。

正確にはコンソールが出ないだけであり、Xは問題なく動作していたが。

UEFIモードは最初からフレームバッファが動作しているらしく、それに関係するモジュールを組み込んでおき、フレームバッファコンソールに対応していないといけなかった、ということらしい。

試行錯誤を繰り替えした結果、以下のモジュールをカーネルに組み込んでおけば問題ないことが分かった。

どちらかもしくは両方がなかったり、モジュールになっていたりすると、コンソールが出なくなる。initramfsで読み込んでもいいのかもしれないが未検証。

あとは、efibootmgrに地味に苦しめられた。

マザボ、というよりはUEFIに依存すると思うが、初期状態ではエントリの一覧表示ができなくて困った。

先頭のエントリしか表示されず、表示されないエントリについてブートオーダーを変更しようとしたり、エントリの削除などを行おうとしても失敗してしまう。

解決策は、一度エントリを追加し、追加したエントリを削除する。これで問題なくなった。

いや、最初からまともに動いてください。困るので。

efibootmgrでブートオーダーをいじくっていたからなのかはわからないが、UEFIからして起動しなくなってしまったりもした。原因は特定できていないが、CMOSクリアをかければ問題なく起動するようになる。厄介な。

ちなみにマザボはASRock 990FX Extreme4。

これでOSのインストールやら起動やらは問題なくなった気がする。しかしながら、gentooへのソフトのインストールが不完全だ。32bitプログラムの動作環境も整えていない。

multilibでなければならない64bitプログラムがなくなったので、nomultilibにしてしまったのだ。emulライブラリとか気に食わんのでいいんだけど、chroot環境の構築めんどいなぁ。


2013/10/10 03:50

環境構築し直していた。

UEFIモードでOSをインストールし直した。

windows8はインストールが完了しているが、gentooの方は不完全。

windows8上で動作するVMwarePlayerでなら起動するが、単体では起動できていないっぽい。

ぽい、というのは、画面に何も出力されないからわからないのだ。

カーネルの設定がおかしいのか、なにかツールが足りないのか、起動後ずっと何も表示されない。

windows8上で動作するVMwarePlayerでも同じく何も表示されないのだが、GUIを使うつもりがないので一応問題ない。

sshで接続して作業したり、sambaの共有フォルダにアクセスする程度なので支障が出ないのだ。

しかし、起動にこけたりしたら原因を特定できないので、早くどうにかしないと。

表示が問題ないインストールディスクで使ってるものと、ほぼ同じ設定ファイルを使ってビルドしたカーネルでもだめだった。

ほぼ同じ、というだけで、initramfsが不要な形に修正しているのが原因かもしれない。

あるいは、initramfs内のスクリプトに答えがあるのかもしれない。

とにかくめんどうだ。UEFIモードにしたおかげで起動直後のポスト画面の表示時間が短縮され、起動が速くなったのはいいのだけど。

あと、UEFIモードにしたおかげで、gentooの起動にGRUBなどのブートローダがいらなくなった。UEFIスタブとかいうやつで、カーネル単体で起動できる。

これ以上時間食いたくないなぁ。作業に戻りたい。

だがしかしgentooの単体起動が。ぐぬぬ。

起動開始直後に、ハードディスクのアクセスランプが少し点滅した後すぐ反応なくなるところから考えると、/のマウントに失敗しているのだろう。

/のマウントに必要な機能をカーネルに含めれば、最終的にディスプレイマネージャが立ち上がってログインできるようになると思うのだけど。

インストールディスクで起動してlspciすれば解決する予感がするがめんどくさいのだ。

グラボを新しくするべきか考え中。

具体的には、グラボをultra fast boot対応のものにしようかなぁと考えている。

ultra fast bootにしたマシンを起動する動画を見たが、休止状態やスリープなどからでない通常の起動で、電源投入から5、6秒で操作可能な状態になるので、かなり速い。

しかし、現状でもwindows8のシステムドライブをSSDに変更したこともあり、起動速度は十分な気がする。

起動速度とわずかなパフォーマンス向上のために、1万払うのはなんだかなぁ、という気持ち。

gentooのUEFIモードでのインストールには、SystemRescueCdを使った。

公式のインストールディスクがUEFIモードでの起動に対応していないので仕方がない。

ていうか、SystemRescueCd自体がgentoo。公式のインストールディスクに毛が生えたようなもの。

startxって打てばX起動するし、GParted使ってGUIでパーティションいじくれるし。

UEFIモードでの起動に加えてgdiskやefibootmgrも入っているので、UEFIモードでのインストールも問題ない。

USBメモリも作成できるので、作っておくと便利。


2013/10/07 14:20

ようやく環境が整ってきた感。

ホストOSをwindowsにできるようにしていた。簡単に言えばgentooとwindows8のデュアルブート環境にした。

しかし、ただデュアルブートにするだけではOS間のデータ共有が面倒だったりと、不便なことになってしまうので、少し工夫した。

ホストOSがwindowsの場合、vmwareplayerを使ってgentooを仮想マシンとして起動できるようにした。

起動するgentooはデュアルブートで起動できるものと全く同じ。仮想マシンのディスクに物理ディスクを割り当て、起動できるようにした。

sambaやsshが入っているので、samba経由でデータを共有したり、sshでログインして作業したりもできる。

windows側にはcygwinを入れてあるので、cygwinにXサーバを追加すればGUIプログラムも起動できたりするんだろうか。

まぁさすがに、linux用のdpをいじったりする場合には、gentooを直接起動しようと思うけど。

そんなわけで、windows用のdp開発環境が整ったわけだ。

ここ数日環境構築に費やしてしまったので、早く開発に戻りたいところ。


2013/10/02 22:30

マウスも対応した。

vmwareにつっこんだgentooは、割といい感じに動いている。

open-vm-tools-kmodのインストールは、カーネルを3.9系のものにすることで対応した。

「複数のモニタを循環する」とかいう、何言ってんのか分からない機能を使うことで、複数のモニタにフルスクリーン表示することができていい感じ。

OpenGLも使えたが、想定通りというか、おまけっぽい印象を受けた。とりあえず、深度バッファが機能していないっぽかった。あるいは、プログラムの方がいけないのかもしれない。深度バッファのサイズ指定してなかったかも。

そうでなくても、OpenGL2.1ぐらいまでしか対応しないようなので、期待はできない。

とりあえずブラウザや動画プレイヤーをインストールしてみて、どんな感じで動作するのか確認する。

vmware上でgentooを動かしているマシンはCPUがintel-vtに対応してないcore2quadなので、amd-vに対応したメインマシンではどうなることやら。性能上がるといいんだけど。

ああ、あとグラボもよくなる。メーカーからして違うが、げふぉのローエンドかららでおんのミドルエンドになる。

intel-vtに対応していないせいで、32bit版のgentooを入れるはめになったが、メインマシンには64bit版を入れる予定。

32bitのマシンでdpをビルドして分かったことは、OpenGLの定数をenumで定義するのはびみょうだということだ。unsigned long longな値とかあるせいで、コンパイルエラーになる。

enumではなくconst autoにしたら通ったので、後で直しておこう。


2013/10/02 05:20

とりあえずキーボード対応した。

windows側、うまくできるか不安。

そんなことより、仮想マシンにつっこんでるwindowsがまれによくホスト巻き込んでフリーズして参ったので、ホストをwindowsにしようかと思っている。

まず、すでにwindowsが入っているマシンにvmwareを入れて、その上にgentooをインストールして色々試してみることにする。

しかし、VMWarePlayer、バージョン5かららしいが、バルーンヒントが消せない。

「お使いのコンピュータに戻るには、Ctrl+Altを押してください」とかいうのが毎回出てきてうざい。

それが出てるところクリックしても、その下をクリックしたことにならないし邪魔なことこの上ない。

前のバージョンを使えるようなら変えてしまおうかしら。

あと、vmware toolsのインストールがうまくいかない。

gentooのリポジトリにopen-vm-toolsとかいうのがあるので、それをインストールしようとしているのだが、open-vm-tools-kmodのインストールでこける。

どうやら、新しいカーネルに対応していない記述になっているらしい。

ちょっと検索してみたら対応するためのパッチが見つかったので使おうとしたが、どうも古いバージョンのvmware tools用らしくパッチが失敗する。

すごいめんどくさい。しかしやらねば。どう対応しよう。古いカーネルのソースからカーネルを構築しようかしら。それが一番楽そう。


2013/10/01 04:00

細かい修正をしていた。

そう細かくないこともしてたけど。インターフェース変えたり。

ウィンドウやディスプレイの幅、高さ、位置などのデータをdp::Long(long long型)やdp::ULong(unsigned long long型)にしてたのをやめた。dp::Int(int型)で統一した。

理由としては、幅や高さをOpenGLで使用する場合に不便だから。それに、幅や高さの指定に64bit整数が必要になることなんて、絶対にないなんてことはないだろうけど、まぁすぐには必要にならんだろう。

パソコンのディスプレイの解像度なんか、1920x1080とかいうクソみたいなのが主流のようだし。横長やめろよテレビじゃねぇんだぞ。

あと、linuxの場合のみだが、dp_commonのロード時、アンロード時に行なっていたXOpenDisplay()やXCloseDisplay()の呼び出しを、別のライブラリ(dp_xlib)に分離した。

dp_windowやdp_displayなどで必要になるので、共通的なdp_commonのロード時、アンロード時に処理させてたんだけど、dp_commonはdpを使用するプログラムに必須。コマンドライン引数の処理からしてdp_commonの関数を使ってるし。

なので、dp_windowやdp_displayなどを使わないプログラムであっても、XOpenDisplay()やXCloseDisplay()が呼び出されることになってしまう。そんな無駄なことはしたくないので、別のライブラリに分離して、それをdp_windowやdp_displayなどから参照する、という形にした。

そんな感じか。この次はキーボードとマウスの対応を行なう。

キーボードの対応がうまくできる気がしなかったので今まで敬遠してたんだけど、風呂入ってる時にいいアイデアが浮かんだので試すことにする。起きたら。

そういえばpulseaudioの利用周りを修正するみたいなこと言ってたけど、想像以上に無茶そうなのでやめた。

オブジェクトの破棄時にもロックする必要があるとか困る。std::unique_ptrで対応できないじゃないか。

ああ、あるいはpa_threaded_mainloopではなくpa_mainloopにすればよかったんかな。キーボードとマウスを対応したら試してみるか。


戻る