Kobo Touch/Glo/Mini hacking スレ Part.5

■楽天公式
http://kobo.rakuten.co.jp/

■専用wiki
http://www49.atwiki.jp/kobotouch/

※前スレ
Kobo Touch/Glo/Mini hacking スレ Part.4
http://uni.2ch.net/test/read.cgi/ebooks/1360673958/

Kobo Hack情報元祖
ttp://wiki.mobileread.com/wiki/Kobo_Touch_Hacking

海外情報源
ttp://www.mobileread.com/forums/forumdisplay.php?f=223

Kobo Touchで英和辞書
ttp://petit-noise.net/blog/20120808/kobo-touch%E3%81%A7%E8%8B%B1%E5%92%8C%E8%BE%9E%E6%9B%B8

Kobo用高速化Jpegライブラリ
ttp://ux.getuploader.com/KOBO/download/1/Kobo_libjpeg-turbo_updater_20120824.zip

Kobo Touch専用ホームボタンにページ送りを割り当てるデーモン（常駐アプリ）
http://ux.getuploader.com/kobo/download/5/kobo_fwbtd_20120912.zip

※注意
全て自己責任でおながいします

CustomFirmware for Kobo Glo / Kobo Touch / Kobo Mini "Advanced Edition" Ver0.95

http://ux.getuploader.com/KOBO_HACK/download/68/Kobo_CFW_Ver0.95.zip

■主な機能

１ 不具合修正

�@ 外部SDカードに保存されたファイルの名前に２バイト文字が使用されている場合
Kobo本体に差し込むとKobo上で文字化けが発生してしまう
�A 内蔵ストレージに置いたファイル名、フォルダ名に特定の文字が含まれていると
”FSCKxxx"といったファイルになり、ファイルやフォルダが削除されてしまい、使用できない。
�B CBRファイルの中に、上記�Aのような名前を持つファイルが格納されている場合に
正常に使用できない。
�C Wifi設定が壊れてしまうと、以後何度設定を変更しても保存されなくなる。
�D 外部SDカードを使っていると、色々なタイミングで高確率でフリーズする。
�E 青キン明朝などのユーザーフォントを利用していると、電源ON時に開いた本でその設定が壊れ
デフォルトの設定に戻ってしまう

