Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Avi Kivity wrote: Anthony Liguori wrote: Yes. I was actually thinking of tunneling the curses data but another option would be a more proper character-based encoding. The advantage of that is that you could also send over fonts. curses is very un-vnc-like, it's a single stream an you need all of it to get something meaningful. Much more in the spirit of vnc is to encode 'character tiles', and to allow coalesced updates like the regular vnc protocol. Yes, my main interest in curses was to avoid having to deal with character mapping. I was planning on just using vte terminal to render the data. Maybe doing a proper encoding is the right thing to do though. Ah, CGA as in color graphics adapter. Why not add the encoding to vnc and use the regular -vnc option? if both viewer and server support the feature, and if the display is in text mode, it would be used automatically. Yes, this is what I want. I still want to be able to connect to it via telnet though independent of VNC. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Anthony Liguori writes ([Qemu-devel] [PATCH] Support redirect -curses over a character driver): I love the -curses feature but I really wanted to use it over a telnet: character device. This patch enables this and changes the syntax of the -curses argument to take a character device. Surely it would be better to introduce a new option and leave the old one (which people might be using) behaving the old way ? Ian.
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Ian Jackson wrote: Anthony Liguori writes ([Qemu-devel] [PATCH] Support redirect -curses over a character driver): I love the -curses feature but I really wanted to use it over a telnet: character device. This patch enables this and changes the syntax of the -curses argument to take a character device. Surely it would be better to introduce a new option and leave the old one (which people might be using) behaving the old way ? I don't really feel strongly either way. Regards, Anthony Liguori Ian.
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Ian Jackson wrote: Anthony Liguori writes ([Qemu-devel] [PATCH] Support redirect -curses over a character driver): I love the -curses feature but I really wanted to use it over a telnet: character device. This patch enables this and changes the syntax of the -curses argument to take a character device. Surely it would be better to introduce a new option and leave the old one (which people might be using) behaving the old way ? -curses hasn't been in any official release (well, kvm-63 will be out soon), so users haven't yet had a chance to rely on it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Avi Kivity wrote: Ian Jackson wrote: Anthony Liguori writes ([Qemu-devel] [PATCH] Support redirect -curses over a character driver): I love the -curses feature but I really wanted to use it over a telnet: character device. This patch enables this and changes the syntax of the -curses argument to take a character device. Surely it would be better to introduce a new option and leave the old one (which people might be using) behaving the old way ? -curses hasn't been in any official release (well, kvm-63 will be out soon), so users haven't yet had a chance to rely on it. I'm on the fence because while I like what I've posted, I'd like to eventually tunnel the curses data over VNC in which case, having a separate option makes sense. -curses would imply that the GUI would be rendered with curses. So, 'qemu -curses' does what you think, 'qemu -cga telnet::1024,server -vnc :2' does what I want and still lets you interact with VNC, and then down the road 'qemu -cga vnc:org.qemu.vga -vnc :2' allows CGA tunneling over VNC. But this is really future looking so I'm somewhat indifferent to what we do now. I'll update the patch according to whatever the consensus is. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Anthony Liguori wrote: I'm on the fence because while I like what I've posted, I'd like to eventually tunnel the curses data over VNC in which case, having a separate option makes sense. -curses would imply that the GUI would be rendered with curses. I'm lost. What does 'tunnel curses data over vnc' mean? A new character cell based encoding (vs. pixel-based)? So, 'qemu -curses' does what you think, 'qemu -cga telnet::1024,server -vnc :2' does what I want and still lets you interact with VNC, and then down the road 'qemu -cga vnc:org.qemu.vga -vnc :2' allows CGA tunneling over VNC. What's -cga? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Avi Kivity wrote: Anthony Liguori wrote: I'm on the fence because while I like what I've posted, I'd like to eventually tunnel the curses data over VNC in which case, having a separate option makes sense. -curses would imply that the GUI would be rendered with curses. I'm lost. What does 'tunnel curses data over vnc' mean? A new character cell based encoding (vs. pixel-based)? Yes. I was actually thinking of tunneling the curses data but another option would be a more proper character-based encoding. The advantage of that is that you could also send over fonts. So, 'qemu -curses' does what you think, 'qemu -cga telnet::1024,server -vnc :2' does what I want and still lets you interact with VNC, and then down the road 'qemu -cga vnc:org.qemu.vga -vnc :2' allows CGA tunneling over VNC. What's -cga? That would be the second option which controlled what the CGA data was sent over. stdio would be the default. It doesn't have to be -cga. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: I'm on the fence because while I like what I've posted, I'd like to eventually tunnel the curses data over VNC in which case, having a separate option makes sense. -curses would imply that the GUI would be rendered with curses. I'm lost. What does 'tunnel curses data over vnc' mean? A new character cell based encoding (vs. pixel-based)? Yes. I was actually thinking of tunneling the curses data but another option would be a more proper character-based encoding. The advantage of that is that you could also send over fonts. curses is very un-vnc-like, it's a single stream an you need all of it to get something meaningful. Much more in the spirit of vnc is to encode 'character tiles', and to allow coalesced updates like the regular vnc protocol. So, 'qemu -curses' does what you think, 'qemu -cga telnet::1024,server -vnc :2' does what I want and still lets you interact with VNC, and then down the road 'qemu -cga vnc:org.qemu.vga -vnc :2' allows CGA tunneling over VNC. What's -cga? That would be the second option which controlled what the CGA data was sent over. stdio would be the default. It doesn't have to be -cga. Ah, CGA as in color graphics adapter. Why not add the encoding to vnc and use the regular -vnc option? if both viewer and server support the feature, and if the display is in text mode, it would be used automatically. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] [PATCH] Support redirect -curses over a character driver
I love the -curses feature but I really wanted to use it over a telnet:
character device. This patch enables this and changes the syntax of the
-curses argument to take a character device. 'stdio' is special cased to not
go through a character device. The rest use a pty to proxy the data to the
character device. curses insists on a pty so we limit this feature to
everything but WIN32 since I don't believe Windows supports ptys.
Using this patch, you can now do something like '-curses telnet::1028,nowait'.
To get the old behavior, just use '-curses stdio'.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/console.h b/console.h
index b8a5c6d..43e1284 100644
--- a/console.h
+++ b/console.h
@@ -141,7 +141,7 @@ int vnc_display_password(DisplayState *ds, const char
*password);
void do_info_vnc(void);
/* curses.c */
-void curses_display_init(DisplayState *ds, int full_screen);
+void curses_display_init(DisplayState *ds, CharDriverState *chr, int
full_screen);
/* x_keymap.c */
extern uint8_t _translate_keycode(const int key);
diff --git a/curses.c b/curses.c
index 87aa9b3..a020dd1 100644
--- a/curses.c
+++ b/curses.c
@@ -32,6 +32,7 @@
#include signal.h
#include sys/ioctl.h
#include termios.h
+#include pty.h
#endif
#define FONT_HEIGHT 16
@@ -41,6 +42,7 @@ static console_ch_t screen[160 * 100];
static WINDOW *screenpad = NULL;
static int width, height, gwidth, gheight, invalidate;
static int px, py, sminx, sminy, smaxx, smaxy;
+static int slave;
static void curses_update(DisplayState *ds, int x, int y, int w, int h)
{
@@ -278,16 +280,102 @@ static void curses_atexit(void)
curses_cleanup(NULL);
}
-static void curses_setup(void)
+#ifndef _WIN32
+static void pty_read_proxy(void *opaque)
+{
+CharDriverState *chr = opaque;
+char buffer[4096];
+ssize_t len;
+
+do {
+ len = read(slave, buffer, sizeof(buffer));
+} while (len == -1 errno == EINTR);
+
+if (len 0)
+ qemu_chr_write(chr, buffer, len);
+}
+
+static void chr_read_proxy(void *opaque, const uint8_t *buf, int size)
+{
+ssize_t len;
+size_t offset = 0;
+
+do {
+ len = write(slave, buf + offset, size - offset);
+ if (len == -1 (errno == EINTR || errno == EAGAIN))
+ continue;
+ if (len 0)
+ offset += len;
+} while (offset size len 0);
+
+if (offset != size)
+ fprintf(stderr, curses: short write to slave pty\n);
+}
+
+static int chr_can_read_proxy(void *opaque)
+{
+return 1024;
+}
+
+static void chr_event_proxy(void *opaque, int event)
+{
+if (event == CHR_EVENT_RESET)
+ invalidate = 1;
+}
+#endif
+
+static void curses_setup(CharDriverState *chr)
{
int i, colour_default[8] = {
COLOR_BLACK, COLOR_BLUE, COLOR_GREEN, COLOR_CYAN,
COLOR_RED, COLOR_MAGENTA, COLOR_YELLOW, COLOR_WHITE,
};
+#ifndef _WIN32
+if (chr) {
+ struct termios term;
+ FILE *fin, *fout;
+ SCREEN *screen;
+ int master;
+
+ if (openpty(master, slave, NULL, NULL, NULL) == -1) {
+ fprintf(stderr, fatal: could not open pty\n);
+ exit(1);
+ }
+
+ tcgetattr(master, term);
+ cfmakeraw(term);
+ tcsetattr(master, 0, term);
+
+ tcgetattr(slave, term);
+ cfmakeraw(term);
+ tcsetattr(slave, 0, term);
+
+ fout = fdopen(master, w);
+ fin = fdopen(master, r);
+
+ if (fout == NULL || fin == NULL) {
+ fprintf(stderr, fatal: could not reopen pty\n);
+ exit(1);
+ }
+
+ qemu_set_fd_handler2(slave, NULL, pty_read_proxy, NULL, chr);
+ qemu_chr_add_handlers(chr, chr_can_read_proxy, chr_read_proxy,
+ chr_event_proxy, chr);
+
+ screen = newterm(getenv(TERM), fout, fin);
+ set_term(screen);
+
+ /* we won't get resizes so we need to start out telling curses the
+ proper size */
+ resize_term(25, 80);
+} else
+#endif
+ initscr();
+
/* input as raw as possible, let everything be interpreted
* by the guest system */
-initscr(); noecho(); intrflush(stdscr, FALSE);
+noecho(); intrflush(stdscr, FALSE);
nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
start_color(); raw(); scrollok(stdscr, FALSE);
@@ -332,7 +420,7 @@ static void curses_keyboard_setup(void)
}
}
-void curses_display_init(DisplayState *ds, int full_screen)
+void curses_display_init(DisplayState *ds, CharDriverState *chr, int
full_screen)
{
#ifndef _WIN32
if (!isatty(1)) {
@@ -341,7 +429,7 @@ void curses_display_init(DisplayState *ds, int full_screen)
}
#endif
-curses_setup();
+curses_setup(chr);
curses_keyboard_setup();
atexit(curses_atexit);
diff --git a/vl.c b/vl.c
index d5a1dbc..16c9900 100644
--- a/vl.c
+++ b/vl.c
@@ -172,7 +172,6 @@ BlockDriverState *bs_snapshots;
int vga_ram_size;
static DisplayState display_state;
int nographic;
-int curses;
const char* keyboard_layout
