On 07/02/2013 14:59, Martin Betak wrote:
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Martin Betak" <mbetak(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, February 7, 2013 1:12:03 PM
Subject: Re: [Engine-devel] engine-config behaviour on -g by alternateKey
On 07/02/2013 12:08, Martin Betak wrote:
> Hi All,
>
> I've been working on the ability to set keyboard layout for VNC server as per
each individual VM. Currently the only option is to use engine-config to set the value
globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to
database and respective entities there were raised valid concerns about why is this option
called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note
that also VDSM calls this config value as 'keyboardLayout').
> So to achieve consistency I also renamed it in engine-config.properties and set
KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting
(engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g
KeyboardLayout works but it is unable to read the value by the alternateKey)
> engine-config -g VncKeyboardLayout fails with "no such entry with default
version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the
user given key name directly to database which returns zero results. Setter methods such
as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given
key-name which correctly constructs appropriate ConfigKey even when given alternateKey
name.
>
> So I wanted to ask whether this is the desired behaviour (set by alternateKey name
but get only by the primary) or is this a bug? I have also simple patch that fixes this
and enables also getting the config value by alternateKey.
>
> Thank you
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>
Make sense that if we allow alternate names for backward
compatibility/etc., -g will work for them as well, so my view is worth
fixing in the config tool.
but, are you sure it affects spice? i thought spice has its own handling
for this.
I traced the appropriate setting to VDSM code which builds the libvirt xml configuration
and it seems that the option VNC/spice is orthogonal to the keyboard layout - i.e. you
chooose your connection type VNC/spice and then you choose your keyboard layout
independently - you can see this exact behaviour in virt-manager for example in the
Display Spice panel. Also the only place where ConfigValues.VncKeyboardLayout is used is
in VmInfoBuilderBase to set a config property called VdsProperties.KeyboardLayout :-)
So should I include the patch for engine-config (very small local change - only 3 lines)
in my current patch
http://gerrit.ovirt.org/#/c/11314/ ?
Thanks
please indent your replies to be easier to see what your reply is.
please check with spice developers, i remember something about in spice
the keyboard layout is handled by spice based on client keyboard layout,
regardless of the qemu parameter.
btw, iirc, qemu now supports enabling both spice an vnc. i think we
should consider enabling both.
and yes, seems like a reasonable patch, but should be a separate one to
yours (yours should depend on it i guess)