２ 追加機能
�@ 外部SDカード、内蔵ストレージに保存されたzipファイルをcbzファイルにリネーム
�A 外部SDカード、内蔵ストレージに保存されたrarファイルをcbrファイルにリネーム
�B 外部SDカード、内蔵ストレージに保存されたTextファイルをHTMLに変換
�C PDF,CBZ,CBRファイルのページ送りをkepub.epubと同じ左→右スワイプ、または
スクリーン左部タッチにより「次ページ」になるように変更する機能
�D CBZ、CBRファイルのファイル名が [著作者名] 書籍名.cbz(またはcbr)というフォーマットに
準拠している場合、Kobo上の著者名、書籍名を自動で正しく更新する機能
�E 書籍の登録後に、ユーザー本、ストア本ごとに著者名・格納しているフォルダ名・出版社名
などから自動で本棚を作成して書籍をその中に格納する機能
�F 壊れたり、消せなくなった本棚を全て削除し、�Eの自動本棚作成機能を使って本棚を
再構築する機能
�G 内蔵ストレージ領域に、Linuxのswapパーティションが存在した場合、起動時に自動で
スワップ領域としてKoboが利用できるようにする機能
�H データベースが肥大化してしまい、動作が重くなった場合にデータベースの最適化を
実施する機能
�I データ補完をKoboのコンテンツ処理に連動して実行。また、起動時に再補正を実行する機能
�J データの高速Commitモードを使う機能
�K 起動中やサスペンド画面に表示されるアニメーション・静止画を自由にカスタマイズできる
テーマ機能
�L (kepub.epubのみ）使用するフォント、フォントサイズの設定をテンプレート書籍の設定に
従って全書籍共通化するフォント設定共通化機能
�M 最後に読んだ本が格納されている本棚にある本を「最近読んでいる本棚」に自動登録する機能
�N データベースのキャッシュサイズを任意に拡張するDBキャッシュサイズ拡張機能
�O Koboがフリーズした際に、電源LEDを赤点灯し「フリーズしたこと」を通知する機能
�P よりKoboで読書を快適にするための独自フォント「KB Mincho」「KB MinchoM」の実装

本棚だけでなく、検索アイコンも追加してみました。

http://ux.getuploader.com/KOBO_HACK/download/103/shelveicon-130327.zip

kobo glo, mini の場合、検索アイコンが追加されます。
kobo touch にはもともと検索アイコンがあるので変化ありません。

また、今回はソースも同梱してます。

今回は開発者向けのリリースです。
QtCreator にカスタムウィジェットを追加するプラグインができました。

　
https://github.com/t-bucchi/NickelWidgetForQtCreator/archive/130406.tar.gz　

これは github で公開することにしました。
TouchDropDown のリストアイテムが GUI 上から追加できないなど、
まだ色々いまいちなところがあるのですが、とりあえずデザインはできるように
なりました。
# こんな程度じゃ Promotion で作ってもあまり変わらないかも・・・

また、上記プラグインを追加した QtCreator で前回作った CFWSettings をデザインした
サンプルも用意しました。

　
http://ux.getuploader.com/KOBO_HACK/download/109/CFWSettings130406.zip　

今回は、CFWSettings のプロジェクト自体を QtCreator で開けるような形に
なってます。
ツールチェーンなどのビルドの設定さえすれば、QtCreator 上でビルドも可能です。

なかなか時間が取れなくて、遅くなってしまった。
もっと早く出したかったんだけど。

CFW設定画面の雛形と nickel のカスタムウィジェットの表示サンプルを作ってみました。
設定メニューに "CFW Settings" を追加して、タッチすると Widget のサンプル画面が表示されます。

ソース:
http://ux.getuploader.com/KOBO_HACK/download/105/CFWSettings-130330.tar.bz2　
バイナリ:
http://ux.getuploader.com/KOBO_HACK/download/106/libcfwsettings.so　

画面イメージ
http://ux.getuploader.com/KOBO_HACK/download/108/kobo-cfwsettings-1.jpg
http://ux.getuploader.com/KOBO_HACK/download/107/kobo-cfwsettings-2.jpg

TouchLabel など、tweaks で解析済みのカスタムウィジェットに加えて、ドロップダウンリストや、
ラジオボタン、画面下部のページ切り替えウィジェットのクラス定義も調べて追加しました。

- TouchLabel (タッチ可能ラベル)
- TouchCheckBox (チェックボックス)
- TouchDropDown (ドロップダウンリスト)
- RadioButton (ラジオボタン)
- N3ButtonLabel (通常のボタン)
- TouchSlider (スライドバー)
- WirelessPaginationWidget (ページ切り替え)

ひとまずこれだけあれば設定画面を構成するのに充分かなと思います。

まだ、QtDesigner での構成でなく、直接コードに書いています。

ご無沙汰してます。

Kobo用フォント第3弾「KB丸ゴシック」初リリースです。
KB明朝と同じく、Kobo端末上でキレイに縦書き/横書き表示されるように、
調整を行いました。

英数字がプロポーショナルになっています。
その他の文字は等幅です。


★ダウンロードは以下からどうぞ。
(バージョンがBeta6となってますが、初リリースです)
http://ux.getuploader.com/KOBO_HACK/download/100/KBMaruGothicBeta6.zip


★このフォントはまだベータ版です。
なので、フォント名は「KBMaruGothicBeta6」となっています。
バグ等を潰したのち、近いうちに「KBMaruGothic」になる予定です。
Kobo上で、書籍へのフォント設定を行う際は、この事をご留意下さい。
「お試し」でご使用されることをおすすめします。

★Readmeを読んだ上でご使用下さい。
このファイルを使用したことで何か問題が発生しても責任は負いかねます。

★不具合のご報告や、ご意見・ご質問・ご要望等あればご遠慮なくどうぞ！

前スレ991です。

内蔵64GBへの換装、成功しました。
作業手順は通常の換装とまったく同じです。

http://s1.gazo.cc/up/51203.jpg
http://s1.gazo.cc/up/51204.jpg
http://s1.gazo.cc/up/51205.jpg

CFW0.95と検索アイコンをインストール後、
いま読み途中の自炊cbzを20冊ほどコピーしましたが、
表示、検索ともに問題なし。作者名の本棚も自動作成OKでした。

耐久性うんぬんはしばらく使ってから、ということで。

明日は6時出勤なので、今日はこのへんで失礼します。
おやすみなさい。

>>8
耐久性より32GBを超えた書込みの方が気になる。

>>8
64GBのSD使えたんですね。
一通り調べた際、殆どのサイトで32GBが使われていて64GBの話題は無かったので、
勝手に32GBまでしか使えないと思い込んでました。

やっと規制解除されたー

前スレのcbzの人、xpの圧縮フォルダでzip作ってないよな？
あれ2GB制限あるんだよねw
http://support.microsoft.com/kb/301325/ja

>>8
乙
スゲーなあ。まともに動くなら追加投資5000円の価値はあるな。
しかし、高速MicroSDを内蔵した結果、超低速ストレージに化けそうで勿体無いなw
30mb/秒が3mb/秒ぐらいにはなりそうな悪寒。
使えるなら外部SD運用の方が幸せだったり。

>>11
7+Lhaplusで作成しましたが、
そういえばその際に何かダイアログがでていたのを思い出しました。
なるほど、改めて思い返すとzipの作成ミスだったのかもしれません。

別のソフトでzip作り直してみることにします。

外部SDでも６４Gつかえるんですかね？ ６４G持ってる方試してみて。お願い。

>>13
え？てことは最適化していないのかな？

>>15
ChainLPで最適化した巻別のcbzを作った後に全て解凍しタイトル別に圧縮。
という、手順を踏んだため最後にLhaplusを使う事になったのです。

ギガバイトサイズの圧縮、解凍にlhaplus使っちゃダメだよ
エラー出まくるから
それでlhazに乗り換えた

外部SD使いたくて>>3ダウンロードしようとしたけど繋がらない

つか、巻別になってるものをまとめなくても。
一気読みには良いかも知れないが、koboでのページ扱いとか考えると無茶な気がする。

>>18
>>3使わなくても外部SDは認識できるはず。

>>20
フリーズしちゃうんだけど

kobo過去スレから外部SDだけに対応するパッチ見つけたので解決した

2.4にバージョンアップすればよかったのか
すでに2月に出ていたとは知らなかった
失礼しました

前スレで、自炊本100冊入れて10MBだということでしたが、contentテーブルに1ページずつないとページが飛ばされちゃうので内容確認したいのですがいらっしゃいますか？
ちなみに、今のところcbzもcontentにフルページ情報が必要っぽいので、ダイエットしても半分くらいです。

昨日一晩かけて1152個のcbzをコピー。pcから取り外してカバンに入れ、朝6時に家を出て、6時50分に会社着。この通勤時間内にデータベース処理は終わりましたが、バッテリー残量が59％だったんで、CPUを酷使してますね。
帰宅電車であれこれいじりましたが、レスポンスは32GBのときと体感差は無しです。相変わらず本棚は遅くて使い物になりませんが。

32GBはclass4、64GBのほうはclass6相当のはずなので、体感できるほどのパフォーマンス差はないかもしれません。

たぶん外付けでも64GBいけるはずですが、未確認です。

>>25
その千数百個のデータで32GB以上入ってるんですか？

>>19
元々巻別で管理してたのですが、ファイル数が多く本棚を開くのに何秒もかかりあまりに不便だったためタイトル別にまとめたのです。

> 一気読みには良いかも知れないが、koboでのページ扱いとか考えると無茶な気がする。

ページの扱いが無茶、とはどういった意味でしょうか。
以前と比べ不便に感じるのは、本を開く際に少し時間がかかるくらいだと思っているのですが。

>>26
ご存じだと思いますが、SD、SSD、HDDに限らず、フォーマットすると
おおよそ10％容量が減ります。

SDHCの32GBでは、だいたい29GBくらいが空き容量として残るでしょうか。
そこにkoboのシステムやらCFWのスワップ領域を確保するため、
最終的な空き領域は27GBくらいだったと思います。あくまでも私の場合です　orz

要するに私の環境では27GB超えれば、32GBのSDカードを満杯にしたのと同じということです。
現在1177個のCBZファイルで26.5GB転送済みなので、あと500MB転送すれば、32GB分は消化した、ということです。

今週末に自炊する分を入れれば、たぶん32GB超えは達成できます。
そんときにまた報告します。

以下妄想。
実現方式の検討はできるものの今のところ実装の余裕がない…

*cbzのメタデータ
tweaksのQtScript(JavaScript)pluginを改造してhook経由のshellから外部kickさせて、
scriptでzip内のepub準拠opfをparseしてdb登録させる、とかすれば
著者名やら諸々を綺麗な標準書式metadataで対応可能なのかもねえ。
無理にQtScriptをつかわなくても、Python(PyGameのやつ)だとか、
opfのxmlをparseして必要情報に変形できればOkだから
xsltprocモノ+shellでもいいんだろうけど。
(metadataを限定的にするなら正規表現で必要情報を抜き出すだけでもいいだろうし)
#libxslt(xsltproc)とかlua(standalone)とかsquirrel(standalone)とか、
#使えそうなものは一応昨年末に途中までportしてあったりする。
#(バイナリだけは作って未テスト)
#standaloneでのlua,squirrelあたりはpythonよりはfootprintが小さいからportしようとしたんだが、
#xml,sqliteに対するbindとかその辺を調査しないと実際に使えるのかわからん。

これだけだと、libcbの構造上、zip内1ファイル=1recordなのは解消できないけど…
あ、gotoPage等その辺をいじって論理pagenoと実pagenoの変換すれば
1話(実1章)=Koboの認識する1章にできるのかもしれない…
実pageno=章top + 章内offset
goto系のページ移動は章内offsetのinc/decと範囲外への移動で章も移動になるようhack
これだけだとjump移動が破綻するから、libnickel側のReadingViewのMenuViewとかも
章対応にしないといけないか…ここはちょい調査がいるので厄介そう
DB側に記録されるdogearとかその辺も合わせて辻褄合わせないといけないだろうし、
生png/jpeg,metadata対応cbz(cbr),metadata未対応cbz(cbr)の3つを少なくとも
libcbで扱わないといけないからかなり大変だなあ。

*サムネJump
menuの項目追加して、複数ページ(WirelessPaginationWidgetを置いた)dialog上に
dialogの1ページ＝Nサムネに分割して複数ページに貼り付けていって、
indexからのページ移動みたいな操作でjump pageさせるようにすればできる？
オンデマンドでサムネ生成していくのはさすがに操作性に劣るだろうから
事前生成だとして、登録時に負荷がかかりすぎるのが難点。
i各ページのサムネ生成と保存をしないといけないから
全コンテンツの読み込み＆(サムネ生成に必要な分の)decodeがいる。
まあpcで事前生成させるとか端末外に回せる作業ではあるが。
生成したサムネはまとめて(zip2cbzにかからない拡張子ordirで)zipにするとか、
コンテンツ個別dbを作ってそこにぶち込むとかすえばOk。
nickelが想定しないサブファイルができているので、nickelのコンテンツ削除をhookして
コンテンツ本体のcbzが削除されたときに、サブファイルも消すようにしないといけない。

>>30

サブファイル削除にリアルタイム同期は必要ないから
・Linuxのdir監視の仕組みを使ったイベント処理
・既存のhookの枠内でのcleanup処理
とかでもいいか。

サブファイル生成はキャッシュ的な位置づけで
・事前生成済ならそれを使う
・なければオンデマンドでサムネを生成した段階でサブファイル生成
でいいかな。
キャッシュ的な観点だと常にバカ正直に残してもメディア容量食うだけだし、
基本ReadOnlyな外部sdの扱いが面倒になるから、
完全にキャッシュとして、limit sizeまでのサムネを残す、
としたほうがシステムとしては正しいのかもしれず。

>>24
ごめん、何を聞きたいのかちょっと分からないんですけど

contetテーブルに必ず１頁毎にxhtmlデータが挿入されるはずだからスキャンした自炊データでそんなに小さくなるもの？という意味です。

>>27
割れ氏ね

>>33
良くある画像kepubは1つのxhtmlで1つの画像を表示しているだけだから
画像が200枚あればxhtmlも200個になるんだけど、うちのは目次項目の数しかない。
つまり1つのxhtmlに複数の画像が入っている訳ね。
1つのkepubあたりの画像は平均200枚前後で、xhtmlはだいたい10〜20個です。
こんな話でいいのかしら？

>>35
ああ、なるほど。ChainLPだけではないか、別の方法で作っているということですか。
どっちにしろcbzの場合には使えない方法ですね。
では半分程度の削減で我慢することにします。

>>35
ありがとうございました。

やはり、cbzメインの話でしたか。
私は、cbzを悪く言うつもりはないけど、何一つカスタマイズできないので
独自のkepubに完全移行しました。
まだまだ作成は面倒だけど、ページめくりも基本cbz同等だし満足している。

>>38
いや、残念ながらcbzとkepubで決定的に違いがあります。
cbzだと1頁毎に反転しないのです。設定によりますが。
ですからサクサク読み込め頁めくりも速く眼も疲れません。

ちなみに、CFWを入れるとdbサイズが多少大きくなっても問題ないですよ。
360MBのdbでもとりたてて遅いと感じませんでした。
600冊ほど、実際には複数巻をまとめたので800冊以上でその程度です。
半分にする方法はvolume_shortcoversテーブルの内容を削る方法ですが、これだとしおりを書き込みで呼び出すことができなくなります。
今実験的に半分にしてあり、それでしばらく運用してみます。

>>39
いや、うちのはcbzと同様にMAX6ページ毎のリフレッシュになりますけど…。
ただ、公式ファームのバグで、2.4.0からは一度アイコンメニューを出さないといけなくなってるけど。
あと、ページめくり自体は本当にcbz同等です。

>>41
なるほど。
頁移動はどうなりますか？cbzだとスライダーで１頁めから最後まで移動できます。
ChainLPで作ったものだとスライダーが使えないから不便でした。

>>42
上でも書いたけど、全体をいくつかのブロックに分けていて、
それぞれxhtmlに複数枚の画像が入っています。
そのxhtmlの中の画像群ごとにスライダーで移動できます。

ただ、cbzでは有効な移動手段がそれしかないのかもしれませんが、
kepubだと、xhtmlごとに目次に名前を付けてジャンプさせる事ができるので
通常はそちらを使用し、移動でスライダーを使う事はまずありません。
目的の画像へ飛んで、そこから普通にめくるだけです。

ChainLP作成のkepubでスライダーが使えないのは、
使えるべき範囲に画像が１枚しかないためです。

>>43
何度も回答ありがとうございます。
やはりそうなるのですね。
一気にジャンプが欲しいので私としてはcbzのスライダーがありがたいです。
kepubも良さそうですが、ChainLPが自動でそういうxhtmlを作ってくれるのでなければ手間が掛かって大変そうです。
今でさえ、同じタイトルの本を読んでいる最中に気に入らないからとしばしばChainLPにかけ直して調整していますから。
色々試行錯誤されていますね。貴重な情報ありがとうございました。参考にさせていただきます。

>>44
別に仕様上は全画像ひとまとめにする事は可能なんですが、
epubのがっかりな仕様により、大量の画像には向いていません。

この仕様のkepubに変換する簡単ツールは公開済みなんですが
未だ誰にも認めてもらえず残念至極ｗ

>>45
どこに公開してあるの？
試してみたい

>>45
ごめん みつけたw
すぐにみつかってビビった。
試してみるね。ありがとう。
ときに、分割上限が22なのには訳があるの？
この分割仕様なら全30巻とかのコンテンツもまとめられそうな気がしたんで。

>>47
分割の項目数は、最初に窓の大きさを決めた時に入ったのが20項目だったのと
koboの目次項目数が１ページ11だったため22になっています。
上限撤廃は考えていますが、画像を直接いじる機能を積んだ後の予定です。

あと、画像入力は9999枚まで通ると思いますが、
1ファイルの想定はコミックス1冊程度で、1分割30枚程度です。
分割しなくても直接特定の画像までとばす方法はあるのですが
わざわざ分割させているのは、epubの残念仕様を緩和するための苦肉の策なのです。
よって、内容は不明ですが30冊もひとまとめにすると、きっと残念な結果が待っています。
（分割上限がなければ実用性はあるかもしれないが）
今のCFWの本棚を使えば、なにも30冊をまとめる必要はないと思いますけどね。

>>48
沢山のファイルを入れると重くて本棚が役に立たなくなるんよねw

あっ！
もしかして、cbzをこのePubに変更すれば、本棚も実用的な速度になったりして？

>>49
たくさんとはどれくらい？
500冊くらいでは速度は落ちないよ。CFWだと。

>>50
一冊あたり35MBぐらいだとして、千冊分ぐらいのcbzを運用してる。実際はまとめてるので、ファイル数としては300ぐらい。プラス、テキストベースのePubが百冊ぐらいかな。
要するに32GB満タンです。本棚はアクセス時に10秒〜20秒待たされます。
DBサイズは600MB程の大所帯です。

ちなみに500冊のその状態でDBのサイズはいかほど？

1000冊てすごいね
1日1冊でも3年くらいかかるね

>>51
320MB。

俺もｃｂｚが1000冊だけど318MBで10秒も待たされないよ。
本棚の数が多いんじゃない？

500冊、DB軽量化仕様画像ePub : DB320MB

1000冊、cbz : DB318MB

なんか辻褄が合わなくておかしくね？
謎は深まルネ〜w

でも、確かに本棚の量は多い方かも。
今、あらためて数えてみたら、250件程ありました。原因はコッチなのかも。

>>55
辻褄は合うでしょ。ひとつのcbzファイルに何冊分を入れてあるかとか、1冊でも普通のラノベはページ数が少ないけど、例えばカズムシティなんか入れればページ数は多い。
ラノベでも分厚いのを見かけたことがある。なんとかのホライズンとかだったような。紙の本の限界に挑戦みたいなの。

>>56
いや、勿論そういう運用誤差はあるだろうけどね。ただ、確実に一冊単位で作ってるePubと沢山放り込めるcbzでは後者の方がDB大きくなりそうだなあーとイメージしてた。
さらに言えば、サンプル情報の本の冊数はcbzの方が倍多い訳でw

なんか訳わからん感じの仕上がりじゃね？

>>57
まずはdbの中身を覗いてみよう。
そうすれば理解できるはず。

俺のｃｂｚは4bit pngで一冊が200ページ20MB程度

>>58
んんーじゃあ同じコンテンツ(200ページ分)をcbzとePub(内部分割10)で作った場合は、どうなる筈なの？
予想では、劇的にePubの方が軽いと認識してたんだけど。違うのかなあ。

そうでなきゃ意味なくね？

なをだkoboは割れ仕様で自滅まっしぐらかよww

なぜ割れと決めつけるのかね

内蔵SDを16GBに換装して、満タンcbz運用が幸せってことでFA臭いな

epubだろうがcbzだろうが「絵」を取り扱う以上、あまり変わらないと思われ。

割れ割れは宇宙人だ

61のニックネームは、宇宙人に決定したw

cfw 0.95 plus は今どこでダウンロードできるのん？

cbzをePub化して本棚快適♪
ってのは誤情報ってことでええの？

>>64
仕事しろヲタカス

久しぶりにkobo touchをいじったら自作cbzを転送しても読めなくなってしまった。
ので、CFWに初めて手を出してみることにした。
しかし、 >>3 がダウンロードできないので 0.95β5でとりあえず運用中。
ダウンロードのコツとかあるのかな?

あれれ、本当にダウンロードできなくなってるや。

つーわけで、再Up

0.95
http://ux.getuploader.com/KOBO_HACK/download/111/Kobo_CFW_Ver0.95.zip

0.95Plus
http://ux.getuploader.com/KOBO_HACK/download/110/Kobo_CFW_Ver0.95_Plus.zip

パスワードロックやセンターズーム使いたい人はPlusを、それ以外は0.95でどぞ

漫画はepub化しても恩恵が少ない、というべきかいねえ。

しかし、1ファイル3Gってｽｹﾞｪなあｗ
スワップ無かったら絶対に開けないんじゃなかろうかｗ

>>68 >>72
どういう比較検討からそんな結論付けになるのか一度きっちり説明して欲しいわ〜
流れだけ見ていたら、誰もまともに検証してないでしょうに。
憶測だけで結論を出していたら、またいつか同じような話題になった時に
「誰かが意味無いって言っていたよ」　という無責任な一言で片づいちゃう。
他力本願はいいけど、根拠のない無責任な発言はイカンと思うんだよね。
別にcbzと画像epubとどっちが有利だろうと、かまいはしないけど
何か決定的な比較要素が欲しいんだけど、何か無いですか。

>>73
DBのサイズを比較検討するのに、下記のコンテンツサンプルがいるね。
コレは簡単に作れる。
1. cbz
2. ChainLPで作成した画像ePub
3. ReconstructionKepubで作成した画像ePub

勿論、同じ元データで作成。

んで、コレを検証するために、ファクトリーリセットしたkoboで(ry

ファクトリーリセットまんどくせー
ってことなんでね？

DBの中身を見れてる人が恩恵無しと言ってるんだから、俺は検証する労力が惜しい。
あとは、気になる人に任すわ。

>>71
TNX

大雑把に言えば

例：100ページの漫画をepubとcbzにした場合

keypub：毎ページが「挿絵」と同様に処理されるため、100レコード最低限できる。
cbz：最初っから１ページ1レコード。つまり100レコードであることには変わらない。

なので、DB上は「どっちも変わらない」。

だけど、epubはメタ情報を読みながらの展開になるので、jpgやらpngをレコード情報から
単に読み出して表示するだけのcbzよりびみょーにウェイトが入る。

こんなとこかの

>>72
詳しい事は分かりませんが、3GBのファイルが開けるのはCFWのおかげなんですね。

改めて各開発者を始めkoboayaさん、
ありがとう！！

>>76
＞keypub：毎ページが「挿絵」と同様に処理されるため、100レコード最低限できる。

↑これが100レコードでなければ同じではないということ？

さらに、テキストepubでも100個のxhtmlに分かれていたら、画像100枚のcbzとDB上の重さは同じという事ですか？

イチイチ書くことじゃないけど、ちょっとDB周りの話も出てたので少しだけ。

・DBのファイルサイズ

基本的に大きくなることはありますけど、普通に使ってるとサイズが小さくなることは
無いと思ったほうがいいです。
例えば、本を消してその本に関するデータが全て消えたとしてもサイズは変わらないと。
これはSQLってデータベースの仕組みだから仕方無いわけです。
ファイルサイズだけでかいまま、中に保持しているデータ量だけ減っている、そんな状態。
なので、データの保持状態如何によっちゃ遅くなったりするわけでござる。

CFWの「データベース最適化」機能ってのは、この肥大化したデータをスリム化する
機能なわけです。ハイ。
逆を言えば「めったに本を消さない人」は、最適化機能はあまり恩恵は無いのです。

・本棚が開く速度

本棚は、本棚の数というより本の数に関係すると思ったほうがいいです。
本棚が１つ２つでも、中に数百といった本が入っていれば遅くなります。
逆に言えば本の数が少ないと、本棚が幾ら増えてもあまり速度低下はありません。

・内蔵SDの64G化

できるもんなんだなあ・・凄い。
でも、多分64Gをパンパンにしちゃうと、nickelの構造上かなり遅くなるのでは・・・
これは是非動作速度の報告が欲しいですねえ。

ちょっと前に、VolumeIndexテーブルの中身を消して運用している人がいたみたいだけど
特に大きな問題は無いのかな？ DBのスリム化という意味じゃ大いに意味があるとは
思う＞VolumeIndexの削除

ではでは

>>78

テキストベースのepubはレコード数は劇的に少ないですよ。
まぁ、中身をどう作るかにもよるとは思うのですが。
（xhtmlをどう分割するかってコトやあね）

漫画ってのは、ページの連続性を保証するために1ページ1レコードにせざるを
得ないわけだけど、テキストベースだとフォントサイズや
行間設定によって1ページに表示できる文字数が変化するわけだから
何を持って「1ページ」とするか、決められない。
なので、そういうレベルでデータを保持できない。

漫画はそんなことないでしょ？ 文字の設定がどうだろうがなんだろうが1ページは1ページ。

epubファイルの細かいフォーマットとかはよくわからないけれど
漫画をepub化したときに、例えば１０ページを一つのxhtmlに記載すればDB上は
1レコードになったりするのかもしれないけれどねえ。

>>80
えええー！ずっとその話してるですけどw
効果ありそうじゃんw なんやねん

200ページの漫画を10個のxhtmlに分割してePub作ると200レコードが10レコードになるかもってことですか？

DB上は１０レコードになると思うよ。少なくともメインの「content」ってテーブルは。
でも、挿絵とかの情報を保持しているvolumeなにがしってテーブルは、
200レコードになるんじゃなかったっけか。
（流石にそんな検証はしたことはないｗ）

メインの情報を読み込み→挿絵情報を読み込み→データを展開って流れだから
DB的に考えれば、メイン：挿絵情報が１：１のほうがロスは少ない。
けど、nickelの内部での処理は遅いかもしれない
（漫画のepubが”もっさりする”という原因はおそらくこれじゃないのかな）

この比率が１：１０になったら、漫画のepubのもっさり感が減るかも。
でも、それはDB云々じゃなくnickelの問題かと思われ

>>80
なんとなく、ｃｂｚでも画像epubでも、「理論的には」出来上がったDBの大きさが同じだから
どちらで登録しても動作に変化は無いだろう、という理屈で >>72の結論に至った事は分かりました。

でも、前スレで自分のDBの容量が他の1/10程度だと判明した事から
画像epub内のxhtmlの数を減らしている事が直接DBの容量に関わっている事がうっすら分かった気がします。
かといって、動作が軽いのか普通なのかは全く分かりませんけど。

色々実験してわかったのはCFWでバッファを増やしているから、内蔵記憶装置32GBまでならdbのサイズを気にしなくても良い。

それでも気になるならChainLPを使っているcbzの場合、以下のようにすればdbサイズが半分になる。ただし、しおりをはさめるけど呼び出せない。
今のところこれ以外の不具合なし。自己責任で。これでわかる人でなければやっちゃだめ。

delete from volume_shortcovers where shortcoverID like '%.cbz/P0____.%';
vacuum;

追加

しおりの問題はcbzだけ。同じdbにあるkepubには影響なし。
xhtmlを作るのはChainLPだけですまないし、スライダーでのジャンプができなくなるから私は使わないことにしました。
地道にスライダージャンプは便利。

とくに書かれてないので気になるんだけど、swap領域ってどのくらい確保するのが最適なんでしょう。

自炊cbzを1299個で約30GBを転送し、問題なく動いてます。

32GBのSDHCが記録できる実容量は約29GBですから、64GBのSDXCの有効性は確認できました。

この状態で本棚を開くと、おおよそ90秒近くかかります。
本棚（作者名）が483個もあるので、やむをえないところでしょう。

一方で「ライブラリ」→「本」の表示はそこそこ速いです。
およそ2秒程度で縦5個の表紙サムネイルが表示されます。
まぁ、1画面分を送る、または戻るごとに2秒程度かかりますから、多少のストレスは感じます。

検索も実用的な速度で、ほぼインクリメンタルサーチと言っても過言ではないです。

現状では本棚の利用はあきらめました。
その分、大量の自炊本を持ち歩けるほうが私的にはうれしいです。



＞koboayaさん
CFW便利に使わせてもらってます。
64GBいっぱいになるにはまだしばらくかかりそうですが、上記のとおり、検索が圧倒的に高速なので
私としてはストレスフリーで使えると期待しています。

Recon何ちゃら(名前ムズイ)の機能をChainLPが取り込んでくれたら、一般化しそうですね。DBの軽量化出来そうだし。
強く連携を求む。

まあ当面は私もcbzかな。

>>88
容量削って速度が上がるならともかく、現状では変わらないからね。
ページジャンプが快適な方が良いよなあ。

>>87
割れ氏ね

>>90
宇宙人さんお疲れ！

>>87
本棚483個・・・。
初期のkoboからすると想像を絶する運用だなあ・・・。

bucchiさんの >>5 は開発者向けのカスタムウィジェットを追加するプラグインとの事でしたが、
それを利用すると具体的にどんな事ができる様になるのでしょうか。

そう言った事は詳しくないので、よければ詳しい人がいれば教えていただけませんでしょうか。

「PCに接続されています」でフリーズ。
電源OFFできないし、リセットホールのリセットもできません。
どうすればいいですか？

>>94
充電は切れてませんか?
それも考えられないようであれば、koboサポートへGO!

どうやらバッテリーが0%だった為で、アダプタで充電したら復活しました。
お騒がせしました。

>>96
復活おめですw

64Gに換装しました。
内部に３０G、外付けにもcbzいれており、ファイルは1500ほどです
ホームから本棚に移動は15秒で、読むのも問題ないのですが、
最近よんでいる本棚を編集しようとすると3分弱またされます。
こんなものでしょうか？
それともswapがまちがってるのでしょうか？
swapとはよくわからないのですが、partion wizardで90MBほどにしてMAX設定したのですがやり方あってますか？
初心者のためすいませんが教えてください。

追記です
本棚の数は６０です

割れ氏ね

本棚が糞重くなるのは仕様っぽいね。
一昔前は100冊でも動作が怪しかったから、かなり改善したと言うべきなのかもしれんが。
そのうち一万冊入れても軽々動作♪ とかになる日が来るんだろうね。

リアル本棚、本当に要らんくなりそう。

>>93
QtCreatorという Qt アプリの統合開発環境があるのですが、
その開発環境上でnickel 内部で実装している画面上の部品を
使ってUIをデザインできるようになる
プラグインです。

なので、kobo本体に入れるものではなく、
koboをハックして画面を追加するときに
役に立つものです。
と言うわけで開発者向けリリースと書いたわけです。

突然にすいません
0.95Plusを快適に使わせていただいているものです
特にパスロックが有難いです
そこでちょっと気に掛かる事がありまして一筆。
パスロックが単調に設定したもので押した部分だけ手脂が付いてしまい
なんとなく押した場所がわかるような　？
キーエントリーをランダム配置などのイタズラ（？）が容易にできないでしょうか

もう一点本棚単位でのパスロックが可能でしょうか
開発、改良を先導している方々に感謝をしつつ検討をお願いいたします

エロパスですね？ｗ

>>103

本棚単位の処理は多分無理じゃないかなあ。

>>98

swapは90Mくらいじゃああまり効果は感じられないと思うけど、問題はそこじゃなく
単に本の冊数が多いので、データの更新に時間がかかってるだけだね。

koboreader.sqliteファイルが300M越えたあたりから劇的に動作が遅くなるのは
もう仕方の無いことなのかもしれない。

キャッシュサイズMAXにするのなら、swapは512Mくらいあったほうがいいかも

>>103
手脂拭けよｗ

kobo touchで内部SDが32GBでswapは2GB、ファイルは1400で使用サイズは25GB、koboreader.sqliteサイズは470MBで本棚数は10ですが、本棚の表示まで４秒とそれほど遅くないです。

>>107
Swap2GBって奮発したねえ。
意外と効果あるのかもしれんね。

512MBで十分でしょ。
300MB越えると云々の方が間違えてる。

なら、なんの違いなのか気になるね。
私は>>107さんよりもライトな使い方してるけど、20秒近く待たされる。

swap512mb DB410mb Files900 23gb

sqlite3のバッファサイズは？

>>102
開発者さん自ら答えて頂いて恐縮です。
相変わらず僕には分かりませんが、Koboハックの発展の為のものなのですね。

これからも楽しみにしています。
頑張ってください！

dragonはauraって新機種だったのか・・・。

nickel積むんだろうけど、なんか勿体無いなあ

bucchiさんだいじょぶかな。
いままでずっとROMってたけど、ブログなくなってて悲しくなった。

逮捕されました

>>115
一分かからず、こんなふざけた屑レスがつくとは・・・
よっぽど勢いがあるとこならともかく。。

あ、そっか。普通、会社は9時始業だもんな。
朝一のおしごとご苦労様です。

>一分かからず、こんなふざけた屑レスがつくとは・・・
十分ね・・・
まちがえた はずかしorz

>>113

早く分解写真みたいな〜

んー、aura=dragonだとすれば、ramは512MBに増量してそうだから
解像度が増えた分のfb増量を差し引いてもメモリに余裕ができて
(画像いじくる箇所は別にして)アプリが軽くなるんじゃないかなあ。

ま、その他はCPUがわからないことにはなんともいえず…
(gloの前科があるからimx5のままで1GHz CPUと言ってもおかしくない)
imx6だとepdcのデバドラなんかも強化されてるっぽいので、切り替わってほしいが…
#たしか、fb内での2値化とかその辺の作り込みの記事がimx6関連のfreescale community blogにあったはず。

アプリはホーム画面の見た目が変わってるけど内部設計は従来のままなんだろうなあ(笑)
koboのplatform的には5世代目扱いなのかな。

#パネルと11nと(多分RAM増量)に$166.99を投資するのはコスパ悪し…
#仮にCPUがimx6だったとしても、アプリの出来が従来継承だと思うと、まだきついなあ…

>>118

あ、11nは従来もか。チップ変更して実行性能があがってなけりゃ同じことか。

新型は２５％高速化か
ヅアルコアにして2倍速にしてほしいわ
多少電池犠牲にしても

石に頼る前にしっかりチューニングして欲しいわ

ギガジンに記事載ってた

＞厚さは約1.2cm、重さは約240gです。 タッチスクリーンでは紙面スペースがこれまでよりも30%広く、1GHzのプロセッサーにより従来製品と比較して25%の高速化、ページめくりがスムーズに行えるようになっています。

「Kobo Aura HD」は265ppi・解像度1440×1080のタッチスクリーンを採用で本日から北米での予約販売を開始 - GIGAZINE :
http://gigazine.net/news/20130416-kobo-aura-hd/

重さが約240gっていうのが気になる。
バッテリー削ってでも200gぐらいに抑えられなかったか。最大1ヶ月持てば十分だろ。
E-inkの利点って軽さと電池の持ちが最大の武器だと思うんだけど。
早く実機のレビューが見てみたい。

色々動き出してるのは嬉しいな。
用心して暫くgloのwifi切っとこ。

悪い。スレチだね。

cfwありがたく使わせてもらっています。
cfwに関わった全ての方々に心から感謝します。ありがとう。

ttp://techlogg.com/2013/04/kobo-to-launch-new-limited-edition-aura-hd-e-reader/2564

なんかここだとやっぱりimx507っぽいことが…
imx5@800MHz(touch/mini/コンペ製品)→imx5@1GHzで125%ってこと？

>Under the hood, Kobo added a 1-GHz CPU,
>which the company claims makes page turns 25 percent faster than the competition

日本語だと「従来製品」となっているけど、海外記事だと対コンペで25%と言ってるなあ。

キンドルのこと？

>>124
たぶん読んでると従来機種よりガンガン電池食うんだと思う
書き換えにgloの倍の電極動かさないといけないし、cpuの負荷も増えてるし

スリープ時はどの機種でも大差無いだろうから、動作時間に合わせた大きさの
バッテリ積んだら副次的にに2ヶ月持つことになったんで、ちょうどいいから
宣伝文句にしちゃえてなとこかと

>動作時間に合わせた大きさのバッテリ積んだら副次的にに2ヶ月持つことになったんで
どういうこと？
「2ヶ月持つ」はスリープ状態で放置じゃなく1日〇〇時間読書して2ヶ月でしょ
従来はそういう表記だった訳だし

CPUがimx507のままだとしたら、PC接続での書き込みもっさり感に代表される、
microSDアクセス性能とかも従来通りなんだろうなあ。

ペリフェラルの利用port変更がシステム設計上可能だったら
UHS-I対応ポートにすることで速くなる可能性はあるものの、
ピンを共有している他機能の利用次第だろうし。

ざっくり画素数80%増しで、fbとしてはアライメント込で倍量ちょい上くらいで+1.5MB。
アプリ側は1画面分で済むから1イメージバッファに対して1.7MB→3MBくらい。
画像展開用バッファ・拡大縮小等テンポラリバッファ・qt自体が持つwsのバッファ
ホーム画面等で表示されるcoverpageイメージも肥大化するわけだから、
等々あわせたら、画素数増がメモリに与える負荷は+10〜+15MBくらいなのかなあ。

ここだけみるとRAM増量してるかどうか微妙なところだが、オリジナルのswapなし状態で、
ある程度のコンテンツ運用した場合にメモリの空きはどのくらいあったんだっけか？

画像加工やらws処理等での作業負荷が単純計算でgloと比べて80%弱増加することを考えると
imx507のままって本当なのか？と思わなくもないものの、
Qtをneon enableでコンパイルする等してある程度改善できて、
なんとかなっているのかしらん？

#fw 2.5.0がリリースされたのか…zoomはメンバー変数offset直指定だからチェックしないとまずいな。

>>130
実使用の状況に合わせて電池容量増やしたら、車での10,15モード？みたいな
ああいう決められた負荷の計測方法だと伸びたんじゃないか？って感じ

>>131
(1440*1080)/(1024*768) ≒ 1.98
(1440*1080)/(1024*758) ≒ 2.00
ざっくり画素数2倍じゃないん？

>>133

ごめん、そのとおり。
何故かボケてgloを1152*758で78%と出していた。＞ざっくり80%

##

fb計算は正しい数字でalign等計算していたんだが、
アプリ内のバッファや処理負荷は誤った全部80%前提だから、
まあ、画面周りの処理負荷は2倍で、
メモリは誤った部分を80%→100%で補正すると
fbは正しい計算なのでそのまま+1.5MB強
nickel内部:フル画面1枚分のバッファ:1.5MB→3.0MBの+1.5MB
fb+システム全体でメモリへの追加負荷は+12MB〜+18MB程度かなあ？

お昼休みにこんにちわ
先週は自サイトの復旧に時間取られて kobo は全く触れませんでした。。
タイーホされたわけではないですよw

ちょっと前のレスになりますが
>>103

> パスロックが単調に設定したもので押した部分だけ手脂が付いてしまい
> なんとなく押した場所がわかるような　？
> キーエントリーをランダム配置などのイタズラ（？）が容易にできないでしょうか

最近の ATM の暗証番号入力みたいなやつですよね。
いいですね。比較的簡単に実現できるので、時間ができたら試してみます。

> もう一点本棚単位でのパスロックが可能でしょうか
これはちょっと無理ですね。
仮に本棚にロックをかけられても、本棚ではない「本」の一覧や、本検索の結果まで
ガードしないといけないわけで、現実的には無理ですね。
力になれず申し訳ない。



最近は任意の本を開けないか調べてるところ。
任意の本の Volume クラスは VolumeManager::getById() で本ID(DBから取得)から
取得できることはなんとなく分かったけど、それを開く方法がよく分かってない。
N3ReaderOpener とか ReadingViewMixin::createReader とかが
絡んでそうなことは分かったんだけど、その先が・・・。

何がしたいかというと、任意の本が開けるなら、自分で DB 引けば
Yet another 本棚が作れるんじゃないかと。
GUIにまで手を出せるようになったので自前本棚とかも作れるかなーと。
で、このスレの DB の神様に教われば、本家の本棚よりも軽くて快適な本棚が
作れるんじゃないかなーと妄想してるのです。

# え？ 2.5.0 出てるの？ 確認面倒だなぁ・・

>>134

[再検討]
nickel内部:フル画面1枚分のバッファ(grayscale8bit):0.76MB→1.5MBの約+0.8MB
nickel内部:フル画面1枚分のバッファ(rgba32bit):3MB→6MBの+3MB
cbzでpngがgrayscaleで作られた場合はそうでもないが、
モードによりrgbaになった場合やjpegでrgbaの場合等はmemory量負荷が大きい。
qwsの内部で生成されるテンポラリなバッファもrgba系が多いのかなあ？
そういう状態を仮定するとトータル20MBを超えた増加でもおかしくないかも。

うちのテスト機環境だと起動直後にブラウザでwifi onしてtelnetで入って
空き13MBくらい(db 300MB)だったので、やはりRAM増量がないと危ういのだろう。

###

2.5.0のglo系firmをちらっと見たが、新規u-boot,kernelが増えてなくて
これまで通りdragonのE606C0があるから(scriptの機種判定)
やはりaura=dragon(E606C0)でimx507+512MBっぽいな。
firmのurlに/5/は増えてないから第四世代のバリエーションなのかねえ…

HwConfigの定義はV1.7が最新のようだ。stringsをぱっと見て、
display panel関連に1440x1080とか6.8" Bottom EPDとかが増えている。
DisplaCtrlの部分に"MX6SL+TPS65185"のエントリ
メモリに"DDR3",CPU speedに"1.2G"が増えている…
まあHwConfigはntxのplatform共通ツールだからplatformとしては存在しているってことか。

u-bootはE606C0(dragon)以外のものはかわらず
kernelは
glo等従来製品(第四世代):r5845_#606→r6415_#610
E606C0:r6311_#1010→r6427_#1027
*前期型touch(第三世代)はkernel変わらずなので、後期型touch/glo/miniのみ影響

Qtは4.8.0ベースのままかわらず。
libnickelのsymbol見た限りではdragon***クラスが大量増加
(N5***かと思ったがそうではなくて、第四世代の中でUIだけ別設計っぽい)
libnickel自体かなり小さくなっている…半減近く縮んでいるなあ。

>>136

訂正。
Qtはベースバージョンは4.8.0のままだが、半分くらいは何か手が入っている。

*/usr/lib/変わらず
*busybox変わらず
*unrar変わらず

*driver moduleではntx508/g_file_storage.koが変わっている。
kernel patchのrev upで入ったbug-fixかな。

*Kobo/udevスクリプトはreboot時の画像表示まわりが少し変化

*/etc/init.d/upgrade-wifi.shはdragon対応でramsizeのパラメータをhwconfigから取るように修正

*/etc/init.d/rcSは/proc/shmmaxのkernelチューニング追加
デフォルト33554432を67108864に倍増

2.5.0来てますねえ。さって、久しぶりにリセットぶっこくかあ。

最近、リアルでえらいことになってるのでなかなかKoboがいぢれない。
bucchiさんのサンプルダウンロードしてubuntuPCに転送しているとこで終わってる。。

FWが2.5.0になって面白そうなのに、辛いなあ・・・

ファーム更新のたびにリセットしないで、それ用のSDを用意しておけばいいんじゃ
お試しSDは2GBのものにしておけば DD でのバックアップも短時間ですむし

2.5.0にしたら青点滅で起動しなくなりやがった。

仕方無いのでイメージ書き戻し。。。

ってゆーか、ハードウェアファクトリーリセットまでできないじゃん・・・

どーなってんの

Σ(ﾟДﾟ υ) 地雷ですか？

久しぶりに殻割ったら、電源ボタンのある隅が浮いたｗ

やべ、電源ボタン逝ったか？と思ってネジ外してチェックしたら・・・

問題なかったｗ　というよりこれは構造的に電源スイッチが利きにくくなるわけだ。
スイッチボタンは物理的に基板に接続されていないんだけど、よく見ると
電源スイッチがある右上部は、基板がネジ止めされてなく、ピンで差し込んでるだけ。

これじゃあ、殻割ったときに接触不良になる人が続出するわけだ。

教訓：割った殻を元に戻す前に、電源ボタンのある右上の基盤をしっかり差し込んでおけ

無事に2.5.0になった。ファクトリーリセット後にいきなり2.5.0をぶち込んだのが
悪かったのかな・・・。2.4.0にして、それから2.5.0にするとうまくいった。

うーむ、DB変わってるな・・・。ちなみにリリースノートは以下の三行

1.読みやすいレイアウトでEPUBを読むことができます
2.ストアが使いやすくなりました。
3.バグを修正しました

、、、本当かあ？ｗ

FWのDLリンクplz

ふうむ、フォント設定共通化は動かないな >2.5.0

現在修正中＋デフォルトで本棚アイコン組み込みちう

む、本棚アイコンが動かないな。検索アイコンは動くのだが。

DB周りの大きな変更点は、設定メニューから設定できる項目が
これまで/mnt/onboard/.kobo/配下のconfファイルに入れてたものが
データベースにテーブルとして設定されるようになったこと。

で、この設定テーブルの何と多いことか。気になる項目が山のよう。
全てはdragonへの布石なのか・・・。

しかし、さっきのリリースノート、嘘ばっかりじゃねーかｗ
epubのレイアウト？ ストアが使いやすい？　嘘こけ！ｗ

>>148
確認ありがとうございます。

え゛。本棚アイコン動かないですか。
解析できるかなぁ。tweaks pluginそのままだからなぁ。
前回は tweaks に助けてもらったから、今回はまじめに調べてみるか。

>>146
mobilereadに貼ってあった。
本当に日本でダウンロードされるものと同じかはわからないけど…

http://www.mobileread.com/forums/showpost.php?p=2159069&postcount=1

本棚アイコン続報

ホーム画面では全く効かず。CBZ読書中からだと効く。

センターズーム

問題なし

PassLockってUSB接続解除時にPass要求されない。

とりあえず2.5.0の各種確認終了。正式版じゃ明らかになさそうなので
正式版でもう一回検証しましょうかね。

あーあ、本当にリアルのごたごた片付けてKoboで遊びたいなあ・・・

>>152 (koboayaさん)
起動直後は効かないのは元々なのでOKです。
起動後、ホーム画面の「ライブラリ」メニューを押した後から
本棚アイコンが反応するようになれば、FW 2.4.0 と同じです。

# 一応、タイミングは要確認ながら、効くことがわかってちょっと安心しました。

>>bucchiさん

ライブラリを押しましたが効きません・・・

色々やったけどやっぱり本を読んでる最中しか効かないっぽい？

お互い、週末にのんびり修正しましょうｗ
Blogの復旧が終わってれば、ですけど・・・

一分勝手スリープは治ってるかもかも。

しかし、CFWと各種モジュールを入れた後の使い勝手が違いすぎて
我ながら笑えるｗ

あ、そうそう。bucchiさんのblogに書き込んでいた人がSQL関係に手を出したと
言ってるので、QtでDBを取り扱う環境の確立に一石投じてくれそうで大期待なのです。

独自本棚やるなら、最低で２階層化はしたいですねｗ

iosのkoboでgloの本棚全部表示されてる

最近touchを使い始めたのですが、「ホームボタンをページ送りに」が機能しません。
色々試して、余計な手順を省いたつもりの下記のパターンでもだめでした

1.ファクトリーリセット
2.sqliteをいじってアカウント認証パス
3.公式FW2.4.0に更新
4.CFW0.95適用
5.kobo_fwbtd_20120912.zipのnoscipt付のファイルをKoboRoot.tgzにリネームしてkoboの「.kobo」フォルダへ
　CFWの「Homeボタン変更〜」のextフォルダをkoboへ
6.USBを抜いたら更新中と表示されて再起動

これで、ホームボタンの機能が変わると思ったのですが、1回クリックでホーム画面に戻ってしまいます
何か必要な作業を漏らしているのでしょうか

ちなみにフォントでKBMinchoは確認できるのでCFWの適用は問題なく出来ていると思います

>>158
0.95には「ページ送りを割り当てるアプリ」の配布パッケージは同梱してないよ。
extに入れたのは、そのアプリ(ライブラリ？)を起動するためのデーモン、ええとつまり、設定ファイル。
(0.95のreadmeにパッケージされてない理由が書いてあった)

なので別途配布パッケージを入手してインストールしたら良いと思います。

>>158
ああ、ごめんなさい。
読み間違えてました。
インストール手順は問題なさそうですな。
再起動してみました？
デーモンが効いてないのかも。

このスレがサポート掲示板になっちゃダメだ。
不具合報告、動作検証までにとどめておくべき。

>>161
きゃああああああああああ (40歳・男性)

>>161
禿同

10時間以上書き込みが無かったら書いていいことにしよう
俺がわかることだったら暇つぶしで答えてやるよ

すみません。ここハックスレでしたね
FW2.4.0だと使えないということではないようなので、
ターミナル使って調べてみます
シェルコマンドなんて久しぶりだ…

お騒がせしました
原因はkoboCFW.confを.koboではなく/mnt/onboardに置いてました…
フォントが追加されていたのでてっきり機能として追加されていると思っていました

rcSAddでext\boot.shを呼んでいるのに実行されないのはCONFIG_FILEがない時か…
あ、パスが違う（赤面）
READMEを読み直したら、ちゃんと.koboの下って書いてある
お恥ずかしい限りの凡ミスでした

勘違いだったという報告も大切。恥ずかしかっただろうに、ありがとう。

[著者名] タイトル.cbz　のファイル突っ込んでも著者不明のまま本棚が作成されません。
原因わかる方います？

>>161
その通りだな
>>164 の言う様にあまりにも書き込みが少なければ、過疎化を防ぐ意味でも多少はいいと思うけど。

すみません、解決しました。

解決しました。　→情報量0

○○を変えたら、解決しました。
原因は○○でした。　→情報量0以上

現CFWユーザーが2.5.0でCFWを入れたい場合は
ファクトリーリセット→2.5.0にアップデート→CFWインストール
という順序でいいんでしょうか。

>>110
swap領域を512MBで作りなおしてみたけど４秒は変わらなかったよ。
なにが違うんだろうねえ？

>>173
わざわざありがとう。
となると何が問題なんだろ。
コンテンツなのかなあ。
今度、リセットしたら、細かく検証してみます。

.kepub.epub形式の文章読んでると時々2ページ進むようになったんだが他にこうなった人いる？
kobotouch
2.4.0
0.95+

最初の進むタッチで反応しなかった時、次のタッチで2ページ進んでしまう
もし反応しなかったら一度戻るタッチして(この場合は戻らない)、
再度進むタッチすると1ページ進む。

>>174
韓国製のmicroSD使ってるんでないの

>>176

0.95＋だとたまに同じ症状が出たので0.95に戻した。
.kepub.epubだけで無くcbzも同じ。
0.95だと出ない。

>>176 >>178

自分は
kobo glo
2.40
0.95
.kepub.epub
で同じ症状出ています。

cbzは確認してませんが。

それって0.95以前の昔からある症状じゃないの
少なくともオレはずーっとだよ

カスタム以前の話だろーな。
楽天に凸したことあるぜ。
まともな返事ないけどなw

昔からそうだから仕様だと思ってたw
読むには支障がないから、さほど気にしてないけど、
ストア購入本は頁数の記載が無いから、稀に頁が飛んでも気づかない時があって困る。

kobo aura HDレビュー
http://ebook.itmedia.co.jp/ebook/spv/1304/24/news038.html

ちょっと教えてください。

kobo glo
FW 2.40
CFW　0.95

この状態でkoboのオンラインストアから本を購入して、glo本体に転送したいのですが、
通常通りUSBで接続する方法で転送した場合、勝手にFW2.50にアップデートされてしまいますか？

現状で何も不満が無いので、ファクトリーリセット等せず、ただ購入したデータだけ転送したいのです。

>>184
勝手にはされないがうｐしないとデータ転送が出来なかったかな？
（ヴァージョンうｐして下さい云々の確認メッセージが最初に表示される）

あれ？もう出たの？2.5.0

>>183
ここのCFWさえ乗れば買うだろうな、俺は。

>>186
bugfixで2.5.1出てるみたい

2.5.1ただいま検証中

>>185

そうですか。
じゃあ、アップする必要がありそうですね。
ありがとうございました。

2.5.1、本当にただのBugFixだけくさいなあ。
日本で本当に正式版としてリリースされるかどうかは不明だけど、あのリリースノートじゃ
多分、これも様子見FWだろうな。

ちなみに、0.95も0.95Plusも2.5.xでは問題があります。

・フォント設定共通化機能が動かない
・本棚アイコンの動作がおかしい

2.5.1で、本棚アイコンが動作するようになったんだけど
今度は、標準のホームアイコンが本棚アイコンと同じ動きになってまったｗｗｗ
多分、クリック座標の問題なのかなと思われ。

dragonのHome画面変わってるなー。あれ次世代Nickelなんだろうか。
でも、TouchはおろかGloもあのホーム画面は厳しそうだ。

正式版2.5系はdragonの発売に併せて来そうだなー

オーバークロックはできない？

>>192
知らないけど、
そうゆうハックはできてないんじゃないのか？

電池の減りが早くなるだけだろ

>>194
だよねー。
サクサク動く代わりに四六時中充電に悩ませられるより、まったり長時間活用の方が電子書籍端末として役に立つ。
そう思って、readinglifeもwifiも常時チェック外して使ってるw

当たりコアだとクロック上げつつ電圧下げられる
クロック上げずに消費電力だけ下げるという使い方も
ま、そこまではまだ無理のようだけど

CPUの一般論だな
E-inkの一般論は、書き換え速度を早くするには電圧上げる必要がある
現状でバランスとれてると思うよ

書き換え速度にCPUがボトルネックになってるとは知らなんだ。
てっきりEinkの限界がボトルネックかと。

E-inkは速くならんのか・・・
それ以外でデータベースの処理とかCPU関係ないの？
メモリ周りがボトルネックなのかな

CPU強化してフラッシュを画素単位にして画面更新を高速化してほしい
全画面一律の書き換えは必要ないでしょ

>>200
そりゃhackレベルで済まない最適化がいるねw

>>201
FWでじゃなくて新機種で、てこと

それってarcだよね、という誘い受けに思える、、
結局、E-inkも液晶並のリフレッシュレートを求めると
液晶並に電力を消費して、モノクロで、MTTFも短くなる
液晶に対する優位性が無くなってしまうのです。それでブリヂストンは撤退した

e-inkの利点を殺すような方向の開発なんて無意味な気がするな。

動画が見られるようなリフレッシュレートとかは求めてないけど
koboブラウザのスクロール程度の追従性で、スクロール後の画面全体のフラッシュが無くなるくらいになればいいな、と
それぐらいCPUを働かせても、バックライト発光させるよりははるかに省電力じゃなかろか

2日ほど前にkobolabsにaura用のkernel,u-bootがあがったようだなあ＞hw/imx507-aura

相変わらず、新機種発売時にfirm公開はするものの、過去機種の最新ソースは放置っていう…

>>206

んー、ぱっと見u-bootは
・キーまわりにかなり手が入っている
・FrontLightの制御が入っている
・CPUのmax freq. 1GHz判定が変わっている
・esdの接続portが変わっている(?)
・ntx hwconfigのverupに伴う追加
・flash_header*.Sのram paramsは変化なし
あたりっぽいなあ。

なんかHWCONFIGにDisplay Bus Widthとかが増えていて8bit/16bit等指定できるようなので
aura HDでは解像度2倍をbus幅2倍(8bit→16bit)で対応してるのかな？
(pin設定等SoCの詳細まで見てないけど、その辺の影響でesdのportも変わったのか？)

現行機だけみるとCPUパワーというよりは
e-inkパネルの性能がボトルネックだと思うな。
書き換え要求を出してから完了するまでが遅い。
その間 CPU は遊んでるか別のことやってるから
CPUネックじゃないと思う。

その点、gloのパネルは解像度が高いのに
パネルの書き換えが早いので体感的にサクサクなんだと思う。

e-inkのwaveformをいじれれば書き換えも早くできたりするのかな？

ところで、Kobo Aura HD のハックはすぐに出来るものなのだろうか？

無知で申し訳ない。KoboのハックにはiPhoneの脱獄の様にセキュリティの穴が必要だったりするのかな。

ノーガード

ハックの前に、入手できないんだが。
手に入れた人いるの？

すみませんアドバイスをいただけないでしょうか？
CFWのインストールは完了したのですが、その後の認証回避がうまくいきません
extフォルダをコピーする場所がおかしいのかと思い色々試したのですが、何度試しても「koboへようこそ！」の画面になってしまいます
kobo gloです
よろしくおねがいします

こう言っては身も蓋もないけど、認証回避ってそんなに必要なこと？

>>212
アドバイスが必要なら、
行った事手順の詳細を全て書き出してみたらどうかな。
その質問だと、extフォルダは.koboフォルダの横に置いたら？ぐらいしか誰も答えられない。
言ってせいぜい再起動して見た？ぐらい。

>>214
ありがとうございます
extフォルダを置いた場所を順番に書き出します。
再起動は爪楊枝リセットで毎回おこなっています
１．.koboフォルダの横に置きました
２．.koboフォルダの中に置きました
３．.koboフォルダの中のkoboフォルダの中に置きました
４．１−３の場所にextフォルダ内のファイルを置きました（順番に）
以上です
いかがでしょうか？

>>215
なるほど。それで、
そのフォルダの中は空。とかいうオチだったりしませんか？

>>215
CFWのインストール要件は満たしてるんだろうな
公式FW2.3.1〜2.4.0が導入されている Kobo Glo

Auraも2.5.1もこないねえ
どこかで詰まってるのかな？

ところで、koboの会社は楽天が買収して子会社になったはずだが、何故アメリカの販売が最優先なんだろうか。
いや、それは需要から許されるとしても日本で向けに何のアナウンスも無いのはどういう事だ。
こんな扱い受けるとKindleにでも移りたくなってくるな。

自炊に向いてるからkoboを使用しているが、その辺りをKindleがカバーしたら間違いなくKindleに移りそうだ。

ローカライズは大変なんだよ
グダグダ言うならさっさとKindleに移ればいいだろ

　 　　　＿＿＿_
　 　　　／ノ 　 ヽ､_＼
　　　／（ ○）}liil{（○）＼ 楽天様が金を出したのにアメリカの販売が最優先なんて許せないお！
　 ／　　　 （__人__）　　　＼ 日本向けに何のアナウンスも無いのはどういう事だお！！
　 |　　　ヽ　|!!il|!|!l|　/　　　| もうKindle買うお！！ 本気だお！！

　 ＼　　　　|ｪｪｪｪ| 　 　 ／

　　　　　　　　　　　　　　　　　　　　　　　　＿＿＿
　　　　　　　　　　　　　　　　　　　　　　／　　 　 　＼　　　ﾁﾗｯ…
　　　　　　　　　　　　　　　　　　　　 ／　　⌒　　　⌒＼
　　　　　　　　　　　　　　　　　　　／　　　(●　）　（― ）＼
　　　　　　　　　　　　　　　　　　　|　　　 ::::⌒（__人__）⌒:::::|
　　　　　　　　　　　　　　　　　　　＼　　　　　　 ￣　 　　／
　　　　　　　　　　　　　　　　　/⌒ヽ　／ 　　　　⌒＼
　　　　　　　　　　　　　　　　｜　｜ `|　/　　　　／＼＼
　　　　　　　　　　　　　　　（　　　ﾉヽ |　|__　　＜　　 .|　|_
　　　　　　　　　　　　　ニニニニニ （＿(ニニニニニニニ
　　　　　　　　　　　　　｜|　｜|　｜|　｜|　｜|　｜|　｜|
　　 ／￣￣＼　　 .　　｜|　｜|　｜|　｜|　｜|　｜|　｜|
　／　　_ノ　　 ＼　 　 .｜|　｜|　｜|　｜|　｜|　｜|　｜|
　|　　 （ ●）（●）l　 　 .|｜ ｜|　｜|　｜|　｜|　｜|　｜|
.　|　　　 （__人__） |　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 |　　　　｀ ⌒´　|　
.　 |　　　　　　 　 } 　　早くKindle買えよ
.　 ヽ　　　　　 　 }　
　　 ヽ　　　　　ノ
　　　/　　　 く
　 　/　　　　　ヽ

>>220
6分かけてせっせと >>221 を作ってたと思うと笑えるな（笑）

どうしてSONY君はAmazonを装うんだろうね

>>222
このスレを見た時間がいつかという条件が抜け落ちているな

開発で使用してる言語版が最初になるのが普通だがなあ
金で頬叩くような話は醜いな（しかも楽天の金で219の金じゃない）

>>224
IDで投稿者を識別する能力（あるいは知識）が抜け落ちているな

やっぱりどうしても開発者の方のコメが無いと過疎るし余計な雑談から荒れ始めるな。

挙動がおかしくなり始めているような気がするのでメモリのバックアップを取ろうと思うのだが
現状をそのままバックアップ取って、別メモリに書き戻しても大丈夫なのだろうか？
最終的にはファクトリーリセット後にも取り直すけど、途中で逝ったら悲しいので…。

>>228
USB接続だとシステムのコピーは出来ないと思った。
新メモリへの書き戻しは、殻割してSDメモリコピー用のプログラムでHDDにイメージをコピーして
そのイメージを新microSDに書き戻さないと。

>>222
いや、なんか少し経ってから作りたくなったもんで…テヘ

今ｅｉｎｋで自炊用で一番いい端末は何かな

>>228
殻割りせずKoboをPCにUSB接続する前提の方法
1.KOBO_Readerパーテーションの中身をPCにコピー(全ファイル・全フォルダをバックアップ)
2.ファクトリーリセット
3.1で取ったバックアップをファクトリーリセット後のKOBO_Readerパーテーションに書き戻す
4..koboフォルダにVer2.4のファームウェアをコピー
5.バージョンアップと認証が終わり、本のデータもバックアップされたものになっている。
6.タイムゾーンと(必要なら)wi-fiの設定をして、念の為PCアプリなりwi-fiで同期を取る。
自分はこの方法でやっている。

フォルダ名間違えとった。
× KOBO_Reader
○ KOBOeReader
だったorz

2.5.2になってもまだ正式リリースじゃないんかい。
いったいどーなってんの。

正式リリースされにゃ、どーしようもできんだろーがっ

最近になって、このスレの存在を知ったのですが、koboaya氏のCFWは本体バージョンが2.5.1でも使用できるのでしょうか？
readmeには2.3.1-2.4.0となっているので不安なのですが・・・。

>>235
現状では不具合が出るそうだ。
このスレの140あたりに戻って読んで見るといい。

開発者さんなかなか出てきてくれないなぁ。
開発に疲れたなら、開発終了宣言して欲しい。

疲れたんじゃなく、2.5系が正式にならないとなかなか動けないわけですよｗ
arcの日本での販売も、よくわかんないしねえ。

開発終了宣言？自分がKoboで本を読んでる間は出したくねえなあｗ

そういう、端末だし

＃まあ、リアルでえらいドタバタあるのでなかなかKoboで本を読めないのも事実なんだが・・

>>238
このスレになって以降あまり動きがなかったので、不安になっていたのですが、そういう事情でしたか。
疲れているのではないかと、的外れな事を言ってしまい申し訳ありませんでした。

では新バージョンのリリースを、開発者さんの動きと合わせてに楽しみにしています！

>>237
3個上のレス

いつの間にかデスクトップアプリ3.2.2なり同期をしたらフォントが保持できずドキュメント デフォルトに

残り数GBになると安定しなくなるなあ
64GBのSDXC検討中

64中残り２GBで不安定です。たしかに

>>241
同じく

>>242
前に64GBSDのレポートがでてたが、
結局、ちゃんと使用できるのかな？

microSDXCってそもそも対応してるのかという問題が

>>246

CPU(SoC)としてはSDXC対応してないから、SDXCをSDXCとして本来仕様でフルに使うことは無理だけど、
アドレス空間64GBのSDHCのようなもの、として扱うことはできるんだろうから
論理的なソフトウェアのレベルとしては使えているんじゃないの。

最初にXCの書き込みがあって以降その手の話をみかけないところをみると、
消費電力や電気的特性等、ハード・システム上の問題も運用不可なほどにはなさそうだし。

残り容量すくないときの「不安定」って、どういう状態？
うちで発生したことがあるのは
・サムネールイメージを生成できない
・db書き込み時のテンポラリファイル生成が容量不足で失敗してnickel落ち(数百MBのレベルの残容量のとき)
あたりかな。
サムネールの問題は残容量の問題なのか、元イメージの大きさ(アプリの作業RAM量)の問題なのかはわからんが…

サムネイルの不具合は2.5.0以降にしてから起こらなくなった

64GB、今のところは快調です。
自炊CBZが1761冊で約40GB。
本棚は重くて使い物になりませんが、検索で補ってます。

>>248
赤ランプ点灯がわりと頻繁に出るようになった。
重い書籍を高速でめくると赤ランプとかね。

CFW 0.94β
2.4.0
内蔵32GB換装
外部SDも利用
でcbzファイルを読了しても
Reading Lifeの読書データの読んだ冊数に
反映されてないようですが、
koboから購入分のみ対象なのでしょうか？
それとも私の端末だけの問題でしょうか？

>251
kobo miniだけど16gで半分しか使ってないけど購入本を高速でめくると赤ランプ点くよ

>>250
羨ましいけど、32GB+32GBを買った今では
、簡単に64GB+64GBには変えられないのが悔しいなぁ。

>>252

cbzってそもそもreading lifeの対象だっけか？

>>253
あ、やっぱりそうなんか。
容量減るとその頻度が増す気もするけど、気のせいかな？

まあウチのgloはスクショも効かなかったりするんだが、ハズレなのかもしれん…。

>>256

空きメモリ量が絡んでアプリ落ちしてるなら有り得るんじゃないのかな。
大容量sdに大量に突っ込んで、アプリが管理しているコンテンツが増えると
DBを筆頭に諸々ワークメモリ増えて圧迫するわけだし。

メモリ不足は、swap作れば多少は持ち直すかも。

あと、DBのキャッシュを元に戻すとか（MAXにしても、そこまで大量に本を
突っ込んでるとキャッシュ不足になりかねんから）

ぉーい、何時になったら2.5系正式版になるんだー(ﾁﾝﾁﾝ

>>254
無理に64GB内蔵にする必要はないと思いますよ。
私の場合、自炊の文庫・新書をすべて持ち歩く狙いがあったので64GB化してみました。
タブレットで使ってた64GBを流用しただけなので追加コストがゼロでしたし　orz
64GBが一杯になったら外付けは32GBを使います。
まぁ、あと自炊作業が600冊ほど残っているのが頭痛いです。終わるまで地震こないでほしい...

アップデート回避で買った書籍をＤＬする方法って無いんですかね？

ダウングレードしたい
サクサク動作するメリットより
ライブラリに戻る機能のほうが無いと困る

32GBSDで運用してるけど、残り9GでKOBOデスクトップとシンクロできなくなった。
俺だけ？

え、2.5系列って、もう公式版きたの？

個人輸入したAura HDが届いたからSD換装しようと思ったけど、
作りがしっかりしてるから蓋が開かないわ…

そんな罠があるのか

いつ日本で出るんだろう？
今Glo2台持ってるけど、出たら即買うわ

gloの蓋も苦労したのにもっとカチンコチンなの？

glo触ったこと無いけどホント固い。
角を少し浮かせてからピックのようなものでこじ開けていこうとしたけどダメだった。

>>ID:j7c401tw

すっげぇ！Arc買ったんだ！惚れる！ｗ
超絶欲しいのに、未だ日本での発売予定アナウンスすら無いってどゆことよorz

by the way

構造が見えないんだけど、角さえ浮けばそこにクレカみたいな、ちょーっと硬めな
カードを挿して水平にスライドさせればカシメ構造ならすぐ外れると思うが、、、

Gloから電源スイッチの構造が変わってるから余程無茶しない限りは
基盤まで「逝かせる」ようなコトにはならないと思うけど、、

嗚呼、Arc欲しい。自炊した先月のNTの再開FSS、Gloでもキツイぜ・・・

>>269
ArcじゃなくてAura HDね。
ほんと、角が浮けば後はすぐ外れると思ってたんだけど…あてが外れたわ。

>>269
もう一度やってみたらどうにか外せた。
フロントパネル裏に粘着テープが貼ってあるせいで固く感じるみたい。
http://uploda.cc/img/img51a37bf163312.jpg
http://uploda.cc/img/img51a37e2b82200.jpg

>>271
画像キター！

>>271
サンディスクの4GＢに笑った。
やっぱり、こうやって改造するガジェットフリークのニーズも意識して作られてるのか、
それとも、コスト的にこうせざるを得ないのか
どうなんだろ

>>271
買いだな

>>271
おお、GJ
はめ込み位置がパネル寄りになってたから、殻割りできるか心配だったけど安心した
SDカードなのも確定だし、こりゃ買うしかない

内蔵も外付けも64GBを認識。上のほうで問題なく使ってる人がいるから大丈夫なはず。
http://uploda.cc/img/img51a3929647a5e.jpg
http://uploda.cc/img/img51a3929d2fc0c.jpg

ちなみにCPUはMCIMX507CVM1B、メモリはSAMSUNGの2GBでK4X2G323PD-8GD8。

個人輸入で買いたい人はindigo.caから買えるよ。カナダから発送で北海道まで9日で到着した。

でも、お高いんでしょう？

コミコミ2万ってところじゃね？
どっちにしろGloの2倍強だし俺は様子見だな・・・

>>276
glo解像度に変換したpngがどんな風に表示されるのか、気になります。

分解画像キターーーーーーーーーーーーーーーー！

・・・こ、今回も赤外線式なのかorz

いやあ、でもいいなあ。欲しいなあ。

>>278
送料込み209.63ドルだからそのくらい

>>279
画像を用意してくれたら試してみるよ

>>281
よろしくお願いします。
2枚ともS1500の自炊PDFからJPEG書き出し→ChainLPでglo最適化したpng画像です。

モノクロ　1024×728（600dpi）
http://s1.gazo.cc/up/54338.png

グレイスケール　1024×728（300dpi）
http://s1.gazo.cc/up/54339.png

>>282
コレで大丈夫？
http://uploda.cc/img/img51a61a0719c41.jpg
http://uploda.cc/img/img51a61a002e407.jpg

http://uploda.cc/img/img51a61a13dc2f5.jpg
http://uploda.cc/img/img51a61a0dcd8a4.jpg

もしかして補も優秀なのか？

glo用のデータに見えんな。美しい。

>>283
マンガは無いかい？

>>283お疲れです
279が同じ画像でAura最適化したものを出してくれるのがありがたい
1080x1440になるのかな

>>283
ありがとうございます！
いいですね。まったく違和感ないです。
aura HD用に再変換しなくても済みそうなので、安心しました。

>>287
了解。さっそくアップしておきました。
aura HDのパネル実解像度（1440x1080）にしてあります。

aura HD用モノクロ
http://s1.gazo.cc/up/54431.png

aura HD用グレースケール
http://s1.gazo.cc/up/54432.png

283さん、お手数ですが、また表示テストしていただいてもよろしいでしょうか？
よろしくお願いします。

↑
297じゃなくて、297です。
自分自身のレス番アンカー間違えた　orz

>>289
おちつけ

>>288
glo用よりもくっきり表示。
http://uploda.cc/img/img51a769a0bcae2.jpg
http://uploda.cc/img/img51a769975d469.jpg

http://uploda.cc/img/img51a76a67cde75.jpg
http://uploda.cc/img/img51a76a80d71b2.jpg

>>291
綺麗だな。スゴいな

うーん
2万弱なら、ネクサスでいいやって思ってたけど、内蔵SDとか、これみせられると迷うな

>>286
CLAYMORE20巻から。
余白が大きい漫画は余白カットで大体ジャンプ単行本サイズで表示できます。
ちなみにAuraの画面大きさは縦14cm * 横10.5cmです。
ただ、ここまできっちりカットできる作品も中々無いかな…

http://uploda.cc/img/img51a76d31881fe.jpg

こんばんわ
前回koboを文鎮化（本スレ４５冊目くらいだったかな）させてしまった者です。覚えてないかな・・・
最近またkoboを買い戻しました。
今回はしっかり勉強して、快適なkoboライフを送りたいと思っています。
質問とかするかもしれませんが、お願いします。

おはようございます、文鎮さん。

かつて文鎮

>>294
�dです。
やはり細かく見えるなあ。
欲しい・・・

>>291
ありがとうございます。
aura HDは素晴らしいですね。表示といい、内蔵SDといい
Eink端末では最高でしょう。
あとは日本で売り出されるかどうか　orz

310 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2013/06/01(土) 13:41:17.56 ID:CLZJwj+v [1/2]
>>305
ソースは伏せるが、今夜はauraの発表とそれに伴うキャンペーンのお知らせがあるよ。

auraの予約で先着順でプレゼントがあるから気になってるユーザーは要チェック。

>>300
信用ある有名サイトならともかく、2chでソース伏せた情報なんて全く信用ならんだろ。

いくら楽天が非常識な会社だからって
土曜の夜に発表はないわな

てすと

aura HDまだか

ここ最近の停滞具合は何事かと
HDうちも欲しいんだけどなぁ。。。まだかなぁ
Kobo Glo買って2週間しか経ってないけど
欲しい

2.6.1だと・・・・

/usr/local/Kobo/nickel -qws -skipFontLoad &

2.6.1のrcSより。

nickelなんつうオプション追加してんねん・・・

ﾜﾛﾀ
それ飛ばしてええんかｗｗｗ

うわ、2.6.1のHome画面別モンじゃん

本格的にaura HD前面に推しだしてきたな。

某所の情報によると、あっちこっちのライブラリに手が入ってるらしい。
libjpegが標準でturboになってるとかどうとか。

nickelの起動時オプションは、フォント設定が壊れる問題をようやく直したということか。
起動時にフォントをロードさせない・・・bucchiさんが当てたパッチそのまんまやん。

リリースノートが見つからない。一体どこにあんだ。

右上の設定アイコン関係は随分使いやすくなったな

また日本はおいてけぼりでつか

2.6.1のUI、個人的には前より好き。
流行りのフラットデザインを取り入れた？

それよりも、欧米の最新版Kobo Desktopを入れたら、日本語縦書き書籍が普通に開けたので驚いてしまった。表示はガタガタなので、まだ調整は必要そうだけど、PCで読めるようになるのもそう遠く無いと思う。

dragonの次はphoenixですかい。

gloが益々陳腐化していく・・・悲しい。

PCB=`ntx_hwconfig -s -p /dev/mmcblk0 PCB`
case $PCB in
E60610D*) echo trilogy;;
E606B*) echo kraken;;
E5061*) echo pixie;;
E606C*) echo dragon;;
E606F*) echo phoenix;;
*) echo trilogy;;
esac

http://i.imgur.com/B3BduDp.jpg
前より使いやすい

かなりサクサク

.koboに展開したものを入れると自動的にアップグレードされる
Aura, Glo, Mini, New Touch用
http://download.kobobooks.com/firmwares/kobo4/koborocks/kobo-update-2.6.1.zip

カ、カスタムファーム班の解析を待ちます！！

明るさ調節できるやんけ
http://i.imgur.com/5uZYYs8.jpg
http://i.imgur.com/jqkOPKW.jpg

結局2.5系はなかったことになったんですね。

なんとゆーか・・・・

正直、2.6.1はこのスレと某所のCopyRightを主張したくなるような感じだｗ

CFWの「最近読んでいる本棚」がホーム画面から一発でアクセスできるようになったのは
良い事なのか、悪いコトなのか・・・

＃ どうも、一番先頭の本棚をホーム画面に表示するようだ。その関係で「最近読んだ本棚」が
＃ 常時ホーム画面に表示される。でも、相変わらず中身を切り替えても内容のリフレッシュは
＃ 無いけれど。

I/Fはかなり良くなった感じだね。いい加減、日本で正式リリースすりゃいいのに。

>>318

完璧に「無かった」ことにするんだろうねｗ

新ファーム試してる人、本棚作成とかライブラリ検索で待たされるの改善された？

Mark 3 Hardware: Original Touch (N905, N905B Models)
old Touch用
http://download.kobobooks.com/firmwares/kobo3/koborocks/kobo-update-2.6.1.zip

>>320
かなり改善されてると思う

てか、cfw使ってるのとかわんないや

てか、cfw入れたら起動できなくなった
またファクトリーリセットからやり直しだ.....

>>315
New Touch　とは何ぞや？

>>324
N905C Model

最近久し振りにナンプレやろうとしたら、
下側の数字ボタンの数字が消えていたんだけど、
自分のところだけかなぁ。
使用機器はtouchでcfw0.95を使っています。
というか自分以外で同じ症状の人がいた場合、
ナンプレの需要って。。。

2.6.1入れたいけどbookの再DLめんどくせえ

>>321入れてみたけど
ホーム画面変わらないよ

>>328
zipバラして、中に入ってるKoboRoot.tgzを所定の場所に置いてるかー??

2.6.1 入れてみたけど、USBでの転送速度 早くなったよー

2.6.1 新ファーム、本棚が2つ出来たり、削除できなくなったりの不具合発生

>>329
所定の場所とかよくわからないけど
デバイス情報ではバージョン2.6.1になってるのでアップデートはできてると思う
何か設定するところあるの？

製造番号より、old Touch にて2.6.1を導入してみた。
ホーム画面は従来通りで変わらず、解像度が足りなくてgloと区別してんのか？

またしてもepub表示に大きな変化があり、自作の画像epubは全画面表示されず…悲。
ただ、ページ切り替え時の画面消去が無くなったため、
画面が真っ白になることはなくなった。

これにより、koboshopでDLできるコミックではうれしい変化があった。
画像１枚表示の通常epubにおいて、一枚ごとの画面消去が無くなったため
画像と画像の間の白画面が無くなりフラッシュしなくなった。
結果的に画像送りそのものはcbzに近いものとなっている。
（できるんなら、もっと早くやっとけよ！）
画像epubの１ページリフレッシュは相変わらずだが、かなり見やすくなったと思う。

あと、ライブラリ検索の立ち上がりの遅延は無くなり速くなったようだ。

まだ正式公開版ではないにしろ、
この流れでリリースだとまたサポートに苦情を出さなければならなくなりそうだヨ！

>>333
ふむ。古いTouchはホーム画面そのままってことか
ちょっと残念

2.6.1からついにTouch差別化か・・・。
解像度だけの問題なんだろうかいね。2.6.1をMiniに入れてみてどうなるか知りたいなあ。

＃ 個人的には、Miniは新ホーム画面になるんじゃないかと思ったり

CFWの検証、今回は流石に進んでいまへん。
某所の情報で、数え切れないくらいのモジュール変更が入ったとの情報があるので
ダメ文字回避なんかもチェックしたほうが良さそうなんで。

＃ 要するに、これまで有志で必死になって潰してきたバグを直してる可能性が大ということ

その前に、まず2.6.1を正式リリースしろとｗ

カスタムファーム入れている人が、261入れる時って、ファクトリーリセットした方が良いでしょうか？

ダメ文字とか、外部SDトラブルとかが解決されてるなら、2.6.1試してみたくなってきたなあ

自動本棚がある限り、CFWの進捗に全てを委ねます。頑張ってくだしゃ

miniに2.6.1入れてもホーム画面は変わらないですね。
2.6.1を適用すると購入本(小説等)の画像(表紙・挿絵・写真)が
白枠付きになって縮小表示されるのがmini使いにはツラい。
購入本でも画像のみのマンガは縮小されないのだが。

>>336
CFWを入れてるとアップデート出来ない。
認証や同期がめんどくさければPCでkoboereader内をバックアップしてからファクトリーリセット
→終わったらkoboereaderにバックアップ書き戻し+.koboフォルダに2.6.1アップデータを入れてUSBを外して終了。

2.6.0の国内版きたね。
CFWの対応が待ち遠しいよ。

ひー昨日FRかけて2.6.1にしたばかりなのに
国内版の2.6.0て…

2.6.0だと・・・・orz

もーいいや、ファクトリーリセットしよorz

ダメ文字問題直ってないやん。

そのくせdosfstoolだけは最新版になっちまってる・・・。またバイナリパッチが必要なのか？

こりゃあ、まいったな・・・

つかね
内蔵だけであきらめればよくね?
32+32Gだってどうせ足りねー足りねーって言ってんでしょ?
そういう人は1Tあったって足りない、じぶんの使い方を変えたほうがいいよ。

公式アップデート来たみたいですけど、2.6.0入れる際、
.confとか.images削除だけで十分でしょうか？
それとも、ファクトリーリセットしといたほうがいいのかな。

kobo gloスリープモードも変わったｗｗシンプル過ぎるｗ
今までのスリープモードのキャラ、勝手にkoboちゃんて呼んでるけど
あいつに名前はあるんだろうか

ごめん、間違えたｗ

本スレでナンプレ直ったと報告ありました。
とりあえず自分以外にも需要があってほっとしました。
スレ汚してしつれいしました。

auraに、ダウンしてきた2.6.1を手動で入れてみた。気づいた変化は以下のもの。

　・ホーム画面の「最終同期日時」が「13/06/11」のような半角表示だったのが
　　「６月１１日」と全角表示になった。

　・epubでのマンガの表示が、ヘッダ・フッタの常時表示が加わり縮小表示になった。
　 cbzでは全画面表示のまま。

これじゃepubで出力したマンガが見られたものじゃないが直し方もわからないので、工場出荷（2.5.2）に戻す。
近い将来auraが日本市場に導入されファームのバージョンアップがされるとこうなるのだろうか？
それとも日本ファームは修正されるのか。
参考まで。

まぁcbzで安定だな。
無理にePub化することにいよいよ価値が無い。

新ファームにjpg高速化って当てて大丈夫なのでしょうか？

>>352
様子を見た方が良いと思う。
標準でlibjpegがTurboになってるという話もあるし。

自作の画像epubで全画面表示出来ない問題が発生したんだが、
同じファイルを入れ直してみたら正常に戻った　…ような気がする。

ちょっと気づいたんだが、
USB転送後のコンテンツ処理に、なんかバグがひそんでいるような気がする。
なんだか挙動がおかしいことがある。
ファイル上書きもダメになったような気もする。

どれもこれも断言できないけど。

>>346
ねえ、だれか答えて・・・

>>355
>>340が言うように、ファクトリーリセットをかけた方がいいんじゃないか？

バカアヤ早くしろ
まったく使えねー奴だな

早く日本語ファイル名使えるようにしろ
キモいアニメーションなんかいらねーよ

cfw入り2.4.0を無線でUPしたら、SDの文字化けがでなかった。ターボjepgいれたらハング！ファクトリーリセットして2.6.0入れ直したらまた文字化けが…

>>359
gloです。

350だが、さっきauraをkoboデスクトップアプリに繋いだら同期されてファームがアップされた(2.6.1)。
やはりepub画像にはヘッダフッタが表示されてしまう。対策はなされてないようだ。

>>361
.kepub.epubにしてもダメ？

kobo Touch ＆gloは2.6.0のままだわん。

少し分かったこと。
先日先行して2.6.1を導入した際に、自作画像epubが全画面表示されずテキストモードで立ち上がる不具合を確認したが
翌日改めて公式公開の2.6.0にアップデートし直したあとは、上記の症状は出なくなったようだ。

つまり、画像epubが全画面表示されないのは2.6.1のバグであるといえるんじゃないかな？
auraの人、ご愁傷様です。

でも、もしかして、今後のアップデートでそのバグが引き継がれたらいやだなぁ。
公式公開されていないものに対してサポートにクレーム入れるわけにもいかないし…。

auraは海外版のだから2.6.1は公式でしょ？

>>346
当方 Kobo Touch 2.40 + CFW 0.95だが、2.6.0にアップデートできたよ。
ただ、本体更新中にフリーズしたので爪楊枝リセットしたけど、
再起動後、再び更新処理が走って無事に2.6.0になりました。

2.6.0にしたくないんだけど
PCに繋げてkoboデスクトップ起動したら勝手にアップデートされますか？

>>362
.kepub.epubにしています。
ＣＦＷ入れるか、auraに入れても大丈夫かなあ…。

とりあえず、dosfstoolのパッチ箇所を見つけないとなあ。

ダメ文字問題以外は、とりあえず動くようにはなった＞CFW on 2.6.0

アドオン系（パスロック、センターズーム、本棚アイコンなど）は未検証なり。

ダメ文字問題は、どーしてもパッチ箇所がわからなかったら最悪旧バージョン使うかｗ

ちなみに、bucchiさん開発の「フォント設定壊れ＆SDカードフリーズ問題回避モジュール」を
現在導入せずに様子見中。

おそらくnickelに追加されたオプションで、bucchiさんのモジュールと同じ結果になったんだと
思うが・・・。

とりあえず進捗報告でした

aura HDのCFW対応について・・・・

多分ですが、2.6.0対応のCFW（便宜上、0.96と呼称しますが）は本棚関係は動くと
思うのですが、いわゆるテーマ機能は微妙かも、です。
png2raw作者様の見解を知りたいところですな。

パスロックなどのアドオンモジュールは全く予測不能です。

ごぶさた。プロバイダー規制でまともに書き込めない今日この頃。

png2rawは、メモリ量の問題がなければ動くんじゃないかなあ。
(auraのメモリ量は結局従来製品と比べて倍量でいいの？確定情報求む)

toolchainの変更やらライブラリの変更に伴う影響を調査してないけど、
影響ありそうなら再コンパイルコースだなあ。

mng関連も似たようなものだけど、フレームレートがどうなるかは
動かしてみないと…って感じかな。

dosfsckやらzoomやらfilterやら、諸々2.6系対応に伴うネタはあるが…

あぼーん

>>324
オフィシャルサイトができてたよ
http://www.newtouch.co.jp/newtouch/index.html

意外とくせになる味があるよな

>>359
ファクトリーリセットして2.4.0入れ直してcfw,ターボjepg入れてUPdate、ダメ文字okターボも入ってる見たい。2.6.1まで出来た。

>>375
アップデートの時ハングする時があるけど爪楊枝でリセットボタンを押せば無問題。

>>376
LEDか赤の時ね

>>377
LEDが赤の時ね
誤字訂正

>>376
爪楊枝が中でボッキリ折れて取れなくなった件について

>>379
何処にどんな角度で刺した？

>>380
ホントはクリップ使ってる。

金属物は頻繁に使うとKoboちゃんが壊れちゃう＞＜

裏蓋開けりゃとれるだろ

さーお楽しみの週末が来たよー。
CFWはくるかなー。今回はキツイのかな？

こっちに書くべきだったわ

とりあえず２．６にVer0.95ぶっこんでみたら再起動エンドレスｗ
いろいろやってみるわ

ライトボタン押しつつクリップでリセット

むーdosfstoolのパッチ箇所が明らかに違う。うまくいかん・・・。

ダメ文字問題解消しないと、CFWの目的が達成できねーじゃないか。。。

どうせ手を入れるなら、シッカリ直してくれんとかなわんね。楽天らしいといえばらしいけど。
一年近くたっても体質は変わらんねぇ。

acro買ったが、のりづけのせいであけたとき画面にひび入った
gloと違ってSDカード交換しようとすると破損率高いと思う
再注文しました

>>389
ひえええ・・・
ご愁傷様でござる

>>389
あの両面邪魔だよな
俺ははがしちった

お、投稿できた
6/4にindigoにaura注文、6/10に届いた俺が通りますよ

届いてすぐ殻割り、32GBに換装
殻割りは慎重にしたほうがいいよ
ほんと、画面やら枠やら割りそうになる

FW は2.5.2のままでCFWを適用、ただいま書籍コピー中
起動アニメとかも解像度を合わせれば再生できた
自動本棚とかは問題なく使えてる
パスロックはなんとなく見合せ

acroでなくてauraだった

今度は換装せずに2.5のままでCFW入れて下のSDカードで管理かな

ここでgloの画面を割った俺が通りすぎますよ

殻割り考えてる人は、ちゃんとしたツールを準備したほうがいいよ
アマゾンで「iphone 工具」とかで検索すると出てくる300円くらいのでいいから

auraは割ったあとドライバーも必要なので、小さい＋ドライバーも準備しる！

gloを殻割りしようとして
JAL-WAONカードをへし折ったのが俺だ

今、日本国内では、「戦争」が勃発している。しかし、この「戦争」に気づいている人、
この「戦争」の恐ろしさに気づいている人はほとんどいないだろう。
なぜなら、この「戦争」は、長い年月をかけて、用意周到に、徐々に徐々に、仕掛けられたものであり、
これを「戦争」と（正しく）認識することは極めて困難だからである。

　もちろん、「女性専用車両」や「クオータ制」などの女性優遇策を目の当たりにして、
「今、日本で、おかしなことが起こっている」と察知している人はいる。しかし、まさか、それが「戦争」
だとは思っていないだろう。私・ドクター差別にしても、これが「戦争」だと自覚したのは、つい最近である。

　その「戦争」とは、「女性」対「男性」の戦いである。この「戦争」を仕掛けてきたのは「女性」であり、
「女性は差別されてきた」あるいは「女性は差別されている」などと称して、「聖戦」気取りで、際限のない「女権拡大」
を目指している。一方、男性にとって、この「戦争」は、自分たちの（当たり前の）権利を守る防衛戦である。

　ただし、相手は、「女性」だけではない。と言うか、本当の相手は、その裏にいる「似非フェミニスト軍団」
と「反日勢力」である。「似非フェミニスト軍団」が、「女性」をそそのかし、男性に戦争を仕掛けている、
それを「反日勢力」は（「棚からボタ餅」とばかり）利用しているのである。

　この「似非フェミニスト軍団」は、陰に隠れているのだが、実は、判別しやすい。彼らは、「女性の視点」とか、
「女性の目線」などという言葉を多用するので、すぐわかる。これらの言葉を聞いたら、「要注意」である。

　ところで、「似非フェミニスト軍団」は、どんどん、兵力を増強している。「女性学」という似非科学を用いて、
学生を洗脳し、毎年、多くの似非フェミニストを世に送り出している。政治家、官僚、マスコミ、裁判官、
検察官、弁護士、学校の先生、大企業の社員など、社会的に影響力のある職業に、多くの兵士を送り込んでいる。

しかも、厄介なのは、「クオータ制（女性枠）」などというインチキ制度を用いて、それらの兵士を増強しよう
としていることである。それらの兵士は、能力なんぞなくていい、能力なんぞ求めない。何しろ、
「似非フェミニスト軍団」にしてみれば、似非フェミニズムに洗脳された「頭数」が増えればいいだけだからである。

と言うことだから、「似非フェミニスト軍団」が、能力主義を否定する「クオータ制（女性枠）」に賛成する、
その導入を推進するのも頷ける。彼らには、はなから、「優秀な人材を採用する、登用する」なんて気は
サラサラないのである。むしろ、「能力のある男性」は、足手まとい、と言うか、「敵」なのである。

　この意味では、「似非フェミニスト軍団」は、「反日勢力」と利害が一致している。能力のある男性が蔑ろにされ、
能力のない女性が優遇される、これは、日本の弱体化に繋がるので、「反日勢力」にとって、好都合である。
しかも、この「戦争」によって、男性と女性がいがみ合うわけだから、直接、（「反日勢力」が）手を下さなくとも、
日本がどんどん自滅していく、反日勢力にとっては、さぞ、笑いが止まらないことだろう。

　「熱湯に投げ込まれたカエルはビックリして飛び出るが、水から徐々に温められたカエルは茹でられて
死んでしまう」と言われるが、今の日本は、まさに、その状態である。「聖戦」気取りで、際限のない「女権拡大」
を画策する連中の悪業に気づいて、早く手を打たないと日本は「一巻の終わり」である。
「反日勢力」に（完全に）乗っ取られてからでは、何をやっても、もう遅い。

　もし、あなたも、「今、内戦が起こっている」との認識をお持ちであれば、是非、私らの「戦い」
に参加していただきたい。この「戦い」は、むしろ、私ら（男性）にとっての「聖戦」である。
http://blogs.yahoo.co.jp/sabetsu5555/31617282.html

2.6用のCFW、楽しみに待ってます。
がんばってください。

同じく、一昨日届いたばかりで、まだ使いこなしてませんが
楽しみにしています。宜しくお願いします。

ところで、手書きメモや数独に「お試しアプリ」って
タイトルが付いていますが、お試しじゃないアプリもあるんですか？
カレンダーや時計をJAVAで書いてHTMLで実行している
人が居ますが、それ以外には見当たりません。
海外ではメモ帳アプリがありましたが。

javaが使えるなら、スケジュール帳とか、TODOとか
色々出来ると思うんですが。メリットないですかね？

そんなことが簡単に出切るなら、何よりも、ファイラーを作って欲しいな。
まぁそこまでゆとりと能力のある人は、なかなか現れないけど。

>>402
かえってファイラーのほうが難しいと思う。

アプリに関しては、作成に挑戦されている方も。
http://petit-noise.net/blog/kobo%E7%94%A8%E3%82%A2%E3%83%97%E3%83%AA%E4%BD%9C%E6%88%90-%E3%81%9D%E3%81%AE1/

hackスレの人かな？　これ見ると、カレンダーみたいに
表示させるだけのものなら行けそうだけど、それ以上は
現状なかなか大変そう。

あ、epubでカレンダー画面作って、テキスト選択して
メモ貼ればいいのか。呼び出しが面倒だな。

>>401
HTMLで実行ってJavaじゃなくてJavaScript？

>>405
これですね。HTML/javascript
http://zapanet.info/kobo/app_calendar.html

当月しか表示できないけど、月送りのボタンが実装できれば
それなりに使えると思われ。
軽量・大画面なので、スケジュール帳は需要ありそう。
俺はスクリプト書けないけど、誰かつくれませんかねえ？

2.6に現在のCFW適用できます？

>>407
出来ないと思う
>>385

>>407
ファクトリーリセットしか受け付けなくなりまふ。

おひさしぶりです。

しばらくぶりにここのぞいたら 2.6.0 でてるとのことだったので
週末に入れてみました。

日本版 fw 2.6.0 の url は以下みたい。

http://download.kobobooks.com/firmwares/kobo3/rakutenrocks/kobo-update-2.6.0.zip for (old?) touch

http://download.kobobooks.com/firmwares/kobo4/rakutenrocks/kobo-update-2.6.0.zip for glo

軽くlibnickel.so 覗いたら thumb コードになってた。
どうりでサイズが小さくなったわけだ。
thumb のコードは慣れてないから追うの面倒だなー

ストア本一冊丸ごと連番SS保存なんて無理ですかねー

てす

同じくThumb命令セットには慣れてないので面倒感が…(笑)

###

fsckがらみのダメ文字はなんとかしたほうがいいだろうから、
linaroのtoolchainでオリジナルをコンパイルしてみて
compile-timeみたいな避けがたい差異は除外して実質的に同一バイナリができるのが確認できるようなら
invalid charsのチェックしている部分だけ修正したバイナリを作ってみるかなあ。
(これまでのバイナリパッチと同レベルな保守的なスタンス)
#アグレッシブなスタンスのパッケージなら最新安定版をもってくるんだろうけど

####

ついでに、某所のダメ文字に関する推察にこっちでコメント
日本語部分をbase64ライクにエンコードしてるのは当該rubyのスクリプトが
fsckがらみ(+mountがらみ)のダメ文字対策としてそうしてるっていうだけじゃないかしらん？
nickel(koboのオリジナル環境)そのものには関係ない話。

cbzじゃなくてepubベースで運用してるなら、ファイル名それ自体にはあまり意味がないだろうし。
(cbzでも自前でdb内のcontent title等を後から書き換えるようにしてしまえば同様なんだろうけど…)

2.6用のCFW欲しい

その前にauraが欲しい。日本では売らないのかな。

2.6に自動アップデートされてしまったので
β版でいいので2.6用のCFW欲しいです

ダメ文字関連でちょっとした発見(あまり役に立つ話ではない)
Kobo内というかLinuxから日本語を含むファイルをFAT fsに作ったとき、
SFNは"____~1.txt"みたいなものになり、これはオリジナル版のdosfsckでもエラーにならない。

#FAT fsにSFNについてのencoding情報が仕様上ないので、UTF8から何に変換すればいいか決められないため、
#暗黙にcp437だとした変換をして、全部変換不能文字扱いで"_"になるんだろうなあ。

PC接続でwindowsから日本語ファイル名を使った場合だけなんだなあ。
8+3のSFNを生成しない設定がボリューム毎にできるはずのWindows7以降なら、PC側で回避できそうな気もするが…
"fsutil 8dot3name"関連ってNTFS以外のFAT系でも使えるのかなあ？

>>417

"暗黙にcp437"というかmountしたときのcodepage設定次第が正しいか。

###

で、dosfsckがらみで分かったこと。

-------------------------------------------
[3.0.6(Koboで使われている版)]
SFNに"ポ","ソ"系ダメ文字が出現するとき、SFNがbad_nameと判定される。
bad_nameのとき、SFNに対して"FSCK%d.%d"なauto-renameが行われる
この時LFN側との対応付けに関する配慮がないため、LFN側エントリがSFNエントリを見失う。
そのため、エントリとしてはSFNのみの"FSCK%d.%d"な名前のファイルがあるように見える

[3.0.10以降]
ポソ系ダメ文字を含むSFNがbad_nameと判定されるのは変わらず。
bad_nameのとき、SFNに対して"FSCK%d.%d"なauto-renameが行われるのも変わらず
ただし、この時、LFN側エントリへの配慮がなされたため、
SFN:"FSCK%d.%d" → LFN:"ソリティア"
という対応関係で、SFN側は元の名前が消えるがLFNは正常に元の名前が残る状態になる。
※LFN非対応な環境から覗くとやはり"FSCK%d.%d"にrenameされてしまったように見えるわけだが、
　2013年現在、実質そんな環境は想定しないでいいだろうから、支障はない
-------------------------------------------
※SFNとLFNの対応付けへの配慮とは、LFNエントリ側にあるSFNエントリチェックサム値の更新作業
-------------------------------------------

ってなわけで、3.0.6ベースでやるなら
1)バイナリパッチ(アドレスが変わるだけ)
2)バイナリパッチ相当のことをソースで行い自前バイナリを作る
3)どうせソースコンパイルするなら3.0.10以降のlfn_fix_checksum()処理部分をバックポート
*)そこまでするなら3.0.10以降の安定板でもいい、という話になるが…どれが実績として安定板といえるのか？

ま、至急に対応するなら1)になるわけだが…

期待してるぜ
仕事遅い上にキモヲタのボコアヤは用済みかw

>>418

一応(1)のバイナリパッチ版は情報出しておくことにする。
(まだ未検証だけど、文字列部分の書き換えだけだから問題が出るとも思えないし)

*日本版2.6.0内のものが対象(N905B(旧型Touch)用のKoboRoot.tgz内バイナリを使ったがglo用でも同じだと思われる)
MD5 (dosfsck.original) = 1f86fb3cce29d73e479acb4b6d293fa8
MD5 (dosfsck.patched) = 69e2baf430f3706931a9633e2b9a8095
-----------------
000072FC: 7C 22
000072FD: 22 2F
000072FE: 5C 3A
000072FF: 2F 00
00007300: 3A 00
-----------------
以前のものにあたっていたもう一か所はfile_cvt()の中だと思われ、
それ関数はコマンドラインからのdrop等のファイル名指定 or インタラクティブモードでのrenameで入力されたファイル名
の正規化でしか使われないため、Koboでの"dosfsck -a -w"運用では不要と判断し、未patch

###
package作る気はないので、telnetで入って突っ込むなり、自前でpackage作るなり、お好きにどうぞ。
2.6.0ではinetd.confが更新されるようだから。そこをtelnet有効化に上書きしなおすパッケージ作らないと中に入れないため、
いずれにせよ、一度はKoboRoot.tgzを作る必要があるだろうけど。

ビルダーボコアヤ仕事しろ

仕事しろ　＝　本業に専念してCFWは暇な時でいいです

ようやく光明が！ktkr

俺みたいに勝手に2.6にアップデートされてしまった人多いと思う
CFWが公開されるまでkoboで読む気にはなれない

dosfsckがらみのつれづれメモ

1)3.0.10以降の方式の場合、LFN-SFN間のネーミング変換ルールには外れてしまうので、
diskチェックツールによっては異常とみなされる可能性があるかも？

本来は、「SFN単独のエントリ」と「LFNに対応するSFNエントリー」でbad_name判定を変えるべきで、
実際にカーネルのVFAT fsでは、少なくともファイル名生成関連の関数コメントで
SFN単体/LFNと関連するSFN(SFNが"foo.bar"でfoo部分に"~num"なし)/LFNと関連するSFN("foo~1.bar"形式)
という場合分けで、それぞれについてSFNの構成文字(許容される文字)も異なるとしているようだ。

2)OEM CPを前提にした単体SFNが(Shift_JISについては)bad_name扱いになりつぶれてしまうことには変わりないので
　場合によっては問題が残る…

WindowsでのLFN省略(SFNのみとなる)ルール上は(0x80以上の)拡張文字があれば
常にLFNが生成されるようなので現実には支障ないが、
LFN非対応だがShift_JIS日本語対応な組み込み機器なんかと外部sdメディア共有していると問題があるのかもしれない。
Koboに挿入してdosfsckされることで、
組み込み機器側で生成した単体SFNファイル"ダメポ.mp3"をFSCK000.000みたいに変更されてしまうわけだから。

3)3.0.10〜3.0.20のどこかの版で"-c <codepage>"なオプションが追加されたが、これは
インタラクティブモードでのSFN表示の変換に使われるだけで、bad_nameでは機能しない。

4)NTになって拡張利用されるようになったDIR EntryのNTResフィールドに対して、
独自にSFN生成抑制フラグ(0x20)を割り当てるkernel patchがある(かつてあった？)ようで、
これの場合filenameの構成文字が何であってもbad_name()は常に0(bad nameではない)を返す。
(bad_name回避に利用できないかと一瞬思ったが、使えそうにない)

※NTResは例えば"foo.txt"をSFN:"FOO.TXT"(NTRes:本体部全小文字flag=1,拡張子部全小文字flag=1)
　とするために使われていて、lower case flagの2bit以外はreservedな状態。

##

SFN-LFN対応を維持したままSFN側がauto-renameされる3.0.10以降の方式と
bad_char()パッチでShift_JISでrenameされないようにする現行パッチ方式の比較で、
どっちがマシなのか微妙なとこだなあ。

FW 2.6.0のtoolschain関連メモ

*2.6.0は基本的にlinaroの2013.04版toolchain(gcc-4.8)でコンパイルされている
*一部(タイムスタンプが5/1等少し古いもの)についてはlinaroの2013.04版toolchain(gcc-4.7)の場合あり(dosfsck等)
*更にepdc_test等元々freescale由来のものはfreescale提供のtoolchain(gcc-4.4.4)のままで再コンパイルしているっぽい
*未更新のものは従来通りCodeSourceryのtoolchain(Sourcery G++ Lite 2010q1-202: gcc-4.4.1)と前記freescaleのもの(これは残っているかどうか未確認)
*ntx_hwconfigのようなものは特殊

#dosfsckをlineo toolchainでコンパイルしていて、4.7と4.8混在状況に気づいた

んー、toolchainのバージョン合わせたのにdosfsckで同一サイズのバイナリができねーと思ったら、
dosfsckのMakefileでLFS support関連の情報を取るのに
$(shell getconf LFS_CFLAGS)
とかしてるよ。

クロスの場合は明示的に指定するとかしないと、32bit環境でクロスコンパイルした時と
64bit環境でクロスコンパイルしたときでコンパイルオプションが変わってくるやん。
host側のconfを見ても意味がないので、本来なら素のMakefileを使わずに
Kobo build用にMakefileへのpatchを入れておくべきだなあ。

多分、Koboの開発は32bitでやっているだろうから、
ホストのgetconf LFS_CFLAGSで"-D_FILE_OFFSET_BITS=64"が返ってきて、
open64()あたりが使われるコードになる。

64bitホストでコンパイルしてるもんだからホストのgetconf LFS_CFLAGSは""を返して(nativeに64bitだから)
なんかopen64()が使われない、少し小さいバイナリが出来ていた。

#64bit環境でKobo関連buildするときは色々とトラップがあるなあ

>>427

ろだにdosfsckのパッチ関連まとめたものを上げておいた。
(ソースパッチとバイナリパッチの生成バイナリの比較等)

zip内のpatch版dosfsckの使い道はお好きに。
比較用のオリジナルと(実質)同一性チェック用の自前build以外の、
patch3種(binaryレベル1種/sourceレベル2種)は全部ダメ文字回避の目的を果たす同一機能

以下、zipファイルに入れ忘れたpatchの実態
#################
## dosfstools-3.0.6/Makefileへのパッチ
## 64bit build-hostで支障なく、Koboオリジナルリリース版と
## 同一設定(確証はないが実質同一バイナリは確認済)でbuildするためのパッチ
## 単にコメント行を活かすように入れ替えるだけ
@@ -24,8 +24,8 @@
DOCDIR = $(PREFIX)/share/doc
MANDIR = $(PREFIX)/share/man

-#OPTFLAGS = -O2 -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-OPTFLAGS = -O2 -fomit-frame-pointer $(shell getconf LFS_CFLAGS)
+OPTFLAGS = -O2 -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
+#OPTFLAGS = -O2 -fomit-frame-pointer $(shell getconf LFS_CFLAGS)
#WARNFLAGS = -Wall -pedantic -std=c99
WARNFLAGS = -Wall
DEBUGFLAGS = -g

#################
## dosfstools-3.0.6/src/check.cへのパッチ
## 文字列を"*?<>\"/:::"にしてあるのは生成コードをなるべくオリジナルと同一にする目的。
## 格別そういう意図がなければ"*?<>\"/:"でいい
## バイナリパッチは"*?<>\"/:\0\0"にした状態に相当(ただしこれだと生成バイナリの文字列配置が変化する)
@@ -253,7 +253,7 @@
static int bad_name(DOS_FILE *file)
{
int i, spc, suspicious = 0;
- char *bad_chars = atari_format ? "*?\\/:" : "*?<>|\"\\/:";
+ char *bad_chars = atari_format ? "*?\\/:" : "*?<>\"/:::"; /* patch for cp932(Shift_JIS) */
unsigned char *name = file->dir_ent.name;

/* Do not complain about (and auto-correct) the extended attribute files

#################

本業忙しくて何もできねー

いやん

ばかん

うふん

そこは

CFWユーザではないのですが、patchのみ使用させて貰ってました。
SDカードに入れてる自炊本の日本語表記だけをしたかったので
本当にありがたく使わせてもらってました。

2.6対応のpatchもお願いします。

●ポ・ソ系ダメ文字fixは一応KoboRoot.tgzを作ってあげてみた(動作は未検証)

●外部sd文字化け=mountオプションが足りない問題は相変わらずだと思うが、従来通りの対応でいけるはず
inittabは更新されていないのでCFW入れていて、
その環境から2.6にアップグレードしていれば、rcS2の自動patchが効くはず

2.6.0入れるのにファクトリーリセットしなきゃいけなくなった人は後者の自動patch機能が消えるから、
別途それだけを対応するパッケージがいるのかな。

勝手に2.6がインストールされてしまったのでファクトリーリセットして放置
2.6用のCFW待ちです

フォルダに入れた自炊本が自動で本棚登録される機能が便利すぎて、
CFWがないとkoboを使う気になれません

うっわ・・・やられた。コマンドラインsqlite3が動かないわ。

流石にこればっかりはLinux初心者の俺じゃ手が出せない・・・

なんでよ、2.5.xの頃は全然動いてたのに・・・・・

・・・バイナリ探さないといけないのか・・・

>>439

Debianのarmhf版から構築すればいけると思うなり。
SIDだとsqlite3+libsqlite3+libncurses+libreadline+libtinfo
くらいで動くと思われ。
(というかそれで今コマンドラインsqlite3起動までは確認した)

Wi-Fi切ってて同期しない俺は勝ち組
でも、最近買った本が読めない。
積み本も沢山あるんで、崩して待ってます

お仕事合っての趣味なので気長に待ってますので
無理せず頑張って下さい

png2rawはlibpngのバージョンがあがってバージョン違いでlibをロードできないようなので、こいつはコンパイルしなおしかな。
(旧版のpng2raw-static-12はlib変更の影響をうけないstatic版なので動く)

fbmngplayはlibmngが問題なく、libmng->libpngはlibmngが管理しているのでOk

###

んー、2.6.0で更新されたファイルを眺めていて気付いた。(2.5.*は見ていないので、2.4.*→2.6.0での変化)

なんかlibxsltが入っているなあ。どうもFictionBookとかいうフォーマットがらみの対応で、
xslt変換が必要になったっぽいのかな？(/usr/local/Kobo/fb2.xsl.gzが関連する)
(直接日本のユーザーには関係しない機能追加なんだろうけどね)

xsltがらみのコマンド(xsltproc)を突っ込めばcbz内に入れたopfから情報を抜き出してdbへ反映とか
shellベースでできるので、xsltのお勉強中。

>>440

一応抜き出して依存libも含めてまとめてみたのをろだにあげておいた。
従来のものが置かれていたdir位置をそのまま引き継いでいるため、/bin,/usr/libになっている。
(標準的な配置に変更しようかとも思ったんだが、
既存CFWを引き継いだ状態からだと旧ファイルcleanupの手間が増える気がするので…)

##

libxsltはやはりlibxmlと同じくwithout debugでコンパイルされているらしく、
debian既存のxsltproc(debugありのlib前提)では素直には動かせないようだ。
(symbol lookupだけの問題ならpreload等で回避可能かな)
#依存ライブラリはlibexslt,libgcrypt,libgpgあたりの追加が必要だった

>>png2raw作者様

ありがたやありがたや・・・・（涙

たちまち、本棚やらフォント設定共通化やらは全て動作しました。

助かりました＞png2raw作者様

fbmngplay、png2rawの動作も確認。ようやく0.94の頃くらいの動きになったのですが
bucchiさんのhookモジュールをPRELOADするとnickelが死にます。
なので、コンテンツ処理に連動したデータ処理ができなかった0.94相当の動作ということです。

やっぱり今回は一筋縄じゃいかないねえ・・・

とりあえずのβ、激しくキボー。
0.94相当で結構でつ。
自炊グタグタで泣いてます。

>>445

おお、よかったよかった。コマンドライン機動までしか確認してなかったので(どうせ依存libの関係とかABI不整合とかだけだろうから)、
本当にdbにアクセスして正常に動くか少しだけ不安だったんだよね(笑)

以前のもののバージョン見てないけど、sidから抜いてまとめたのは3.7.17っす。
>3.7.17 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668
bug-fix等致命的にやばそうな問題の修正updateが出てないか、
たまにpackageのupdateを監視する必要あるかもねえ。

##

libxsltの問題はxsltprocのソースをみると、どうもlibxml2のほうとのconfigure option不整合の問題っぽいなあ。
結構libxml2のdebugXMLがらみを使ってるツールがあるらしくて、普通は--with-debugでconfigするみたいで、
dbianやらubuntuやら普通のリリースはそのconfigure設定を前提に、付属ツール等もコンパイルしている。
(libxml2の--with-debugは普通の感覚のdebug-build/release-buildとは少し意味合いが違う)
Koboの場合、無駄に--without-debugでconfigしてるために、困ったことになっているようだ。

libxml2をre-compileすっかなーと思いつつも、xsltprocでlibxmlのdebugXML関連APIは
--debugオプション使ったときだけ使われて、その他の場合は全く使用しない様子なので、
実使用上問題になるのはld時のシンボル名解決だけだからLD_PRELOADで回避してみる作業中。

opf->著者名等の抜出スタイルシートは適当に簡易版を作ったので、
1)cbz/cbr内に*.opfがあったらそれを展開
2)xmlprocで情報抜出
3)dbに反映
という一連の作業スクリプトが作れる道具がやっとそろうかなあ。
**抜き出しxsltが「簡易版」なのは、opf仕様を見ずに１サンプルから適当に仕様類推してるだけだからなんだけどね

#xsltprocが動くとこまで確認できたらpng2rawなんかの2.6.*環境対応メンテする予定

ワクテカしてきた！！
転送に時間かかるので、事前に手動でバージョン上げちやおうかな

>>445

hook前提にしたものだとnickelの内部構造が劇的に変わると使えなくなるのがつらいねえ。

###

dosfsckがらみってやっぱ悩ましい。

*ダメ文字とみなさなくする方式(現行)
○Windows側のネーミングルールと整合したままなので、
　どんな機器でメディアを見ても問題が生じる可能性が低い
×Koboのバージョンアップでオリジナル版に上書きされるため、
　バージョンアップ再起動のタイミングでrcSからdosfsck(上書きされたオリジナル版)がかかり、
　ダメ文字ファイルが壊れる

*3.0.10以降の方式(auto-renameはするがSFN-LFNの関係は維持)
○一度ダメ文字判定され、auto-renameがかかると、そのエントリのSFNは不正ではなくなるため、
　アップデート時のオリジナル版への上書きでも問題が生じない
×SFN-LFNの関係は維持するものの、LFN-SFNのネーミングルールはWidnowsのルールから逸脱する
　非LFN対応環境で見ると"FSCK000.000"な名前に見えてしまう(今時レアな環境だろうから、実質的には気分の問題？)

**バイナリパッチ方式の場合、udev/usbとrcSのKoboRoot.tgz(Kobo.tgzも)展開後に(reboot前に)
　patch版を戻しなおすような仕掛けをしておいたほうがいいのかもしれない。
#例えばrm /bin/dosfsck; ln -s /opt/cfw/bin/dosfsck /bin/dosfsckみたいな感じで
#安全なところに置いたパッチ版をもってくる

>>447

とりあえずdebugXML関連ダミーシンボルのpreloadでxsltprocが動くことは確認できた。

>root@(none) ~]# LD_PRELOAD=/opt/test/lib/libxml2FakeDebugXML.so /opt/test/bin/xsltproc test.xsl test.opf
>Warning: program compiled against libxml 208 using older 207
>compilation error: file test.xsl line 11 element stylesheet
>xsl:version: only 1.0 features are supported

ってな感じ。
libxmlとの間のバージョン不整合があるが、まあ、機能としては動いているので、致命的でなければよしとするか。

test.xslでエラーが出ているのはxslt 2.0で書いていた名前空間宣言部分で出ているだけで、
本体を1.0仕様で書いてあれば問題なく出力された。

dosfstoolは４を採用。
2.5.0で改変されたフォント設定共通化も対応。
本棚関係はほぼ完全動作。
SDカード文字化けは当然修正。
Kobo明朝、なんとなく以前より綺麗なｷｶﾞｽ。フラシーボ？

Bucchiさんのモジュールが動かないので

・スリープ画面と電源OFF画面の挿げ替え
・コンテンツ処理終了と同時にページ送りの補正や本棚の自動生成

この辺りが動かない。

・パスロック
・センターズーム
・本棚＋検索アイコン

これらが未検証。ってな状態でごわす

>>451

センターズームはlibcb.so内部のクラスメンバー変数配置次第だからコンパイルしなおしだけだと動かないだろうなあ。

1)読書開始時の自動回転抑制
→内部構造には依存しない。ctorとsetOrientation()があまり変化がなければ修正は不要だと予想
2)センターズーム
→内部を直接いじっているので解析しなおし(2.3.*→2.4.*でも変数offset変わった前科があるので、解析必須だろう)
3)8bit(paleete/grayscale)pngガンマ補正
→hookしているのがxxxArchive:data()の画像データ取得メソッドだけなので、そのあたりは変化なしで修正不要と予想。

>>450

opfを調べてみたものの、シリーズ名やらサブタイトルやらはmetadataとしては定義されないのか。
ストア本のopfも、著者名・タイトル・出版社名・日時あたりだけってのがほとんどで、
descriptionは入れてないようだから、ストア梵は基本的に購入時・同期時にストア側から送られてくる情報をDBに突っ込んでいるのかな。

うーむ、自炊本にdescriptionを入れるのはopf仕様だけでできるようだが、
ライブラリ・本棚のlist表示で直接見えない部分だから実用的なメリットが乏しく、
自炊蔵書管理をきっちりしたいという整理ニーズの自己満足だけだなあ。

list表示で目にすることも多く実用性のあるシリーズ名と巻数は独自metadataじゃないと対応できない…

自炊本の情報管理に使えそうな一般的な(野良仕様・特定蔵書管理アプリ仕様じゃない)metadata仕様ってないのかなあ。

>>452

text2fbはversion 0.13だとSeg.fault or Illegal instructionで落ちるっぽいなあ。
途中まで動いているから、freetype経由でフォントをあれこれしようとするあたりで死んでるのかな？
(UTF-8とunicode(WCHAR)の変換でiconvもリンクしてるからそっちかもしれない)

こいつも2.6.*対応で再コンパイル(場合によっては修正)が必要ってことね。

CFWも容易じゃないんだね…

libcbは大体これまで通りのクラス構造・制御の流れで、センターズームはアドレスずれの修正くらいで済みそうだなあ。
(ちょい見たことがないメソッド名があったような気がするが、hackには関係ないところなので放置)

unrar経由で書庫内エントリ名情報を取ることに起因する、cbrのエントリ名文字化けも多分そのまま。
1)unrar側の問題(UTF-8ファイル名非対応な設定の問題)
2)libcb側の問題(subprocess(unrar)から出力されるtextのencodingの扱いがデフォルトのiso8859-1)
両方が関係するが、少なくとも2)については状況は変わらず。
1)は確認していないが、受け手の2)が対応していないのだから、1)も対応してるとも思えない。

** unrarのwrapperによる対策は有効なはず
** (ハートマーク等UNICODEでしか規定されない文字を含む書庫内エントリについての制約も残存)

>>456

昨日ちらっと見た限りでは、libcbは大枠変わらず、
ABI変更(HF化)に伴うアライメントズレが原因で
メンバー変数offsetズレが発生しているだけっていう感じみたい。

*HF化以前
doubleをロード・ストアするとき常に整数レジスタを経由するので、
機能としてVFP-mem間のメモリアクセスでも
コードとしては整数レジスタ-memになっていた。
これは、コードとしてはオーバーヘッドが大きいが、
メモリアクセスのアライメントは整数レジスタ幅の32bit(4byte)で済む

*HF化以降(FW 2.6.*)
doubleは直接VFP-mem間でロード・ストアするため、
無駄な整数レジスタを使った中継コードがない。
(整数レジスタの局所的な自由度が上がるため、周辺コードの最適化も進む)
ただし、VFPのメモリアクセスはunalinedだとペナルティがある。
そのペナルティを避けるため、普通は8byteにalign配置する。
(ズレ問題に関係ないが関数引数や戻値なんかも直接VFPレジスタが使われるので効率化する)

この結果、以前+0x7c等unlined 8なアドレスだったdouble変数が
+0x80等align 8に配置されるようになり、offsetズレが発生している。

libcbのComicsReaderクラスでは2か所ほどoffsetズレがあるが、少なくとも１か所はこれ。
もう一か所は継承元PanningViewMixin側のメンバー変数だから内部までは見てないけど、
doubleのalignmentが絡んでるんじゃないかなと予想(hackに関係しないので未調査)。

フォントや画面まわりの一部など、実数(double)を内部でメンバー変数として持っていそうクラスあるいは
Qt側のその手のクラスをポインタじゃなくて実体としてメンバーに持っていれば
HF化の影響でのoffsetズレがある可能性が高い。

#text2fbのfreetypeとの間の問題は、これとは関係ないかもなあ。
#たしか記憶だとFTの実数は固定小数点でやってたはずなので、
#VFPレジスタ渡しには関係しないし。
#どっかdouble渡しするAPI使ってたかなあ…

>>450

ああ、今更ながら…

jpeg→joegturboみたいな実メリットがlibxml差し替えの場合殆どないから
オリジナルFW libxml(debugXML無)→差し替え libxml(debugXML付)
までするのはやりすぎだろうけど、
どうせLD_PRELOADするなら、debugXML付の既存lib(debianの等)をpreloadするほうが、
xmlprocとlibxml間のバージョン不整合もないし素直だよなあ。
(無駄にdiskspaceを占有するけど)

##

ISBN Titlerみたいな感じでopf生成してくれるアプリってないのかな？
著者名＋タイトルだけなら、ISBN Titler→ファイル名→opfで済むけど、
どうせならopfに対応づけられる情報は全部突っ込みたいところ。

ISBN TitlerはISBNバーコード画像認識にZBarとかいうのを使っているようだから、
こいつにはpython2時代だがpython bindingもあるようなので、
ZBar使ったpython scriptでも考えてみるかなあ。

時間がとれず全く作業できなくて申し訳ないです。

hookライブラリが使えないとなると
その他のパスロック、本棚アイコン、
スリープショットも全滅ですね。

thumbになったから、ライブラリもthumbでビルドしないと
いけないんだろうな。
あとはthumbのABIにマッチしてるかも
調べなくちゃだなー

FW更新もあり、完全に時期を逃した感があるんだが
少し前に作った画像epubのテスト動画をアップしてみた。
youtu.be/ZAqSnazd058

ところで、
glo(FW2.4.0)をwifiで2.6.0にアップデートして動作確認後
手動で2.6.1にアップして画像epubが縮小表示するバグを確認。
その後、そのまま手動でUSBから2.6.0のKoboRoot.tgzを転送し
ケーブルを抜くと、自動更新後見事に2.6.0に戻ってしまった。

さて、海外版auraでも2.6.0化できたりするのかな？

June 2013 Release - 2.6.1b - Bug Fix Release
Note Reuse of version number - Bad Dog Kobo, Bad Dog

Mark 4 Hardware: Aura/Glo/Mini/Touch Low Cost (N905C Model)
2.6.1
84.3 MB - 88,440,655 bytes
http://download.kobobooks.com/firmwa...date-2.6.1.zip

>>459

QtのやつはQt自体のbuildが辛そうだからすぐにはできないけど、
どうせ諸々再コンパイルするついでがあるので、
pure Cのhookはコンパイルして試してみようか？

#んー、QtのためにVMから実マシンに環境移そうかなあ。

>>462
返信遅くなってすいません。
お申し出ありがとうございます。

今からちょっと時間がとれるので試してみます。
明日までに実現できなければお願いしてもいいですか。

ん？単に thumb でビルドしただけだとロードされない。
というか、LD_PRELOAD でビルドしたものを指定すると起動すらしない。
むー。

toolchain を >>426 の通り linaro 2013.04 の gcc-4.8 でビルドしたら動くようになったー。
この情報なかったらハマってたなこれ。
いつもいつもありがとうございます。

ということでフックライブラリ作ってみました。

http://ux.getuploader.com/KOBO_HACK/download/115/hook-20130622.zip

touch のみでとりあえず確認してます。

LD_PRELOAD 変数を削除する処理を追加したのをアップしなおしました。
loadfont.so にあった処理をこっちに移したものです。
こっち使ってください。

http://ux.getuploader.com/KOBO_HACK/download/116/hook-20130622-2.zip

>>465

うちはtoolchain関係はバイナリ同一性チェックの必要もあるので、
使われる可能性があるlinaro-4.7/4.8をalternativesで切り替えるようにした。
さすがにもうCodeSourceryのはいらんかな。Freescleのやつは微妙…。
#あと、linaroのはKobo採用な2013.04(gcc-4.8)以降、
#2013.05版,2013.06版のgcc-4.8があるので、
#Kobo採用版以降のlinaro latest版は実験用に入れる予定。

で、libcb.soのほうは、hookかけていたctorのうちC1のほうが消えてC2だけが残っているというのに気付いて、
mangling nameの"C1","C2"って何の違いだろう？と気になって調査中。
まあ、残ってるC2だけhookかければいいのはわかっているが、なんで消えたのか気になる。
たしか中身同じコードだったし、多分片方は使われるシーンがなかったから
gcc-4.4とgcc-4.8での最適化の違いでバッサリ消え去ったんだと思うものの…

#eclipseのPTP(のRDT)でWindows上のeclipseからLinux(VM)上で
#リモートクロスコンパイルかける環境構築しようとして挫折中。
#rdt-serverまわりで、なんかエラーが頻発していて原因不明。
#Linux側へのRSE(DStore)でのアクセスとか基本的なとこは通ってるんだがなあ。
#(Remote explorerまわりではエラーが出ていない)
#最終的にtargetのKoboも含んだ3台構成の環境にしたいんだが先は長い…

センターズームはとりあえずアドレスズレと消えたctor(C1)を外したものをコンパイルしてブツはできた。
チェック＆デバッグはこれから。
ついでなのでUIレスで実利用できないテスト用の画像フィルター部分の機能もすこし強化中。
意図的な強化じゃなくて、前に入れている途中でdisableにしてた部分をenableにしてコンパイル通して、
環境変数でパラメータ渡せるようにしてるだけだが。

zoomモジュールにいれこむ前の段階の単体コードだけなら、
レベル[0%,25%,50%,75%,100%]の５点(4区間)指定のスプライン曲線でトーンカーブ指定できる、
つーのがコード自体のデバッグはほぼ済んだ状態で残留中(3月からだから熟成3ヶ月)。
n点任意指定じゃないのは、スプライン曲線生成を逆行列事前計算とかして固定行列演算化するための制約。
白黒反転とかコントラストとかブライトネスとかそれなりに普通のはまかなえるはず。

環境変数I/Fは動的に変更もできず自分でもテストしづらいから、
とっととlinaro gcc-4.8でQt buildしてUI作れっていう話だよなあ(笑)
#そのまえに、自分の機能テスト用にfifoでコマンド送ってコントロールするのでもつくろうかな。

相変わらずココは凄いなぁ〜
おら、久々にワクワクしてきたぞ

ガムバッテクダサイ

オナガイスマス (心から)

なんでkoboにはこんなに技術者に恵まれてるんだろうな・・・
まあ、ひどいとこを修正のために集まったっていうのもあるんだろうけど、
それ以外に、なにか、ガジェットとかオープンソースとかの魅力がそれには関係しているのかもな。

>>bucchiさん

ありがとうございました。ばっちり動きました。これで0.95と同等まであと一歩って感じです。

>>png2raw作者様

png2rawもやっぱ再コンパイル必要そう？

んー、tool類の再コンパイルしようとするとlib類のbuildが必要だが、
公開されてるソースのbuildスクリプトが古いままだからconfiguration等が不明だ…
まあ、大体のところは以前のバージョン引き継いだ設定だろうし、
機能のenable/disableが違ってなければsharedで利用する限りは
headerとsymbol nameだけの問題だから支障はないはずだが…

github上でissueで要求出しても(ビジネスルートじゃないから)対応悪いことが多そうだし、
某氏が再び電凸してくれそうだから、そっちに期待すっかな(笑)

##

この先のupgrade御のdosfsck未patch版への上書き問題に対処するために、
1)udev/usb,rcS等KoboRoot.tgz展開直後にpatch版への書き戻し処理挿入(前に書いたの)
2)rcS2みたいな方式でpre-rcSをrcSより先に実行させてそこで書き戻し
あたりが考えられるが、(2)だけだと、rebootを伴わないKobo.tgzのときに困るか。

#rcS2みたいにpre-rcSでrcS,udev/usb内のupgrade処理への(1)処理を自動patchする機能は
#rcS相手の自動patchとなると少しリスキーだから入れない方が安全かなあ。

っていうか、upgrade処理が2か所にあって、udev/usbのKobo.tgzのは展開後に
環境変数等の再設定したりするシステム環境設定処理が含まれたりするから、
rcSと同期して(rcSに追従して)メンテしないといけない、悪い作りだよなあ。

##

[2.6.*でのplain-text表示]
相変わらず文字エンコードがアレで実用できない模様。
エンコード指定できるようにするfooter widgetとかtextのために新規に作ることになるからなあ。
(せめて全部utf-8見做し扱いとかなら実用になるんだがね)
plain-textのビュアーはlibnickel内だったと思うからhackは探すのが大変そうだし、
うまくinterceptしてencoding指定できるか微妙な予感…
やっぱ前に作ったnkf通しのhtml化運用ってのが妥当な線なのかなあ。

>>471

png2rawはとりあえず至急なら(初期版だけど)png2raw-static-12を使うことは可能だと思われる。
preloadで残っている旧libをリンクさせてshared版を使おうとしても、
libpngから先で依存しているlibz等がABI不整合で(?)コケるから、
再コンパイルしかないだろうなあ。

#>>472で書いたようにlib側のbuildしないとpng2rawがコンパイルできないから、
#今そのあたりをやろうとしている最中…

なるほど、分からん(笑)
でもオラすっげぇワクワクすんぞ!!

>>473

png2rawはソース分割大工事中で中断していた状態だったのでコンパイル通すのに手間がかかった。

libpngはとりあえず旧版にKobo patchもなくconfigureで指定していた
1.6.*までに廃止されたオプションを除去するくらいでものはできているようだ。
compile option等合わせ込んでないから同一バイナリではないが
当座shared libでしか使わないので気にしない。

libzは某所情報で1.2.8ということだったが、Kobo日本公式2.6.0だとstringsを見る限り1.2.7.1のようだ。
(compile通してshared linkするだけならさして関係ないが)
こっちはこれからコンパイルだけど、旧版にKobo patchはなくconfigureもcorss指定だけだから
同じような感じですんなり通りそう。

>>475

あまり重要でない箇所でseg.faultが出るケースがあるようだが、
通常の画像出力は問題なく正常に機能することは確認できた＞png2raw 2.6.0対応版

関係ない箇所でのseg.fault直したらあげられるかな。

ほとんどのモジュールが入れ替えになるのは辛いねぇ。

png2rawが動作すれば、とりあえず0.95の頃の機能はほぼ実装完了になるから
至急、というわけではないけど「とりあえず動く」レベルの再コンパイルで
良いかと思われ。

fbmngplayは動いてるから、とりあえずそのままかな

>>477

一応軽くテストした限りでは問題はなくなっと思われるのであげたよ＞png2raw
documentつけてないけど、使い方は従来のまま。

さて、ついでなのでlibmngをやっつけてfbmngplayも再コンパイルしてみるかなあ。

>>478

libmngをやっつけるためには依存してるlcmsとjpeg(jpeg-turbo)がいるんだが、
lcms(little CMS:カラーマネージメント)って、
ヘッダにVERSIONのマクロはあるものの、
lib本体に埋め込まれたversion文字列はないし、
ぱっと見バージョン確認APIもなさそう。

Kobo旧版:1.18a(公開ソースのpackage)
最新版:2.4

まあ、CMSなんてKoboにあまり意味があるか不明だし、
主だったところで使ってそうなのはlibmngくらいっぽいから、
バージョン上げてないと期待しよう。

#packageでまとまって公開されてないと、
#バージョン確認とか個別に取りに行くのとか手間がかかるなあ。

>>479

jpeg-turboもバージョンがわからん(笑)
元になったIJGのAPIエミュレーションレベル設定は
同時に作られているjpegtran等のツール類を見れば分かるんだが
jpeg-turbo自体としてのバージョンは調べる手段がなさそう。

IJG libjpegのAPIエミュレーションレベルは
(従来のIJG 6b版からの置き換えなので)"6b"設定で、
v7-v8のAPIは対応しない設定のようだ。

##

liblcms : 1.18a (従来バージョンのまま)
lcmsはv1のlastが1.18aらしくてv2とはAPIが変わっている可能性があり、
古いlibmngはv1しか想定していないだろうからそのまま従来版。

libjpeg : jpeg-turbo 1.3.0
2.6.0のリリース時期からすると1.2.*だとは思うものの、
shared libのlink利用なら別に最新版も支障はないかという。

libmng : 1.0.10 (従来バージョンのまま)
多分もやは誰もメンテしていないのではなかろうかと思われるので、
バージョンアップなどない。
追加patchは、configure.inのautomakeマクロ"AM_C_PROTPTYPES"削除修正
(うちのbuild-host環境がかわって、開発ツール類バージョンアップの影響で発生した)
AM_C_PROTOTYPESはobsolateになったようなので、
古いautomakeものでpatchがなされていないものだと、
他のものでも、この先たまに発生するかもしれない。

ってなわけで、dep. libとlibmngが出来たので、
これからやっとfbmngplay本体にかかれる。

>> koboayaさん

動いてよかったです。。
おれが CFW の足引っ張っちゃまずいなーと思っていたので
ひとまず安心しました。


by the way

新 UI でも本棚アイコンは必要そうだなぁ。
パスロックにしろ本棚アイコンにしろ、Qt の環境整えないと作れないや。
linaro の gcc-4.8 で Qt ビルドしてみっかな。

あれー。Qt Plugin の buildkey 変わってるじゃん。

FW2.4.0まで

buildkey=arm linux g++-4 no-pkg-config QT_NO_QWS_CURSOR QT_NO_QWS_QPF2

FW2.6.0

buildkey=arm qws/linux kobo-g++ no-pkg-config QT_NO_QWS_CURSOR QT_NO_QWS_QPF2

これは Qt にパッチがあたってんな。
しかも configure のオプションも変わってそう。

ってなわけで、fbmngplayも一応linaro gcc-4.8版をあげてみた。
こっちもdocumentなし〜

いくつかいじっている途中版だったような気がするが、
1Q前の作業なので記憶に定かではない…

*clear screen関連でのcolor-name表現をhtml/cssのcolor-name全部突っ込んだような気がする
// 17(standard)+130(extra)=147 color names
koboだと厳密なcolorそのものに意味はないが…
start,endの画面クリアを指定できるようにしたのも追加かな
(テストしたら"none"がrestoreだったりするので、ちょいこの機能は微妙なレベル)

*B/Wの2値変換して高速アニメモードで表示する(実験版で上げたような気もするが…)

freetype2とiconvをrebuildして、text2fbもできたので、上げてみた。
*デフォルトで使われるフォントを"/usr/local/Kobo/fonts/KBMincho.ttf"にしたので、
　単に文字を出すだけならフォントファイル指定はいらないはず。
　今のところこのデフォルトは内部固定

#FreeTypeとiconvはバージョンアップがあったかどうかわからないので
#従来版をlinaro gcc-4.8でrebuildしてshared link

##

FreeTypeはサイズと内部string見る限りでは
相変わらずMonoType社のiType rendererが入っていて、
それなしの自前コンパイルの倍サイズ。
(テンプレ本+特定フォントでの落ちも変わらずだっけ？)

>>484

text2fbだけは端末DPIを自動設定する都合で、
ntx_hwconfig経由で端末インチサイズを得る処理が入ってるので、
そこが機能するかどうか…
atod()で数値化してdpi計算してるが、
失敗したら組み込みデフォルトのTouchのDPIになるはず。

webで調べるとauraは265dpiっぽいから、
自動設定に失敗すると、実265dpiの画面に対して
Touchとみなした167dpiでフォントのポイント数を決める状態になる
(かなり小さい文字になるはず)

##

他のツールでのaura対応は、フレームバッファーがでかくなった分のメモリ確保の問題か、
フレームバッファーのラインアライメントの問題が想定されうるが、
touch/gloでアライメントが違うから後者は多分問題ない。
前者はauraが本当に従来機種比でメモリ倍増なら問題ない。

##

** 2.6.*対応版 コマンド類 TODO **
* fbfill
　矩形fillもの。text2fb関連で画面消し用途で派生。

* nkf
　オリジナルのままなので再buildだけ。
　txt→html script要修正

* unrar UTF-8 filename対応
　再buildだけで済むはず
　受け側のcbr viewerのrar関連クラスが
　外部デフォルトエンコードiso8859-1な問題が残るので、
　実験用のまま(少しは改善するはずだが)

* busybox lsのutf-8ファイル名対応
　旧版なら再buildだけで済むはず
　全部差し替えは検証がつらいから
　/opt/cfw/bin/busyboxにおいて、/opt/cfw/bin/lsにsymlinkを張っておくかな
　どうせならバージョン上げたほうがunicode対応がちょっとでも進んでいるかなあ…
　/opt/cfw/binにおいて比較的安全そうなコマンドだけ使うならリスクも低いし。

>>482

バージョン自体は変わってなくてもソース公開してない状態で追加で手が入ってそうだと
Qtのbuildはちょい面倒そうだなあ。

やっぱlibcbの画像フィルター実験はfifo経由のコマンド制御でやってみるか。
(local web server+ssiで設定を送り込むとか、無理やりなUIも作れるといえば作れるか？)

##

fifoの制御I/F関連、
nickel-hardware-statusライクな仕組みで
fifoで外部から内部に働きかけるI/Fを作っておくと、
script側からnickelのイベントkickすることもできるようになるかもねえ。
うまくDBの更新を通知できるとCFWでの変更を即反映できるようになるんだろうけど。
(うまく目的に合致するslotがあればいいんだけどねえ)

画像フィルター関連はリアルタイムにコマンド受け取る必要もないので、
画像関連のhookが呼ばれたタイミングでコマンド到着を
non-blocking readで確認する程度で事足りるかなあ、
と思っているんだが(fifo詰まりの状況発生可能性は、そういうもんだと諦めて)
nickel内部に働きかける制御用I/Fだとfifoが詰まっても困るし、
nickel本体の動きとは非同期にコマンド受け取って
適切なタイミングでnickelにイベント投げないといけないだろうから、
Qtのスレッド機構で実装すべきだよなあ…

nkfは再コンパイルだけなのでとっととあげておいた。
txt→htmlの修正は前にスレに貼ったか、前に上げたのにいれたかしたことがあったはず。
txtをnkf通して全部utf-8化してからhtml生成するようにするやつ。
guessオプションでencoding判定してヘッダにそのencodingを埋め込んで、
元encodingのままhtml化する原本txtに忠実な志向性のものと
どっちがいいのかなあ、と思いつつ放置してたやつなんだが…

###

で、何故か謎のスクリプト言語squirrelのバイナリが出来上がったのでそれもあげてみた。
sqliteとかxmlとか、外部libのbindingを入れ込まないとちょい実用性に欠けるかと思いつつも…
(pureなsquirrel(sqコマンド)とは別にsquirrelshというshellっぽいものも入れてある)

###

txt変換ネタとスクリプト言語でふと連想したこと…
青空文庫形式のテキストをかなり限定的に(簡易的に)epub化するのって
スクリプト言語だと難しいかな？
生のtxt形式を放り込んでそれなりに読めるレベルでkobo内でepub化とかさ。
(xhtmlのならxsltで変換して諸々追加してepub化すればいいのかしらん？)
kobo内でブラウザでtxtダウンロード→kobo内で加工→読書
とか…

ネ申がいるスレはここですか？

hookは動くようになったんだが、サスペンドフック時のスクリプトが
途中でコケてるかどうかわからないが、png2rawによるサスペンド画像が表示されない。

フックスクリプトそのものは動いているので（ghostbusterで画面を消すのは動いてるから）
スクリプトが途中で止められているんだろうか。それとも、このタイミングで何かしらの
理由でpng2rawが動かないのか。

telnetでコマンドラインからサスペンドフックのスクリプトを実行すれば、画面消去→
サスペンド画面表示、と動くから、ますますわからん。

なんとなーく2.6系ってサスペンド画面や電源OFF画面がかなり変わってるから
フックした後の後続処理が悪さこいてるのかなあ・・・

もしかしてスクリプト終了まで処理がブロックされてないのかな？
家に帰ったら確認してみるか。

>>489

touch/miniとglo/auraだと挙動が違ってたりして。
新UIのは処理クラスも処理手順も微妙に違うとか、なんかこの先ありそうな…

>>489

んーと、メモリ量とかその関係で落ちることがないわけじゃないかもなあ＞png2raw
swap環境だとさすがにそうでもないはずだし、telnetで入ったときとhookで呼ばれたときで
大幅に使えるメモリ量が異なるってこともないと思うが…

>>489
調べてみたらスクリプト実行後に画面を書き換えてるっぽい。
要するに、スリープ直前じゃなくなったみたい。
またフックする関数の調べ直しか・・・。

>>bucchiさん

うげげ。挙動変わってるなーと思ってましたけど、そんな感じですか・・・
ちょっとの間、スリープ画面＋電源OFF画面の挿げ替えは我慢しますか。
解析作業が大変なのは、よーくわかるので。

とりあえず、現状まとめ。

・バグ（文字化け、ダメ文字問題）は解消済み
・フォント設定壊れ問題とSDフリーズ問題は「やっと」Kobp本体で対応したんで対処無し
・ページ送り補正、フォント設定共通化は問題なく動作
・本棚関係も問題なく動作
・データパッチのタイミングは0.95とほぼ同じ。
・DBキャッシュやSwapは何も考えず動作中


問題点

・アドオン系（本棚アイコン、検索アイコン、センターズーム、パスワードロック）は未検証だけど多分動作しない
・スリープ、電源OFF時の画像挿げ替えは動作しない
・三人の作者（俺、bucchiさん、png2raw作者様）の多忙により検証不足ｗ

こんなとこか。0.95以下の状態だから、ちょっとリリース気が引けるし
readme書く時間ねーからリリースもできんｗ

＃この状態で人柱になる覚悟ある人居る？

もうちょっと落ち着いてからでいいや・・・

人柱やります。
てか、文字化けと本棚さえあれば、とりあえずの運用はok。
強制アップデートされた人に救いのβ、お待ちしてます。

とりあえず、text2fbに添付していたfbfillもコンパイルして軽く確認したものをあげておいた。
任意色での画面クリアor矩形fillするだけのもの。

あと、気付いたらマニアックかもしれないmakefileになっていた、
fbシリーズ用の共通設定makefileつーのを
ネタとしてあげおいた。

ふつーはmakeの中でこんなことするくらいなら、
$8shell sed...)とか使って外部で加工するつー突っ込みはおいといて、
makefileなのにぱっと見た目、関数言語に見えなくもないという…

>>494
add-onもヲタくせーアニメなんかいらねー
さっさとリリースしろ愚図

スクリーンセイバーをヲタくさく出来ないのは残念ですが、
是非お願いします。
プログラムのことは全く解らないので、人柱ぐらいしか協力できないのです
それより、swap無い状態で自炊本を沢山突っ込むのは怖すぎる。
とりあえずファクトリセットして待ってます。
さようなら2.4.0

KBMin+テンプレ本のnickel落ちは相変わらずなんだなあ。
今回はうまくstack logが取れなかったので昔のを見直してみたら、
確かにbzip2関連じゃねーな、これ。
単にsymbolが近くになくて不適切なシンボル名が出てるだけだ。

で。該当箇所のソースを見てみると、
free()を呼んだstack frameっぽい。
itype_rdr_done_itype_outline+0x48:
->func_xを呼ぶ
func_x(void* y)
y!=0のとき
r0ベースの構造体メンバーを読み取ってy[-4]を引いて書き戻し
free(y-4) <=これがFT_Stream_OpenBZip2+0x73a5cのframe
&y[-4]が確保メモリtopでそこにsizeか何かがあって、
ユーザーに見せるptrが&y[0]という形はc++的な感じだし、
r0がthisでr1=yっみたいだから、
FT2自体はCだけどiTypeレンダラーはC++なんだろう。

func_x()の前がitype_rdr_done_itype_outline()だし、
終わった後のnew確保な領域の解放に伴うヤバいことじゃねーかなあ、と推測。
中身の生存期間とのミスマッチとか…二重解放とか。

>>494

power controlの手法(nickel外部呼出しの仕組み)が変わってなければ、
スリープなどはfakeshさんのnickelから呼ばれるshをwraperを使ってthookかけて、
そこから起動するっていう別方式なら内部に依存しないから2.6.*でも機能するはずなんだけど、
従来方式スクリプトとの間をつなぐブリッジスクリプトを挟まないといかんのかもね。

nickel内部hook方式が確立する直前にやっていた、apmdでsleep
poweroffコマンドのwrapでpoweroffつー方式でも
同様にnickel外部での対応なので2.6.*でもいけるんだが、
こっちは旧型touchの場合、kernelのbug-fixがないと
power-extendedがデバイス状態を反映しないのでうごかんのよねえ。
apmdはdebianからarmhf版を取ってこないといけないけど、それで済むはず。

まだkernelの変更有無とか全然みてないけど、
kernelのpower extended patch moduleは
再コンパイルしないと使えないだろうなあ…
#これもunnamedな変数に対してoffset address指定の直読みとかやってる
#邪悪なものだけど、カーネルのその周辺コードはあまりかわらないから
#再コンパイルだけで済むだろう


###

CFWのβ(というか機能が一時的に限定されている分CFW Minusか？)
基本機能に支障がなければ欲しいなあ…
CFWがないとGlo側を2.6.0にできないので、
新UIもまだ見てない状態だし(笑)

なんか改めて見直してみると公開ソースのbuildスクリプトの中に、
configureの--prefixの扱いが変な感じのがあるなあ。

packageのクロスコンパイルへの配慮次第ではあるんだろうけど、
普通はprefixはtarget上でのpathを指定して、
build環境上でのsysrootへのinstallは
make DESTDIR=<sysroot path> install
でするんじゃないかなあ。

pkgconfig関連がtarget上のpathになってしまうとbuildで参照しようとして困るってのは
PKG_CONFIG_SYSROOT_DIRを指定してbuild上でのpathに置き換えて
cflagsとかを取り出すのが普通なんだろうし。

glibなんてクロスに配慮してないわけないと思うのだが、
なんでprefixをbuild環境上でのsysroot指定してるんだろうか？

path関係はちゃんとしないとバイナリに入るrpathとかで
build環境のpathが埋め込まれたりしてちょいキモチワルイ。
libtoolが絡んだりするとうまくキレイにクロス用設定できなかったりするので、
libのpath関係は厄介なもんだが…
(最終手段としては、chrpathで削るバイナリ書き換えするんだろうが)

>>500

オブジェクトの二重解放くさいという想定で…
「ここに来たら(ここからcallされたら)常に二重解放の２回目」
っていうのなら簡単にfix-patchもありうるんだが(アドレスのみがcontext)、
「変数がどうでという条件諸々あって、その時にcallされたら二重解放の２回目」
という環境状態contextだとpatchするのが困難だろうなあ。
itype_rdr_done_itype_outline()
とかその上位の
itype_rdr_make_itype_outline()
とか、iType Rendererオブジェクト周りの構造を押さえないと
いけないのかなあ。

二重解放を検知しても気にしねーでノーエラーで戻すように細工しつぃまう
とかいうのはglib内でのhookになるしヤバすぎるか。
(ft2から来た場合かを戻り崎で判定して限定すればいいのかな？)

###

最近出たfreetype-2.5からは
> Adobe's CFF engine is now the default,
> which makes a good reason to change from the 2.4.x to the 2.5.x series.
なもんで、Adobe, Googleあたりの貢献で
かなりいい感じになっているような雰囲気だし、
iTypeなんて捨てちゃってもいいんじゃない派に
趣旨替えしちゃおうかしらん…
(buildしてpreloadで試すくらいはしてみようかなあ)

今日glo買ったばっかで初期設定してたら最新の2.6になってしまった
見た感じ2.6のcfwはまだ出来ないんですよね
安定してるっぽい2.4(5?)とかにダウングレードするとかは出来ないんですか？
それともcfw開発者様からの朗報を待つしかないんでしょうか

>>504

ファクトリーリセットされるバージョンは多分2.4.*以前だろうから、
desktopとか単体アップグレードを回避して手動で2.4.*へアップグレードすれば
2.4.*運用できるんじゃないかな。
(単体アップグレードの回避はわからんけど、Desktop経由の場合、
PCから切断する前に.Kobo内のKoboRoot.tgzとupgradeフォルダーを削除すればiいいはず。
初期化のアカウント紐付関連は別途一度認証回避状態にして
FW 2.4.*にしてから必要ならアカウント認証させなおすとか。
(認証済み状態の2.6.*のdbからアカウントだけ抜き出して2.4.*のdbに戻すとか)

急ぎで依存libだけrebuildしてたけど、そろそろclean rebuildしてみるか、というので
サックリこれまでのsysroot内を消してやってみている。
packageのバージョンは調査していないのでとりあえず従来packageでbuild中。
(バージョンアップがある程度分かっているjpeg/pngはFW 2.6.*に合わせているが)

・atomic operation問題(Thumb化の影響)
Thumbだと古い"SWP"命令が使えず、
LDREX/STREX使ってretryされるコードにするのが普通らしいが…
これが影響するのはGNOME glibと古いQt(4.6.*時代のもの)

[glib-2.20.0:gatomic.c]
glibは2.23.*あたりでgccのbuilt-in __sync__*関数を使うようになり
gatomic-gcc.cファイルが増えたようで、
その後2.23あたりでそれ関連は全部ヘッダに移動し、
現在ではgatomic-gcc.cファイル自体は消滅
#gcc以外で__sync* built-in関数がない場合にどうしているのか不明

gatomic-gcc.c以前の版のThumb対応は、検索してみたら
なんかgatomicだけlib分けてARM Inst.でコンパイルする
とかいうpatchがあるようだ。
さすがにそんな後ろ向き対応よりは__sync__*()使うpatchを
入れたほうがいいかなあ。

[Qt:qatomic]
4.8.0だと関係ないが、GNOME glib由来(初期に少し関連があった程度?)の部分では
4.6.*時代は同じ問題があったようだ。
4.8.*ではarmv6/v7はLDREX/STREX使ったコードなのでThumbでも問題なしのはず。
(まだqtに行ってないので"SWP"に関してだけの話だが)

>>506

>その後2.23あたりでそれ関連は全部ヘッダに移動し、
「2.28だか2.29だか、2.2*の最後のあたりで」の誤り。

>>504
昨日買ってきたgloを初期化して認証回避して、起動したら2.1.5だったよ

>>506

glib-2.22.0のpatchは結局
1)glib/Makefile.{am,in}あたりのgatomic.*(.h以外)をgatomic-gcc.*に修正し
2)glib-2.24あたりからglib/gatomic-gcc.cを取ってきて、glib/にcopy
っていう形でお茶を濁してみた。
どうせheaderとshared link用途だけだろうから
対応してる2.24とか持ってきてもいいのかもしれないが…

本来はconfigureでgcc builtinの__sync系を検査して
HAVE_GCC_BUILTINS_FOR_ATOMIC_OPERATIONS
を設定して、それを元にして決めるようにMakeFile.inなんかを修正して
まともにMakefileを作るようなものにするのだろう。(2.24での流れ)

っ

ttp://ux.getuploader.com/KOBO_HACK/download/125/Kobo_CFW_Ver0.96%CE%B21.zip

とりあえず、組み込んでいたopt配下のバイナリを入れ替え。
ダメ文字問題をはじめとした、データぶっ壊し＆文字化け系の問題は解消できていると
思われ。

とりあえず報告求む。

＃ 自分の環境に入れた状態だと、まぁスリープ画面と電源OFF画面のテーマが
＃ 動かないこと以外は一通り動作していると思う・・・

busyboxでエラーが出てとまったので、
FW 2.6.*だと"1.22.0-kobo"で新版だったはずだなあ、と
見に行ったら、公式には1.21がstable最新版で、
1.22.0はunstableでもリリースされてないんじゃないか…

FW2.6.0のがどの時点のものかわからんから最新版masterにしておくかなあ
バイナリのstringsで2013/05/22とかあるが、これはコンパイル日時だろうなあ。

commit logを見る限りでは2013/05/23のntpd関連以降、
一週間前くらいまで１月弱更新が止まっていたようだから、
5月のntpd関連が全部入っているなら
比較的安定落ち着いた時期のものってことになるのかな？

##

他は保守的なくせに、busyboxみたいな根幹部分で妙に色気出して、
ここまでアグレッシブな選択しなくても…

>>512

なんとかicuまで到達

・prefixはtarget上のperfix
・sysrootはinstall時にDESTDIRで与える
・DEVICEROOTが"/"で始まらないのは個人的に気持ち悪いので変更
とかいう方針で修正していたら結構な手間が。

普通のは
make DESTDIR=${DEVICEROOT} install
とかでいいんだけど、
aclとattrはBSD install風install-sh(by SGI)によるinstallで流儀が違う。
DIST_ROOT=${DEVICEROOT} $MAKE install
とかしてDIST_ROOTで渡さないといけない。
#makeが外部のコマンドを起動するときにmake内部の
#(コマンドラインで定義した)変数を環境変数に突っ込んでくれるなら
#make DIST_ROOT=${DEVICEROOT} install
#でもいいような気はするがどうだっけかな？

あと、acl,attrのクロスだとinstall関連では
INSTALL_USER,INSTALL_GROUP,DISTRIBUTION,PLATFORMなんかを
このあたりの設定ももしかすると必要なのかもしれず。

###

で、icuってなんか前に色々と手こずった記憶があるものの、
最終的にどうしたかを差分取る前にrmしてしまったような気配…
もともと公開ソースにpatchはあるがbuildスクリプトがない状態だったから
あれこれ自前で格闘してたような記憶…

ここを超えたらQt本体にかかれるはずだが…

>>510
サンクソbokoaya、俺はこれで十分だわ
あとは好き勝手にヲタアニメ組み込んでくれ

>>505>>508
ありがとう
Kobo_CFW_Ver0.95に同梱されてた認証回避で2.4にしてDesktopでセットアップ後
.Kobo内のKoboRoot.tgzとupgradeフォルダーを削除したら2.4cfw出来ました
先に>>505さんのやり方で回避してから2.4にアップグレードでも出来たのかも知れないけど
なんせテンパってたせいで散々リセットやアップグレードを繰り返した後気づいたもんで（笑）


あと無事cfw化出来たから別にどうでもいいっちゃいいんだけどちょっと気になったことがあって
認証回避で2.4にしてextフォルダーコピーしても
koboへようこそ！の画面のままでホーム画面に戻らなかったんだよね
>>212と同じだと思うんだけど解決策も書き込まれてないみたいだし何が原因だったんだろ

レベルの低い話でスマンが一応参考までに以下俺が行った作業内容書いとく

ファクトリーリセット後USB接続
kobo-update-2.4.0の中身(upgrade、KoboRoot.tgz、manifest.md5sum)を/.koboにコピー
USB接続解除(アップデート)後リセットボタンで再起動
USB接続後Kobo_CFW_Ver0.95の.koboとkoboCFW.conf(過去スレにconfも入れるべきとのレスがあったため)を/にコピー
USB接続解除(アップデート)後リセットボタンで再起動
USB接続後Kobo_CFW_Ver0.95の認証回避についてのextを/にコピー
USB接続解除後リセットボタンで再起動
言語選択後
koboへようこそ！セットアップは簡単です。さあ始めｒｙ

>>513

icu終了。
Chromium版での変動がらみのみ。
・バッサリ削られた機能のmakeを抑制するconfigureオプション
・"public/"に移動された"unicode/"ディレクトリ周りが元pathで参照したがるもの多数なので、
　元パスで参照可能になるようln -sでリンクを張って調整

libraryのrpathなんかはまだ調べてないけど、
pkgconfigがらみの*.pcはキレイな状態なのを確認。

さて、buildが通るレベルでのlibrary整備はできて、
残るはQtなんだが、BuildKeyが変わってるつー話だから、どうしたもんかねえ…
(一応build-allがQtに突入して旧configure設定のまま仕事しはじめてるが…VMだから遅い)

>>515

>USB接続後Kobo_CFW_Ver0.95の.koboとkoboCFW.conf(過去スレにconfも入れるべきとのレスがあったため)を/にコピー
koboCFW.confは".kobo/"の下に入れた？

認証回避のext/boot.shが動く条件は
(1)CFWが導入されていること(前提)
(2)内蔵SDに".kobo/koboCFW.conf"が存在すること
が必要だから誤って"koboCFW.conf"を(PC接続したときの)内蔵SDのルート
(.koboと同じ階層)に置くと、条件(2)を満たさず、認証回避が発動しない。
*** "koboCFW.conf"は".kobo"の中に置く ***
*** "ext"はルート(".kobo"と同じ階層)に置く ***

それ以外に認証回避が実行されないケースは想定できないなあ。

>>516

あ、いかん、やってしもーた。
ふとbuild中の画面をみると"arm-linux-g++"の文字が…
pathが通ったままだったので、古いCodeSourceryのgcc-4.4でコンパイルしてるやん(笑)

ってなわけで、とりあえずQtのBuildからは撤収ナリ。
実マシン上のlinuxに環境移して出直しだな、こりゃ。

#うちの環境だとFedora(VM)→Ubuntu(実マシン)だから、
#実マシン以降だと、その辺の調整もいるかもしれず。

>>503

実バイナリ覗いてなくてソース上でちらっと見た限りでは、
> #01 sp: 0x7efa7300 ip: 0x30adea50 /lib/libc-2.11.1.so: abort+0xfc
> #02 sp: 0x7efa7420 ip: 0x30b12ee8 /lib/libc-2.11.1.so: __fsetlocking+0x3e8
> #03 sp: 0x7efa7a50 ip: 0x30b1d49c /lib/libc-2.11.1.so: malloc_usable_size+0x770

malloc.cのmalloc_usable_size()以降で、abort()を呼びに行くようなのは、
malloc_printerr()あたりで、
こいつは確かにfree()の頭のほうで実際に解放する前のchunkチェックで
エラーを検出したら
> malloc_printerr (check_action, errstr, chunk2mem(p));
を呼んでいる。

check_actionのbit値が0x02が立っていれば
エラー表示の後でabort()するのがmalloc_printerr()の仕様。

>#define DEFAULT_CHECK_ACTION 3
なので、デフォはabort()コース

このcheck_actionはstaticな変数ではあるが
> mallopt(int parameter_number, int parameter_value)
経由で値を変更可能。

>itype_rdr_done_itype_outline()
入口でhookして、その関数内だけ一時的に値を変更して
0x02のビットを落としてやれば、
free()のメモリチェックで二重解放を検出しても
abort()にまわらず戻すことは可能だなあ。
(本当に単に二重解放だけならさほど破綻しないような気がするし、
どうせバグはバグなんだから元々破綻しているわけで、
さほど悪化することはないかと思わなくもない…)

この方針で対策patchはできるけど、
修正patchじゃなくて落ちなくするpatchでしかない(笑)
根本的には直したことにならないが運用性は改善するかもしれない…

#特定フォント+特定コードで発症するかなりレアなタイプだから
#バグの存在を認識してないんだろうなあ。
#他社から購入してるライブラリ内だから、保守契約がどうなってるとか、
#ビジネス的な部分がからんで、対処しない判断なのかもしれないけど。

>>482

buildkeyの2,3番目の要素あたりを見る限り、
"mkspecs/"下にlinaro toolchain用に
新規specファイルを適当にでっちあげて置けばいいのかな。
(Qt自体への追加patchの有無はわからんけど)

#Windows用のクロスQtを作ろうとしかけた時に
#mkspecs周辺をふらふら探査した記憶があるなあ。

>>519

------------------------------------
itype_rdr_done_itype_outline(void* this_, void* objptr) {
　if (objptr != NULL) {
　　void* p;
　　if ((p = *(void**)(objptr+0x38)) != NULL) func_x(this_, p);
　　if ((p = *(void**)(objptr+0x34)) != NULL) func_x(this_, p);
　　if ((p = *(void**)(objptr+0x30)) != NULL) func_x(this_, p);
　　func_x(this_, objptr);
　}
}
------------------------------------
小さかったので適当に手動デコンパイルで疑似コード化してみた。
こんな感じだから、丸々objectの解放する関数っすなあ。
stack frameに出て他のは多分3番目の呼出し。
別のとこでの解放の後でポインタにNULL入れておけば
ハマることもなかろうに…

真面目にバグ修正するなら他でobject+0x30とかのポインタを解放してる箇所みつけて、
その解放後にNULL突っ込むコードをなんとかして挿入するのかな。
和が少なくて小さくて単純な関数なら関数そのものをpreload hackで
差し替えるところだけど、大きくて複雑そうなら、
無理やり修正hackにjumpしてくるように動的にコード書き換えるとか？

>>521

ああ、
>別のとこでの解放の後でポインタにNULL入れておけば
>ハマることもなかろうに…
こう書いたのは、
・初期化でNULL設定
・コード等条件によってmalloc()することもあるし、使わないこともある
・最後にitype_rdr_done_itype_outline()で使ったポインタのリソースをまとめて全部解放
・その方針なのに、何の理由か途中で一部のポインタは解放するなんてことを特定箇所で入れてしまった
っていうような流れを想定してたからで、
・普通は解放後は常にNULL設定する方針
・たまたまどこか特定の箇所だけNULL入れ忘れ
の場合もありうるなあ。
その場合は「NULLいれておけば」という批判はピントずれだが、
これはこれで別の観点で批判対象になるな。

ま、どーでもいい話だけど、こういうレベルのバグを残してるものを
商用ライブラリとして製品販売してるつーのもなんだか…

>>522

単一objectが所有権(リソースの解放を行う責務を持つのが誰なのか)があいまいなまま
複数の変数からポイントされている、っていうケースのほうがありうるか。
で、それのどれかが、自分が使い終わったから解放じゃ〜、ってしてしまうとか。
(ふつーそういうのに対しては何らかのref countの仕組みを入れ込むもんだが)

確保/解放の関数両方をhookして、こっそりメモリ確保時にrawなサイズを+4して
[-8]にrefcount入れ込ん管理してやるとかすれば、比較的安全にfixできねーかな。

>>523

特定フォントと特定文字コードで出るっていうことは、二重解放じゃなくてBOF的な現象の可能性が高い？
フォントの情報に従って計算してその値の量か何かでメモリを埋めていく処理で、
計算値が実は異常値だが、そのチェックをせずに単純にメモリに書いてしまう。

このほうが発生条件との間でより整合性のあるシナリオかなあ。

なんにせよ、gnu mallocのprinterr出力とか、エラーの判断ロジックとか、
その時のメモリ状態とか、動的な部分でチェックするのが先か。

堕ちるページに含まれる文字列を、１ページ＝１文字に分解して、
どの文字で落ちてるのか特定すれば、状況把握しやすいかなあ。

ガッ

>>517
試しに.koboに入れてやり直してみたら認証回避出来ました
ありがとうございます

それとついでなんで>>505のやり方でも出来るか確認してみたらちゃんと上手くいったんで報告だけしときます

[memo]

・[おまけブラウザ]Bookmarkにせめてタイトルをつけられるようにできないか？
QSettingsに１項目1QStringで保存されているはず。
これを
"タイトル<space>URL"
で保存するようにして
listではそのままの見た目で表示
listから選択して取り出すタイミングでうまく処理を入れ込んで
<space>でSplitしlast要素のみのQStringを生成し、それを呼出元に渡すことで辻褄をあわせる
QStringやlist系の基本的な関数をhookするのは影響が大きいので、
動的なコードpatchで無理やりhack側にjumpさせることになるか…

・[おまけブラウザ]bookmarkのlist表示画面、listページが移動可能であることを示すような
　UI要素が何もない困ったデザインも気になるところ

・[おまけブラウザ]mime-type登録済拡張子を持つファイルしかダウンロードできない制約の除去
せめて拡張子じゃなくてmime-typeで判断しないと
cgi経由等でダウンロードする場合に困るんだよなあ。
前に調べた記憶だとハンドラーで判定してたはずなのでそこを殺す

・[おまけブラウザ]pdfなどのダウンロード御にnickelがコンテンツ追加を認識する
　タイミングとその仕組みはどうなってたのか確認
青空文庫txtダウンロード後に変換処理を呼び出すaction hookが可能か？
備考:スケッチブックの場合はsave後に明示的にFSのコンテンツスキャナを呼び出していたはず
現状のCFW hookがコンテンツスキャナ後の流れでのhookならそのhookのままでOk
txt->html変換を変更してtxt->青空文庫形式判定->各形式に応じた処理

制限除去してzipを直接ダウンロードできるようにした場合、
cbzとすべきではないものもcbzにしてしまうので、
その対応も考えないといけないか…
(明示的にスキャナを走らせているなら、呼ぶ前に判定(画像ファイルの含有率等)して
スキャンにかからない隠しdirに移動)

ダウンロードファイルの移動とか諸々考えると、明示的にscannerを呼び出す処理フローなら、
呼び出す前にすませないといけない処理はいくつかあるなあ。

・[カバーページ]".kobo/images"のメンテナンス
破損・生成に失敗しているもの・元がHQすぎて無駄にdiskspaceを取っているもの・
コンテンツ本体が削除されているのに消えてないもの(ある？)
PC接続時にPC側で行うのは道具がそろっているので簡単。
Kobo内でやるためにはもう少し道具がないと実用的にならないか。
Qt内でやるなら道具はそろっているが、Qt外部だと現状の道具立てでは、
少し迂遠なマニアックshell scriptになりそう…

カーネルのバージョンまとめ

* 2.6.0(JP)までで、海外版の2.6.1は未調査
* KoboLabs公開ソースのAura用カーネルの中身は未調査
* 過去版のうち、生文字列を調べていなかったものを調査
* manifest.md5sumの値を追加

[寸評]
* 旧版Touch(E905B)のカーネルは見捨てられたまま
* 2.6.0でGlo/Mini/Touch(E905C:新版/ローコスト版ともいわれる)用カーネルにも手が入っている
Freescale patchの適用済番号も進んでいるようだから、
cpuに合わせた正しい設定へのBug-fixまで当たっているといいんだが、
ほとんどntx共通ファームの都合での更新だったりしかねない…
* Tool-chainはFreescaleの開発パッケージに含まれるもののままだと思われる。

###################

[KoboTouch:2.0.2〜2.6.0]
md5: f75279756c789789c066b5b0da0f4af5
"Linux-2.6.35.3-850-gbc67621+"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #325 PREEMPT Wed May 23 09:35:44 CST 2012"

###################

[KoboGlo:2.2.0]
md5: a04883f212d4160e8f6ffdc6fdc01feb
"r5686_#605 Oct 18 11:45:43"
"Linux version 2.6.35.3-850-gbc67621+ (chitai@chitai-Aspire-V3-471G) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #605 PREEMPT Thu Oct 18 11:45:43 CST 2012"

[KoboGlo:2.2.1〜2.4.0]
md5: a98226ce78e7402cb65b9b77a22d379e
"r5845_#606 Nov. 5 14:13:06"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #606 PREEMPT Mon Nov 5 14:13:06 CST 2012"

[KoboGlo:2.6.0]
md5: e778f045fac228d4498aa0a3dbf54834
"r6495_#617 Apr 22 11:07:47"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #617 PREEMPT Mon Apr 22 11:07:47 CST 2013"

###################
(つづく)

(つづき)

[KoboAura(E606C0):2.3.1]
md5: 8048cb458dc7a849ca944732391e9e8d
"r6114_#1005 Dec 12 18:33:34"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1005 PREEMPT Wed Dec 12 18:33:34 CST 2012"

[KoboAura(E606C0):2.3.2]
md5: cd78426207d00c55dfdc3d6f24be895a
"r6114_#1006 Dec 13 11:52:44"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1006 PREEMPT Thu Dec 13 11:52:44 CST 2012"

[KoboAura(E606C0):2.4.0]
md5: f826a27b28fb33f22863e3253030e6fa
"r6311_#1010 Feb 7 17:55:09"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1010 PREEMPT Thu Feb 7 17:55:09 CST 2013"

[KoboAura(E606C0):2.6.0]
md5: 87c382819d3e1909448b55ca9a45e3f6
"r6512_#1038 Apr 25 15:48:22"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1038 PREEMPT Thu Apr 25 15:48:22 CST 2013"

###################

[KoboLabs公開ソース(mx507用)]
*arch\arm\boot\のuImage(timestampが他のImage,zImageよりも新しい2012/09付)
"r5448_#603 Sep 27 17:23:16"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #603 PREEMPT Thu Sep 27 17:23:16 CST 2012"

*その他転がっているkernel image
"Linux version 2.6.35.3-850-gbc67621+ (george@dilemma) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #2 PREEMPT Wed Aug 8 10:44:09 EDT 2012"
これはCodeSourceryでコンパイルしてしまったゴミが残ってtar.gzに入ったまま
公開されているのだと思われる。

>>528

「Freescale patchの提要済番号が進んでいる」の件は誤りだ。
なにをボケていたのか…

＃package更新もあるし、公開ソース、同期してくれんかなあ…

kernel関連情報更新TODO
・海外版2.6.1(差し替え云々の新旧があったがkernelも影響あったのかなあ)
・driver module関連がこれまで未着手だったので調べる

Touch(N905B)のカーネル環境が変わってないってことは
power-extendedのfix-patchはそのまま使えるかな。
apmdはarmhf版からまとめなおしたほうが(気分的には)よさそう。

前にお試しで作ったcifs(smb)モジュールも使えるはずだが、
高知したままだから謎…

##

自分のもの以外だと、HOMEキーページ送り化デーモンは
2.6.0でふつーに使えているんだろうか？
(libの問題がなさそうだから大丈夫だと思うが…)

カーネルのバージョンまとめ

* 2.6.1b(差し替え版)まで調査
* 過去版の2.5.*系を追加
* KoboLabs公開ソースのAura用カーネルの中身は未調査

[寸評]
* 2.6.1b(差し替え版)はE606F0対応がメインだと予想

###################

[KoboTouch:2.0.2〜2.6.1]
md5: f75279756c789789c066b5b0da0f4af5
"Linux-2.6.35.3-850-gbc67621+"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #325 PREEMPT Wed May 23 09:35:44 CST 2012"

###################

[KoboGlo:2.2.0]
md5: a04883f212d4160e8f6ffdc6fdc01feb
"r5686_#605 Oct 18 11:45:43"
"Linux version 2.6.35.3-850-gbc67621+ (chitai@chitai-Aspire-V3-471G) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #605 PREEMPT Thu Oct 18 11:45:43 CST 2012"

[KoboGlo:2.2.1〜2.4.0]
md5: a98226ce78e7402cb65b9b77a22d379e
"r5845_#606 Nov. 5 14:13:06"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #606 PREEMPT Mon Nov 5 14:13:06 CST 2012"

[KoboGlo:2.5.0]
md5: a8a9462d665b958ad616f5b802c6b3ca
"r6415_#610 Mar 25 10:27:17"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #610 PREEMPT Mon Mar 25 10:27:17 CST 2013"

[KoboGlo:2.5.1〜2.6.1(a/b)]
md5: e778f045fac228d4498aa0a3dbf54834
"r6495_#617 Apr 22 11:07:47"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #617 PREEMPT Mon Apr 22 11:07:47 CST 2013"

###################
(つづく)

(つづき)

[KoboAura(E606C0):2.3.1]
md5: 8048cb458dc7a849ca944732391e9e8d
"r6114_#1005 Dec 12 18:33:34"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1005 PREEMPT Wed Dec 12 18:33:34 CST 2012"

[KoboAura(E606C0):2.3.2]
md5: cd78426207d00c55dfdc3d6f24be895a
"r6114_#1006 Dec 13 11:52:44"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1006 PREEMPT Thu Dec 13 11:52:44 CST 2012"

[KoboAura(E606C0):2.4.0]
md5: f826a27b28fb33f22863e3253030e6fa
"r6311_#1010 Feb 7 17:55:09"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1010 PREEMPT Thu Feb 7 17:55:09 CST 2013"

[KoboAura(E606C0):2.5.0〜2.5.1]
md5: fa4254a883ce6ffaa591a8a03f47230f
"r6427_#1027 Mar 28 15:02:51"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1027 PREEMPT Thu Mar 28 15:02:51 CST 2013"

[KoboAura(E606C0):2.5.2〜2.6.1(a/b)]
md5: 87c382819d3e1909448b55ca9a45e3f6
"r6512_#1038 Apr 25 15:48:22"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1038 PREEMPT Thu Apr 25 15:48:22 CST 2013"

###################
[KoboXXX(E606F0/E606F0B):2.6.1b]
md5: 51e9767d02503be5e44150d3f80706bd
"r6688_#2016 May 31 14:40:00"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #2016 PREEMPT Fri May 31 14:40:00 CST 2013"

* u-bootも2.6.1bから追加(E606F0/E606F0B別々)
* u-bootのnamingを見る限りメモリチップ変わらず256MB
* stringsを見る限りmx50系なのでCPUも系統は変わらず(clock speedは不明)
* kernelのuImageファイルのsuffixは"-E606F0B"
* kernelが"F0B"なのをみると、雰囲気的にはF0無印はproto版等なのかな？と思わなくもない


###################

[KoboLabs公開ソース(mx507用)]
*arch\arm\boot\のuImage(timestampが他のImage,zImageよりも新しい2012/09付)
"r5448_#603 Sep 27 17:23:16"
"Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-desktop) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #603 PREEMPT Thu Sep 27 17:23:16 CST 2012"

*その他転がっているkernel image
"Linux version 2.6.35.3-850-gbc67621+ (george@dilemma) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #2 PREEMPT Wed Aug 8 10:44:09 EDT 2012"
これはCodeSourceryでコンパイルしてしまったゴミが残ってtar.gzに入ったまま
公開されているのだと思われる。

よくわからないが、頑張ってくれていることがよくわかる。
無理せずのんびり頑張ってください。

そういや2.4.0以降だと/usr/local/Kobo/下にliblzma.soが
入ってるんだよなあと今気づいた。
折角あるんだし、これも普通に使えるように環境を整備しとくべきか。
ln -sで/usr/libにlink張ると変に悪影響出ちゃうかなあ？

bzip2だけlibで使えないのはシャクだなあ。
うちの開発機は何かの都合でいれたので存在するんだが、
何の依存関係で入れたのか記憶に定かではない…

#コマンドだけはbusyboxがstaticにbzip2/lzmaを盛ってるおかげで
#昔から使える状態だったけど…>xz(lzma)とbzip2関係

ImageMagickがlibtoolのltdlを使っている関係で、
なんでltdlのlibそのものはKoboに入れてない(使ってない)のに
libtool packageを含めているのか調べてみた。
(仕組みをよくわかっていないが…)

・普通のパッケージはltmain.shを内部に抱えていてconfigureでカスタム生成している。
・libmngはautogen.sh方式で、別途libtoolを必要とする。

ってことが存在理由だと思われる。

で、このlibmngが曲者で、autogen.shはunmaintained/下にあり、
クロスを考えずに作られて捨て置かれた状態のままのものに見える。

Koboではautogenの最後にconfigureを動かす部分をremoveするpatchだけで
buildしているので、せっかく${DEVICEROOT}/usr/local/bin/${CROSSTARGET}-libtool*
とか作ったものを使わず、build環境側のlibtoolを使っている。
それによる影響があるのかはわからないが
これだとlibtool packageをbuildする意味がない気がする。

今更autogen.shでやるのはないだろーと思ったDebianやReadHat等が
どうしているのかを調べると
・Debian系: makefiles/makefile.linuxを修正しそれでmake
・SUSE:同上
・RedHat系:autogen.shは使わずautoreconfでconfigure等を生成
ということのようだ。
元から*.a[cm]とか*.inがあるわけだし、
auto(re)confするだけっぽいんだが、
RHみたいにautoconf系でやれない理由があるんだろうか？
(configure作るまでもなくDebian系みたいにMakefile.linux書き換えでもいいんだけど)

##

そのついでに1.10への各ディストロのpatchを見てみると、
・Debian:buildを通すためのpatch,typo patch程度
・RedHat:distro自体のupgradeに付随した(re)build調整等はあるが、コード自体はオリジナルのまま？
・SUSE:zlibがらみのメモリリークの修正がある
ってことみたいだなあ。マイナーlibだけに各陣営てきとーにいい感じに放置。
sfのCVS見に行ったら、もう少しfix系がありそうだが…

大きなお世話だろうが、linux系なんかにそんなに入れ込んでも
いずれ途方もない虚無感に襲われるだけなような気が…

linaro toolchainのpkg-configがらみでハマったことのメモ

linaroの配下のarm-linux-gnueabihf-pkg-configはwarpperで、
環境変数等を自分の配下pathに合わせて強制置き換えする。

configureのバージョンとかoptionとか条件はわからないが、
host(target)を指定クロスbuildのとき、
${HOST}-pkg-configがあればそれを優先する場合があり、
上記のようにwrapperが環境変数書き換えてしまうため、
ユーザーが与えた意図通りに機能しないケースが発生する。

　PKG_CONFIG_DIR
　PKG_CONFIG_LIBDIR
　PKG_CONFIG_SYSROOT_DIR
あたりが影響を受ける。
　PKG_CONFIG_PATH
は安全。
ただし、"PKG_CONFIG_SYSROOT_DIR"が奪われるので、
cflagsとかのbuild上pathへの置換を
ユーザーのsysroot(${DEVICEROOT})に対して行えない。

なんでコマンドラインからチェックでpkg-configしたときは${DEVICEROOT}下の目的libを見つけるのに
configure内で見つけないだろう？と結構悩んでしまった。
crosstoolとbuildのでpkg-configのバージョンが違うせいか？とか…
(まさかwrapperがトラップになっていたとは思いもよらず…)

##

ついでにrpathがらみの対処法メモ

ImageMagickがどうしてもhost,build混在のrpathをsoに書くので、
ディストロはどう対応してるのかDebianをみてみたら、
so作ったあとでchrpathでサックリdeleteさせていた(笑)
#少し前の版だと、それに加えて(laファイルへの対策か)libtoolがrpathを渡そうとする
#hardcode関連部分を一部殺すようなlibtool scriptへのpatchも入れていたようだ。

やっぱImageMagickはそうすることになるのかなあ…

>>537

そうかもねえ。
ま、業務なら費用対効果で考えてやらないだろうけど、
これに関しては、趣味でしかないわけさ。
「拘るべきところ」なんてのを冷静に考える気はないし。

#2.6.*対応CFWの報告等したいから引っ込んでろという話もあるだろうからアレだけど…

>>png2raw作者様

β1だし、そんなにダウンロード数も伸びてないので、報告は少ないと思われｗ

まぁ、逆を言えばちゃんと動いてる・・・と思いたい。

ちゃんと想定通り動いてると思いますよ。
有難いことです。

>>540
2.6.0対応ありがとうございます。ちゃんと動いてます。
まだ2.6.0に慣れなくて面食らって報告遅れてすんませんでした。

ぐはぁ
β普通に見逃してた
普通に動いた

>>540

うーむ、betaを出して〜といっておいて、まだインスコしてない私…とっとと入れます。

CFW入れる前のOFW 2.6.0アップグレードの段階でdosfsck対策をしとかないと、
既存のダメ文字含みファイルが潰されるので、そのあたりいじらねーとなあ…
(OFW260+dosfsck対策版をマージしたKoroRoot.tgzでアップさせるのが一番お手軽か)

##

ImageMagickをやりつつ、buildが通った各パッケージ見直し中
(ImageMagickは表紙画像メンテツールなんかで使えないかな？という目論見)

[Busybox]
旧1.17.1のpatchのうち、
・mkfs.ext3(をmkfs.ext2でfakeする)
・ntpdのstepスクリプト起動と-qオプションの関係
この２つはKobo(ntx)固有の事情があると思われるので残存。
他は1.18時代に修正済のpatchなので破棄
・dhcpc:一部のサーバーでsecs fieldのチェックが(仕様を超えて?)厳しく、まずいのでその辺の対策だったらしい
・Makefile:GNU make 3.82で本来の仕様に修正され、過去互換性がなくなったことに起因するMakefileエラー対策

後はconfigのunicode範囲拡大のpatchを追加すれば、
ls等一部コマンドでの日本語の扱いが少し改善して以前試しに作ったもの相当になるかな。
(vi等文字幅/バイト幅が必要なものはそれように対策しないとどうしようもないだろうけど)
今回は"/opt/cfw/bin/"に置いて、ある程度安全そうなコマンドは常用してみようかと。

>>540

あー、2.4.*時代のsoが残ったまま2.6でcfwすると、確実に死ぬと思われ。
リカバリーor殻割りlinuxでmountしてメンテorメンテファームでmountしてメンテ
リカバリー以外は一般向けじゃないだろうから、
cleanupの仕組みをいれないことには…

メンテファームにFATのp2領域作って、PCから修復用OFWパッケージを置けるようにして、
起動時そこれががあれば自動で内蔵sd0p1に展開してOFWに戻す
とかいう外部sd起動のOFW戻しリカバリーの仕組みでも入れたほうがいいのかもねえ。

メンテファームのシステム側は、extの仕組みと同じく、
自動修復用スクリプトがあればそれを呼ぶだけの
汎用で使える機能にしたほうが利便性が高いか。

fb系ツールとfreetypeはあるから出力系はある程度Okで、
入力系でタップイベントを拾ってなんとかできれば
修復用パッケージを置くのはPCがいるけど
実作業は単体で処理できるようになるかもなあ。

正式版までのcleanupの仕組みを真面目に考えたほうがいいだろうなあ。
fakeshさんがやっていたような感じのhookで
busyboxが実体となるコマンドをスクリプトで置き換えてやるか、
削除リストを一緒にcfwのtgzに入れておいて、
cfw版rcSで「そのリストがあればそれに従い非互換・不要ファイルを消す、
消し終わったらリストファイル自体を消す」
ってな感じで。

>>545

どうせGUIベースなメンテアプリ作るなら、Qtのstrand-aloneアプリでいいのか。
2.6.*のtoolchain変更とは独立してるわけだから従来の開発環境で作ればいいわけだし。
(とはいえ、うちは旧toolchain関連のものはサックリ消した後だから
buildからやり直しになるが…dev packageをまとめて保存しとくべきだったかな)

[KoboMin+テンプレ本の特定文字での落ち]
とりあえずrcSで環境変数"MALLOC_CHECK_=1"を設定してabort()しないようにして、
試したところ落ちなかったので、メモリチェックで不整合検出して落ちていることは確認できた。
(エラーメッセージ自体はまだ確認していないが)
#JIS補助漢字の前のページ83区or84区内のどれかの文字

[unicode文字表示対応busybox]
・shのファイル名補完とかその後のカーソル移動は使えている気配
　(もうちょいいじって行入力の編集で問題なさそうならtelnetで入るときのシェルにしてもいいかなあ)
・予想通り、viは文字幅とかいろいろ絡んでいて残念なことに

どうやら2.4.*以降、AVE(zave)ファイルを認識しているようだ。
なんかiPad方面(というかDTP業界おなじみのQuark方面なのか？)のフォーマットらしいが…
zaveはComicZipReaderが担当するようだからzave=Zipped AVEってことか？
AVE自体はQImage()がそのフォーマットを扱えれば、reader側も扱える。
(reader側担当はzip/rarなんかのコンテナまわりと表示UIの下請け)

Qtのimagepluginにそれらしきものがいないから、
本当に表示できるのか謎だけど…
AVEフォーマットが画像に関して既存のpngっていうことなら
何も考えずにOkってことかもしれないなあ。

その場合でも、本来のフォーマットとしては画像だけじゃないのかもしれないけど、
libcbが扱うので画像オンリーの対応ってことになる

>>549

Qtに関して詳細調べてないけど、
Koboの非公開自前patchでQt内にstaticに組み込んであるとか、
nickel(or libnickel)内にpluginのclassを埋め込んでいて、
コードで登録しているとか、そういうケースも想定しうるか。

んー、どこかに小さいzimファイル置いてるところないかなあ。

zaveの関係で2.4.*以降追加された機能を見直してみると
zimファイル対応があるようで、オフラインWikipedia環境にできるようなんだが、
各国丸ごと版みたいなGB単位のものはさすがに入れる気にならない(笑)

試しに小さそうなfr語のzimファイルを入れてみたら、
ちゃんとコンテンツスキャンで認識して本の状態で登録されて開ける。
1冊でもzimファイルが入っていれば、
翻訳・辞書と同じ並びにウィキペディアが追加されて検索できる(はず)
なところまでは確認できたんだが…

入れたzimファイルがまずかったのか、中のpngファイルのpngバイナリを
テキストファイルだと思って表示しているような変な状態になって、
実動作の確認ができない…

zim=Wikipedia固定の扱いらしくて、著者="全員"っていう表示になった。
複数のzimファイル入れたときに、検索とかどういう振る舞いをするのだろうか？

Kobo_CFW_Ver0.96β1を glo と aura に導入してみたので軽く動作報告

[gloで確認できたこと］
・DB更新中のアニメ動作
・CBZファイルのページ送り補正機能
・自動本棚作成 StoreBookInsertShelf="FIXED" UserBookInsertShelf="FOLDER" で確認
・ファイル追加時の本棚登録
・本棚再構築
・"最近読んでいる本棚" 機能 RecentlyReadingTarget="READING" で確認

※glo はほぼ正常に動作していると思われる。

[auraで確認できたこと]
・CBZファイルのページ送り補正機能
・自動本棚作成 StoreBookInsertShelf="FIXED" UserBookInsertShelf="FOLDER" で確認
・本棚再構築
・"最近読んでいる本棚" 機能 RecentlyReadingTarget="READING" で確認

[auraで機能しない／おかしいもの]
・DB更新中のアニメ
・ファイル追加時の本棚登録

auraは本を追加してもすぐに本棚に登録されず、次のDB更新のタイミングで追加される
内部的には追加されているが、表示が間に合ってない感じ
最近読んでいる本棚の表示と同じ状況と思われ

動作確認専用のmicroSDを準備しているので、無茶な実験もできるよ
何かあれば人柱になる準備あり

ついでに報告

auraのmicroSDを64GBに換装してみたら、ちゃんと動作した
使ったのは SANDISK の SDSDQUA-064G-U46A

50GB以上ファイルを追加しても動作に問題なし
ただし、本の一覧などはそれなりに遅くなる

>>552
乙

2.4.*以降、libnickel内にCheckFileSystemCommandというクラスがいて、
このクラスはFSそのものとDBのcheckとrepairを行うようだなあ。

その中でcheckAndRepairFS()が
umount /mnt/onboard
dosfsck -a -w /dev/mmcblk0p3
mount -o %1 -t vfat /dev/mmcblk0p3 /mnt/onboard
mount -o remount,rw,%1 -t vfa /dev/mmcblk0p3
とかやっている。
"%1"部分のmount optionをどこからどう引っ張っていているかは
調べてないけど、ctorでどこかからか取り込んでいるのかな。
("mount | grep ..."な文字列もいるし)

dosfsckが走るのはrcSとudev/usbだけと思い込んでいたが、
2.4.*以降の場合、nickelが直接呼ぶ場合もあるということか。

このcheckFS自体は問題なさそうだけど、
この手の内部で処理シーケンスを管理するタイプに問題があると、patchが厄介だなあ。
(呼び出されるコマンドのwrapだけで対策できるならいいんだけど)

###

zimファイルその後
・複数のzimを入れたときは、最後に入れたものがwikipedia検索の辞書として使われるようだ
・読書中にwikipedia検索するとzimのviewerで該当項目に行って、
　そのときはビュアーに懐かしい"戻る"ボタンがいたような気配…
　(zimビュアーから元の読書中の本に戻らないといけないから戻るボタン必須)
・zimは開けるけど、本のように読んでいくのはできない？zimの作りによるのかな？

>>555

訂正
「戻る」はzimビュアー内(wikipediaコンテンツ内)の項目linkの戻りでしかないな。
元の読書本には戻れないので、用語辞典的な使い方しようとするととストレスが溜まりそう。

#どうやらfooter内のwidgetとしては「戻る」ボタンラベルlが顕在っぽいので、
#これを2.4.*以前の時代の本来の戻る機能として再活用できんもんかなあ…

さて、ちょっと時間がとれたので解析はじめますかね。

[nicklelのエンコーディングまわりの解析情報]

・cbrのエントリ名が腐る件

これはQString <--> QByteArray(c-string)の型変換が直接の原因で、
内部では
QTextCodec::codecForCStrings()
のCStringまわりのencodingのデフォルトが
latin-1(iso-8859-1)であることが原因。
暗黙の型変換ではfromASCII() → codecForCStrings->toUnicode()
でcodecForCStrings->toUnicode() → fromLatin1()
な感じでlatin-1→ucs2(uchar→ushortのビット幅広げるだけの単純透過copy)が行われる

##

・".txt"ファイルがバケる件

バージョンによって挙動が異なるが、少なくとも2.6.*では
kepubのviewerがtext/plainとして担当しているようだ。
(parserが".txt"->kepubのViewerを生成という流れ)
http経由のものならヘッダでencoding等付加情報があればいけるのかもしれないが、
localで情報なしのtxtが渡されるとうまく対処できない模様。

で。バケた文字をみると"漢字"→"&#230;&#188;&#162;&#229;&#173;&#8212;"だったので、
これはutf-8文字列をiso-8859-1だと思ってlatin-1→ucs2したパターン。

ファイル読み込みはTextStream()で、こいつはutf自動判定がデフォでenable。
ただし検知精度が低い。
判定できないときはcodecForLocale()がデフォになり、
環境変数等localeがちゃんと得られないとfallbck先はやはりlatin-1
ということ。

で、utf検知があってBOM対応があるようなので以下のencodingにするのが使える。
1)UTF-16/UTF-32等の仕様としてBOM付なencodingを使って誤検知を回避
2)邪道だがUTF-8-BOMにする(UTF-8-BOMを欲しがるなんてVisualStudioみたいだなー)
両方とも、
txtのencodingた正しく認識され、".txt"のまま"漢字"が正しく表示できるようになった。
#locale設定してデフォルトをutf-8にするのは試していない。(影響範囲が広いから)

>>558

●外部コマンドとのtextのpipe的なことが絡む場合
→前者のQTextCodec::codecForCStrings() が文字化けを発生させる

●外部ファイルとのtextの読み書きが絡む場合
→後者のTextStream()のcodec指定、codecForLocale()の場合は
　localeの設定 or utf自動検知失敗

というのが結論

"*.txt"はBOMつければ回避可能なので、まあこれまでのhtml変換と似たような
対処なので、対策してもしなくても同じようなもんだな。
#TextStream()でcodec指定して読ませたとしても、結局担当しているのが
#kepub viewerで内部ではtext/plainとして<pre>的にf扱っているんだろうから
#どこでhtmlのデータとみなす正規化をかけるのかの違いでしかない。

cbrのほうは、cbrだけに閉じた状態で作用するpatchにするのがちょい面倒。
codec変えてしまうと、広範囲に使われている生cstring文字列→QString全部に影響する。
まあ、普通はasciiで埋め込まれた生文字列をQStringに代入したりするだけだから
utf-8変換が入っても速度以外は影響がでないし、速度を気にするシビアな箇所ではないから
気にしなくてもいいのかもしれないんだが…

armで動的にコードを書き換えてhack code部にlong jumpさせるっていうのは面倒そうだが、
関数内部でピンポイントに修正コードを注入するにはそれしかなさそうだし…

Qtビルドできれば、対象関数は2か所でどちらも１画面で済みそうな小さい関数ｄから
丸ごと差し替えてシンボル名ベースの安定したhackにできｒんだけど…

Thumb になったのか、gcc のバージョンが上がって最適化が進んだのか
以前に作った解析ツールがことごとく使えない。
まいったなぁ。

>>552

>・DB更新中のアニメ

fbmngplayでauraの解像度だとなにかうまくいっていないのかな。
boot等他のアニメについても同様にauraで動かないならその可能性が高いなあ。

画面sizeを得るあたりとか、画面サイズ＞mngのサイズの場合にどうなるかとか、
その辺を確認してみるか。

>>561
auraでも2.5.2なら再生できるのは確認済
解像度を合わせなくても、小さく表示されるだけで再生はできる
2.6系で何かが変わったんだね
それ以上はわからんけど

>>562

2.6系固有の話っすか。んー、なんだろうなあ。

問題がありそうなのは本棚とDB更新アニメだから、
auraだとhookが意図しないことになっているとかかな？

libnickelにDragon*というaura用っぽいクラスがいっぱいあるから、
auraのときはそっちを使ってhookさないものがあるのかもしれないという気もするが、
Dragon*=新UIクラスだとしたらgloもDragonクラスをつかうはずだしなあ。

>>556

結局6GBくらいのWikipedia Jaのzimファイルをダウンロードして
FATのサイズ制約回避で2gb splitして、拡張子をzimaa〜zimadにして転送
(zim readerのサポート拡張子をみるとzimaa〜形式の分割対応らしい)

で、本としてもカテゴリー等を辿って項目を見ていくことが可能なのを確認。
メインページの下(後ろのほうのページ)にある日本地図みたいに
横幅大きいレイアウトがうまくなくて表示できていないものもあり。

他の本からWikipedia検索可能だが、やはり元の読書中の本に戻れず片道切符なのが残念。

内蔵に置くには換装必須だけど、外部SDでも使えるなら、
それなりに使えるんじゃないかなあ。

ホーム画面の検索(Touchだと設定からの検索)から検索して
項目に飛べるように機能強化しれくれば便利な気がする。

外国に住んでて、外国の本を中心に読もうと思っているんですが、
１．日本でkobo gloを買って、海外のストアから書籍を購入し読むことができますか
２．外国でkobo gloを買って、（日本に一時帰国した時など）日本で海外のストアから購入した書籍を読むことはできますか
３．海外でkobo gloを買って、海外のストアで購入した書籍と可読性を維持しながら、日本の楽天から本を買うことはできますか。

ちょっと特殊なケースかと思いますが、ご存知の方いらしたらお願いいたします。

>>565
日本でkobo gloを購入し、楽天IDで運用している者です。

kobo端末でログアウトするとストア書籍は端末から消去され
ファクトリーリセットしたのと同じ状況になります。
よって、3はNo、2はkobo端末にダウンロードが済んでいれば普通にYesだと思われます。

1はPC側のkobo desktopのログイン画面に、選択肢はあるのですが
http://uploda.cc/img/img51cf630ea1d8e.png
fnac.com等、楽天ID以外のアカウントを持っていないので試しておりません。

あと、この質問は
【楽天】Kobo Touch glo mini 52冊目【コボ】
http://uni.2ch.net/test/read.cgi/ebooks/1372483000/
での話題のように思います。

>>563
昨日の報告の修正

[auraで機能しない／おかしいもの]
・DB更新中のアニメ
　auraではDB更新中にプログレスバーが表示されて「xx%処理中」みたいな表示が出る
>libnickelにDragon*というaura用っぽいクラスがいっぱいあるから、
>auraのときはそっちを使ってhookさないものがあるのかもしれないという気もするが、
　なので、これが正解かも

・ファイル追加時の本棚登録
　昨日確認したときには本棚はできていたが0冊になっていた
　今日確認したら本棚もできていて冊数もちゃんと表示された
よくわからんが、タイミングの問題かも

CFW導入後のgloとauraのroot配下差分を取ってみたら、顕著な違いは libqca-ossl.so と libqca.so くらいだった
＃なぜか /etc/zoneinfo と /etc/zoneinfo-leaps が大きく違っているが、動作に影響があるとは思えない
アニメ表示以外はauraでも大丈夫そう

aura HDの報告ありがとーです。

コンテンツ処理に連動した本棚整理ができていないのは
もしかするとbucchiさんのフックモジュールが動いていないのかもしれない。

＃ 新しい本を突っ込んでUSB接続解除したあと、コンテンツ処理中の画面で
＃ 95%〜100%表示になったあたりで青LED点滅が発生しないと
＃ フックモジュールが動作していないことになる

アニメーションは、mngファイルがglo用とTouch/Mini用の解像度しか用意できて
いないので難しいかなあとは思ってたけど、やっぱりダメかあ。

実機が無いのでどーしようもできまへんなあ・・・

PCB判定して、aura HD(Dragon)や、その後継機（Phoenix)は表示しないように
するしかないかなあ

>>568

拡大縮小かあ…
rgb888→rgb565(frame buffer)の減色転送のところで
拡大縮小しながら転送することを考えてみるかなあ。

>>565
ありがとうございました。ログイン画面にfnacなど複数出るということは、
IDさえあれば入れそうな感じですね。
IDだけ作って、それから日本で買ってみます。
値段が相当違うので、日本で買えるならそれに越したことはないと思います。

[ComicBook(cbz,cbr)におけるファイル名のソート]
1)書庫エントリ順に取り込み
2)未サポート形式を除去(順序不変)
3)重複除去(エントリのpathは有効なのでpathが違えば別物扱い) (*)
4)ソート処理
　A)path名は除去しファイル名のみで比較評価
　　"/path/name1.name2.ext"->"name1.name2.ext"
　B)最初に出現する"."以降は切り捨てる(=最初の"."までの部分で比較評価)
　　"name1.name2.ext"->"name1"
　C)大文字・小文字は識別するが、数字部分を数とは認識しない(普通に文字列として比較評価)
　D)特にqStableSort()を使っているわけではないので同値のものは順序維持は保証されないと思う
　　"name1.name2.ext1"->"name1"
　　"name1.name3.ext2"->"name1"
　　この２つがあった場合、どの順になるかは不定(集合が不変なら結果は常に同じだが)

(*)重複はQtのQStringとしての文字列重複でしかないのでこの段階で重複のどれが残るかは確定しない。
　実際に書庫内のファイルにアクセスするときのキーはファイル名なので
　そのファイル名が複数あった時、ライブラリ側がどう振る舞うかによって、
　重複エントリA,重複エントリBのどちらが得られるかは変わってくる。
　普通はエントリ順に早い者勝ちだから重複エントリAが返ってくる実装だと思うが、
　ハッシュや非安定ソートしたsorted-listやらが絡む管理方法だったりすると一概にはそう言えず。

むか〜しmobilereadのforumでソート順がどうだとか実験してた人がいて、
それ以来気になっていたのでソースで調べてみた。

pathが意味を持たないのと、"."以降まるっと切り捨てられるのには要注意だな。

なにやらcbzのparse(DBへの登録)の大まかな流れが分かったっぽい。

Contentクラスを継承しているVolume(本全体)とかShortcover(各ページ)とかのクラスを作って
必要な情報をセットした上で、libnickel本体にsignalでそのobjectを投げつけるようだ。
受け取ったslotが後はよしなにDB登録してね、っていう。

受け取りslotをhookすれば、コンテンツスキャンして本の登録がある毎に、
その情報をDB登録前にinterceptして書き換えるようなことも可能だなあ。
(情報のやり取りを考えるとVolumeをQScriptに渡して必要情報replaceするほうが少し楽？)
正規の処理フローの中での書き換えだから、タイトルなんかは即時反映するっていうのがメリットか。

本棚関係は完全にlibnickel側の分担だろうから、そっちが似たような仕組みで
うまく「最近追加した本」みたいな流れでinterceptできれば…

うーん。suspend 時の壁紙だけど、バッテリー残量の表示は定期的に
再描画されちゃうみたいだ。

スリープ時のバッテリー表示を止めることはできると思うけど、
壁紙を表示してる時だけ止めるってのが難しいんだよねぇ。
壁紙のファイルがあるか毎回調べれば実現はできるんだけど、ちょっとねぇ・・。

>>573

2.6にしてCFW入れてから壁紙設定してなかったので、
スリープのバッテリー表示ってなんだろ？とか思ったが、
スクリーンセーバーで読書中本の表紙＝ONの時に出る
ステータス(旧UIだと上部バーで、新UIだと左下囲み)のやつかな？
USB給電中だと状態を更新して定期的に出るわけか。

これって、表紙表示じゃないplain表示のときは出ないんだよねえ。
coverpageモードとplainモードで違うから、
どこかにコントロールしてるところがあるんだろうけど、
外部からcallできるようなものかどうか…

ファーム入れ替えて再起動したtouchが1時間くらい更新中から帰ってこない
やっちまったかなぁ

旧touchにCFW0.96β1をいれてみました。
スリープ画像入れ変えが出来るともっとうれしいです。
報告ぐらいしかできないですが、今のところ安定しているように思います。
応援しています。

.koboフォルダにある affiliate.conf は、
いわゆる広告収入のアフィリエイトと何か関係あるの？

内蔵sdのclassって影響しますか？
やっぱりclass10のほうが断然いい？

>>578
速いに越したことはない
あんま変わらないんだから出せる額の最高速買っとき

>>578
class10とclass4を試したことがありますが、個人的には、断然いいというほどの
差は感じませんでした。　私の買ったClass10がはずれだったのかもしれませんけど。

>>578
Transcend32GのClass4と10を比べたけどスマホやデジカメのストレージみたいに唸るほどの違いはわからないレベル。
但し、Class2を使うと明らかに遅くなる。

>>577

nickelの中に"Affiliate***"という広告主毎のクラスが色々転がっているから
affiliate.confと連動してるんだと思うが、今のところ国内じゃ関係ないし、
その辺を解析しても面白いことに使えそうではなさそうだし
コード見たことすらないので、confに連動してどう振る舞いが変わるのかよくわからん。


#関係ない処理のコードも無駄に全部入ってるからメモリ食うっていうのが
#なんかキモチワルイが、Qtのアプリって基本そういうものっぽいのかな。
#外部にlibがあるはずのlibzipが何故かlibnickel内部にstaticに取り込まれてるようだとか
#色々ムダはある。(多分AdobeDRMとか外部のものがstaticに取り込んでるんだと思うけど)

sdのclass指標ってread性能ベースだっけ？

PC接続してのコンテンツ追加とか、そのあとのコンテンツスキャンとか、
個人的には諸々writeが体感して遅さを感じるので、
class10かつwrite(特にDBを考えるとrandom write)がそれなりにいいやつを
探し出さないと快適とはいえないかも。

開発用旧型Tuoch:サムソンのなんか当時writeが良いと評判だったやつ(class10 32GB)
読書用Glo:trancendのclass10 32GB
で使ってるが、圧倒的にTranscendを積んだgloのほうが遅い(笑)
(性能良くてもサムソンのをあまり信用してないから開発機に入れてるんだが)

>>579-581 >>583
うーむなるほど
確かに問題は書き込みスピードの方かもしれないですね

クラス10入れてもUSB転送速度遅いので変わらないとおもってました

でも、ランダムライトって買って測って見ないと解ら無いんだよね

>>585

SD系スレに貼られるcdmベンチのデータで情報収集するくらいしか手はないだろうなあ。

前に虎のを適当に測定したときベンチプログラムは違うけど、
PC上でのcdmとKobo実機でのベンチで、PCと比べて
seq.readで10〜20%減、seq.writeで1/3まで低下(60%以上減)
くらいの感じだったから、USB転送が遅い(writeが遅い)のは
いかんともしがたい状態だと思う。
(write性能が違うメディア間でKobo上での性能比較はしてないけど)

#OS自体の問題なのか、KoboのCPU(Soc)iMX50*に起因する問題なのかはよくわからん

auraはこないのか・・・
ttp://eetimes.jp/ee/articles/1307/04/news136.html

>>587

> 楽天の担当者は、「ディスプレイを高精細化したので、CPUやチップセットもより性能が高いものに入れ替えた。
> そのため価格が高くなっている」と説明する。

チップセットはともかく、CPU本当に(gloとの比較で)変わってるの？
cpuの型番等が分かる品質の分解写真あったらurl教えて〜

実機もちでtelnetで入れる人がいたらcpu&clock speed&memoryの情報教えてほしいなあ。
(あとntxのhw_configツールの出すhw config情報もだけど)

#自分でバラマキ低価格戦略とっておいて、「日本市場では端末価格が安いから…」という理由はなんとも。

zoomモジュールの新版、テスト中。

今回のは従来からのページ移動時のセンターだけじゃなくて、
ズーム倍率変更時に中心視点を維持したズームになる機能も追加。

FIFOを使った外部からの制御I/Fを入れたので、
多分local webページからSSI経由で設定変更可能になるんではなかろうかと期待。
専用に受け取りスレッド立てているわけじゃないから
何度も連続に設定を送りつけるとfifo詰まるだろうけど(笑)

どうもctorが片一方消えた影響か、ctorへのhookが効いてないなあ。
(自動回転抑制にしか使ってない部分だけど)

>>589

あ、前にも一度はまった、thunk(ベニア？)経由でjumpしてくるので、
シンボルでhookできないってやつだ＞ctor
んー、thumb化された関係でthumb,armの切り替えが絡むし、ちょい厄介なのかなあ…
素直にhookがかかってる他のmethodに処理を移動させるほうが無難か…

>>590

どうも違ったようだ。2.6.*で消えたと思っていたが、同一コードが１つの実体にまとめられて、
名前だけは独立して存在していた模様。(ctorのC1,C2)
で、それの片引っかけ状態で、引っかけそこなった側しか通過しないという…

ということで、以前のバージョンの機能は大体確認終了。
zoom倍率変更時のセンター維持もそれらしく動いている。

後は画像フィルター周りの機能のFIFO経由の制御の確認。

>>591

echo "set filter.gamma=25" >/tmp/cfw-hack-libcb
や
echo "set filter.gamma=05" >/tmp/cfw-hack-libcb
とか適当なな値でやって、一応設定がimage-filter部に届いて
levelを再計算して、それらしい画像変化をしているようだ。

後はレベル補正フィルターの確認とやっつけでSSI作成かな。

>>588
ほい

(none) login: root
[root@(none) /]# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 999.42
Features : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 5

Hardware : Freescale MX50 Reference Design Platform
Revision : 50011
Serial : 0000000000000000
[root@(none) /]# cat /proc/meminfo
MemTotal: 513904 kB
MemFree: 18484 kB
Buffers: 15244 kB
Cached: 335128 kB
SwapCached: 284 kB
Active: 179588 kB
Inactive: 238920 kB
Active(anon): 11976 kB
Inactive(anon): 56204 kB
Active(file): 167612 kB
Inactive(file): 182716 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513904 kB
LowFree: 18484 kB
SwapTotal: 530108 kB
SwapFree: 528524 kB
Dirty: 20 kB
Writeback: 0 kB
AnonPages: 67980 kB
Mapped: 27512 kB
Shmem: 44 kB
Slab: 7236 kB
SReclaimable: 5220 kB
SUnreclaim: 2016 kB
KernelStack: 480 kB
PageTables: 640 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 787060 kB
Committed_AS: 173852 kB
VmallocTotal: 1376256 kB
VmallocUsed: 12492 kB
VmallocChunk: 1333728 kB

microSD換装でswap追加しているので念のため

>>588
「ntxのhw_configツールの出すhw config情報」っつーのはわからん
教えてくれれば情報取るよ

>>593-594

thanks
これでやっと、EPDそのものを除くと、
メモリ倍増＋対パネル間バス幅倍増(?)くらいが
大きな違いだとほぼ確定か。

ntxのconfig値を出すツールは
#ntx_hwconfig -l -s /dev/mmcblk0
とかでHW CONFIGを表示してくれる。
disk上でいうと0x80000からに書き込まれているもの。
(u-bootもkernelもこの情報を元に諸々デバイス設定して動いている)

imxのfreescale関連deviceのdriverが微妙に腐っていてdisplayの
物理的なサイズ情報等を真っ当に返してくれないもんだから、
しょうがないからtext2fbだとこのntx_hwconfig呼んで
返してきたパネルのインチサイズ文字列からDPIを計算しているという。
他のツールだとDPIまでは必要としてないので、
今のところ必要なのはフォント扱うこれだけなんだけどね。

そういや、前にbucchiさんがwidget関係やってた頃に、
Nickelのカスタムwidget以外の素のQt Widgetは
タップ等のイベントが飛んでこない、
といっていたのを思い出した。

というのも、おまけブラウザが原因。
こいつは、どうもガードしそこなってるdialog等多々あるらしく、
しばしば生のQt Widgetでdialog出してくるんだよねえ。
script実行時間が長いから中断するか？とかいうやつとか、
html5のfile APIがらみのやつとか。

素のdialogが前面に出てしまうと画面操作不能になっちゃうから困りもの。
電源キーでのsleep操作でsleep->resumeすることで
危機から脱出できる場合がほとんどだとは思うものの…

tapのdelegateとかあの辺をmixinしたwidgetにしか
イベント流してないんじゃないかと思うんだが、
なんとかしたいな〜。

sleep 時の壁紙が出ない問題、hook ばっかり疑ってたけど、
コンソールにこんなの出てた。

png2raw: error: too many parameters: /mnt/onboard/.images/suspend.png

作者様何かわかりませんか？

50suspend ないで実行している行はこれ

/opt/cfw/bin/png2raw -K -ta /mnt/onboard/.images/suspend.png

シェルプロンプトから /opt/cfw/hook/suspend/50suspend を直に実行すると
壁紙が表示されるので引数が間違っているわけではないみたい。

あと、50suspend 内で export を実行して環境変数を表示させて、
シェル実行側の環境変数を上記に合わせてみたんだけど、やっぱりシェルからは表示できる。

なんだろ・・。

>>595
ほい

[root@(none) /]# ntx_hwconfig -l -s /dev/mmcblk0
HW CONFIG v1.7 , size=39 bytes :
[0] PCB='E606C0' [ E60800|E60810|E60820|E90800|E90810|E60830|E60850|E50800|E50810|E60860|E60MT2|E60M10|E60610|E60M00|E60M30|E60620|E60630|E60640|E50600|E60680|E60610C|E60610D|E606A0|E60670|E606B0|E50620|Q70Q00|E50610|E606C0|E606D0|E606E0|E60Q00|E60Q10 ]
[1] KeyPad='FL_Key' [ MX357|MX357+Wheel|MX357+Joystick|MX35-5inch|1Key|E60M10|E60M10+Touch|E60620|E60630|E60640|E606A0|FL_Key|NO_Key|FL+HOME ]
[2] AudioCodec='No' [ No|ALC5623 ]
[3] AudioAmp='No' [ No|TPA2016 ]
[4] Wifi='WC121A2' [ No|AW-GH381|AW-GH321|GB9619|PW621|WC160|WC121|WC121A2 ]
[5] BT='No' [ No|AW-GH381|AW-GH105 ]
[6] Mobile='No' [ No|Moto 3G ]
[7] TouchCtrl='neonode_v2' [ No|TSC2004|Wacom Digitizer|Watop Digitizer|AUO-TP2|neonode|PVI|ITE|neonode_v2 ]
[8] TouchType='IR-Type' [ No|R-Type|Digitizer|C-Type|IR-Type ]
[9] DisplayCtrl='MX508+TPS65185' [ S1D13521|S1D13522|K1900|M166E|MX508|K1901|MX508+TPS65185|MX6SL+TPS65185 ]
[10] DisplayPanel='6.8" Bottom EPD' [ 6" Left EPD|6" Right EPD|9" Right EPD|5" Left EPD|5" Right EPD|6" Top EPD|6" Bottom EPD|5" Top EPD|5" Bottom EPD|6.8" Top EPD|6.8" Bottom EPD ]
[11] RSensor='G Sensor' [ No|Rotary Encoder|G Sensor ]
[12] MicroP='MSP430' [ MSP430 ]
[13] Customer='9' [ No Brand|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25 ]
[14] Battery='1500mA' [ 1000mA|1500mA ]
[15] Led='TYPE1' [ TYPE1 ]
[16] RamSize='512MB' [ 128MB|64MB|256MB|512MB|1GB|2GB|4GB ]
[17] IFlash='Micro SD' [ Micro SD|NAND Flash ]
[18] ExternalMem='Micro SD' [ No|SD|Micro SD ]
[19] RootFsType='Ext4' [ Ext2|Ext3|Ext4|Vfat ]
[20] SysPartType='TYPE3' [ TYPE1|TYPE2|TYPE3|TYPE4|TYPE5|TYPE6|TYPE7|TYPE8|TYPE9|TYPE10 ]
[21] ProgressXHiByte=0x02
[22] ProgressXLoByte=0xB0
[23] ProgressYHiByte=0x03
[24] ProgressYLoByte=0xE8
[25] ProgressCnts=0x00
[26] ContentType=0x00
[27] CPU='mx50' [ mx35|m166e|mx50|x86|mx6|mx6sl ]
[28] UIStyle='Customer UI' [ Ebrmain|Customer UI|Android ]
[29] RAMType='K4X2G323PC' [ MDDR|DDR2|K4X2G323PC|K4X2G323PD|DDR3 ]
[30] UIConfig='Normal' [ Normal|Normal2|AD ]
[31] DisplayResolution='1440x1080' [ 800x600|1024x758|1024x768|1440x1080 ]
[32] FrontLight='TABLE3+' [ No|TABLE0|TABLE0+|TABLE0a|TABLE1+|TABLE2+|TABLE3+ ]
[33] CPUFreq='1G' [ NC|800M|1G|1.2G ]
[34] HallSensor='TLE4913' [ No|TLE4913 ]
[35] DisplayBusWidth='16Bits_mirror' [ 8Bits|16Bits|8Bits_mirror|16Bits_mirror ]
[36] FrontLight_Flags=BootON:OFF,TABLE1X:OFF
[37] PCB_Flags=NO_KeyMatrix:ON,FPC_Touch:OFF,LOGO_LED:OFF
[38] FrontLight_LEDrv='SY7201' [ SY7201|A8169 ]

>>bucchiさん

ぬぉｗ 何でなんでしょうね
/opt/cfw/hook/suspend/50suspendを直接キックしたら動いたので
てっきりhook関係かと思ってたのに・・・。

>>aura HD+0.96β1で動作報告くれた諸氏

DB更新中のアニメーションとかは、元データがTouch用とGlo用しかないので
ちょいっと加工しないと使えないんですよね。
なので、aura HDの場合はDB更新中はアニメーションではなくLEDの点滅にするとかに
変更しようか考えちうです。

＃＃ コードネーム・フェニックスの新機種のこともあるから解像度依存のデータは
＃＃ あまり用意しないほうがいいのかもしれませんが

無事に色々動いているようで何よりです。
新UIでも、やっぱりbucchiさんの本棚アイコンは欲しいですねｗ

本棚アイコンモジュール出来ました。

っ http://ux.getuploader.com/KOBO_HACK/download/127/shelveicon-130706.zip

CFW0.96β1 専用です。
touch, glo は動作確認してます。
FW2.6.0 になって結構変わっているので mini は動くか自信無いです。

Gloたんデスクトップアプリから同期しても最新ファームになっちゃうの(´・ω・｀)？
今のままではカスタムファームが死んじゃう＞＜

>>597

getoptのオプション解析終わったあとのファイル引数取り込みで引数が多すぎる場合にでるな＞too many parameters

多分hookスクリプト実行状況下でのpng2rawは0引数を期待する状態
(pipeでpngが渡されることを期待している状態)になってしまっているんだろう。

実行環境から判断したin/out-fileの想定が優先されてしまっているのはまずいので
option,ファイル引数で指定した状態を優先するように修正します。
(stdin/outのチェックで実行環境判断している部分が思慮不足だったのだと思われる)

カスタムファーム入れる意味あるっけ？

カスタムなファームにする意味がある

入れる必要を感じなければ入れなければよい…

>>598

おお、ありがとう。

ふーむ、
>[11] RSensor='G Sensor'
って加速度センサーついてるのか？>aura

それ以外のwifiやタッチパネルのコントロール系は従来(glo以降の機種)とかわりなしだな。

あと目立ったところでは、パネルが電力消費する分バッテリー容量は大きくなってるみたいだなあ。

ファームが 2.6.0になってから、カスタムで入れてフォントが認識できなくなった ><
何が変わったんだろ ?

>>607
自己解決・・・再起動で認識しました

>>600
いつも感謝です。
アイコンが絶妙な位置にあって更に使いやすくなってますね。

>>600
miniでも動きました。
miniでは表示が一部欠けています(アイコンが大きい?)が、
機能的には本棚・検索への移動共にOKです。

>>600
いただきました。ありがとうございます。内部32G換装したgloで使用しています。
2.6.0にアップデートされてからかなり不便でしたが0.96βのおかげでやっと快適なkobo生活に戻りました。
全く関係無いとは思いますが、2.6.0+0.96βにしてからkoboデスクトップとの同期が度々中断されるようになりました。
リセットとかで直るので、特に問題は無いのですが。

png2rawがらみでlibpng-1.6系のAPI等をちょっとだけ精査。

RGB_to_GRAYのtransformがあるので、png decode出力を
grayscaleで出すことができるんだなあ。
#元々輝度情報を分離しているjpegとは違うから、
#結局出力手前で固定小数点で輝度計算してるだけだけど

libpng->rgb888->png2raw内でrgb565->fb内部で4bit gray
よりも
libpng->gray8bit->png2raw内でrgb565->fb内部で4bit gray
のほうがメモリが少なくて済みそうだなあ。

fbのモード変えればgray-8bit->rgb565->gray-4bit
のような無駄なことしなくて済むんだろうけど、
nickelがいる環境下で一時的とはいえモード変えるのはリスクあるから、
そのへんはやむなしか。

transform_shiftとかいう階調ビット幅落としフィルター機能っぽいものもあるようだが、
公式FWのsoのstringsを見る限りSHIFTサポートなしの状態っぽいなあ。

ついでに、某所でのlibpngの話のなかで
普通に作ったら"__ARM_NEON__"がdefineされない
という件があったのが少し気になっていたのでその辺を調べたら、
gccで"-mfpu=neon"指定しないとdefineされないのかな、これ。
linaroのは"-mfpu=vfpv3-d16"デフォルトだから
結局素のconfigureだとneonなし状態の設定になるわけか。

なんか他のでもハマりそうなパターンだなあ、これ…
Qtとか公式にneon対応があるものは
公式FWだとちゃんと有効化してコード生成されているのかなあ。
(vector化みたいな最適化がらみのneonコード生成はともかく)

Touchでカスタムファームβ当てたら、更新中からずっと進まなくなって
初めてファクトリーリセットかけた

>>609-611
返信遅くなってすいません。
動作報告ありがとうございました！

以前、アイコンが押し間違えやすいと報告があったので
他のアイコンとの間隔を少し広げてみたのです。
ちょっとした改善なんですが、気づいて貰えると嬉しいものです (^^)

また、mini でも動作したようで安心しました。
たしかに glo と同じアイコンを使っているのではみ出してるのかも
しれないですね。はみ出してるのは検索アイコンでしょうか。

変換アダプタを使ってコンセントから充電しようとしたらPCに接続しますか？と表示されたんですが・・・・
これはこのまま接続を選んで良いのでしょうか？

[WikipediaReader(libwikipedia)]
外部のzimプログラムとの関係はみていないが、
plugin内部のReaderはkepub継承のWebKitでのhtml表示。
主なところはkepubの実装まかせで独自処理は少ない。

目についたのは、"PowerManager::aboutToSuspend(SuspendControl *)"なシグナルの使い方。
"aboutToSuspend()"をslotに繋いでおくとサスペンド前に飛んでくるので、
自分にとってサスペンドされると都合が悪いタイミングなら
その引数SuspendControlに対してSuspendControl::veto()を呼び出して
拒否することができるようだ。

「戻る」のラベルボタンは、kepub継承のWebkitブラウザでの
共通操作としてのページ戻り機能っていうことのようだなあ。
epubなんかでも目次からlinkでjumpした時に「戻り」表示されるし。
(おまけブラウザは直接Webkit継承だから自前で上部に戻りボタン出しているけど)

####

__ARM_NEON__問題。

"-mfloat-abi=soft"はhardの間違いじゃないかなあ？
ヘッダarm_neon.hのinclude時のcheckで引っかかった時に
errorメッセージの中の設定例でそれが出ているけど、
実際のgccのソースarn.hだと
if (TARGET_NEON) \
　{ \
　builtin_define ("__ARM_NEON__"); \
　builtin_define ("__ARM_NEON"); \
}
で
#define TARGET_NEON (TARGET_32BIT && TARGET_HARD_FLOAT \
　&& TARGET_VFP && arm_fpu_desc->neon)
だから、逆に"-mfloat-abi=hard"必須だと思う。
linaro toolchainの実動作上もそうだし。
だから、linaro toolchainの-mfloat-abi=hard設定を前提にすれば
追加"-mfpu=neon"だけで__ARM_NEON__がdefineされる。

>>615

別に接続しても実害はないと思うし、接続しなくても充電は行われるので、
どっちでもお好きに、っていう感じだと思う。

コンテンツスキャンとCFWのコンテンツ処理を走らせたい時に、
充電アダプタなのにわざと接続PCを選んでておいて、
ケーブル抜いてコンテンツスキャン走らせるっていうのは
よくやってる。
(実際にPCに接続させて取り出して、っていうのよりお手軽なので)

>>616

あ、例は"-mfloat-abi=soft"じゃなくて"-mfloat-abi=softfp"か。
だったらarm_neon.hの例はそれで間違いじゃないな。
linaro toolchainだと"-mfpu=neon"だけでdefineされるっていう結論にはかわらないけど、

・png2rawバグ修正
ひっそりとアップしておきました。
ついでに、ちょっと内部処理もいじっって軽負荷化を図ってみた。
あと、検討中なのはlibjpegでのjpegロードと、
異解像度機種のための拡大処理。
真面目にやったところで最終的にgray-4bitに落とされるから、
お手軽にバイリニア補間だけでいいかなあ、とか。
(fbmngplayのほうはちょっと考慮しないといけない要素が他にもあるので
お手軽に拡大処理を突っ込むわけにもいかないかもしれない…)

・libcb-hack.so(旧libcb-zoom-hack.so)
ブラウザでの設定ができてないけれど、まあ生ものとして上げてみた。

htmlだとコントロール部品の表現力がアレだし、
頑張ろうとするとJavascriptだし、
Kobo上だと下手をすると操作性が悪くて逆に使いづらくなったりするし、
というので、モチベーションはロー。

いくつかのパラメータ設定profileを手書きでファイル化しておいて、
メニュー選択でprofile選んでfifoに流し込む方式なら単純だし、
テスト用途だとそれでもいいかな、とか思い始める今日この頃。

localの指定pathのファイル名を取り込んでメニュー項目化とか考え始めると、
結局html5+JavascriptでQt4.8.0のWebkitの対応度によるし、
その辺はshでのcgiで埋め込んでhtml生成するとかで躱したほうがいいのかな。

>>614
miniは本棚アイコンのほうが重症です。
http://img.wazamono.jp/pc/src/1373381509146.jpg
検索アイコンは虫眼鏡とわかりますが、
本棚は元のアイコンを知らないと何だかわかりません。

>617
その手があるのか
電源onoffじゃ本棚更新されなので、パソコン起動してusb刺してた

>>620

SizePolicyをFixedから変更してリサイズされるようにすれば治りそうな気がするけど、
他のmini専用で持ってない共通リソースをminiで表示するときはどう設定しているのかなあ。
(nickel内でのお作法として)

・busybox viのutf-8対応

shなんかでの入力では漢字1文字のハンドリングは正常だから
共通libの行編集などではバイト数≠文字幅なutf-8を正常に扱えている。
だからvi内部でカーソル画面桁位置計算が対応していないのだろうと重い、
ちらちらとbusybox vi.cを眺める。

そういえば"^x"等表示不可な文字の場合特殊な表現になったりするわけだから、
必ずしも1バイト=画面1文字幅固定な短絡した数え方じゃないはずだよなあ。
コントロール文字等の特殊な桁数えをしているところにpatchして
utf-8先頭文字が来たらutf-81文字分のシーケンスを
全部消費するように数えるのが基本形かな。

問題はそのutf-8の1コードシーケンスと画面上の文字幅の対応づけ。
当座しのぎならなんとでもなりそうだけど、
真面目に対応しようとなると困ってしまう。
libbbのunicode対応関数でその手のutil関数あるかなあ…。

それと、NFC,NFDあたりの正規化がらみの問題もあるがこれはpendingだろう。
Macで"が”みたいな濁音文字が"か"+濁音コードのUNICODE×2で
符号化されちゃうっていうやつね、主に気にしているのは。
(busyboxの場合既存のlibに丸投げできないから面倒そうだ)
#何らかのterm経由でtelnetで入って使う前提になるから、
#その辺はlocal側でUNICODE文字コード正規化かけられる前提で
#無視しちゃっていい問題なのかなあ？

ある程度落ち着いたらFW2.6用の外部sd文字化けパッチをリリースして頂ければ嬉しいのですが

>>624
>>510-511
ベータ版は使いたくない、ならじっと待つしか無いです

touch+0.96bだけど、readmeに書いてある基本的なとこ？はちゃんと動いてるよ。
ありがとう。
新ファームって本棚編集なんかが軽快になってんだな。
一応公式開発チームもがんばってんのね。

届いたばかりのgloでeasyKoboBackupがバックアップ失敗してしまい
起動しなくなったらどうしようと不安ではあったけど
おっかなびっくりでCFW_Ver0.96β1入れてとりあえず使えてる

なぜか同じ著者なのに [著作者名] 書籍名.cbz で著者名が
認識されるのとされないのがあるのが気になった。
まだkoboの使い勝手に慣れてないんで使い込んでないけど開発者様に感謝

>>625

ベーダ版だから使いたくない云々の問題じゃなくて、
多分624の人はCFWの追加機能はいらなくて、
[2.6.*系対応の外部sd文字化けパッチ]単品が欲しいんじゃなかろうか？

>>627

>なぜか同じ著者なのに [著作者名] 書籍名.cbz で著者名が
>認識されるのとされないのがあるのが気になった。

ありがちなのは"[”や"]"が全角になっているケース。
特に"]"のほうは、後ろに空白が入ると
"] "(半角"]"+" "の2文字)
と
"］"(全角1文字)
でフォントによっては識別しにくい場合がある。

>>629

んー、zip→cbz等と同じタイミングで、
全角"［"や"］"を使っている"［著者］ タイトル.cbz"形式ファイルを
半角に正規化するような前処理を走らせておけば
この手のミスは対策できるかな。
版数や出版年月等の備考的なものをタイトル以降に全角括弧で付記するなど
意図的に全角括弧を利用しているケースで誤認しないようにしないといけないけど。

>>620
写真ありがとうございました。
助かります。

なるほど。本棚アイコンのマージンを増やしたせいで
追い出されちゃったんですね。
時間がとれたらちょっと直してみます。

>>628、625
意図は628さんの書いた通りです。
初Koboなのにaura発注してみたものの、本体のバックアップ取れるか不安だったので外部SDの文字化けパッチ単品だけでまずはチャレンジしてみたかったのです。
スレチですいません。

>>632
auraだったら無理に2.6.1にする必要なし
ここ↓から 2.5.2(Mark 4 Hardware)をダウンロードして適用してからCFW 0.95で快適
ttp://www.mobileread.com/forums/showthread.php?t=185660
2.5.2でもauraなら新ホーム画面なので使い勝手がいいよ

うっかり2.6.1になっちゃったらファクトリーリセットしてやり直せばいいし

>>625,628
自分が624さん同様それを望んでる一人です。
ベータ版だから嫌とかじゃなくて、外部SDの文字化けさえ
なくなればそれで良いという者もいるんです。

gloで必要にして十分だったので、昨日来たauraにも0.96β1を入れてみました。
自分的に必須なのが本棚と文字化け解消、ページ送り向き変更なので、
快適にauraを使えてます。
いつもながら感謝です。

>>634
俺もそうだわ。そうはいってもないものは仕方ないから0.96入れてまぁ今はそれで使ってる

2.6.1でも一部漢字をファイル名に使うと本体のストレージでもゴミになるから
外部SDの文字化けだけじゃ足りないよ

aura用にコミック自炊するときは解像度はどう設定すればいいのですか？

gloに最適化したもには拡大して表示されるのですか？

auraほしいなー！

>>638 仕様公開されているし、DbyDにするならやり直しかな
片面表示か見開きにするかでかなり変わってくる
解像度的に見開きでも文字の識別は可能な解像度ではあるけど
小さいので多分無理、豆本以下になる

拡大表示はされるけど、自炊するならやり直すべき

x>>638
glo用(758x1024)に最適化してるなら特に支障なし
touch用(600x800)ならやり直し推奨
小さい画像でもcbzなら勝手に拡大表示されるよ

スリープモード壁紙、フルスクリーンにしなければ、文字は掛からない位置に出ると思うので、
そちらを検討していただけないでしょうか

拡大縮小といえば、cbz/cbrだとスムージングありでスケーリングされるんだけど、
pdfの場合はスムージングなしな気がする。

QImageに対するスムージングありのスケーリングだと一旦RGBにしてから行われるので、
非DbDな画像or拡大中は、画像を読み込んだ直後にRGB化されちゃうんだよなあ。
なるべく最後までグレスケで持って行った方がメモリ節約に…とか思っていたが、
サクッとRGB化されるケースが多そうだと分かってちょい残念。
(書庫からの読み取り時間とか、jpeg/pngのデコード負荷低減とかにはなるけど)

画像ベースのpdfをいじっている間、裏側のCPU位置付近が
妙に結構熱くなっていることに気付いた。CPU負荷が高いのかな。

#他機種との兼ね合いでpdfベースで運用してる人って、
#やっぱKoboだとなにかと大変そうだわ。

>>639
>>640

auraに最適化する場合は、1440x1080で作れば良いのですね〜。
やっぱり、glo用に作った物の拡大よりはキレイなんでしょうね。

>>643
758x1024=776192
1080x1440=1555200
だいたい倍だから入る本が半分に減るぞ

WirelessWatchdog::aboutToKillWifi(SuspendControl *)
WirelessWatchdogがWiFiのタイマー切断の監視クラス
WirelessWatchdog::safe()かスレッドからならWirelessWatchdog::kickThreadSafe()で起動
(kickThreadSafe()はeventのpost経由で自クラスkick()呼出し)
意図的にWatchdogを止めたり再開したりするのはsetEnabled(bool)

kick()にしろsetEnabled(true)にしろ時間間隔5分固定(変更不可)の繰り返しタイマーで
QTimer::timeout()→WirelessWatchdog::attemptToKill()のsignal-slot

attemptToKill()内で、
WirelessWatchdog::aboutToKillWifi(SuspendControl *)→登録slot
でWiFi断の問い合わせ
結果をSuspendControl::suspendAllowed()で照会しOkなら
WirelessManager::off()
で実際の切断処理

WirelessWatchdog::aboutToKillWifi(SuspendControl *)にslotを繋いでおいて
飛んできた問い合わせにSuspendControl::veto()で拒否るモジュール作れば、
WiFiつないだままでnickelの操作してデバッグできるようになるかなあ。

>>616 の"PowerManager::aboutToSuspend(SuspendControl *)"は
PowerManager::canSuspend(void)が同じようなことをしている。
というかSuspendControlのネーミングからするとこちらが本家。
こっちはsuspend()内からcanSuspend()経由で問い合わせて許可なら
suspendDeviceWithAlarm(void)で実際のsuspend処理への流れか。

>>625,628,634,636
これ↓じゃダメなのか？

Kobo Touchのバグ退治
http://d.hatena.ne.jp/goriponsoft/20121124

2.6.0に当てたけど、外部SDの文字化けはしていない。

>>646

外部sdの文字化け対策は依然として有効だと思うよ。
内蔵sdのポ・ソ系ダメ文字対策はdosfsckが更新されたからどうだろう？
dosfsckのバージョン自体は変わってないから、
外部lib変更の影響を受けないなら古いのが上書きされても問題ないのかな。

需要多そうなので・・・

ttp://ux.getuploader.com/KOBO_HACK/download/131/KoboPatch_for_2.6.x.zip

CFW化はせず、SDの文字化けとダメ文字問題だけ回避したパッチ。
0.96β1から引っぺがして再構築。

多分大丈夫だとは思うけれど、作者は全く動作確認してまへんｗ

今回は、公式CFW2.6系であればminiだろーがaura HDだろーが大丈夫だと思う。

フォント共通テンプレが最初は適用されたのですが
二回目から変更して再起しても変わりません
何故でしょうか？

Libnickelの中、おまけブラウザ周りのコードを散歩。
過去にアイデアが思い浮かんでstockしていたものを掘り返し調査。

・お気に入り
なかなかハードル高し
select&goはsignal hookで済みそうだが、
add->save Qsettingsやload Qsettingsの流れに
うまく割り込めない。
いっそQSettingsを乗っ取る方がいいのか？

・ダウンロード関連
ダウンロード可能拡張子を追加することはできそうな感触。
(pluginのサポート拡張子QStringListに追加するような仕掛け)
zip拡張子がダウンロードできるようになったとして、
ダウンロード先dir指定をどうするか？
N3FSSyncManagerでスキャンさせる前に移動させないとまずいが…
N3FSSyncManagerへの"/mnt/onboard/"下のファイル指定scan依頼の場合に
pre-process hookして移動させてパス名文字列も変更してから本来処理を動かすか？
zip→cbzはmv後にhook scriptに流せばOkか？

・ブラウザフォント
ctorのpost-process hookかloadviewのpre-process hookあたりで
setfontすれば指定できるかなあ。

・エンコーディング指定
そのうちブラウザの設定メニューに追加したいものだ…

>>643 小説はそうでもないけど、コミックはかなり見やすくなる
スクリーンが潰れずに見えるようになるしね

文庫小説の自炊は縦1400でスキャンしたデータしか残っていない

kobo auraと言えばauraの分解の仕方って教えていただけないでしょうか

>>652
touchやgloと違ってauraはまず額縁を外す
ただし、額縁と液晶が両面テープで接着されているので、慎重にやらないと額縁が割れたり、最悪液晶が割れる
最初の一回目はゆっくりあせらずやるのが吉
クレカや爪じゃなくて、ちゃんとした道具を使ったほうがよい
アマゾンで「iphone 分解」で検索して出てくるような安物でおk

一度分解できたら両面をきれいにはがしておくと二回目からは楽
コツは四辺のツメを全部浮かせておいて、ゆっくり両面をはがしていくようにする
ツメの数は縦横共に等間隔に六箇所、全部で24箇所ある
本体側にツメがあり額縁側は受けになってるので、道具をすきまに差し込んで本体側にコジる感じ

額縁が外れたら、内部の四隅のネジを外すと基盤が外れるので、裏側のmicroSDにアクセスできるようになる
ネジはプラスネジだが、精密ドライバーやメガネ用のドライバーを準備しておくこと
基盤を外すときは上側から引き起すようにすると外しやすい
ちょいちょい殻割をするようであれば、ネジは外したままでもとりあえず問題なし

組むときは上部のスライドスイッチの噛み合わせに注意
額縁をキッチリ嵌めないとタッチ操作が効かない

こんなとこかな

>>653
652じゃないけど、ありがとう。
明日32ギガのカード買って換装にチャレンジしてみる。

>654
652だけど写真付きでアップお願いします。

>>654
>>655
すすめも止めもしないが、殻割のあとはちょっとプカプカするぞ
後悔しないようにな

>>648
なんか>>646と同じ内容の、バージョン非依存パッチの/etc/init.d/rcS2が組み込んであるのに、
わざわざ/usr/loca/kobo/udev/sdや/usr/loca/kobo/udev/usbが含まれててバージョン依存してる。
無駄だのぅ。

dosfsckコマンドのバージョンに問題がないなら>>646のほうが余計なものがないだけマシな気が……。

>>657

パッチってえのはそんなもんだべ。

dosfsckがバージョンアップして苦労したんだ。そこは勘弁してくれい。

2.61βでjpeg高速化が効果あるのか確かめる為に自炊cbz本のページ送り速度比較しようとしたら
2.61βから0.96β入れるだけで二倍ぐらい早くなった
0.96βにjpeg高速化ライブラリ入れてみたけど体感ほぼ変わらんなあ
cfw入れただけで随分早くなったことにビックリだ

auraはから割り止めた方が良いのかのぅ
でもDD無しにカスタムファーム化するのは怖いんだよね

んー、そういやメンテファーム for Auraもないから、
Aura殻割りなしであれこれやってる人はある意味チャレンジャーなんだなあ。
(telnetで入ってddで外部sdにバックアップするとかしてればなんとかなるか)

1)HW CONFIG領域(0x80000〜)
2)WAVEFORM領域(0x6ffe00〜)
3)u-boot,kernel
(3)は公式ファームから取れるのでいいんだけど、
(1),(2)の提供がないとメンテファームは作れない(はず)。
(HW CONFIGはこないだツールでの読み出し値を教えてもらったから
手作業でバイナリ形式に戻すこともできるけど)

waveform,hw-configが実環境(aura)と合ってない状態でbootして
画面表示ができないのとかは無視して
usbnetで入って作業できる実効動作可能なのかなあ…
周辺デバイスはあまり変わってないから
glo用でなんとか凌げそうな気がするんだけど。

>>661
情報やデータの取り方を教えてくれれば提供できるよ
microSD抜いてLinux上でホゲホゲするのも可

CFW0.95を入れてから、再現条件は不明ですが、時折ページ送りの向きが逆になることがあります。
むしろ、逆の方が使いやすいのですが、任意に変更する方法は無いでしょうか？
右手で持つ時に、右側タップで次ページ、中上部か左側タップで前ページの設定が理想です。

それ元のシステム設定で変えられるじゃん

>>664
元々の設定で変えられる3パターンの、ページ送りの向きを逆にしたいのです。
現在、原因不明ですが時々ページ送りの向きが逆になってくれています。

>665
同士よ！送りが広い方が良いですよね

横書きと縦書きのページ送り方向の違いのせいじゃないの？

glo+2.6.0+CFWで
時々、ショップ購入本が自動本棚に振り分けられないわけだが
何かキーが変わってるのかな？

プレビューは別項目があるからいいけど、
正規の本が本棚登録外れると探すのがめんどくせ。

初期化してglo 2.6 cfwも2.61β
だいたい問題なく入ったんだがフォント共通化だけ効かない

0.95用のアイコン位値最適化したパッチはないのでしょうか？

>>663
同じ症状です。
不思議なんだけど自炊文庫cbzは左タップで順送り。ところが新書自炊cbzでは右タップで順送り。
PDFならまだしもcbzですから開き順が記録されてるとも思えないし。

>>671
横書き。縦書きでページ送りのデフォが逆なのと
関係が有ると思われ。画像はオリジナルの
横書きと同じに成るんでしょ。

>> 671

cbz/cbr/pdfページ送り修正を使っていて、
特定コンテンツで常に発生する現象なら、
修正対象を選択する条件に合わないコンテンツが
登録されることがあるってことだよなあ。

>> 663
663さんのはcbzの話だとすれば、やりたいことって
CFWの送り方向補正をoffにして登録しなおせば済むんじゃないの？
(epubで右タップ順送りにしたいっていうなら
新たにDB書き換えなる機能がいるだろうけど)

Kobo glo買おうと思うのですけど、
楽天から買うとエントリーで10ポイントって書いてあります。
これって10円ってことですか？
ビックでもほとんどポイントつかないので、安く買う事って出来ないのかな。

>>673
何でここに書くの？
知恵遅れですか？

エントリーはドロアプリのほうだね
glo今買うってことは2000円クーポン組だろうから590円分くらいつくんじゃないかな

>>28
＞ご存じだと思いますが、SD、SSD、HDDに限らず、フォーマットすると
＞おおよそ10％容量が減ります。

ものすごい亀ですまんがそれフォーマットのせいじゃねーよ
1000000000Bを1GBって表記して売ってるメディアのせいだ

>>676
二進法の計算できないだけだよ

>>672
自炊cbzは画像なのになぜ開き順が変わるのかが不明なんです。
ちなみに自炊文庫、新書ともに底本は縦書きです。
実はちょっと思い当たるのが、文庫は内蔵SD、新書は外付けSDに保存してること。明日にでも検証してみます。