セリア100円LEDライトの透明化改造

お絵かき用の左手デバイスとしてテレビの赤外線リモコンを使用しておりますが、中々良いです。 応答速度がやばいほど遅いのではと危惧しておりましたが、試しに作ってみたところ、全然大丈夫。 ローコストで入手性も高く実に良いと思うのですけどねぇ

ちなみに自作受信器の中身はatmega328で受信、MCP2221でUSB-TTL通信し、PC(Linux)側では専用daemonが待ち受けてuinputでキーコードを吐く仕組みにしております。将来的にはこれをPC側のdaemon無しに単体で動くように、大昔買ったまま放置してあるトラ技の78K0オマケ基盤をUSBキーボード化して、それとatmega328が通信してUSB化するという構想なのでした。*1

まぁ普通にビットトレードワンのリモコンキットを買えば廉価かつ確実、しかもこれだけでUSBキーボードになるようです(^^)

ビット・トレード・ワン USB赤外線リモコンアドバンス ADIR01P

が…これはリモコンボタンを押しっぱなしにしてる間、キーを押下したままにしてくれるのだろうか？ 例えば、shiftキーを割り当ててそのボタンを押している間、shiftが押しっぱなしになってくれるだろうか？…という疑問が今イチ拭えなかったということも自作に走った一因です。

ちなみに自作受信器では、「同じリモコンボタンが108msぐらいの一定時間内にリピートしない、もしくはリピートコードが来なければ、ボタンを離したという事にしてuinputにキーのリリースコードを生成」という仕組みにしております。

ただ、押下状態を保持したいボタンは極少数。リピートするとパカパカして使いづらい機能のほうが圧倒的多数なのですね。 そこで一部のボタンについてのみ、設定ファイルでモデファイアフラグ「holdable」を指定することで押下状態保持を明示的に指定。 デフォルトでは、「リモコンボタンを一発押したらワンショットですぐにリリースコードを生成し、直後の同一リモコンボタンのリピートを無視する」という仕組みです。*2

ワタクシ、自分の改造版MyPaintではshiftキーを押しっぱなしでペンタブのスタイラスをドラッグするとブラシサイズを変更、という機能に割り当てているので割とキーを押しっぱなしに出来るかどうかは重要なのです。Kritaでも同じです。あとCTRL押しっぱなしでカラーピックとか、これも同じ。

しかし問題がまだひとつあって、それが基板の容器なのですね。

セリアのLEDライトが大きめで余裕があって光を通し、しかも100円と大喜びで買い込みましたが… いざ作ってみるとこのLEDライトのカバーとスイッチを兼ねた半透明の拡散板が、赤外線LEDの信号を送受信ともに多少邪魔してくれる、という…*3

昔の100均ライトはこんな良い拡散板ではなく、透明ドームにブツブツの点があるだけでしたからね。しかし赤外線にはむしろ透明のほうが良い模様。

というわけで結局、ストックしてあった、旧式のブツブツ透明タイプな小型LEDライト容器に入れ替えて使っておりますけどね。もうこのボディは入手できないのだろうなぁという…

まぁ100均ライトにこだわるのをヤメればいいだけなのですが、ライトは電池ボックス付きなのでそこもお得なポイントなのです…

将来的にはESP8266で、留守時にだけリビングに置く電池駆動の遠隔照明操作リモコンとか考えていただけに、ちょっとこの赤外線パワーダウンはなぁと。

んで他の用途にまたまた同じLEDライトを買ってきて、つらつら眺めていてふと思ったのです。

このドームをバキュームフォームで透明プラバンで複製してはどうだろうか？

↓

目の前にバキュームフォームされたような透明の物体があるじゃろ？

ああっ！！ コイツの包装プラがあったわ！！

さっそく切り抜いて

