タグ付けされた質問 「display」

グラフィックウィンドウを無効にして、ターミナルエミュレータ出力のみでqemuを起動できたことを思い出すようです。そして、ここでは、ncursesインターフェースを使用するという意味ではありませんが、それは素晴らしいのですが、出力を直接端末に流して、カットアンドペーストを容易にします。 私が試してみました： qemu -nographic binary.img # simply no display qemu -curses binary.img # nice text output, but not directly flowing in the terminal qemu -noframe -curses binary.img # same as above qemu -nographic -curses binary.img 許容できる回避策は、使用している端末に合わせてcursesコンソールのサイズを変更できることです。今のところ、端末のサイズに合わないので迷惑です... qemu -curses binary.img SeaBIOS (version 1.7.0-20120603_194846-gandalf) iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+07FC86A0+07F886A0 C900 …

18 terminal  qemu  serial  display  curses 

スマートフォンまたは別のPCのいずれかからRDPセッションを行った後、コンピューターを起動してログインに進むと、カーソルのある黒い画面が表示される理由を誰もが知っていますか？私はWindows 10 Pro 64ビットを実行していますが、この問題は以前にありませんでした。リモートデスクトップセッションの後、ロック画面が表示され、パスワードでログインするように求められますが、その後、Enterまたは矢印を押すと、黒い画面とカーソルが表示されます。ショートカットやキーを押して何かを表示することはできません。ctrl + alt + del、ctrl + shift + esc、alt + f4、何も機能していないようです。私はモニターを1つしか持っていないので、他のWindows 10ユーザーが持っているようにWindowsがデフォルトのディスプレイを認識できないという問題はありませんが、これは異なるようです。

14 windows  rdp  windows-10  display 

Mac（10.7.2）からLinux（Ubuntu 8.04）にログインするときに、X11接続をssh転送することで、新たな厄介な問題が発生します。ssh -Xを使用してリモートマシンにログインし、そのシェルからX11ベースのアプリケーションを起動しても問題はありません。 最近起こったのは、転送されたディスプレイがブロックされているため（おそらく）、同じシェルからのX11アプリケーションの追加の呼び出しが、しばらく（数時間程度）後に開始できないことです。たとえば、xtermを起動しようとすると、次のような、不適切なDISPLAY設定に関する通常のメッセージが表示されます。 xterm Xtエラー：ディスプレイを開けません：localhost：10.0 しかし、ログインしてすぐに開始したX11アプリケーションは、以前に開始したものとまったく同じディスプレイ（localhost：10.0）を使用して、問題なく実行されています。 sshd_configで詳細ログをオンにしましたが、xtermの起動試行の失敗に応じて、/ var / log / auth.logファイルにこれが表示されます。 sshd [22104]：チャネル8：オープン失敗：管理上禁止：オープン失敗 サーバーに再度ssh -Xを実行して、新しいシェルを開始し、新しいディスプレイ（localhost：11.0）を割り当てた場合、同じプロセスが繰り返されます。 ）、しかし数時間後、そのシェルから新しいものを開始できなくなります。 詳細：Ubuntu 8.04で実行されているOpenSSH sshdサーバー、ディスプレイは、デフォルトのApple XサーバーでLion（10.7.2）を実行しているMacに転送されます。システムは、1つのスイッチを介してイーサネットLANに接続されています。どちらのマシンもファイアウォールを実行していません。最近（数日前）まで、このセットアップは完全に機能したので、次にどこを見ればいいのか迷っています。私は決してX11やSSHの専門家ではありませんが、UNIX / Linuxの経験は豊富です。sshd_configのTCPKeepAliveをnoに設定したり、「host + localhost」を設定したり（私がグーグルしていることがわかります）など、これをデバッグするためにいくつかのオプションを変更しようとしましたが、クライアントまたはサーバーの構成に明らかな変更はありません。 Linux 11.10ラップトップから同じネットワークとスイッチを介して同じリモートホストにログインする場合、この問題は発生しません。Macからの同じ実験が失敗しても、同じsshログインシェルからxtermを数時間後に呼び出すことができます（確認のために今朝テストしました）、Mac固有の問題のようです。 「LogLevel DEBUG3」がリモートマシン（sshdサーバー）で設定されており、クライアント接続に変更が加えられていない場合、/ var / log / auth.logは、使用されているポート番号である接続ステータスレポートにわずかな変更を一晩表示します。 Linuxマシンからの1つの成功したsshセッション（私は思う）によって、以下の接続＃7： sshd [20173]：debug3：チャネル7：ステータス：次の接続が開いています：\ r \ n＃0 server-session（t4 r0 i0 / 0 o0 / 0 fd …

10 ssh  mac-osx  x11  display