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
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
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
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
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
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 aligu...@us.ibm.com
---
console.c | 14 +-
console.h |6 +-
qemu-char.c |2 +-
3 files changed, 19 insertions(+),