組み込んでみたらなんと！ピッタリじゃないすか！！ いや当たり前なんだけど(^^;

というわけで、これはただの仮組み。

まぁとりあえず今の動いている左手用リモコン受信器は放置し、 以前、同様に１００均ライトボディに組み込んで作ったリモコン発信器*4のカバーを交換してみたところ…

今まで真下から発射しないと受信してくれなかった天井灯が、斜め遠方からの照射でらくらく反応してくれるように！

これでしばらくは完全透明LEDライトケースに困ることは無さそうです。

うーむ今まで捨てた包装プラを取り戻したい気分ですは…

てかまぁ、「四角いけどフタ付きの完全透明小物収納用硬質プラボックス」をセリアで見つけてしまいまして、これはこれで電子工作のケースにかなり向いてそうに思いましたですね。 普通の食品用密閉容器のような軟質プラではなく、ポリスチレンっぽい感触の接着剤効きそうなプラ容器なのですよ。

ではでは！

*1:78K0の開発環境が独特、かつ自分がなるべくwindows使いたくなく、さらにそのうえ最近のwindowsでは無理があるため、最小限の手数でUSB変換モジュールとしてだけ動くようにする予定

*2:一番最初、作った直後は全ボタン押下可能で使っていましたがピーキー過ぎて俺には無理だよって感じでした

*3:ライトとしてみればこの拡散板はただのプラスチックにしては非常に優秀、かなり光を均一にしてくれます。

*4:ラズパイとUSB接続して防犯タイマー的に使ってます

安物マウスを至高の5ボタンマウスに改造

ナカバヤシのDigioシリーズ、個人的にはフォルムがかっこよくて好きなのでした。

そしてこのMUS-UKF148BK

何が良いかってボディに忌々しいラバーコート部品が一切ないことですね*1。 これはメリット激高。 何故、各社ってかロジクールマウスはラバーコートという地雷を踏み続けるのか…？っていうか最近はゲーミングマウスのほうが盛んでもっと様々なメーカーが勃興しているようですが、ゲーミングマウスはちょっと機能が高すぎてお腹いっぱいなので買ったことが無いのです。*2

そしてボディ自体が大きい。以前、Digioの小さいカッコいいマウスを買ってみた時、ホイールの位置が指に合わず腱鞘炎になりそうになりましたが、こいつは大丈夫。

いうまでもありませんが、Linuxでもevdevのおかげでサイドボタンの戻る／進むも何の設定も無しにただ挿すだけで機能しています。*3

しかし弱点が一つ。

静音ボタンなので押した感じが物凄く弱い。 ていうか、もしかしてすぐチャタってぶっ壊れる？という感じなのでした。

購入以来、テキストドラッグで選択中に勝手に解除されることがしばしば。 *4

ワタクシ、デザインと大きさと機能（５ボタン）と有線かつ安価という条件さえ満たせば何でも良かったので、静音性はおまけでした。

そういうわけでこうなったら保証を捨て、改造してタクトスイッチでも乗せてやるぜ！と思って開腹改造に邁進するのでした。

改造について

そういうわけで早速開腹。ネジはこの３つでした。左右と下のソールを剥がさないと行けないので、改造後にカグスベール必須です。

ていうかこのネジがY型ネジでした。 Y型ドライバーを持っていないとこの段階で詰みます。

ナカバヤシさん（というかOEM元さん）、このグレードのマウスにそんな凝ったネジを使わなくても…(^^;

持ってる奴は普通に持ってるので、弄り防止としてもあまり意味がないかと…

さて、んでもって開けてみると…

ん…？

こ、この回路パターンは… マイクロスイッチ共用タイプか！！

というわけで作戦を急遽変更。マイクロスイッチに載せ替えます。*5

とりあえず以前、使わなくなったMSマウスあたりを分解して取ったはずのマイクロスイッチを使用。そのうちもっと良いのを使うかもですがw

スイッチが押し込めるように高さ調整が必要かと思いましたが、載せ替えただけで動きましたな…完全に両用のようです。

なお、ホイールの辺りも割と凝った仕様になっていまして、こんなちっこい部品をマイクロスイッチとホイール受けのスリットにかまして、その上にホイールを載せるという方法になっています。

ホイールが乗った状態のは改造前に撮影したものです(^^;

また、ホイール穴の下に灰色のゴム部品が見えていますが、これは少しでもホイールにティック感や抵抗を出せないかと、その場にあった低反発クッションを小さく切って自分で貼り付けてみたもので、製品には存在しません。

最初はホイールゴムバンドの突起にいい感じで触れてちょっとしたティック感を出してくれましたが、案の定知らない間にはがれたようで完全ヌメヌメホイールに戻ってしまいました。また開腹して取り外すのも面倒なのでとりあえず放置で…

そんなわけで快適マウスが超・快適マウスに変貌。 唯一の不満点といえばホイールのカチカチが無いヌメヌメマウスという点でしょうか…これはまぁ仕方がない。

おまけ：xorg.conf.dの設定

なお自分的xorg.conf.dの設定を以下に乗せておきますね〜

Identifierですが、どうも、aresonとかいうマウスとして認識されてるっぽいので、そういう名前にしました

Section "InputClass"
    Identifier "my_custom_areson"
    MatchUSBID "0c45:7e0d"
    Option "EmulateWheel" "True"
    Option "EmulateWheelInertia" "2"
    Option "EmulateWheelTimeout" "160"
    Option "EmulateWheelButton" "9"
EndSection

進むボタンを160ms以内に放すと進むボタンとして機能し、 それ以上押し続けているとマウスの上下動で超高速スクロールを行います。

ではでは〜

*1:ただしマウスホイールはゴム「バンド」が巻かれているタイプです

*2:高機能製品で何よりも恐ろしいのは、高機能に身体が慣れきってそれ以外では生きていけなくなった所でディスコンされて後継機皆無という状況…

*3:ただし自分的には進むボタンにホイールエミュレーションを割り当て、ごく短時間で離せば進むボタン・押したままマウスを動かすと超高速スクロールという設定にしています

*4:単に、ちゃんと押せて居ないが感触が無いので知らない間に指が離れている可能性もあり

*5:実は最初は左とホイールのだけマイクロスイッチに変えたのですが、右を押した時の違和感が想像以上に高かったので再度開腹して全部載せ替えました。

GtkSourceViewを表示専用にする

GtkSourceViewを表示専用にする、その方法が分からなかったのでメモ

Gtk+3入門

はいアフィ入りました〜w

というか他のGTK関連書籍は正直10年いや20年前のもので役に立たないと思われたからです。ていうか昔は盛んだったんですなぁ(´・ω・｀)

まぁそれはともかく、このアフィリンクの書籍とは一切関係ない話なのですが

以下は普通の知能を持っていれば当たり前の話なのですが、GtkSourceViewに対して変更を禁止しようと思ったのですが 自分はgtksourceview read-onlyなどで延々とググり続けてしまった罠。 なにかset_read_onlyみたいなメソッドがあるのかな〜と…無いですね。*1

そしてその方法について誰も言及していない。何故か。その理由はあまりにも基本的だからだと推察します。

つまり…単にGtkのウィジェットとしてキー入力を無効化してしまえばいいだけではないか？と思いついたからです。

しかし単純にset_sensitive()でFalseにするとナビゲーションすら不能になるという。 そこで、キーボードイベントをconnectしてナビゲーションキー以外はTrueを返してバブリングを抑制。キー入力を遮断してしまうという方法を取りました。

マウスボタンも右ボタンを許すとメニューが飛び出てしまうので潰しておきます。 ただしこれだとテキスト選択してコピーが出来ないので（いや別に出来なくてもいいけど）何か自前の「コピー」だけあるメニューでも表示するとかしたほうが良いかもですね。

他にスマートな方法があるのかも知れませんが、こんな単純なことを思いつきました的な話でした。

サンプルコード

面倒くさいので、GtkSourceViewテスト用コードの全体をコピペ!

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import gi
gi.require_version('Gtk', '3.0')
gi.require_version('GtkSource', '3.0')
from gi.repository import Gtk, Gdk, GtkSource, GObject, GLib, Gio

# For reference of GtkSourceView(but 4.0):
# https://lazka.github.io/pgi-docs/GtkSource-4/classes.html

class Myclass:

    allowed_keys = (
        Gdk.KEY_Up,
        Gdk.KEY_Left,
        Gdk.KEY_Down,
        Gdk.KEY_Right,
        Gdk.KEY_Page_Up,
        Gdk.KEY_Page_Down,
        Gdk.KEY_Home,
        Gdk.KEY_End,
    )

    def __init__(self):
        self.win = Gtk.Window(Gtk.WindowType.TOPLEVEL)
        self.win.set_title("title")
        self.win.set_resizable(True)
        self.win.show()
        self.win.connect("destroy",self.destroy)
        self.win.resize(1024,768)

        # widgets baseically added this self.basebox
        basebox = Gtk.VBox(False,8)
        basebox.show()
        self.win.add(basebox)
        self.basebox = basebox

        # Building:
        # You need `from gi.repository import GtkSource`, `GLib` and `Gio`

        # Coding:
        # Buffer : You need buffer for actual text contents.
        #          The source-view is only `view`, actually you must use
        #          buffer to load or set file type or something like that.
        #          it can be get from source.get_buffer() (empty one)
        #          or, create from GtkSource.Buffer().
        #
        # LanguageManager : To specify the `programming language` for `buffer`.
        #
        # FileLoader: To load file into buffer. Need GLib module to set priority
        #             when use async load.
        #             Also Gio for File (filename) object.
        #
        source = GtkSource.View()
        self.buffer = source.get_buffer()
        # Use Language Manager, to set language (i.e. file type) to buffer.
        self.lm = GtkSource.LanguageManager()
        self.buffer.set_language(self.lm.get_language('python'))
        
        # Set readonly 
        # To make view read-only, prohibit all key inputs except for navigation keys.
        source.connect("key-press-event", self.view_key_handler)
        source.connect("key-release-event", self.view_key_handler)
        source.connect("button-press-event", self.view_button_handler)
        source.connect("button-release-event", self.view_button_handler)

        # Load text contents

        # FileLoader does not accept string filename. use GtkSource.File object.
        filename = GtkSource.File()
        filename.set_location(Gio.File.new_for_path('srcviewtest.py')) # This Needs Gio module.

        fileloader= GtkSource.FileLoader.new(self.buffer, filename) # Not use constructor, use this class method. 
        fileloader.load_async(GLib.PRIORITY_LOW, None, None, None, None, None)

        source.set_show_line_numbers(True)
        basebox.add(source)
        source.show()
        self.source = source

    def view_key_handler(self,widget,data):
        if not data.keyval in self.allowed_keys:
            return True # Prohibit bubbling

    def view_button_handler(self, widget, event):
        if event.button != 1:
            return True # Prohibit bubbling

    def destroy(self, widget, data=None):
        Gtk.main_quit()

    def main(self):
        Gtk.main()

if __name__ == '__main__':
    m=Myclass()
    m.main()

*1:もしあるのなら教えて欲しいガチで…割と困っています

ソニーBDプレイヤーS5100をUbuntu 16.04から操作

何故か16.04なのは気にしてはいけない…というかドラフト記事のまま公開するのを忘れていました(^^)

さて、レビューしたかどうかすら忘れてしまいましたが実はソニーのネットワーク対応BDプレイヤー、S5100を購入したわけであります。もう3年ぐらい前でしょうか。

SONY ブルーレイディスクプレーヤー/DVDプレーヤー BDP-S5100

残念なことにこのマシン、早送りぐらいはできるんですが任意位置への再生位置指定ができないのです。 コマーシャルをバシッと飛ばすことも、前回見た部分を飛ばすことも容易ではない。 PS3の快適な視聴環境から考えると退化以外の何者でもありません。

さて、そんなS5100。 全く知らなかったのですが気まぐれにマニュアルを読みなおして見ると、DMC*1という機能があり、それでスマホなどから操作できるというではないですか。

もしかして、再生位置を指定できちゃったりするのかも？ と思いつつ、調べてみるとなんとUbuntuでもDMC対応ソフトがあるというではありませんか。 それがgupnp-av-cpです。

このソフトを使うには、gupnp-toolsパッケージを入れます。

sudo apt-get install gupnp-tools

そしてターミナルからgupnp-av-cpで起動します。

さて、これでBDレコーダーが見えるようになりました。*2

しかし、もちろんS5100の方の設定も行わねばなりません。 メディアバーからネットワーク設定を選び…「レンダラーアクセス制御設定」で、UbuntuマシンのMACアドレスを許可します。

さて！再生！なんですが…その前に。 サーバとなるレコーダ側の設定でUbuntuマシンを許可していないと、レコーダーの部分をいくらクリックしても

(gupnp-av-cp:15362): WARNING : Failed to get metadata for '0': Forbidden

みたいなエラーメッセージがターミナルに出てしまい、無反応です。

今まで再生位置指定できねーと思ってたんですが、これで出来るとはね。 しかもUbuntuから出来てしまうわけで、感謝の涙が止まりません。

だがしかし。 ひとつだけ言うとすれば

やっぱプレイヤー単体のリモコンだけで再生位置指定できたほうが便利だと思うわ…

と思う、元PS3ユーザーの感想でありました。まぁ、常時PC起動状態だからこれでいいといえばいいんですけどね。ちなみにスマホやiPod touchとかからも出来るらしいんで、そっちを使う手もありかも。

しかし、S5100は動画垂れ流すだけならばPS3の爆音爆熱とは比べ物にならない快適さです。

今の最新プレイヤーはこれらしいですが、同じことをこれで出来るかどうかは知りません。誰か試して！

ソニー SONY ブルーレイプレーヤー/DVDプレーヤー 4Kアップコンバート BDP-S6700 BM

*1:デビルメイクライではなくDLNA Media Controllerの略らしい

*2:勿論レコーダーの再生映像が見えるわけではなく、存在が確認出来るだけ

Ubuntu 18.04における液晶タブレットXP-Pen Artist 15.6の対応状況

Cintiq 13HDをいちいち持ち運ぶのに疲れ、実家用に買ってしまいました。

XP-Pen 液タブ 液晶ペンタブレット 15.6インチ バッテリフリースタイラス フルHD 筆圧8192レベル 6個エクスプレキー Artist15.6

XP-Pen社の液晶ペンタブレット*1 Artist 15.6ですが、Ubuntu 18.04であれば挿しただけで使えます。*2

ただし…

「そのままでは」xsetwacomコマンドが効かない（対応デバイスとならない） libinput支配下のデバイスとなるので、ディスプレイのマップやキャリブレーションなどはxinputコマンドから行うことになります。

しかしですね。

キャリブレーションまではわかりましたが、どうしてもxinputコマンドからの筆圧調整の方法が分からなかったのです。

Artist 15.6は筆圧8192レベルを謳ってますが実際そんなにもレベルはいらないし、なにより8192レベルであるために(自分としては）非常に強く押さないとMAXにならないという。多少、筆圧レベルを犠牲にしても、もっと弱い筆圧でMAXになってもらいたい所…

んで通常はGIMPにしろKritaにしろMypaintにしろ、ソフトの側でそれぞれに筆圧調整が出来るのですが…

ワタクシ板タブと液タブを兼用しているので、そういうアプリケーション側の設定であれば、デバイス感知型でないと意味がないのでした。 そしてデバイス感知型の筆圧調整はGIMPのみ、というね…まぁそこでMyPaintを改造してみましたがそれもなんだかな、という感じでして。

xsetwacom対応化

ワタクシ、こうなったらxsetwacomに対応させてやろうじゃねえかと突如意気込んで色々ソースを拾って読み始めたのですが…

どうも何かがおかしい。 例えばHuionのH610Proなんかはxf86-input-wacomには影も形もないのにxsetwacomでは対応デバイスになっている。

そこでワタクシ意を決し、/usr/share/X11/xorg.conf.dに、以下の99-my-artist.confなるファイルを作成してXを再起動してみたのです。

Section "InputClass"
        Identifier "Artist 15.6"
        MatchProduct "XP-PEN ARTIST"
        MatchDevicePath "/dev/input/event*"
        Driver "wacom"
EndSection

そしたらなんと！

普通にxsetwacom --listでArtist 15.6が表示されるじゃないすかあああああああああああああっ！！

もちろん筆圧感知や調整(PressureCurve)なども普通に動きました(^^)

Artist 15.6の色調整について

あと画面の色ですが、xgammaなどでも一応赤っぽくは出来ますが、階調が犠牲になっているような嫌な雰囲気を感じるのでやっぱりハードウェアでの調整とは違うようですね。

それで最初の青っぽいままで使用していたのですが…

んでふと動作確認のためにWindows10に差し込んでドライバ適用して *3 色調整したんですよ。

そうしたらどうも、Artist15.6がそれを本体内に覚えているっぽい？らしくて、 Ubuntuでも、なんか以前は青っぽかった画面色がほどよく赤くなっているのですね。気のせいかもですが

まぁこの色については、気のせいかもしれませんが、一応。

デバイスとしてのArtist 15.6の手短レビュー

• 悪くはないが、やはりCinitiq 13HDと比べると反応が悪い。特に画面外周部で顕著
  • そのため、アナログ的なダイレクト感が一寸劣る。
  • スペック上はArtist15.6のほうが僅かに上の筈だけど…
• ペンが二本も付属してきた！
  • どうも片方は旧式のようだけど、細くていい感じで好み。
• しかし、ペンのサイドボタン上がボタンとして使えない
  • Windowsでは使える…ただしキーボード的に？
  • MyPaintでスタイラスの動きと組み合わせた高速拡大縮小に使っているので、かなり困る。
    • まぁ左手デバイスに割り振れば問題ないのだけど。
• 物理的定規を使った所、平行・垂直、45度では問題がないが、「浅い角度の斜め」で線を引くとジッター的にブレる
  • これはxsetwacom(wacomドライバ化）をした所、改善した気がする…？
• 視差は調整すればさほど悪くない。Cintiq 13HDと余り変わらない。
  • ただし、前述のように反応が若干遅いので少しイラッとする時がある。
• 結論としては、比較しなければかなり満足できるが、ワコム旧製品からの乗り換えは全くお勧めしない。
  • 何度も言うが値段を考えると中々悪くない。自分的には真・液タブと板タブの中間の存在的印象。

まぁ買ってみて良かったら15.6をメインにするという事も考えていましたが、結局自宅で使ってるのはこっちのCintiqでした。 なお、画面サイズの差はそれほど感じませんでした。

ワコム 液タブ 13.3フルHD液晶 Cintiq 13HD DTK-1301/K0

*1:余談ですが液タブのことを英語ではScreen tabletというっぽいですね

*2:ubuntu 16.04でも、HWEをアップデートすれば16.04.4であれば動作します

*3: これが何故かうまく行かず、大変に四苦八苦。最近はWindowsのほうが色々難しいですな(´・ω・｀)

Xubuntu 16.04.4でkabylake Intel HD 620のログイン画面を改善する

安物マザボのためか、kabylakeであるにもかかわらず三画面できないため 現在、EIZO EV2436W + IIYAMA X2380HS + Cintiq 13HDを接続して、スクリプトでX2380HSとCintiqを切り替えて使用しています。

まぁこれはこれで使えるというか、こういう時にスクリプト一発で切り替えができるのでLinuxは素晴らしい…というのはともかく、問題は何故かlightdmによるログイン画面で、Cintiq 13HD(HDMI-2)が優先されてしまいプライマリのはずのEV2436W(HDMI-1)が暗いまま…という、ね。

いや別に目押ししたりオートログインにしたりしてもいいんだけど、なんか釈然としないわけですコレ。

んで色々xorg.conf.dに書いて試してみたんですが…なんつーか全画面ブラックアウトとか、もっと酷いことになりまして。 結局この方向性は諦めてlightdm側で対処してみることにしました。

いろいろ調べた結果、

• Xubuntu 16.04では/etc/lightdmにlightdm.confが存在しないため、コレを新設。
• lightdm.confに以下の記述を追加

[SeatDefaults]
display-setup-script=/usr/local/bin/intel_hd620_setup.sh

んで、/usr/local/bin/intel_hd620_setup.shとして以下のスクリプトを作成。つか、これはもともと自動起動アプリケーションとしてxfce4から起動していたもので、目押しでログインしたらコイツが呼ばれて画面設定をする手はずになっていたのです。

なお、bashによる遅延実行をするのは、このスクリプトはcintiqがoffされるのをsleepで待つので、ログイン自体が遅くなるかなぁ〜と思って（まぁ0.5秒ぐらいどうだっていいのですが）後学の為にこうしてみました。 ちなみにsleepしないと、cintiqがoffされる前にEV2436Wをonしようとして失敗、サブ画面のX2380だけが点灯するという悲しい状況が「時折」（いつもではない）出現します。

#!/bin/bash
MAIN=HDMI-1
SUB=DP-1
CINTIQ=HDMI-2

(
xrandr --output $CINTIQ --off
sleep 0.5
xrandr --output $MAIN --auto
xrandr --output $SUB --right-of $MAIN --auto
) &

これで試した所、ログイン画面が望み通りEV2436Wに出現しました (^o^)

Xubuntu 16.04.4 & HD Graphics 620でブラックアウト化現象

何が悪くなったのかわかりませんが、xorg.conf.d等いろいろいじっていたら、ログイン直後に３つのモニタすべてがブラックアウトして何も表示されない状態に…orz

んでxorg.conf.dのファイルを戻したんですよ。 それでも治らないんですなぁ…一体何が…!

やっていたことは、xorg.conf.dを使って（自動起動アプリからxrandrではなく）最初からモニタ設定をシームレスに適用させる…ということなのですが。これがまったく適用されない。

/var/log/Xorg.0.logによると、読み込まれて適用はされているのだけど、実際にはほぼ全く反映されず、ログイン画面に至るとファームウェア画面が表示されていたメインのHDMI-1は消え、HDMI-2とDP-1(アナログVGA）が表示されるという始末。

そしてこの状態でログインすると…すべてがブラックアウト！

私が悪かった、と思ってxorg.conf.dに追加したファイルを（まだ消すには惜しかったので）全部コメントアウトして再起動しても、ブラックアウト。

GUIにログイン出来ないので、disableにした自動起動アプリを戻せず、つまりxrandrを起動できない…！ そして、どこのディレクトリにそのファイルが存在するのかわからない！Xsession.dの方でやれば良いのかもですがその時は焦ってて思いつかなかったですな…w

そこで持っててよかったサブマシン！で検索してわかりました。xfce4の自動起動は~/.config/autostart/のdesktopファイルです。よかったよかった。

さらにここで再起動せずにログイン画面を戻すには、落ちているっぽいdisplay-manager.serviceを systemctl restart display-manager.serviceでOK。 この何故かこいつが落ちているところが味噌なのかもしれませんけどね

それで何とか復活できたんですけどね…いやービビった。何がアレなんだろう。どうもplymouth絡みぽいのだけど。

んで/etc/default/grubでGRUB_CMDLINE_LINUX_DEFAULT="nomodeset"に書き換えて(update-grubして)plymouthナシで起動させてみたのですよ。

これだと確かにHDMI-1がメイン画面にはなってくれる。しかし結局xorg.conf.dは無視されてるし、解像度は1920x1200のモニタにも関わらず1920x1080固定で他のモードは存在しない。さらに他のモニタはxrandrから全く見えない（存在していない）という有様で、手に負えなかったのでこりゃダメだ、ということで。

うーんまぁ、結果ログイン画面だけ我慢すれば一応使えてるし、落ちたりしないだけいいのかなぁ…と諦めムード やっぱnvidiaの1050Tiのセミファンレスがほしいよぉ… ていうか性能的には1030で十分なんですが経験上、外付けグラボは64bitものだと2D速度がなんか妙に悪いという事が続いたので、僅かな差額のためにもう買いたくないのですね。

それにしてもいくらマイニング需要っつっても1050レベルまで値上がりしてくれるなよって思いますよホント