On 07/02/2013 14:59, Martin Betak wrote:
----- Original Message -----
From: "Itamar Heim" <[email protected]>
To: "Martin Betak" <[email protected]>
Cc: [email protected]
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
[email protected]
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)
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
