MacBook Pro Retina 13で、擬似解像度をWUXGA相当(Retina)に設定可能にする
はじめに
MacBook Pro Retina 13で、標準で設定可能な最大擬似解像度は1680x1050です。
Display Menu などのアプリを使うと、2560x1600など、様々な解像度が設定できるようになりますが、Retina状態での最大擬似解像度は1650x1050です。
システムファイルを改変することで、Retinaかつ1920x1200擬似解像度を利用できます。数週間利用したところ、安定してそうなので紹介します。
検証機
MacBook Pro Retina 13-inch Late 2012
Mac OS X 10.11.1
免責
- バックアップを取りましょう
- 責任を負いません
方法
http://blog.shiftky.net/2015/01/13inch-macbookpro-retina-1920x1200-hidpi.html
だいたいこれを参考にしましたが、多少状況が変わっています。
差分だけを書くと、まず /System/Library/Displays/Overrides
は、/System/Library/Displays/Contents/Resources/Overrides/
に変更されているため、そこを読み替える必要があります。
また、El CapitanからのSIPの影響でシステムファイルの改変ができないので、作業前にSIPを(部分的に)無効にする必要があります。
リカバリモードでcsrutil enable --without fs
とするとシステムファイルへの書き込みが可能となるので、その後に起動し、作業しました。
作業終了後には再びcsrutil enable
で戻して問題ありません。
状況
最もGPUが貧弱なRetina Macですが、El Capitanのおかげもあってか一応問題ないパフォーマンスで動いています。
文字は小さくなるものの、作業領域が増えるので快適です。
Fire TV Stick買った
買った(レビュー)
Fire TV Stickが1,980円だったので予約注文したものが届いた。
Amazonプライムは先月で切れて更新していないので、プライムビデオは見られない。(不良顧客)
初回起動、セットアップ
最初は表示が崩れたりして不安定であったが、5分ぐらい放置したら直った。
セットアップはAmazonアカウントのログインと、PSKの入力がだるいが簡単に終了。最後にチュートリアル動画を見せられる。
初回起動時は動作が遅いが、放置したり再起動したところ軽くなった気がする。
再起動は設定メニューから行える。
UI
リモコンの応答速度は良い。しかしUIは概ね微妙。
ソフトウェアキーボードがとくに酷い。カーソル位置の概念がないので、入力中に間違えたことに気がついた場合、間違えた位置まで全消しする必要があるのが厳しい。
そもそもリモコンでポチポチ操作する文字入力が使いやすくなるわけがないので、入力はアプリでやろう。
また、ホーム画面の検索のソフトウェアキーボードと、アプリで使われるソフトウェアキーボードは微妙に異なる。
周辺機器
設定画面からBTデバイスをペアリングできるので、ThinkPad Bluetooth Keyboardを繋いでみた。
US配列として認識されてしまうが、日本語入力モードであれば、日本語入力も可能。キーボードから入力切り替えはできない。
カーソルキー、エンターキーがリモコンの方向キー、Escが戻るキーとなる。ホームキー相当は見つからず。
Windowsキーを押すと、検索ボタンとして認識されているのか、何故かGoogle検索画面(通常どこからも辿り着けない)に行き着く。
基本的にあまり考慮されておらず使いにくい印象。
マウスは、アプリによっては対応が不完全だが、利用できるものもある。ホーム画面では反応しない。
対応動画サービス(アプリ)
このへん
暇だしNetflix無料体験はじめようかなと考えている
適当に使ってみたもの
- YouTubeアプリ
- ニコニコ動画
- 動作が重い、テレビで低画質だとつらい
- Amazonプライムビデオ(無料動画)
- 早送りなどのUIが良い
- VLC
- アプリが起動していない時でも何故か再生ボタンを乗っ取っているのが不便
- ES File Explorer
- 普通のAndroidのファイラ、SMB越しで動画再生なども可能
- UIがリモコン向きではないが操作は可能
ゲーム
これでやらないだろ
スマートフォン連携
- Amazon Fire TVリモコンアプリ - Google Play の Android アプリ
- Amazon Fire TV Remote on the App Store
- 公式のFire TVリモコンアプリ。音声検索と文字入力が有用、リモコンボタン機能はあまりメリットなし。
- 携帯電話、タブレット、パソコンで YouTube on TV をコントロールする - YouTube ヘルプ
- AllCast
- 動画とか飛ばせる
Miracast
アプリ
Fire TV StickはAndroidベースの棒なので、任意のapkを突っ込んで遊べる。 不良顧客なのでこのへんで遊ぶ。
- Apps2Fire - Google Play の Android アプリ
- Android端末からADB経由で、Fire TVに任意のapkを突っ込めるアプリ。PCで
adb install
するより楽
- Android端末からADB経由で、Fire TVに任意のapkを突っ込めるアプリ。PCで
- Releases · sphinx02/FireStarter · GitHub
- Kodi
- 昔からあるメディアセンターアプリで、プラグイン機構などもあり色々できる
- Skin->Fonts->Arial basedに設定すると日本語対応フォントになる
- SMB越しで動画を再生可能
- AirPlayに対応しているようだが、iOS9以降とは現在非互換の模様。El CapitanのMacでもAirPlayは利用できなかった。 http://forum.kodi.tv/showthread.php?tid=238523
- このへんの対応を謳うアプリであればできそう(有料) Amazon.co.jp: AirPlay Mirroring Receiver: Android アプリストア
- Firefox Mobile
- スペック・UI的に実用性はあまりない
- エムキャス入れてMX見ようと思ったら、Google Play Servicesがないので起動できなかった
結論
1,980円にしては使えそう。色々とソフトウェアに改善の余地がある。
追記
このアプリを利用することで、iOS9/El Capitanデバイスからの、AirPlayスピーカー、ビデオストリーミング、ミラーリング(1080p)の動作を確認した。
ビデオ再生は、iPhoneでは写真/Safari/YouTubeアプリ、MacではiTunesからの再生を確認(Mac QTからはなぜか再生できず)。
Google I/O とクールなURL
year | url | status |
---|---|---|
2015 | https://events.google.com/io2015/ | |
2014 | https://www.google.com/events/io/ | |
2013 | https://developers.google.com/events/io/ | |
2012 | https://developers.google.com/events/io/2012 | |
2011 | https://www.google.com/events/io/2011/ | 404 |
2010 | https://www.google.com/events/io/2010/ | 404 |
2009 | https://www.google.com/events/io/2009/ | 404 |
2008 | https://sites.google.com/site/io/ |
Slideshareで読み終わった後に勝手に飛ばすアレ
雑
// ==UserScript== // @name Slideshare no next // @version 0.1 // @match http://www.slideshare.net/*/* // @grant none // ==/UserScript== window.addEventListener("load", function(){ SSPlayerController.prototype.showNextSlideshowCTA = function(){}; }, false);
Tampermonkeyで動作確認。Slideshareには人の心がない。
追記
onloadだとうまくいかないケースがあるので雑だと微妙っぽい
さらに雑な解決
var exec = function(){ SSPlayerController.prototype.showNextSlideshowCTA = function(){}; }; window.addEventListener("load", exec, false); setTimeout(exec, 10000);
アニメ内における「コミケ」の呼び方について
ほげ
冴えない彼女の育てかた 第5話を見ていたところ、「コミックマーケット」「コミケ」などの単語が聞こえてきた。
コミケというのはともかく、コミックマーケットという名称を出すアニメは珍しいのではないか。コミケすらぼかすアニメも多いのではないか。と思い、調査隊は同人誌即売会が登場するアニメの調査を始めた。
調査対象のアニメは、自分が見たことのある作品の中で、コミケ回があった気がするアニメとした。
一覧
title | ep | result |
---|---|---|
冴えない彼女の育てかた | #5 | 「コミックマーケット」「コミケ」 |
俺の妹がこんなに可愛いわけがない。 | #4 | イベント名は言及なし、と思いきや「コミケ」と終盤に1度言った |
らき☆すた | #12 | 「コミケ」 |
ゆるゆり | #5 | 「コミックエクストリームマーケット」「コムケ」 |
じょしらく | #4 | 無言で通りかかるだけ |
デンキ街の本屋さん | #1 | 「コミックカルナバル」「コミカ」 |
さよなら絶望先生 | #7 | イベント名は言及なし |
俗・さよなら絶望先生 | #7 | 「夏コミ」がメール文中に登場 |
Steins;Gate | #19 | 「コミマ」 |
まとめ
本題:とくにないな…
その他:4~5話にコミケ回が来るアニメが多いのではないかという知見があった
ほか
コミケとの接触のあるアニメを探し出すのは思ったよりも難しいことがわかった。
放送されるアニメ全てに字幕が入る時代が来れば、全文検索で色々とアレできると思うのでそうなってほしいですね。
InstantGo対応Windowsタブレットで、画面オフの状態で裏でデスクトップアプリを動作をさせる
# 8月ごろに調べてエントリを書こうとしてたものなので、12月現在何かもっといい方法があれば教えてほしい
はじめに
InstantGoについての基本
http://win-tab.net/misc/instantgo/
http://ascii.jp/elem/000/000/872/872162/
検証機:VivoTab note 8
要求
普通のPCで、数十分ぐらい時間のかかる処理をさせて放置しておきたい場合、ディスプレイの電源ぐらいは切っておきたいですね。Dropboxの初期同期とか、Visual Studioのインストールとか。
ノートPCだと放熱などもあるので尚更そうしたい、タブレットならさらに尚更ですね。
しかしInstantGoに対応したタブレットでは、処理を動かしたままディスプレイのみを切るという操作は標準では見当たらず、スリープ(Connected Standby)・シャットダウンしかとれる操作がない。
つまり画面オフの状態ではデスクトップアプリの処理は停止してしまい不便。なんとかしたい。*1
消費電力の都合もあるので、デフォルトがこの挙動なのは好ましいが、抜け道も用意してほしい。
探した結果
以前のWindowsからのMonitor OffのAPIを叩いていると思われるソフトウェア(nircmd monitor off など)を実行すると、Connected Standby状態に入ってしまう。
従来のモニタオフに相当する操作が、全てConnected Standbyへの移行に置き換えられているようだった。
確かにスタンバイ状態と思いきや単なるディスプレイOff状態ということになると、知らぬ間にバッテリが消費されるような動作をしてアレなので妥当ではあるが、代替策を用意してほしかった。
代替
とりあえず、C:\Windows\System32\scrnsave.scr
を実行するとブランクのスクリーンセーバーが表示されるので、これを利用することにした。
この場合は単に黒い画面を出力しているだけと思われ、画面のバックライトが消灯しないので省電効果は微妙。
あとはInstantGo Disabledで運用するという手もあり、多少のメリットもあるが、代償も大きい。
発見
ここで無理っぽいなとエントリを書こうとしてもう少し探したところ、Connected Standbyに遷移しないわけではないが、裏でデスクトップアプリケーションを動作させたままにする方法がわかった。
Prepare software for connected standby (Windows Drivers)
ここの表から、Desktop Activity Moderator (DAM) phase
という状態があることがわかる。
説明によると、Connected Standbyに向けてデスクトップアプリケーションを停止状態に向かわせるためのステートであり、バッテリー駆動では5分をリミット、電源供給ありの場合は制限なしでこのステートに留まれることがわかる。
また、PowerRequestExecutionRequired
リクエストを投げるとこのステートに入れることがわかる。
リクエストが投げられているかどうかは、powercfg.exe /requests
の実行:
にプログラムが表示されているかどうかで確認できる。
これで捜索したところ、このあたりが見つかった
http://social.msdn.microsoft.com/Forums/ja-JP/6c135adb-7993-4691-b700-bd463ed8816c/windows-8-connected-standby-vs-desktop-audio-player-application?forum=windowssdk
http://stackoverflow.com/questions/23398950/any-api-to-prevent-windows-8-from-going-into-connected-standby-mode
後者のコードを参考にして実行したところ、確かに裏でDropboxの同期、ソフトウェアのインストールなどが継続できることが確認できた。
またpowercfg.exe /requests
の実行結果によると、Chrome(デスクトップ版)でダウンロードを実行中、同じリクエストを投げてダウンロードを継続しようとしていることが確認できた。
さらなる検証
しかし、サウンド再生はこの状態ではできないようだった。
動画などを再生しリクエストを投げた状態で画面をオフにすると、スピーカーから音声の再生は止まるが、再び画面をオンにすると再生時間がその分も進んでいることがわかるので、
サウンドインターフェースをWindowsが休止させているのではないかと思い、
ではストアアプリで音楽再生をしたままデスクトップで再生して画面オフにしてはどうかと試してみたところ、デスクトップアプリ側の音だけが聞こえなくなり、ストアアプリ側は継続して聞こえるという結果になった。
ネットワークに関しては、リクエストを投げない状態の場合、pingには問題なく応答するが、適当にiperfのサーバ側を動かして試したところ、何故か繋がったり繋がらなかったりするよくわからない状態になり、
リクエストを投げた状態の場合は、問題なく動作するという結果になった(つまり問題ない)。
結論
サウンド再生がしたいわけではなく、インストールや大規模な同期をする時にはだいたい電源があるので、個人的な要求はこれでまあまあ満たされた。
しかし画面オフのままUSB-OTG接続したUSBメモリに大容量ファイルコピーをしたい場合など、VivoTab Note 8の場合は電源供給と両立できないので困るなと思った(今のところそのシチュエーションはない)。
わりと便利なので使うといいと思いました。タスクトレイに常駐するUIでも書こうか。
不自由な電子書籍の自由化の自動化
経緯
昔、不自由な電子書籍(単独アプリのタイプ,数百ページ)を、iPadで1枚1枚スクリーンショットを撮って自由なpngにした後にPDFにしたことがあった。スクリーンショットを撮ってページを送ってというのを延々と繰り返していた。
アニメ見ながら無心で作業するとかなら案外なんとかなる。まああまりやりたくないですね。
現状
iOS/Androidの電子書籍系アプリというのは、だいたいDRMがついてて、フリックで次のページに移動して、スクリーンショットは普通に取れるという感じではないかと思う。*1*2
スクリーンショットの撮影を自動化すると、様々なアプリで汎用的に利用でき、法的にも問題なく良いのではという気がしたので、Androidでの実現性について調べた。
なお、スクリーンショットを封じていたWindowsの電子書籍ソフトウェアのスクリーンショットを、無理矢理撮影するソフトウェアの製造で逮捕された事例が存在する。
技術的保護手段の回避
がどこまで適応されるのかはわからないが、普通にスクリーンショットを撮影できるアプリならば大丈夫なのでは。
http://www.itmedia.co.jp/news/articles/1402/20/news045.html
方法
これを実現するためには、
調査の結果root権限が無くとも、adbが利用できれば両者を実行できることがわかった。
adb shell screencap -p /sdcard/sc.png
adb shell input touchscreen swipe 500 500 1000 500
の2つを用いて、目的の操作が可能なことを確認した。(isai LGL22 Kitkat)
コマンドの実体は端末の/system/bin/ にあるので、adb shellの権限で適当に叩けばよさそう。
iOSでやろうとするとJailbrokenなデバイスでなんかやるんですかね(適当)
問題点
当然、スクリーンショットで自由化する問題点が引き継がれる。
- 文字データとして利用できない
- スクリーンショットの画像の解像度が端末の解像度に制限される
結論
DRMが死んでほしい