qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] gtk: Modularize GTK display


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH 2/2] gtk: Modularize GTK display
Date: Wed, 03 Aug 2016 10:26:37 +0200

  Hi,

> +static void (*early_init_fn)(int opengl);
> +static void (*init_fn)(DisplayState *ds, bool full_screen, bool 
> grab_on_hover);
> +
> +void gtk_register_early_init_fun(void *fn)
> +{
> +    assert(!early_init_fn);
> +    early_init_fn = fn;
> +}
> +
> +void gtk_register_init_fun(void *fn)
> +{
> +    assert(!init_fn);
> +    init_fn = fn;
> +}

Hmm, do we _really_ want a ad-hoc interface like this, different for
each and every UI?

I think it would be a good idea cleanup the display init code first,
then go modularize the UIs.  Switch the option parsing to QemuOpts (vnc
and spice already use them).  With that in place the UI init functions
can have identical prototypes (like vnc_init_func).

Which in turn allows to have something like ...

struct ui_driver {
    const char *name;
    int type                           /* DT_FOO */

    QemuOptsList *opts;
    bool is_remote;                    /* vnc, spice */
    bool supports_multiple_instances;  /* vnc */
    bool supports_opengl;              /* sdl2, gtk, spice */

    void (*early_init)(bool initialize_opengl, Error *errp);
    void (*init)(void *opaque, QemuOpts *opts, Error **errp);
}

... and register *that*.

We'll also need to sort how to handle monitor integration best (set
password for spice+vnc, disable/enable/reconfigure vnc, "info
spice", ...).  When starting with the local displays (gtk, sdl) we can
defer that for now though.

Another question is what we want do with sdl1 support.  With UIs built
as module we might be able to allow picking SDL1 or SDL2 at runtime not
compile time.  Need to take care we never try to load both though.  And
maybe we should simply ditch SDL1 support and focus on SDL2 instead.

> diff --git a/vl.c b/vl.c
> index 1a5f807..5705a0a 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4232,9 +4232,19 @@ int main(int argc, char **argv, char **envp)
>          display_remote++;
>      }
>  #endif
> -    if (display_type == DT_DEFAULT && !display_remote) {
> +    if ((display_type == DT_DEFAULT && !display_remote)
> +        || display_type == DT_GTK) {
>  #if defined(CONFIG_GTK)
> -        display_type = DT_GTK;
> +        if (!gtk_mod_init()) {
> +            if (display_type == DT_GTK) {
> +                error_report("GTK could not be initialized, exiting");
> +                exit(1);
> +            }
> +            error_report("GTK could not be initialized, using display None");
> +            display_type = DT_NONE;
> +        } else {
> +            display_type = DT_GTK;
> +        }
>  #elif defined(CONFIG_SDL)
>          display_type = DT_SDL;
>  #elif defined(CONFIG_COCOA)

I think you don't load the gtk module on "qemu -display gtk".

Also with modularizing the UIs the decision which UI to pick as default
effectively moves from compile time to runtime and we need something
more clever than that.  IMHO qemu compiled without gtk and qemu compiled
with gtk but gtk module not installed should behave identical, i.e.
fallback to sdl or vnc instead of using DT_NONE.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]