qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] fbdev: add monitor commands to enable/disable/query
Date: Fri, 28 Jun 2013 10:26:19 -0400	[thread overview]
Message-ID: <20130628102619.33b744d2@redhat.com> (raw)
In-Reply-To: <51CCB6C4.1020800@redhat.com>

On Thu, 27 Jun 2013 16:03:48 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 06/27/2013 07:29 AM, Luiz Capitulino wrote:
> > On Thu, 27 Jun 2013 12:05:33 +0200
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> > 
> 
> >>>> +# @device: #optional specifies framebuffer device, default: /dev/fb0
> >>>
> >>> Actually, it will try to get the device name from an env variable first,
> >>> which sounds too automatic for a building block API like QMP.
> >>
> >> The env variable is icky indeed.  But a fixed default (which will be the
> >> one you need in 99% of the cases) is fine IMO.
> > 
> > I prefer having no defaults, but I'm not strong about this.
> 
> I also think that letting HMP leave the parameter optional, with
> first-level fallback to the environment variable and secondary fallback
> to the hardcoded /dev/fv0, while making the parameter mandatory in QMP,
> makes more sense.
> 
> > 
> >>
> >>>> +# Since 1.6
> >>>> +##
> >>>> +{ 'type': 'FramebufferInfo',
> >>>> +  'data': { 'enabled': 'bool',
> >>>> +            '*scale' : 'bool',
> >>>> +            '*device': 'str',
> >>>
> >>> Why is device optional?
> >>
> >> When the framebuffer is'nt active you'll get just
> >> { "enabled" : "false" }, thats why the other ones are optional.  They
> >> all are filled in case the framebuffer is active.
> 
> Would it be any simpler to just have the query command fail when the
> framebuffer is disabled, leave out the 'enabled' member from
> FramebufferInfo, and have all the other members mandatory?

I don't think this is correct. First because mngt would have to parse
the error message to learn if the query command really failed or
the framebuffer device is just disabled. Second because the command does
succeed on returning the framebuffer status even when it's disabled.

> Also, would it ever make sense for a future enhancement to allow having
> more than one framebuffer in use by a single domain?  Even if your
> initial implementation supports at most one /dev/fb* device per guest,
> it might be worth having the query-framebuffer command return an array
> of all enabled framebuffers (a 0-length array when none is enabled),

This is also an argument in favor of not having a default device name
in QMP.

  reply	other threads:[~2013-06-28 14:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-26 11:38 [Qemu-devel] [PATCH 1/2] fbdev: add linux framebuffer display driver Gerd Hoffmann
2013-06-26 11:38 ` [Qemu-devel] [PATCH 2/2] fbdev: add monitor commands to enable/disable/query Gerd Hoffmann
2013-06-26 15:56   ` Luiz Capitulino
2013-06-27 10:05     ` Gerd Hoffmann
2013-06-27 13:29       ` Luiz Capitulino
2013-06-27 22:03         ` Eric Blake
2013-06-28 14:26           ` Luiz Capitulino [this message]
2013-06-27 21:55     ` Eric Blake
2013-06-26 15:48 ` [Qemu-devel] [PATCH 1/2] fbdev: add linux framebuffer display driver Luiz Capitulino
2013-06-27  9:58   ` Gerd Hoffmann
2013-06-27 13:23     ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130628102619.33b744d2@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).