| Message ID | 1329695104-15174-2-git-send-email-aliguori@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 02/20/12 00:44, Anthony Liguori wrote: > We want to expose VCs using a VteTerminal widget. We need access to provide our > own CharDriverState in order to do this. /me wonders why you touch vc's at all for this. Doesn't it make alot more sense to just have a -chardev vte (which then opens a new tab in the ui or something simliar)? cheers, Gerd
On 02/20/2012 03:17 AM, Gerd Hoffmann wrote: > On 02/20/12 00:44, Anthony Liguori wrote: >> We want to expose VCs using a VteTerminal widget. We need access to provide our >> own CharDriverState in order to do this. > > /me wonders why you touch vc's at all for this. Doesn't it make alot > more sense to just have a -chardev vte (which then opens a new tab in > the ui or something simliar)? Does it? That's essentially exactly what -chardev vc does today. vc currently works across all UIs (VNC, SDL, etc). It seems a bit odd to me to have to use a different argument for the GTK UI. Regards, Anthony Liguori > > cheers, > Gerd > >
On 02/20/12 14:45, Anthony Liguori wrote: > On 02/20/2012 03:17 AM, Gerd Hoffmann wrote: >> On 02/20/12 00:44, Anthony Liguori wrote: >>> We want to expose VCs using a VteTerminal widget. We need access to >>> provide our >>> own CharDriverState in order to do this. >> >> /me wonders why you touch vc's at all for this. Doesn't it make alot >> more sense to just have a -chardev vte (which then opens a new tab in >> the ui or something simliar)? > > Does it? That's essentially exactly what -chardev vc does today. vc > currently works across all UIs (VNC, SDL, etc). They all use the qemu terminal emulation and render the chars on a displaysurface. > It seems a bit odd to > me to have to use a different argument for the GTK UI. Why is this odd? gtk *is* different, it takes the character stream and sends them off to the terminal emulation widget. That allows to do stuff vc can't handle by design, for example placing vte in a new window instead of a tab so you can watch vga and serial console side-by-side. cheers, Gerd
On 02/20/2012 07:59 AM, Gerd Hoffmann wrote: > On 02/20/12 14:45, Anthony Liguori wrote: >> On 02/20/2012 03:17 AM, Gerd Hoffmann wrote: >>> On 02/20/12 00:44, Anthony Liguori wrote: >>>> We want to expose VCs using a VteTerminal widget. We need access to >>>> provide our >>>> own CharDriverState in order to do this. >>> >>> /me wonders why you touch vc's at all for this. Doesn't it make alot >>> more sense to just have a -chardev vte (which then opens a new tab in >>> the ui or something simliar)? >> >> Does it? That's essentially exactly what -chardev vc does today. vc >> currently works across all UIs (VNC, SDL, etc). > > They all use the qemu terminal emulation and render the chars on a > displaysurface. > >> It seems a bit odd to >> me to have to use a different argument for the GTK UI. > > Why is this odd? gtk *is* different, it takes the character stream and > sends them off to the terminal emulation widget. That allows to do > stuff vc can't handle by design, for example placing vte in a new window > instead of a tab so you can watch vga and serial console side-by-side. This would require touching a fair bit of code that handles things like defaults. I'm not sure that having the distinction makes anything easier to implement. One thing I was contemplating but ultimately didn't do was QOM-ification of the GTK front end. I couldn't rationalize why you would need to set settings but now I think maybe it would be more useful. So I'll take a pass in the next series at QOM-ification. I think I'll stick with 'vc' but this would effectively be only for legacy syntax. Regards, Anthony Liguori > > cheers, > Gerd > >
Hi, > This would require touching a fair bit of code that handles things like > defaults. I'm not sure that having the distinction makes anything > easier to implement. /me suggests to simply have no default terminals with qemu -gtk. > One thing I was contemplating but ultimately didn't do was QOM-ification > of the GTK front end. I couldn't rationalize why you would need to set > settings but now I think maybe it would be more useful. With a vte chardev you have an object you can attach settings to, i.e. -chardev vte,mode={tab,window}. cheers, Gerd
On 02/20/2012 08:27 AM, Gerd Hoffmann wrote: > Hi, > >> This would require touching a fair bit of code that handles things like >> defaults. I'm not sure that having the distinction makes anything >> easier to implement. > > /me suggests to simply have no default terminals with qemu -gtk. > >> One thing I was contemplating but ultimately didn't do was QOM-ification >> of the GTK front end. I couldn't rationalize why you would need to set >> settings but now I think maybe it would be more useful. > > With a vte chardev you have an object you can attach settings to, i.e. > -chardev vte,mode={tab,window}. Right, but you could do the same with QOM, it would look like: GtkDisplay is-a UserInterface (maybe?) has-a GtkVirtualConsole "vc0" has-a GtkVirtualConsole "vc1" ... GtkVirtualConsole could have a "mode" property. So from a UI perspective, you would do something like: -gtk -set /ui/vc0.mode=tab I think it makes more sense overall as a sub-property of the main ui object verses a property of a character device (which is only tangentially related to the UI itself). Regards, Anthony Liguori > > cheers, > Gerd > >
diff --git a/console.c b/console.c index 135394f..d8303af 100644 --- a/console.c +++ b/console.c @@ -1510,7 +1510,7 @@ static void text_console_do_init(CharDriverState *chr, DisplayState *ds) chr->init(chr); } -int text_console_init(QemuOpts *opts, CharDriverState **_chr) +static int text_console_init(QemuOpts *opts, CharDriverState **_chr) { CharDriverState *chr; TextConsole *s; @@ -1555,6 +1555,18 @@ int text_console_init(QemuOpts *opts, CharDriverState **_chr) return 0; } +static VcHandler *vc_handler = text_console_init; + +int vc_init(QemuOpts *opts, CharDriverState **_chr) +{ + return vc_handler(opts, _chr); +} + +void register_vc_handler(VcHandler *handler) +{ + vc_handler = handler; +} + void text_consoles_set_display(DisplayState *ds) { int i; diff --git a/console.h b/console.h index 6ba0d5d..7225ae6 100644 --- a/console.h +++ b/console.h @@ -356,7 +356,6 @@ void vga_hw_text_update(console_ch_t *chardata); int is_graphic_console(void); int is_fixedsize_console(void); -int text_console_init(QemuOpts *opts, CharDriverState **_chr); void text_consoles_set_display(DisplayState *ds); void console_select(unsigned int index); void console_color_init(DisplayState *ds); @@ -364,6 +363,11 @@ void qemu_console_resize(DisplayState *ds, int width, int height); void qemu_console_copy(DisplayState *ds, int src_x, int src_y, int dst_x, int dst_y, int w, int h); +typedef int (VcHandler)(QemuOpts *, CharDriverState **); + +int vc_init(QemuOpts *opts, CharDriverState **_chr); +void register_vc_handler(VcHandler *handler); + /* sdl.c */ void sdl_display_init(DisplayState *ds, int full_screen, int no_frame); diff --git a/qemu-char.c b/qemu-char.c index b1d80dd..4680d3c 100644 --- a/qemu-char.c +++ b/qemu-char.c @@ -2736,7 +2736,7 @@ static const struct { { .name = "socket", .open = qemu_chr_open_socket }, { .name = "udp", .open = qemu_chr_open_udp }, { .name = "msmouse", .open = qemu_chr_open_msmouse }, - { .name = "vc", .open = text_console_init }, + { .name = "vc", .open = vc_init }, #ifdef _WIN32 { .name = "file", .open = qemu_chr_open_win_file_out }, { .name = "pipe", .open = qemu_chr_open_win_pipe },
We want to expose VCs using a VteTerminal widget. We need access to provide our own CharDriverState in order to do this. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- console.c | 14 +++++++++++++- console.h | 6 +++++- qemu-char.c | 2 +- 3 files changed, 19 insertions(+), 3 deletions(-)