From: Luiz Capitulino <lcapitulino@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] fbdev: add monitor commands to enable/disable/query
Date: Thu, 27 Jun 2013 09:29:06 -0400 [thread overview]
Message-ID: <20130627092906.31f51f1e@redhat.com> (raw)
In-Reply-To: <51CC0E6D.1000808@redhat.com>
On Thu, 27 Jun 2013 12:05:33 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> Hi,
>
> >> --- a/qapi-schema.json
> >> +++ b/qapi-schema.json
> >> @@ -3608,3 +3608,46 @@
> >> '*cpuid-input-ecx': 'int',
> >> 'cpuid-register': 'X86CPURegister32',
> >> 'features': 'int' } }
> >> +
> >> +##
> >> +# @framebuffer-display:
> >
> > Let me bike-shed: we're trying to make command's names verbs. So, we
> > could call this framebuffer-display-set or maybe have two commands,
> > framebuffer-display-enable and framebuffer-display-disable. I prefer
> > the latter.
>
> Can do that.
>
> >> +#
> >> +# Enable/disable linux console framebuffer display.
> >> +#
> >> +# @enable: whenever the framebuffer display should be enabled or disabled.
> >> +#
> >> +# @scale: #optional enables display scaling, default: off
> >> +#
> >> +# @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.
>
> >> +# 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.
>
> >> +void qmp_framebuffer_display(bool enable,
> >> + bool has_scale, bool scale,
> >> + bool has_device, const char *device,
> >> + Error **errp)
> >> +{
> >> +#if defined(CONFIG_FBDEV)
> >> + if (enable) {
> >> + if (fbdev_display_init(has_device ? device : NULL,
> >> + has_scale ? scale : false,
> >> + errp) != 0) {
> >> + if (!error_is_set(errp)) {
> >> + error_setg(errp, "fbdev initialization failed");
> >
> > You should use error_propagate() in order to propagate the error
> > information filled by fbdev_display_init().
>
> Why? What is wrong with simply passing down errp?
Because errp can be NULL, then you'll be unable to detect errors if
fbdev_display_init() is changed to return void. But you're right you
won't need to propagate errors if you drop the if () test, as you
won't be checking for errors anymore.
>
> > Also, I'd move
> > the generic error_setg() above to fbdev_display_init() and make it
> > return void.
>
> Makes sense indeed.
>
> cheers,
> Gerd
>
next prev parent reply other threads:[~2013-06-27 13:29 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 [this message]
2013-06-27 22:03 ` Eric Blake
2013-06-28 14:26 ` Luiz Capitulino
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=20130627092906.31f51f1e@redhat.com \
--to=lcapitulino@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@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).