Re: [libvirt PATCH] keycodemapdb: update submodule for win32 keycode fix
On 5/5/20 8:58 AM, Daniel P. Berrangé wrote: Fix win32 keycode for VK_OEM_102 Signed-off-by: Daniel P. Berrangé --- src/keycodemapdb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/keycodemapdb b/src/keycodemapdb index 317d3eeb96..27acf0ef82 16 --- a/src/keycodemapdb +++ b/src/keycodemapdb @@ -1 +1 @@ -Subproject commit 317d3eeb963a515e15a63fa356d8ebcda7041a51 +Subproject commit 27acf0ef828bf719b2053ba398b195829413dbdd Reviewed-by: Laine Stump (I didn't look up the win32 virtual-key codes, but there is no other change between the two commits, and everything still builds without error, so...)
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, Mar 12, 2018 at 04:03:59PM +0100, Andrea Bolognani wrote: > On Mon, 2018-03-12 at 14:58 +, Daniel P. Berrangé wrote: > > On Mon, Mar 12, 2018 at 03:53:09PM +0100, Andrea Bolognani wrote: > > > On Mon, 2018-03-12 at 14:46 +, Daniel P. Berrangé wrote: > > > > > The build system doesn't get refreshed automatically after this > > > > > change, so it's still trying to generate virkeycodetable_rfb.h > > > > > and failing because the current version of keymap-gen doesn't know > > > > > about it. > > > > > > > > Perhaps it would be better if I just made 'keymap-gen' continue to > > > > accept 'rfb' as a deprecated alias for 'qnum' > > > > > > That would probably be nice regardless, but it wouldn't really help > > > here - unless we decided to stick with the old name in libvirt too. > > > Are you advocating for doing just that? > > > > No, just take your patch as is. Just fix keymap-gen, so we make the > > (harmless) error message disappear for people with existing checkouts > > that have built the old filename. > > But that still wouldn't work seamlessly, would it? The existing > build system would try to generate virkeycodetable_rfb.h, and > succeed, but the code won't compile because it's looking for > virkeycodetable_qnum.h and related symbols now. The resulting virkeycodetable_rfb.h would never be used - it would only be generated because the automagic .deps files automake creates still list the old filename. In fact on that basis I think we can just ignore the failure - it is self-correcting - automake triggers re-generation of the old filename, and that's non-fatal because we actally use the new filename. So just push your current patch as is Reviewed-by: Daniel P. Berrangé Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, 2018-03-12 at 14:58 +, Daniel P. Berrangé wrote: > On Mon, Mar 12, 2018 at 03:53:09PM +0100, Andrea Bolognani wrote: > > On Mon, 2018-03-12 at 14:46 +, Daniel P. Berrangé wrote: > > > > The build system doesn't get refreshed automatically after this > > > > change, so it's still trying to generate virkeycodetable_rfb.h > > > > and failing because the current version of keymap-gen doesn't know > > > > about it. > > > > > > Perhaps it would be better if I just made 'keymap-gen' continue to > > > accept 'rfb' as a deprecated alias for 'qnum' > > > > That would probably be nice regardless, but it wouldn't really help > > here - unless we decided to stick with the old name in libvirt too. > > Are you advocating for doing just that? > > No, just take your patch as is. Just fix keymap-gen, so we make the > (harmless) error message disappear for people with existing checkouts > that have built the old filename. But that still wouldn't work seamlessly, would it? The existing build system would try to generate virkeycodetable_rfb.h, and succeed, but the code won't compile because it's looking for virkeycodetable_qnum.h and related symbols now. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, Mar 12, 2018 at 03:53:09PM +0100, Andrea Bolognani wrote: > On Mon, 2018-03-12 at 14:46 +, Daniel P. Berrangé wrote: > > > The build system doesn't get refreshed automatically after this > > > change, so it's still trying to generate virkeycodetable_rfb.h > > > and failing because the current version of keymap-gen doesn't know > > > about it. > > > > Perhaps it would be better if I just made 'keymap-gen' continue to > > accept 'rfb' as a deprecated alias for 'qnum' > > That would probably be nice regardless, but it wouldn't really help > here - unless we decided to stick with the old name in libvirt too. > Are you advocating for doing just that? No, just take your patch as is. Just fix keymap-gen, so we make the (harmless) error message disappear for people with existing checkouts that have built the old filename. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, 2018-03-12 at 14:46 +, Daniel P. Berrangé wrote: > > The build system doesn't get refreshed automatically after this > > change, so it's still trying to generate virkeycodetable_rfb.h > > and failing because the current version of keymap-gen doesn't know > > about it. > > Perhaps it would be better if I just made 'keymap-gen' continue to > accept 'rfb' as a deprecated alias for 'qnum' That would probably be nice regardless, but it wouldn't really help here - unless we decided to stick with the old name in libvirt too. Are you advocating for doing just that? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, Mar 12, 2018 at 03:30:33PM +0100, Andrea Bolognani wrote: > On Mon, 2018-03-12 at 14:00 +, Daniel P. Berrangé wrote: > > On Mon, Mar 12, 2018 at 02:29:49PM +0100, Andrea Bolognani wrote: > > > This time around it's not enough to just pick the latest commit, > > > because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb > > > renamed the 'rfb' keycode to 'qnum' and we need to accept the new > > > name while maintaining backwards compatibility. > > > > > > Signed-off-by: Andrea Bolognani > > > > When I apply this I get an error during build due to the rename > > > > Traceback (most recent call last): > > File "./keycodemapdb/tools/keymap-gen", line 1054, in > > main() > > File "./keycodemapdb/tools/keymap-gen", line 1049, in main > > args.func(args) > > File "./keycodemapdb/tools/keymap-gen", line 945, in code_table > > SRC_GENERATORS[args.lang].generate_code_table(args.varname, database, > > args.mapname) > > File "./keycodemapdb/tools/keymap-gen", line 402, in generate_code_table > > mapname, ", ".join(database.mapto.keys( > > Exception: Unknown map rfb, expected one of xorgxwin, osx, qcode, usb, xkb, > > sun, linux, xkbdxt, adb, win32, html, atset1, xorgkbd, atset3, atset2, > > xwinxt, > x11, qnum, xtkbd, xorgxquartz, xorgevdev > > > > > > except that it doesn't actually seem to cause an error - it seems > > to be ignored. I'm not sure why we see this, nor why it isn't > > apparently fatal > > The build system doesn't get refreshed automatically after this > change, so it's still trying to generate virkeycodetable_rfb.h > and failing because the current version of keymap-gen doesn't know > about it. Perhaps it would be better if I just made 'keymap-gen' continue to accept 'rfb' as a deprecated alias for 'qnum' Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, 2018-03-12 at 14:00 +, Daniel P. Berrangé wrote: > On Mon, Mar 12, 2018 at 02:29:49PM +0100, Andrea Bolognani wrote: > > This time around it's not enough to just pick the latest commit, > > because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb > > renamed the 'rfb' keycode to 'qnum' and we need to accept the new > > name while maintaining backwards compatibility. > > > > Signed-off-by: Andrea Bolognani > > When I apply this I get an error during build due to the rename > > Traceback (most recent call last): > File "./keycodemapdb/tools/keymap-gen", line 1054, in > main() > File "./keycodemapdb/tools/keymap-gen", line 1049, in main > args.func(args) > File "./keycodemapdb/tools/keymap-gen", line 945, in code_table > SRC_GENERATORS[args.lang].generate_code_table(args.varname, database, > args.mapname) > File "./keycodemapdb/tools/keymap-gen", line 402, in generate_code_table > mapname, ", ".join(database.mapto.keys( > Exception: Unknown map rfb, expected one of xorgxwin, osx, qcode, usb, xkb, > sun, linux, xkbdxt, adb, win32, html, atset1, xorgkbd, atset3, atset2, xwinxt, x11, qnum, xtkbd, xorgxquartz, xorgevdev > > > except that it doesn't actually seem to cause an error - it seems > to be ignored. I'm not sure why we see this, nor why it isn't > apparently fatal The build system doesn't get refreshed automatically after this change, so it's still trying to generate virkeycodetable_rfb.h and failing because the current version of keymap-gen doesn't know about it. It should work properly again after running 'git clean -xdf'; there might be a way to trigger automatic build system refresh but it didn't look like something worth spending too much time on. > We could simply keep libvirt calling it 'rfb' instead of 'qnum', > but 'qnum' does feel like a saner name Yeah, I think we should try to avoid diverging from whatever naming convention keycodemapdb has adopted. The couple of tweaks that I've made should be enough to ensure existing users keep on working even after the rename. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] keycodemapdb: Update submodule
On Mon, Mar 12, 2018 at 02:29:49PM +0100, Andrea Bolognani wrote:
> This time around it's not enough to just pick the latest commit,
> because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb
> renamed the 'rfb' keycode to 'qnum' and we need to accept the new
> name while maintaining backwards compatibility.
>
> Signed-off-by: Andrea Bolognani
When I apply this I get an error during build due to the rename
Traceback (most recent call last):
File "./keycodemapdb/tools/keymap-gen", line 1054, in
main()
File "./keycodemapdb/tools/keymap-gen", line 1049, in main
args.func(args)
File "./keycodemapdb/tools/keymap-gen", line 945, in code_table
SRC_GENERATORS[args.lang].generate_code_table(args.varname, database,
args.mapname)
File "./keycodemapdb/tools/keymap-gen", line 402, in generate_code_table
mapname, ", ".join(database.mapto.keys(
Exception: Unknown map rfb, expected one of xorgxwin, osx, qcode, usb, xkb,
sun, linux, xkbdxt, adb, win32, html, atset1, xorgkbd, atset3, atset2, xwinxt,
x11, qnum, xtkbd, xorgxquartz, xorgevdev
except that it doesn't actually seem to cause an error - it seems
to be ignored. I'm not sure why we see this, nor why it isn't
apparently fatal
We could simply keep libvirt calling it 'rfb' instead of 'qnum',
but 'qnum' does feel like a saner name
> ---
> include/libvirt/libvirt-domain.h | 9 -
> src/keycodemapdb | 2 +-
> src/qemu/qemu_driver.c | 8
> src/util/Makefile.inc.am | 2 +-
> src/util/virkeycode.c| 8
> tests/virkeycodetest.c | 4 ++--
> tools/virsh-domain.c | 5 +
> tools/virsh.pod | 6 +++---
> 8 files changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/include/libvirt/libvirt-domain.h
> b/include/libvirt/libvirt-domain.h
> index 4048acf38a..4128d55852 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -2733,7 +2733,7 @@ typedef enum {
> VIR_KEYCODE_SET_XT_KBD = 6,
> VIR_KEYCODE_SET_USB= 7,
> VIR_KEYCODE_SET_WIN32 = 8,
> -VIR_KEYCODE_SET_RFB= 9,
> +VIR_KEYCODE_SET_QNUM = 9,
>
> # ifdef VIR_ENUM_SENTINELS
> VIR_KEYCODE_SET_LAST
> @@ -2745,6 +2745,13 @@ typedef enum {
> # endif
> } virKeycodeSet;
>
> +/**
> + * VIR_KEYCODE_SET_RFB:
> + *
> + * Compatibility alias for VIR_KEYCODE_SET_QNUM, which replaced it since
> 4.2.0.
> + */
> +# define VIR_KEYCODE_SET_RFB VIR_KEYCODE_SET_QNUM
> +
> /**
> * VIR_DOMAIN_SEND_KEY_MAX_KEYS:
> *
> diff --git a/src/keycodemapdb b/src/keycodemapdb
> index 267157b96c..16e5b07876 16
> --- a/src/keycodemapdb
> +++ b/src/keycodemapdb
> @@ -1 +1 @@
> -Subproject commit 267157b96c62b5445de9cddd21de42fcd943ffe6
> +Subproject commit 16e5b0787687d8904dad2c026107409eb9bfcb95
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index e13544f832..8c872c1f08 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -2580,17 +2580,17 @@ static int qemuDomainSendKey(virDomainPtr domain,
>
> virCheckFlags(0, -1);
>
> -/* translate the keycode to RFB for qemu driver */
> -if (codeset != VIR_KEYCODE_SET_RFB) {
> +/* translate the keycode to QNUM for qemu driver */
> +if (codeset != VIR_KEYCODE_SET_QNUM) {
> size_t i;
> int keycode;
>
> for (i = 0; i < nkeycodes; i++) {
> -keycode = virKeycodeValueTranslate(codeset, VIR_KEYCODE_SET_RFB,
> +keycode = virKeycodeValueTranslate(codeset, VIR_KEYCODE_SET_QNUM,
> keycodes[i]);
> if (keycode < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR,
> - _("cannot translate keycode %u of %s codeset
> to rfb keycode"),
> + _("cannot translate keycode %u of %s codeset
> to qnum keycode"),
> keycodes[i],
> virKeycodeSetTypeToString(codeset));
> return -1;
> diff --git a/src/util/Makefile.inc.am b/src/util/Makefile.inc.am
> index a91b30dca5..d0e1ec3625 100644
> --- a/src/util/Makefile.inc.am
> +++ b/src/util/Makefile.inc.am
> @@ -214,7 +214,7 @@ EXTRA_DIST += \
> $(NULL)
>
>
> -KEYCODES = linux osx atset1 atset2 atset3 xtkbd usb win32 rfb
> +KEYCODES = linux osx atset1 atset2 atset3 xtkbd usb win32 qnum
> KEYNAMES = linux osx win32
>
> KEYTABLES = \
> diff --git a/src/util/virkeycode.c b/src/util/virkeycode.c
> index eda263218c..8976bbf376 100644
> --- a/src/util/virkeycode.c
> +++ b/src/util/virkeycode.c
> @@ -27,7 +27,7 @@
> #include "virkeycodetable_atset3.h"
> #include "virkeycodetable_linux.h"
> #include "virkeycodetable_osx.h"
> -#include "virkeycodetable_rfb.h"
> +#include "virkeycodetable_qnum.h"
> #include "virkeycodetable_usb.h"
> #include "virkeycodetable_win32.h"
> #include "vir
